到底什么是数据湖？全面解读数据湖的缘起、特征、技术、案例和趋势

数据湖近几年迅速蹿红，今天笔者做一个综述，包括数据湖的缘起、数据湖的定义、数据湖的特征、数据湖的技术、数据湖的趋势和数据湖的案例六大部分，如果你要入门数据湖，一定要看一看。

注：文末列出了所有参考文献，方便你拓展阅读。

一、数据湖的缘起

10年前，Pentaho公司（一家开源BI公司）的CTO詹姆斯·迪克森在他的博客中第一次提出“数据湖”（Data Lake）的概念；10年后的今天，在业界“数据中台”大火的时代背景下，再来讨论“数据湖”，应该别有一番韵味。

1、从事务系统到数据仓库

要了解数据湖的来龙去脉，首先得提数据仓库的缘起[1][2]。

“数据仓库”，由比尔·恩门（Bill Inmon）于1990年提出，其被广泛接受的定义是，一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策，通常也被认为是决策支持型应用的必要条件。

此处的定义大多都是针对事务型数据系统而制定的。所谓事务型数据系统，是指记录业务交易的系统，这个名词先是在金融业，特别是银行实施信息化IT系统时使用的。例如银行的交易流水数据库，每分每秒都有大量的交易被数据库所记录并持久化的保存下来，其最小的颗粒度就是一笔“交易”。

但事务性数据系统存在诸多劣势：试想，如果一个银行的分行长想知道今天到目前为止共有多少现钞存款入账，那么系统就需要遍历今天截止到目前的所有交易行为，并筛选其中的存款行为进行汇总。查询交易的行为需要遍历当前系统的所有记录，因此当这一行为频率变高时，会对数据系统造成巨大的读取压力。

除开查询或分析任务对事务型数据系统造成的资源压力外，系统执行任务时，返回的结果只代表着任务开始运行那一刻的数据状态，假设执行查询任务消耗了1分钟，这1分钟内很有可能发生多次的交易撤销、额度修改，增加交易等行为。有些数据系统允许在读取数据的同时写入数据，那么查询任务返回的结果并不能代表最新的状态；有些数据系统则有“读锁”，即在读取数据的时候不允许写入数据，那么这个长达1分钟的查询任务会使得业务交易失败或者暂缓进入数据系统，如果其中发生业务中断，这些交易数据可能面临丢失的风险。

当然，我们可以通过技术手段来避免或缓解事务型数据系统的不足，因此事务型的数据库并不是不能做业务分析，只是当决策者需要进行经营性的分析和决策时，大多数时候它并非最优方案。此时，数据仓库面向主题且便于分析的优势就体现出来了：

数据仓库是面向主题的。相对于事务型系统将交易类型（存款）、交易币种（人民币或外币）、交易数值（存款额）以一条事务（Transcation）的方式存储，数据仓库通常会将一条事务中的不同信息拆分到不同的主题域中分别存储，例如交易类型表、交易币种表和交易额度表等。

数据仓库是集成的。不同主题域中的信息之间以统一的ID，如交易流水号为标识进行链接。这样的好处是当分行长想知道今天到目前为止一共有多少人民币存款入账时，只需要先筛选出交易类型为存款，交易币种为人民币的交易流水号，再基于这些流水号去汇总交易额度，比起原先需要遍历全部交易记录后才能汇总的方式大大节约了系统资源的开销。

数据仓库是相对稳定的。数据仓库通常以时间窗口作为数据批量导入的分区，例如每一小时或一天从事务型系统导入一次数据，在下一次数据导入任务开始之前，系统处于一个相对稳定的状态，有利于进行经营性的业务分析。

数据仓库是反映历史变化的。正是由于通常数据仓库中的数据是基于预先设定好的时间窗口从事务型系统中获取数据，无论是一分钟、一小时还是一天、一周，它都是可以反映数据整体历史变化的，分行长可以清楚地知道今天银行的人民币存款入账环比昨天增长或减少了多少，同比上个月的今天又发生了什么变化。

因此，比起事务型的数据系统，数据仓库能更有效地对业务数据进行统计分析，无论是在提高效率、稳定性还是降低资源成本上都有其优势，所以被广为接受而大行其道。

2、从数据仓库到数据集市

