走向现代化数据分析架构：趋势与挑战 原创 精华

本文是网易副总裁、网易杭州研究院执行院长、网易数帆总经理汪源在ArchSummit 全球架构师峰会的演讲实录，分享对数据分析技术相关的趋势的观察和思考。文末附演讲PPT下载。

当前在数据分析领域新的名词和新的方向是非常多的，所以有很多的客户比较困惑：有这么多的新方法、新趋势，我看得眼花缭乱，怎么办？我提炼出我认为最主要的三条主线，这些主线都是在发展过程中，当前并没有非常高的成熟度，但是我觉得是最值得关注的。

数据分析领域的发展与新概念

数据分析领域的方法论层出不穷，最核心的是上个世纪90年代形成的一系列分析方法，直到今天还是我们使用的最主要的方法。比如1993年由图灵奖获得者Edgar Frank Codd在一篇文章所提出的OLAP与多维分析的概念，由Bill Inmon和Ralph Kimball两位大师级人物提出的“数据仓库”的整套比较规范的建设方法。BI的概念也在90年代开始盛行开来。另外还有数据治理、主数据管理、数据挖掘等概念。

 

最近20年，方法论的创新不是特别多，但是技术体系的进步非常大。有一个技术底座上很大的进步，就是大数据或者说数据湖的一套体系，分为几个主要模块，在最底层是低成本的分布式存储技术，包括在私有环境下部署的HDFS文件系统，在云端主要是对象存储。在计算层发展了MapReduce框架，包括Spark也还是在MapReduce框架之内，在调度层有YARN和K8s。非常核心的一点是这个行业形成了一个标准并且开放的数据格式，最典型的代表就是Parquet，它既可以表达结构化的数据，也可以有效表达半结构化的数据，比如JSON这种嵌套式的结构，也可以转化成Parquet格式。所有的上层应用都会和Parquet格式衔接，所以在这之上又形成了像Hive MetaStore（HMS）这样的体系规范Catalog，还有优秀的SQL引擎，像Impala、SparkSQL、Presto。

 

 

这个体系完全基于开放的技术和标准，这些标准并非由某个单位制定，而是事实上的标准。如果Hadoop相应的技术体系要用传统的商业化产品如Oracle、Teradata等去满足，成本会特别高。这个体系可能是过去20年在基础侧所产生的最大成就。

 

过去20年我们在流计算也形成了非常成熟的基础产品。比如说传输方面有Kafka和Pulsar，在计算方面有Flink，当然早期还有Storm，现在已经基本被淘汰。最近20年在应用场景上盛行各类机器学习相关的应用，我们有个性化推荐、搜索、精准广告、风控、量化交易等，这在20年前是比较少的，虽然与机器学习相关的数据挖掘在30年前被提出来了，但是机器学习真正盛行起来是在这20年。

 

现在数据分析领域相关的概念，有很多而且很杂，经过30年的发展，可能又进入到一个比较混乱的状态。比如说我日常最关注的一些概念，Lakehouse（湖仓一体），刚刚看到它在InfoQ技术采用生命周期已经进入晚期大众阶段。Data Fabric、Data Mesh被列在最左边的早期采用者阶。有一些厂商死活跟一个词过不去，叫ETL，并且产生了一系列的跟它相关的词。有的说我们不做ETL了，要做ELT；有的说我做AutoETL，甚至有的宣传我可以NoETL；还有反向ETL，就是把数仓里面分析的结果又灌到业务系统里面去。

 

还有很多词在刚才的曲线中还没有出现过，欧美讨论比较多。其中一个是Semantic Layer（语义层）。大概是在1991年，Business Objects(BO)在还没有被SAP收购的时候，就提出了Semantic Layer的概念。后来这个词不温不火，最近两三年突然又火起来了，不少创业公司都宣称自己是在做一个Semantic Layer产品。有些叫得朴实一点，说做的是Metric Layer（指标层）。还有一些把自己定位成HeadlessBI，没有头的BI，它不带展示和交互层，但是可以做语义的建模，可以定义好规范的管理。另外，我们国内最近五年一直在讨论的是数据中台、DataOps、数据虚拟化。

 

