数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。
一、数据湖的缘起
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为例，它要解决的核心问题基本上集中在下图：