后来，数据仓库领域的大师Ralph Kimball又演化出“维度建模”的概念，认为数据仓库是一系列数据集市的集合。如果说数据仓库中包含着许多不同的主题域，那么数据集市可以理解为主要面向业务应用的单一主题域。

比如，分行长可以建设面向存储部门的、专门提供存款数据的“存款数据集市”，面向商业贷款部门的“贷款数据集市”，面向信用卡部门的“信用卡数据集市”等，其数据都源自数据仓库，但数据集市的汇总程度更高、更注重业务表示。例如“环比存款增长率”这个指标在数据仓库中可能表示为“上月存款额”和“本月存款额”两个不同的数值，而在数据集市或者数据仓库的“集市层”中，就表示为计算后的一个数值，可以直接被业务所用而无需再做多余的计算。

3、数据湖的由来

数据湖最早是由Pentaho的创始人兼CTO， 詹姆斯·迪克森，在2010年10月纽约Hadoop World大会上提出来的。当时Pentaho刚刚发布了Hadoop的第一个版本。在这样的一个大背景下，可以合理的猜测，当时James Dixon提出数据湖的概念，是为了推广自家的Pentaho产品以及Hadoop的。

Pentaho是个BI分析组件。当时的BI分析主要是基于数据集市（Data Mart）的。数据集市的建立需要事先识别出感兴趣的字段、属性，并对数据进行聚合处理。这样BI分析面临两个问题：

（1）只使用一部分属性，这些数据只能回答预先定义好（pre-determined）的问题。

（2）数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。

而基于Hadoop的BI分析，可以解决这个问题——把所有数据都原样存在Hadoop中，后面需要的时候再来取用。如果说数据集市、数据仓库里面是瓶装的水——它是清洁的、打包好的、摆放整齐方便取用的；那么数据湖里面就是原生态的水——它是未经处理的，原汁原味的。数据湖中的水从源头流入湖中，各种用户都可以来湖里获取、蒸馏提纯这些水（数据）。

接下来发生的事件让数据湖的内涵获得了拓展，这是詹姆斯·迪克森没想到的。

2011年，福布斯在文章《Big Data Requires a Big, New Architecture》中报道了“data lake”这个词，并给出了数据仓库与数据湖的对比：数据仓库的数据在被集成时就会被预先分类，并以最优的方式进行存储，以支撑特定的分析；但在大数据时代，我们从源系统抽取数据时可能无法明确知道这些数据的价值，因此无法给出一个最优的存储方式。

例如，分行长从交易系统中将所有的数据都抽取过来，但并不知道业务部门想做什么类型反映业务历史的变化。因此建议将这些数据先保存在一个海量的数据库中。由于数据来源的格式五花八门而且会越存越多，因此这个数据库需要具备容易访问且存储成本低（允许硬件资源扩容的成本而尽可能降低其他成本，例如软件使用费用、人工维护费用等）的特性，需要进行分析时，再来组织和筛选所需数据，这个数据库就是数据湖（Data Lake）。

彼时的数据湖概念更多地是关于当企业在处理海量异构的数据时，如何在数据产生实际的应用价值之前，为海量数据构建一个易访问且成本低的存储方式，和数据资产化、资产服务化等当下热点名词并没有太大关系。

2014年，福布斯杂志上刊登了一篇名为《The Data Lake Dream》的文章，文章作者EddDumbill描述了数据湖的愿景：

（1）融合所有数据，解决系统间数据孤岛、各类应用统一访问问题；

（2）数据可获取性提高，应用部署时间缩短；

（3）具有弹性的分布数据处理的平台，能同时支撑批量和实时数据操作处理和分析；

（4）数据湖增加安全和管控层面的功能；

（5）重视集中、自动的元数据管理和入湖标准，避免成为没有价值的数据。

数据湖可以解决数据孤岛问题这种特性似乎也挺符合数据湖的理念的。各种数据源都汇聚到一个湖里，自然就解决了数据孤岛问题，但这应该并不是James的本意。从他后来的blog中可以看出，他所认为的数据湖是这样的：

（1）数据湖应该是来源于单一的数据源；

（2）你可以有多个数据湖；

（3）如果存储来自多个系统的数据并对他们进行关联，那么这不是数据湖，而是由多个数据湖填充而成的水上花园（Water Garden）

不过，创始人怎么想已经不重要了……目前大家普遍认为，解决数据孤岛是数据湖的一大特点，毕竟这是一个看上去很美好的事。