这些词都是当下数据分析领域经常看到的，这些词应该怎么梳理和整合呢？接下来就是我的核心观点：现代化数据分析领域主要发展趋势是三大主题，这三大主题我都用“统一”这个词来描述，我认为大家追求的是怎么样做一个统一的基础设施，怎么样做一个统一的中间层，怎么样做统一的数据资产。我也希望整个行业能够往这些方向去聚焦，不要产生太多的相互割裂的概念。

统一的基础设施

第一个是统一的基础设施。比较理想的统一的基础设施，是一个流式湖仓的基础设施——湖仓和流批都一体之后，我们把它称为流式湖仓——它的实现现在开始出现了非常扎实的基础，你不能说它是非常的完善，但是至少是可用的成熟度。这里面除了最底层的对象存储是各个云厂商提供的，其他的都是开源的技术。我们整个文化一直围绕开源的技术，这里面有一些项目就是由我们自己研发之后开源共享出来的。

 

我认为整个统一的基础设施已经形成了六层架构，如果加上元数据就是七个模块的架构。最底层还是存储层，然后是Parquet文件格式层，中间加了缓存加速层，用来弥补上层需求和底层对象存储之间的性能差距，现在出现的有Alluxio、JuiceFS、CurveFS，其中CurveFS是我们开源出来的一个平台，它能够做同样的工作。

 

 

最核心的是在最近两三年我们整个行业中出现了两个新的层次，一个是表格式（table format），一个是表服务（table service），这两个层次能够解决底层大数据体系怎样做到满足湖仓一体、实时更新、版本一致性、ACID等等，之前的大数据没有这样的功能，所以它无法做一些实时的分析服务，只能做T+1的分析。这两个层次可以看到有Iceberg、Arctic、Hudi等。最上层是分析引擎层。

 

Iceberg是Netflix团队开源出来的，我认为它是现在社区里面最有希望成为table format标准的项目。跟它竞争的还有Hudi(Hadoop Upsert anD Incremental)，Hudi最近迫于竞争压力，也把它的table format开放出来的。原来的数据湖三剑客，Delta Lake、Iceberg和Hudi里面，Hudi是一个相对封闭的体系，它的table format是不开放的。

 

Iceberg从数据层面提供了ACID的能力，并且可以读到任何时间点的数据；第二个从元数据层面解决了HMS性能瓶颈，把原来集中式的元数据变成了分布式的元数据，并且相当于给数据构建了一个多级的索引，能够支持高级过滤，这能解决很多问题。很多时候在大数据的体系中，一个query所需要touch的文件数字非常多，可能是几千万、几亿，甚至更多的文件。那么这个query在准备的时候需要去读取哪些文件？我们在自己的场景中之前用Hive技术，一个query启动要花20分钟——它还没有开始跑，只是为了分析清楚到底哪些数据是需要读取的。Iceberg可以把这个性能直线降低至不到一分钟，这是一个非常夸张的进步。

 

第二个比较核心的项目是Arctic，这是我们在8月份的时候开源的一个项目，但这个项目在网易数帆内部研发已经将近三年的时间了。Arctic主要用来帮助Iceberg把整体的技术体系构建完整，因为Iceberg只是一种格式，但是怎样利用这种格式把它组织成面向分析性能最优化的状态，它是不管的，所以我们在Arctic中主要提供了自优化的能力。我们提供了一个基于Iceberg的自优化的机制，并且我们提供了upsert的功能，也就是说支持高效的数据更新。

 

另外我们做到流批一体，一张流表和一张批表的定义是一致的，可以复用。最后为了让这个技术快速落地，我们是可以兼容Hive和Iceberg，一张Hive的表，你不需要做任何动作可以无缝升级成Arctic表，不需要做数据迁移。

 

