一、什么是数据湖

关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。

1、 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。

2、 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。

3、 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。

4、 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。

5、 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。

6、 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。

7、 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。

8、 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。

综上，数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

图1. 数据湖基本能力示意

这里需要特别指出两点：

1、可扩展是指规模的可扩展和能力的可扩展，即数据湖不但要能够随着数据量的增大，提供“足够”的存储和计算能力；还需要根据需要不断提供新的数据处理模式，例如可能一开始业务只需要批处理能力，但随着业务的发展，可能需要交互式的即席分析能力；又随着业务的实效性要求不断提升，可能需要支持实时分析和机器学习等丰富的能力。

2、以数据为导向，是指数据湖对于用户来说要足够的简单、易用，帮助用户从复杂的IT基础设施运维工作中解脱出来，关注业务、关注模型、关注算法、关注数据。数据湖面向的是数据科学家、分析师。

二、数据湖的基本特征

对数据湖的概念有了基本的认知之后，我们需要进一步明确数据湖需要具备哪些基本特征，特别是与大数据平台或者传统数据仓库相比，数据湖具有哪些特点。

在数据方面：

1、“保真性”。数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。

2、“灵活性”： “写入型schema” v.s.“读取型schema”，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。对于任何数据应用来说，其实schema的设计都是必不可少的，即使是mongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。“写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。

数据湖强调的“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。

3、“可管理”：数据湖应该提供完善的数据管理能力。既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。

4、“可追溯”：数据湖是一个组织/企业中全量数据的存储场所，需要对数据的全生命周期进行管理，包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现，需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的，能够清楚的重现数据完整的产生过程和流动过程。

在计算方面：

1、丰富的计算引擎。从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。一般情况下，数据的加载、转换、处理会使用批处理计算引擎；需要实时计算的部分，会使用流式计算引擎；对于一些探索式的分析场景，可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力。

2、多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。

三、数据湖基本架构

在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产进行长期的原样存储；进行有效管理与集中治理；提供多模式的计算能力满足处理需求；以及面向业务，提供统一的数据视图、数据模型与数据处理结果。

数据湖就是在这个大背景下产生的，除了大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：数据接入、数据搬迁、数据治理、质量管理、资产目录、访问控制、任务管理、任务编排、元数据管理等。如下图所示，给出了一个数据湖系统的参考架构。对于一个典型的数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力，能提供多模式的数据处理能力；增强点在于数据湖提供了更为完善的数据管理能力，具体体现在：

1、更强大的数据接入能力。数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。

2、更强大的数据管理能力。管理能力具体又可分为基本管理能力和扩展管理能力。基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的，后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。

3） 可共享的元数据。数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。

图5. 数据湖组件参考架构

还有一点应该指出的是，上图的“集中式存储”更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。

我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如图6所示。理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。

图6. 数据湖中的数据生命周期示意

四、数据湖建设的基本过程

数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的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，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括“数据中台”，都逃不出下图所示的基本建设过程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图9. 数据湖数据流向示意图

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

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

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

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

对于模式二，本质上更接近于批处理。现在许多经典的大数据组件已经提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等经典的计算引擎。以HUDI为例，通过支持特殊类型的表（COW/MOR），提供访问快照数据（指定版本）、增量数据、准实时数据的能力。

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

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

五、总结

数据湖作为新一代大数据分析处理的基础设施，需要超越传统的大数据平台。目前在以下方面是数据湖解决方案未来可能的发展方向。

1、云原生架构。关于什么是云原生架构，众说纷纭，很难找到统一的定义。但是具体到数据湖这个场景，个人认为就是以下三点特征：（1）存储和计算分离，计算能力和存储能力均可独立扩展；（2）多模态计算引擎支持，SQL、批处理、流式计算、机器学习等；（3）提供serverless态服务，确保足够的弹性以及支持按需付费。

2、足够用的数据管理能力。数据湖需要提供更为强大的数据管理能力，包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。

3、大数据的能力，数据库的体验。目前绝大多数数据分析人员都只有数据库的使用经验，大数据平台的能力虽强，但是对于用户来说并不友好，数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配，而不是花大量的时间精力去学习大数据平台的开发。数据湖要想快速发展，如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心，如何将数据湖的能力通过SQL的形式释放出来，是未来的一个主要方向。

4、完善的数据集成与数据开发能力。对各种异构数据源的管理与支持，对异构数据的全量/增量迁移支持，对各种数据格式的支持都是需要不断完善的方向。同时，需要具备一个完备的、可视化的、可扩展的集成开发环境。

5、与业务的深度融合与集成。典型数据湖架构的构成基本已经成为了业界共识：分布式对象存储+多模态计算引擎+数据管理。决定数据湖方案是否胜出的关键恰恰在于数据管理，无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理，都离不开与业务的适配和集成；未来，会有越来越多的行业数据湖解决方案涌现出来，与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法，可能是未来数据湖领域差异化竞争的一个关键点。

（本文来源：简书，作者：bsauce）