然后云计算的“XaaS”的风潮助推了数据湖的兴起，例如软件即服务（SaaS，Software as a Service），平台即服务（PaaS，Platform as a Service），基础设施即服务（Iaas，Infrastructure as a Service）。从这个时候开始，单纯的数据湖就朝向一个“平台级的方案”而演进。

数据湖从本质上来讲，是一种企业数据架构方法。物理实现上则是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析。

目前Hadoop是最常用的部署数据湖的技术，以前这个概念国内谈的少，但绝大部分互联网公司都已经有了，国内一般把整个HDFS叫做数据仓库（广义），即存放所有数据的地方，而国外一般叫数据湖（data lake）。

真正将数据湖推而广之的是亚马逊AWS。AWS 构筑了一套以 S3 为中心化存储、Glue 为元数据服务，E-MapReduce、Athena 为引擎的开放协作式的产品解决方案，AWS 之后，各个云厂商也纷纷跟进数据湖的概念，并在自己的云服务上提供类似的产品解决方案。

2014年6月26日，西瓜哥在“高端存储知识”公众号发表了一篇文章”你知道数据湖泊（DATA LAKE)吗?”一文，首次把数据湖这个概念引入中国。由于那时还没有标准的翻译，为了和数据仓库术语字数对齐，翻译成数据湖泊。

现在，数据湖已经得到快速发展，很多厂商都推出了自己的解决方案。当前商业的数据湖产品包括AWS数据湖、华为数据湖、阿里云数据湖、Azure数据湖，开源的数据湖产品包括delta、iceberg和hudi等等。

二、数据湖的定义

下面是维基等组织给出的数据湖的早期定义，随着数据湖的发展，其实数据湖早已不是原来的“湖”的概念了：

Wikipedia：

数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。

数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。

数据沼泽是一种退化的、缺乏管理的数据湖，数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。

AWS：

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

微软：

Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。

数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。

Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。

三、数据湖的特征

笔者结合多方的观点[2][3][4][5][6][7]，给出数据湖的六大核心特征，从这些特征看，数据湖更是一种企业数据架构方法：

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

（2）“灵活性”：如果数据仓库属于计划经济，那数据湖就属于市场经济[7]，数据仓库强调“写入型schema”，  “写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。数据湖强调的是“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。

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

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

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

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

四、数据湖的技术

数据湖要解决的核心问题是高效的存储各类数据并支撑上层应用，传统的数据湖一般采用HDFS为存储引擎，但在实际应用中面临着难以克服的问题，这直接催生了delta、iceberg和hudi[11]三大开源数据湖方案，虽然它们开始的时候是为了解决特定的应用问题的，但最终促成了数据湖特征的统一。

1、Delta

以Databricks推出的delta为例，它要解决的核心问题基本上集中在下图：

在没有delta数据湖之前，Databricks的客户一般会采用经典的lambda架构来构建他们的流批处理场景。以用户点击行为分析为例，点击事件经Kafka被下游的Spark Streaming作业消费，分析处理（业务层面聚合等）后得到一个实时的分析结果，这个实时结果只是当前时间所看到的一个状态，无法反应时间轴上的所有点击事件。所以为了保存全量点击行为，Kafka还会被另外一个Spark Batch作业分析处理，导入到文件系统上（一般就是parquet格式写HDFS或者S3，可以认为这个文件系统是一个简配版的数据湖），供下游的Batch作业做全量的数据分析以及AI处理等。

这套方案其实存在很多问题 :

第一、批量导入到文件系统的数据一般都缺乏全局的严格schema规范，下游的Spark作业做分析时碰到格式混乱的数据会很麻烦，每一个分析作业都要过滤处理错乱缺失的数据，成本较大；

第二、数据写入文件系统这个过程没有ACID保证，用户可能读到导入中间状态的数据。所以上层的批处理作业为了躲开这个坑，只能调度避开数据导入时间段，可以想象这对业务方是多么不友好；同时也无法保证多次导入的快照版本，例如业务方想读最近5次导入的数据版本，其实是做不到的。

第三、用户无法高效upsert/delete更新历史数据，parquet文件一旦写入HDFS文件，要想改数据，就只能全量重新写一份的数据，成本很高。事实上，这种需求是广泛存在的，例如由于程序问题，导致错误地写入一些数据到文件系统，现在业务方想要把这些数据纠正过来；线上的MySQL binlog不断地导入update/delete增量更新到下游数据湖中；某些数据审查规范要求做强制数据删除。