我认为Iceberg+Arctic在新的技术栈里面处于核心的位置。在老的技术栈中，Parquet是一个开放的文件格式，HMS是大家公认的元数据的服务。在这Parquet和HMS下面有不同的存储体系，还有不同的计算体系，它们两个是唯一的标准，基本上没有别的选择。到今天由Iceberg和Arctic共同构建的这一层会成为一个新的事实的标准，在它下面有很多不同的存储，在它上面有不同的计算体系。这个中间基本上胜出的只有一家，不可能有多家，否则这个技术栈就混乱了。我们目前看好的是Iceberg+Arctic这条路，其实之前我们非常看好Iceberg的发展，所以就做了一个跟它配套的项目Arctic。

 

 

小结一下，统一的基础设施解决的四大问题，第一是湖仓一体，第二是流批一体，第三是标准格式，不仅是文件格式，还包括表格式，最后是实现存算分离。

统一的中间层

第二个话题是统一的中间层。一提到中间层我们就想到ETL，现在很多人想灭掉它。这张图来自从蚂蚁金服出来创业的Aloudata团队，原来大家设想数据从数据源经过ETL进入到数仓再到BI，但实际上如同这张图所画，ETL环节是无所不在的。

 

 

为什么会有ETL呢？所谓的ETL就是一个把原始数据转化成分析所需要的好用的数据的过程。理想的状态下，很多理论大师们给我们规划了一条路线，在数据仓库里面做好了所有的数据转化，每一个团队用很好的BI工具，应该只做数据的展现和交互，所有的计算逻辑应该都在数仓里面完成，或者说最多再加一个数据集市——数据集市其实也可以认为是数据仓库大体系的一部分。但实际上大家会发现每一个团队都会在自己的BI里面又去做了很多的计算逻辑，因为数据仓库的计算逻辑不够用，导致一个很大的问题就是分散的计算逻辑。大家在不同的BI产品中看到的数据口径是不一样的，结果也是不一样的，就是由分散的计算逻辑带来的。

 

 

怎么样解决这个问题呢？有很多的方案，我把它们分为中国方案、国际方案和我们的方案。中国方案就是数据中台，要做到OneData、OneService、OneID，解决指标口径不一致的问题，所有的口径定义、计算逻辑都应该在中台里面做好。数据中台大致有这么几个模块，包括了数据仓库（我认为典型的数据中台是包括了数据仓库这一层）。在数据仓库定义了一套规范的指标层，包括原始指标、派生指标、复合指标，派生应该是原始指标加上时间周期加上修饰词等等。上面是数据服务层，对外提供所有对外的数据。同时又引入了数据治理的概念来保证中台输出的数据是高质量的，是符合安全要求的。

 

 

国际方案没有这么复杂，只有三个核心的概念：Semantic Layer、HeadlessBI和Metric Layer。它们其实是近义词，不同的公司有不同的叫法。有一些公司年头比较长了，比如GoodData，最近宣传自己是Semantic Layer公司。Kyvos宣称给印度政府建了全球最大的数据平台，之后做了很多相关的产品。

 

国际方案里面最贴切的描述是HeadlessBI，我引用了其中一个产品叫Cube，下图来自Cube官网，数据输入来自左边的各种数仓，它在HeadlessBI这一层要做的是数据建模、安全相关的访问控制、性能加速，最后以API的方式提供给右边的下游消费者，主要是BI工具，以及一些数据产品中内嵌的展示，也就是嵌入式的分析。

 

 

我们在这个方向也做了一点贡献，思路和大家不太一样。我们强调的是开发和治理一体化，让指标、模型等等持续保持高质量。大致的产品设计逻辑，是我们在建数仓、建指标这些开发活动的过程中，同步把数据治理的活动也做掉了。这是因为我们发现有很多客户，先找开发的厂商来做开发，做完之后发现数据质量不太行，又去找数据治理的厂商来做数据治理的项目。我们认为可以把开发和治理做到一体化，在开发环节同时把开发治理做好了，就不会有后遗症了。

 

 

最终，我们希望会产生这样一个统一的中间层，包括数据仓库和HeadlessBI两层，后者能做建模，包括指标，做权限、加速和服务，同时把开发和治理一体化了，没有单独的数据开发和数据治理相关的模块。所以它的目标就是通过统一的模型指标计算逻辑和口径，实现事前事中事后的持续治理。这个时候BI层才可以真正的聚焦在展现和交付上，这一层BI我命名为NecklessBI，底下的HeadlessBI是无头BI，上面是只有头没有脖子的BI。

 

 

