大数据业内有两个趋势，已经悄悄滋生出来。
两个趋势下，你面临的可能是个无法解决的问题
第一个趋势，是在任何一个公司，甚至是垂直领域的公司，数据量正在剧烈增长，而且数据类型越来越复杂。
我们已经没有办法通过单一、关系型数据库来存储这些数据了。将BI工具配置一下，指向数据存储，马上开始数据业务分析的日子，一去不返了。
事实上，传统的ETL工具栈，也在努力适应企业内现代化的数据格局，只是架构越来越复杂，效率越来越低。如下图所示：
从数据到洞察（灯泡所示），各个环节都需要精密的控制和配合
很多大型公司，已经认识到这种局面，启动了数据治理，希望可以一举扭转这种被动。我们把这个趋势称之为：现代化数据场景与传统数据工具链的不匹配。
然而，事情还没有结束。即使只是这一个挑战，处理起来就已经是按下葫芦浮起瓢了。若是将这个趋势，与另一个趋势相结合的话，只能用“雪上加霜”来形容了！我们来看下大数据的第二个趋势。
这个趋势就是，使用数据的用户，成分越来越多样，比如业务分析师、业务人员、产品经理、营销分析师、算法工程师等等。
这些身份中，很多人并不是数据专家，数据只是他们日常工作的辅助。问题在于，这些人，在日常生活中，都有令人惊叹的数据体验：
- 他们打开智能手机，在两分钟之内，就可以预订旅行行程
- 他们在Google上提出问题，可以在一秒以内得到答案
- 打开抖音，马上就可以找到自己非常感兴趣的视频
在生活中，这部分用户，对这种“数据的即时满足感”印象深刻。当他们回到公司，发现新创建一个可视化报表，从寻找数据源、数据采集、到清洗、到最终完成工作，需要两周、甚至一个月的时候，这种沮丧之情，是可以想象的。
这种与日常数字生活中，用户体验的巨大反差，也给公司解决大数据问题带来了很大的压力：
- 分析师和业务用户，对自助服务的呼声持续增大
- 公司内数据的复杂性，同样日益提升。
很快，你会发现，你面临了一个不可能解决的问题！
如何理解传统数据架构
回头再看下这些技术栈，会发现，多年来，它几乎没有什么改变。
我们看看这些数据。它们存储在不同的地方，倒是使用了越来越多的现代数据技术，如S3，Hadoop，MongoDB，Elasticsearch等等，当然还有关系数据库。
我们看看数据的使用方式。下面是人们在数据分析中常用的工具。如果公司已经到一定规模，那么你还可能同时存在多个工具链（数据链路）来处理数据：
- 通过自助式BI工具Tableau、Power BI来可视化探索数据，得到洞察结论。
- 使用Excel，进行基本的数据处理和分析
- Python和R，最好配有Jupyter等主流的NoteBook工具，这是数据科学家更偏好的工具
- SQL工具，这个当然也必不可少了
注意：我有意的不把ETL工程师和数仓工程师加进来，因为他们对数据的价值没有主张，是赋能业务线的。
可以看到，不同角色和背景的员工，倾向于使用不同的工具来处理和分析数据。
我们再看看团队间如何协同的。数据使用方非常依赖IT。
- 比如数仓内没有的数据，分析师只能向数仓团队提需求，然后等待数仓团队按照自己的优先级来处理
- 面对未被采集的数据源，数仓工程师只能向IT团队提需求，然后等待IT团队按照自己的优先级来处理
- …也许一个月后…，数仓工程师把数据清洗并建模后，放到数仓某个地方了
- 分析师从数仓找到他们需要的数据，并可以通过BI工具进行后续工作了
上面三个方面构成的工作模式，我们称之为传统的数据架构， 那么他在现代化的企业中，有什么问题呢？
传统数据架构面对的问题与分析-如何逐步演变成劳动密集型工种的
数据链路的维护是灾难
首先通过ETL工具，把数据转移到一个特定区域里，通常是Hadoop集群、云存储、S3等数据湖中。当然，这个工作是需要很多人、很多数据处理脚本来完成的。
如果上游的数据源发生变化，比如，业务同学在Mysql数据表中添加了字段，下游数据该怎么做呢？是维持不变，还是自动的添加上这些新的字段呢？这都是需要考虑的问题。
因此，只是维护该数据链路的正常运行，就已经是一个非常具有挑战的工作了。
大数据已经是人力密集型行业了
数据副本是灾难
大家都知道，直接在数据湖上进行分析，通常情况下都很慢。
一般都是通过ETL，把部分数据（可能是过去30天或某些聚合级别数据）放入数据仓库中，如基于云的Redshift，也可能是Teradata，Vertica，Oracle，SQL Server等非云环境。
这些都是专用系统，昂贵不说，能否提供BI用户想要的性能，还需要画个疑问号。
为了解决上面的问题，一般会引入一个额外的数据产品层-多维数据集（CUBE）。通常的做法是，在数据仓库中预先聚合数据：
- 创建一个新表，用于存储聚合级别的数据集，比如通过会话ID或城市来进行数据的预聚合（sum、count等）。
- 将数据导出到BI系统中，这份数据，是专门给此BI工具使用的。
最后才发现，你为大数据支付了巨大的费用：
- 在基础设施上。公司的每个数据都有10余个副本，无形中需要使用更多的机器。
- 数据管理的复杂性提升。当你拥有大量数据副本时，数据最终会出现不一致。 在受监管的行业或公司，不同版本不一致而提供不同的结果，会被罚款或处罚。
- 引入安全风险。这些零散的数据副本，由不同部门、不同角色的用户来创建和管理，增加了数据泄露和非法访问的可能性
既有架构上，无法构建大数据的自助服务
基于上面的事实，在目前既有的数据架构上，是无法构建起自助服务的：
- 不同的数据存储在不同的系统、不同类型的结构中，最终的Tableau/PowerBI用户面临巨大困难
- 用户不知道他们需要去哪里找到数据。比如销售数据，如果它只是一个非常简单的销售数据分析，就可以直接去使用那个多维数据集；若打算与网站的会话数据联合分析，就没有那么简单了。
- 没有办法解决跨数据源的数据分析。此时，只有依赖数据仓库。
- 在传统数仓场景下，数据使用方过度依赖数仓和IT。正如上面的分析，不同团队有自己的做事方式和优先级，数据消费链路上的强依赖，导致工作效率低到不可忍受
上述这种非常繁琐、过度依赖的工作模式，已经维持了至少10年，基本上没有改变过。如果想让公司变成数据驱动，那么这套传统数据架构，已经不得不调整了。
我们呼吁：把数据使用的权利真正赋予数据公民，使那些通过BI工具、机器学习的员工，可以自给自足的完成工作。当然，这种自助的工作方式，需要在公司的管理和安全控制下。
传统与现代数据架构
把数据使用权真正赋予数据公民
有了上面的分析，我们就可以看看什么样的数据架构，是用户需要的。
首先，它必须支持任何数据源，但又允许以统一的方式访问。解决传统ETL带来的问题的有效办法，就是省去ETL。
大多数公司，都拥有许多不同的数据源，比如mysql、Elasticsearch。同时，必须适用于任何主流的分析工具，如Tableau、MicroStrategy、Excel和Python等等。
如果没有数据仓库和cube，世界将变得更加美好。当然，不可能在一天之内摆脱所有这些，但必须有一个更好的方法，没有人真的喜欢管理这些。
其次，我们深信，甚至崇拜，自助服务和协作。这是现代数据体系必备的能力：
- 自助服务，是在数据消费链路的自助
- 协同，是专家准备数据、产品团队准备产品层面的协同。
再次，性能是所有这一切的关键。如果你做的东西不够快，就没有人愿意在它上面浪费时间。
如果你曾经在大数据基础上，使用过各种BI，并且需要十分钟才能看到查询结果，那就说明，这套架构是有问题的。
即使对于最大的数据集，甚至是数PB和数十亿条记录，我们也必须能够提供一到两秒的交互式体验。
最后，我们认为它必须是开源的。任何类型的数据基础架构，或分析技术都需要是开源的。任何公司不希望被绑死。同时，这也是构建健康的生态系统所需要的。
基于上面的分析，我们已经认清了，什么样的数据架构，才是数据消费者所需要的。那么如何构建这个数据体系呢？
面向自服务的数据架构
数据消费者，需要的不仅仅是服务的自助化，本质上，更是数据的自助化，即自服务的数据。
我们在数据工作栈中，引入一个数据抽象层，来解决数据自助服务的问题。这个抽象层架起数据本身与工具之间的桥梁。
需要使用数据的人，通过这个抽象层，可以获得它所需要的任何基础能力。比如：
- 对于数据使用者，可以通过数据地图查找数据、通过桌面工具来探索数据、通过BI工具来分析数据。
- 对于数据专家，即使是非技术的业务专家，也可以方便的萃取数据，生成一个新的数据集，即“虚拟数据集”
这个数据抽象层，即自服务的数据架构，从物理层上来看，它需要提供如下的能力：
- 可以连接到不同的数据源，并执行查询请求
- 可以跨数据源执行联合查询，并进行查询的加速。
查询的加速，对于自服务的数据架构来说，是至关重要的。可以想象一下，即使面对PB级别的数据，业务人员还是想以交互的方式得到查询结果。也就是说，响应速度不能超过几秒钟。
如何实现一个自服务的数据架构呢？
现代化自服务的数据架构
从架构上来说，它需要包含如下的组件：
- 数据集管理。数据集可以理解为虚拟的数据，主要是解决传统ETL的问题。它不会生成数据备份，没有数据冗余和不一致。同时，也不占用额外的存储资源。
- 数据萃取。通过虚拟数据集的能力，实现数据变换，逻辑复用。
- 数据查找。通过数据地图提供数据的检索能力、元数据完善能力。由于数据集具有很强的规范性，因此可以轻易的根据数据血缘，找到数据的依赖、数据的使用方式
- 查询加速。采用了一套独立的数据加速层，可以称之为 “Data Reflections”，它类似于物化视图。通过Reflections，数据专家就有能力干预查询的加速了。数据查询加速和数据建模过程是统一的，他们合二为一。
相比于传统的数据服务优化，我更强调数据的优化，通过对数据服务和数据双向的优化，来提供协作和自助服务能力。
再强调一次，目前大部分的做法，是把注意力放在工具的优化上。短期来看，可能有效果，但是它不解决根本问题。我们需要从数据的角度，重新审视大数据当前面临的问题，在优化工具的同时，对数据本身进行架构的优化，才有可能解决当前企业快速发展和数据驱动中，面临的问题。
“数据分析”、“数据分析师”这些词很有误导性，它让人认为，分析的目标是数据本身。叫“业务分析”可能好点，它至少会让人把焦点放到业务本身，数据是它的支撑。
注：Dremio是上述数据架构的一个参考实现。文中部分图片来自Dremio。