第四、频繁地数据导入会在文件系统上产生大量的小文件，导致文件系统不堪重负，尤其是HDFS这种对文件数有限制的文件系统。

在Databricks看来，以下四个点是数据湖必备的：

事实上, Databricks在设计delta时，希望做到流批作业在数据层面做到进一步的统一(如下图)。业务数据经过Kafka导入到统一的数据湖中（无论批处理，还是流处理），上层业务可以借助各种分析引擎做进一步的商业报表分析、流式计算以及AI分析等等。

2、Hudi

Uber的业务场景主要为：将线上产生的行程订单数据，同步到一个统一的数据中心，然后供上层各个城市运营同事用来做分析和处理。在2014年的时候，Uber的数据湖架构相对比较简单，业务日志经由Kafka同步到S3上，上层用EMR做数据分析；线上的关系型数据库以及NoSQL则会通过ETL（ETL任务也会拉去一些Kakfa同步到S3的数据）任务同步到闭源的Vertica分析型数据库，城市运营同学主要通过Vertica SQL实现数据聚合。当时也碰到数据格式混乱、系统扩展成本高（依赖收Vertica商业收费软件）、数据回填麻烦等问题。后续迁移到开源的Hadoop生态，解决了扩展性问题等问题，但依然碰到Databricks上述的一些问题，其中最核心的问题是无法快速upsert存量数据。

如上图所示，ETL任务每隔30分钟定期地把增量更新数据同步到分析表中，全部改写已存在的全量旧数据文件，导致数据延迟和资源消耗都很高。此外，在数据湖的下游，还存在流式作业会增量地消费新写入的数据，数据湖的流式消费对他们来说也是必备的功能。所以，他们就希望设计一种合适的数据湖方案，在解决通用数据湖需求的前提下，还能实现快速的upsert以及流式增量消费。

Uber团队在Hudi上同时实现了Copy On Write和Merge On Read 的两种数据格式，其中Merge On Read就是为了解决他们的fast upsert而设计的。简单来说，就是每次把增量更新的数据都写入到一批独立的delta文件集，定期地通过compaction合并delta文件和存量的data文件。同时给上层分析引擎提供三种不同的读取视角：仅读取delta增量文件、仅读取data文件、合并读取delta和data文件。满足各种业务方对数据湖的流批数据分析需求。

最终，我们可以提炼出Uber的数据湖需求为如下图，这也正好是Hudi所侧重的核心特性。

3、Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为自研Iceberg，并最终演化成Apache下一个高度抽象通用的开源数据湖方案。Netflix用内部的一个时序数据业务的案例来说明Hive的这些问题，采用Hive时按照时间字段做partition，他们发现仅一个月会产生2688个partition和270万个数据文件。他们执行一个简单的select查询，发现仅在分区裁剪阶段就耗费数十分钟。

他们发现Hive的元数据依赖一个外部的MySQL和HDFS文件系统，通过MySQL找到相关的parition之后，需要为每个partition去HDFS文件系统上按照分区做目录的list操作。在文件量大的情况下，这是一个非常耗时的操作。同时，由于元数据分属MySQL和HDFS管理，写入操作本身的原子性难以保证。即使在开启Hive ACID情况下，仍有很多细小场景无法保证原子性。另外，Hive Memstore没有文件级别的统计信息，这使得filter只能下推到partition级别，而无法下推到文件级别，对上层分析性能损耗无可避免。最后，Hive对底层文件系统的复杂语义依赖，使得数据湖难以构建在成本更低的S3上。

于是，Netflix为了解决这些痛点，设计了自己的轻量级数据湖Iceberg。在设计之初，作者们将其定位为一个通用的数据湖项目，所以在实现上做了高度的抽象。虽然目前从功能上看不如前面两者丰富，但由于它牢固坚实的底层设计，一旦功能补齐，将成为一个非常有潜力的开源数据湖方案。

总体来说，Netflix设计Iceberg的核心诉求可以归纳为如下：

因此，数据湖并不是炒作的新概念，而是来源于应用的驱动，delta、iceberg和hudi这类新技术实际是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，Iceberg 将其称之为“表格式”也是表达类似的含义。它与底层的存储格式（比如 ORC、Parquet 之类的列式存储格式）最大的区别是，它并不定义数据存储方式，而是定义了数据、元数据的组织方式，向上提供统一的“表”的语义。它构建在数据存储格式之上，其底层的数据存储仍然使用 Parquet、ORC 等进行存储。