最后再说一下ETL。我认为ETL是不会被消除的，它只能被转移或隐藏，因为从数据源到分析所需要的数据一定是有很多不匹配的，数据源在设计的时候不会考虑到为了分析需求设计的，所以说ETL是一定会有的。但是比较现实的是做ETL的自动化，比较低调一点叫AutoETL，高调的NoETL其实也是AutoETL。HTAP这个场景的应用可能有限，大量的分析工作要做多源数据的整合，HTAP在这个过程中发挥不了太多的作用。

统一的数据资产

最后是统一的数据资产。我们企业做数据分析的时候面临很多的问题，不是有强大的算力就可以了，有很多资产管理不到位带来的问题，比如说数据找不到，找到了看不懂，看了之后信不过、不敢用，因为不知道数据质量；最后从企业管理层的角度，他觉得这么多的数据管不牢。这都是在数据资产相关领域面临的很大的问题，之前建数据中台也是希望解决类似的问题，但我认为这主要还是数据资产管理的问题。

 

我看到了一个比较可行的思路就是Data Fabric，它的目的是实现数据的整合利用，它是一个架构思想或者设计理念，并不绑定一个特定的技术实现。Data Fabric强调元数据要集中管理，但是从数据本身可以兼容各种风格数据的处理手段，我们可以用ETL的方式来做Data Fabric，也可以用虚拟化的方式来做。当然我个人认为如果用ETL和数据仓库的方式来做Data Fabric，那么Data Fabric的优势就发挥得就没有那么明显。

 

 

其他几个做数据整合利用的方式的区别，第一个是数据仓库或者数据中台，比较强调数据的集中，同时也强调数据比较深度的预加工，数据仓库就是要对数据进行深度的预加工。第二个是数据湖，强调数据的集中，但是它强调数据不要做太多的预加工，应该按照原始的数据格式都存在湖里面，需要的时候再把它拿出来处理。Data Fabric是强调元数据的集中。

 

Data Fabric的实际落地需要构建四个方面的核心能力：

一是连接数据源，连接各种各样的数据源。比如一些产品更新以后，数据暴露的方式变了，我们再连接花了不少的时间。所以连接数据源是一个非常复杂和非常关键的能力，很多产品目前在这方面做得还不是特别好。

 

 

二是元数据的管理，要做到主动元数据（active metadata）。因为最传统的元数据是要靠手工登记注册的，这种情况下要管理企业的数据资产，工作量是非常大的，而且也很容易导致阶段性做元数据管理，而不是项目验收的时候元数据注册很好，结果项目验收完了，手动注册的元数据就跟不上变化。主动元数据可以主动地扫描这些数据源的数据变化，通过智能化的识别、知识图谱相关的技术帮助我们理解元数据和数据之间的关系。

 

三是数据虚拟化，我认为数据虚拟化能最大程度发挥Data Fabric的能力，因为它能够在数据没有完成集中之前就能够做一定程度的利用，当然它的天花板可能也不是太高，你不能假设所有的数据分析都可以基于数据虚拟化来做。

 

四是我们做的逻辑数据湖，也是Data Fabric的一种实现。逻辑数据湖从逻辑上看是一个湖，但是从物理实现上数据位置还是分散的，还是存在Hadoop、Oracle、MySQL里面。

总结

最后简要总结，现代数据分析技术的三大主题，第一个是构建一个统一的基础设施，这个基础设施能够支撑数据的实时的更新和消费，它本身又是一个开放的、低成本的体系，我们命名为流式湖仓。第二个是统一的中间层，要做到统一的模型、指标、计算逻辑和口径，另外要做到事前事中事后持续的数据治理，它的组成部分包括了数据仓库和HeadlessBI这两个层次。第三个是统一的数据资产，它的目的是要做企业全域数据资产的高效的发现、整合和管理，它在实现上能够兼容各种风格的数据处理技术，核心的概念有很多分析机构提倡的Data Fabric，我们也提供了称为逻辑数据湖的Data Fabric实现。

我今天的分享就到这里，谢谢大家！