数据湖（五）

数据湖建设的基本过程

个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的TCO。

数据湖的建设过程应该与业务紧密结合；但是数据湖的建设过程与传统的数据仓库，甚至是大热的数据中台应该是有所区别的。区别在于，数据湖应该以一种更敏捷的方式去构建，“边建边用，边用边治理”。为了更好的理解数据湖建设的敏捷性，我们先来看一下传统数仓的构建过程。业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式，分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了，不然可以再写出几百页，这里只简单阐述基本思想。

1）Inmon提出自下而上（EDW-DM）的数据仓库建设模式，即操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层；ODS层中的数据，根据预先设计好的EDW（企业级数据仓库）范式进行加工处理，然后进入到EDW。EDW一般是企业/组织的通用数据模型，不方便上层应用直接做数据分析；因此，各个业务部门会再次根据自己的需要，从EDW中处理出数据集市层（DM）。

优势：易于维护，高度集成；劣势：结构一旦确定，灵活性不足，且为了适应业务，部署周期较长。此类方式构造的数仓，适合于比较成熟稳定的业务，例如金融。

2）KimBall提出自顶而下（DM-DW）的数据架构，通过将操作型或事务型系统的数据源，抽取或加载到ODS层；然后通过ODS的数据，利用维度建模方法建设多维主题数据集市（DM）。各个DM，通过一致性的维度联系在一起，最终形成企业/组织通用的数据仓库。

优势：构建迅速，最快的看到投资回报率，敏捷灵活；劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。常应用于中小企业或互联网行业。

其实上述只是一个理论上的过程，其实无论是先构造EDW，还是先构造DM，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”，都逃不出下图所示的基本建设过程。

图22. 数据仓库/数据中台建设基本流程

1） 数据摸底。对于一个企业/组织而言，在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等。在这个阶段一个隐含的重要工作是借助数据摸底工作，进一步梳理企业的组织结构，明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础。

2） 模型抽象。针对企业/组织的业务特点梳理归类各类数据，对数据进行领域划分，形成数据管理的元数据，同时基于元数据，构建通用的数据模型。

3） 数据接入。根据第一步的摸排结果，确定要接入的数据源。根据数据源，确定所必须的数据接入技术能力，完成数据接入技术选型，接入的数据至少包括：数据源元数据、原始数据元数据、原始数据。各类数据按照第二步形成的结果，分类存放。

4） 融合治理。简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理，形成各类中间数据/结果数据，并妥善管理保存。数据湖应该具备完善的数据开发、任务管理、任务调度的能力，详细记录数据的处理过程。在治理的过程中，会需要更多的数据模型和指标模型。

5） 业务支撑。在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务。

上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很多情况下，业务是在试错、在探索，根本不清楚未来的方向在哪里，也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起，这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。

数据湖应该是一种更为“敏捷”的构建方式，我们建议采用如下步骤来构建数据湖。

图23. 数据湖建设基本流程

对比图22，依然是五步，但是这五步是一个全面的简化和“可落地”的改进。

1） 数据摸底。依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是，也就需要做这么多了。数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计。

2） 技术选型。根据数据摸底的情况，确定数据湖建设的技术选型。事实上，这一步也非常的简单，因为关于数据湖的技术选型，业界有很多的通行的做法，基本原则个人建议有三个：“计算与存储分离”、“弹性”、“独立扩展”。建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。

3） 数据接入。确定要接入的数据源，完成数据的全量抽取与增量接入。

4） 应用治理。这一步是数据湖的关键，我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看，数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手，在应用中明确需求，在数据ETL的过程中，逐步形成业务可使用的数据；同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储，强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反，对业务的理解与抽象，将极大的推动数据湖的发展与应用，数据湖技术使得数据的处理与建模，保留了极大的敏捷性，能快速适应业务的发展与变化。

从技术视角来看，数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（对机器学习的支持，可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式，并提供了对应的集成开发环境。对于流式计算的支持，目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前，我们先对流计算做一个分类：

1） 模式一：实时模式。这种流计算模式相当于对数据采用“来一条处理一条”/“微批”的方式进行处理；多见于在线业务，如风控、推荐、预警等。

2） 模式二：类流式。这种模式需要获取指定时间点之后变化的数据/读取某一个版本的数据/读取当前的最新数据等，是一种类流式的模式；多见于数据探索类应用，如分析某一时间段内的日活、留存、转化等。

二者的本质不同在于，模式一处理数据时，数据往往还没有存储到数据湖中，仅仅是在网路/内存中流动；模式二处理数据时，数据已经存储到数据湖中了。综上，我个人建议采用如下图模式：

图24 数据湖数据流向示意图
如图24所示，在需要数据湖具备模式一的处理能力时，还是应该引入类Kafka中间件，作为数据转发的基础设施。完整的数据湖解决方案方案应该提供将原始数据导流至Kafka的能力。流式引擎具备从类Kafka组件中读取数据的能力。流式计算引擎在处理数据过后，根据需要，可以将结果写入OSS/RDBMS/NoSQL/DW，供应用访问。某种意义上，模式一的流计算引擎并非一定要作为数据湖不可分割的一部分存在，只需要在应用需要时，能够方便的引入即可。但是，这里需要指出的是：

1）流式引擎依然需要能够很方便的读取数据湖的元数据；

2）流式引擎任务也需要统一的纳入数据湖的任务管理；

3）流式处理任务依然需要纳入到统一的权限管理中。

对于模式二，本质上更接近于批处理。现在许多经典的大数据组件已经提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等经典的计算引擎。以HUDI为例，通过支持特殊类型的表（COW/MOR），提供访问快照数据（指定版本）、增量数据、准实时数据的能力。目前AWS、腾讯等已经将HUDI集成到了其EMR服务中，阿里云的DLA也正在计划推出DLA on HUDI的能力。

让我们再回到本文开头的第一章，我们说过，数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在线业务，严格来看，并非数据湖目标用户的刚需。但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分，而数据湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力，可以很方便的进行扩展，整合流式计算能力。

5） 业务支撑。虽然大多数数据湖解决方案都对外提供标准的访问接口，如JDBC，市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据。但是在实际的应用中，我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去，能够让应用有更好的体验。