delta、iceberg和hudi诞生于不同公司，需要解决的问题存在差异，Iceberg 在其格式定义和核心能力上最为完善，但是上游引擎的适配上稍显不足；Hudi 基于 Spark 打造了完整的流式数据落地方案，但是其核心抽象较弱，与 Spark 耦合较紧；Delta Lake 同样高度依赖于 Spark 生态圈，与其他引擎的适配尚需时日，虽然这三个方案在设计初衷上稍有不同，但实现的思路和提供的能力却非常相似，我们可以总结出数据湖技术需要具备的能力：

（1）同时支持流批处理

（2）支持数据更新

（3）支持事务（ACID）

（4）可扩展的元数据

（5）支持多种存储引擎

（6）支持多种计算引擎

不同公司根据不同需求选择了不同的数据湖产品，比如阿里云的 DLA 团队选择 hudi 作为其底层数据湖存储引擎；腾讯选择了 iceberg 作为他们的数据湖存储引擎,比如文章《基于 Flink+Iceberg 构建企业级实时数据湖》[12]就介绍了腾讯的企业实时数据湖方案。

五、数据湖的趋势

1、服务模式演进趋势

下面是阿里云[3]给出的数据湖服务架构的演进过程，整体上可分为三个阶段：

第一阶段：自建开源Hadoop数据湖架构，原始数据统一存放在HDFS系统上，引擎以Hadoop和Spark开源生态为主，存储和计算一体。缺点是需要企业自己运维和管理整套集群，成本高且集群稳定性差。

第二阶段：云上托管Hadoop数据湖架构（即EMR开源数据湖），底层物理服务器和开源软件版本由云厂商提供和管理，数据仍统一存放在HDFS系统上，引擎以Hadoop和Spark开源生态为主。这个架构通过云上 IaaS 层提升了机器层面的弹性和稳定性，使企业的整体运维成本有所下降，但企业仍然需要对HDFS系统以及服务运行状态进行管理和治理，即应用层的运维工作。同时因为存储和计算耦合在一起，稳定性不是最优，两种资源无法独立扩展，使用成本也不是最优。

第三阶段：云上数据湖架构（无服务器），即云上纯托管的存储系统逐步取代HDFS，成为数据湖的存储基础设施，并且引擎丰富度也不断扩展。除了Hadoop和Spark的生态引擎之外，各云厂商还发展出面向数据湖的引擎产品。如分析类的数据湖引擎有AWS Athena和华为DLI，AI类的有AWS Sagemaker。

这个架构仍然保持了一个存储和多个引擎的特性，所以统一元数据服务至关重要，如AWS推出了Glue，阿里云EMR近期也即将发布数据湖统一元数据服务。该架构相对于原生HDFS的数据湖架构的优势在于：

（1）帮助用户摆脱原生HDFS系统运维困难的问题。HDFS系统运维有两个困难：1）存储系统相比计算引擎更高的稳定性要求和更高的运维风险 2）与计算混布在一起，带来的扩展弹性问题。存储计算分离架构帮助用户解耦存储，并交由云厂商统一运维管理，解决了稳定性和运维问题。

（2）分离后的存储系统可以独立扩展，不再需要与计算耦合，可降低整体成本

（3）当用户采用数据湖架构之后，客观上也帮助客户完成了存储统一化（解决多个HDFS数据孤岛的问题）

2、技术架构演进趋势

第一阶段：以Hadoop为代表的离线数据处理基础设施。如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施。

第二阶段：lambda架构。随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等，如下图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。

第三阶段：Kappa架构。Lambda架构解决了应用读取数据的一致性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。

3、湖仓一体的演进趋势

数据仓库的设计强调计划，而数据湖强调市场，更具灵活性，因此对于处于不同阶段的企业的效用是不一样的：

1、当企业处于初创阶段，数据从产生到消费还需要一个创新探索的阶段才能逐渐沉淀下来，那么用于支撑这类业务的大数据系统，灵活性就更加重要，数据湖的架构更适用。

2、当企业逐渐成熟起来，已经沉淀为一系列数据处理流程，问题开始转化为数据规模不断增长，处理数据的成本不断增加，参与数据流程的人员、部门不断增多，那么用于支撑这类业务的大数据系统，成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。

对企业来说，数据湖和数据仓库是否必须是一个二选一的选择题？是否能有一种方案同时兼顾数据湖的灵活性和云数据仓库的成长性，将二者有效结合起来为用户实现更低的总体拥有成本？阿里云提出了大数据架构新概念：湖仓一体。

何谓湖仓一体？

（1）湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用知识沉淀到数据仓库

（2）湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作

（3）数据湖与数据仓库的数据，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

六、数据湖的案例

1、AWS数据湖

AWS数据湖[8]基于AWS Lake Formation构建，AWS Lake Formation本质上是一个管理性质的组件，它与其他AWS服务互相配合，来完成整个企业级数据湖构建功能。上图自左向右，体现了数据沉淀、数据流入、数据计算、数据服务等步骤。

（1）数据沉淀：采用Amazon S3作为整个数据湖的集中存储，包含结构化和非结构化的数据，按需扩展/按使用量付费

（2） 数据流入：元数据抓取、ETL和数据准备AWS将其单独抽象出来，形成了一个产品叫AWS GLUE，GLUE基本的计算形式是各类批处理模式的ETL任务，任务的出发方式分为手动触发、定时触发、事件触发三种

（3）数据处理：利用AWS GLUE进行批处理计算模式之外，也可以使用Amazon EMR进行数据的高级处理分析，或者基于Amazon EMR、Amazon Kinesis来完成流处理任务

（4）数据分析：数据通过Athena/Redshift来提供基于SQL的交互式批处理能力，通过 Amazon Machine Learning、Amazon Lex、Amazon Rekognition进行深度加工

2、华为数据湖

华为数据湖基于DLI Serverless[9]构建，DLI完全兼容Apache Spark、Apache Flink生态和接口，是集实时分析、离线分析、交 互式分析为一体的Serverless大数据计算分析服务。可以看到，DLI相当于是AWS的Lake Formation、GLUE、EMR（Flink&Spark）、Athena等的集合，承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。

为了更好的支持数据集成、规范设计、数据开发、数据质量监控、数据资产管理、数据服务等数据湖高级功能，华为云提供了DAYU智能数据湖运营平台[10]，DAYU涵盖了整个数据湖治理的核心流程，并对其提供了相应的工具支持，如下图所示。

3、阿里云数据湖

阿里云DLA数据湖解决方案[4]如上图所示，DLA 核心在于打造云原生的服务与引擎，端到端解决基于 OSS 的管理、分析、计算问题，核心关键点如下。

（1）数据存储：采用OSS作为数据湖的集中存储，可以支撑EB规模的数据湖，客户无需考虑存储量扩容，各类型数据可以统一存储

（2）数据湖管理：面对 OSS 数据开放性带来的管理及入湖困难，DLA的Formation组件具备元数据发现和一键建湖的能力，DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”，比如利用元数据爬取功能，可以一键创建 OSS 上的元数据信息，轻松自动识别 CSV/JSON/Parquet 等格式，建立好库表信息，方便后续计算引擎使用

（3）数据分析和计算：DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎，都和Meta data catalog深度集成，能方便的获取元数据信息。基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式

（4）在数据集成和开发上：阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成。无论是选择哪种，都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上，dataworks的数据地图能力相对更加成熟。

阿里云DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”。传统的企业级数据仓库在大数据时代的今天，在各类报表应用上依然是无法替代的；但是数仓无法满足大数据时代的数据分析处理的灵活性需求。

因此，阿里云推荐数据仓库应该作为数据湖的上层应用存在：即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地；数据湖根据各类业务应用需求，将原始数据进行加工处理，形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，DLA可以将中间结果推送至数据仓库，供企业/组织开展基于数仓的业务应用。阿里云在提供DLA的同时，还提供了云原生数仓（原ADB），DLA和云原生数仓在以下两点上深度融合。

（1） 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容，这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。

（2） 都内置了对于OSS的访问支持。OSS直接作为DLA的原生存储存在；对于ADB而言，可以通过外部表的能力，很方便的访问OSS上的结构化数据。借助外部表，数据可以自由的在DLA和ADB之间流转，做到真正的湖仓一体。

结语

在写这篇文章之前，笔者对于数据湖的理解是零碎的，不成体系的，通过这次归纳总结，我大致能理解数据湖的来龙去脉，希望对你也有所帮助。