论数据湖与数据仓库一体化设计的必要性_数据湖建设的必要性

数据湖概念

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

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

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

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

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

　　

由此，数据湖的概念被提出来了，并引起了大家的普遍关注。

　

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

• 数据湖应该是来源于单一的数据源；

• 你可以有多个数据湖；

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

不过，创始人怎么想已经不重要了……目前大家普遍认为，解决数据孤岛是数据湖的一大特点，毕竟这是一个看上去很美好的事。但是，把解决数据孤岛作为数据湖的使命，也确实引入了不少问题。

而数据湖为什么叫数据湖而不叫数据河或者数据海？一个有意思的回答是：

1）“河”强调的是流动性，“海纳百川”，河终究是要流入大海的，而企业级数据是需要长期沉淀的，因此叫“湖”比叫“河”要贴切；同时，湖水天然是分层的，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的，“热”数据在上层，方便应用随时使用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与成本的平衡。

2）不叫“海”的原因在于，海是无边无界的，而“湖”是有边界的，这个边界就是企业/组织的业务边界；因此数据湖需要更多的数据管理和权限管理能力。

3）叫“湖”的另一个重要原因是数据湖是需要精细治理的，一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”，从而使应用无法有效访问数据，使存于其中的数据失去价值。

这里的回答不必当真，看看就好，下面再来看看官方怎么界定数据湖的：

• Wikipedia定义：数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。数据沼泽是一种退化的、缺乏管理的数据湖，数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。

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

• 微软如是说：Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。

上面从功能角度的定义肯定无法让人满意，本文也不打算去追究数据湖的严格定义，只要明白有数据的地方就有湖，有湖的地方就要治理就好了。我们主要把重点放在为什么要引入数据湖、数据湖和数据仓库的区别以及是否有必要融合数据湖和数据仓库。先从数据仓库面临的问题说起吧。

数据仓库的优势和不足

在计算机领域，数据仓库（英语：data warehouse，也称为企业数据仓库）是用于报告和数据分析的系统，被认为是商业智能的核心组件。数据仓库是来自一个或多个不同源的集成数据的中央存储库。数据仓库将当前和历史数据存储在一起，用于为整个企业的员工创建分析报告。比较学术的解释是，数据仓库由数据仓库之父W.H.Inmon于1990年提出，主要功能是将组织通过在线交易处理(OLTP)信息系统经年累月累积的大量数据，借助数据仓库理论所特有的数据存储架构，做系统的分析整理后再进行各种分析如在线分析处理(OLAP)、数据挖掘(Data Mining)，然后进一步支持创建如决策支持系统(DSS)、主管信息系统(EIS)，以及帮助决策者能快速有效决策的商业智能(BI)系统。

不管是传统的基于Oracle等关系数据库创建的数据仓库还是基于现代大数据平台如Hadoop创建的数据仓库，其都包含以下关键部分：

1. 内置的存储系统，数据通过抽象的方式提供（例如采用Table或者View），不暴露文件系统。

无论传统数据仓库（如Teradata）还是新兴的云数据仓库系统（AWS Redshift、Google BigQuery、阿里云MaxCompute）均体现了数仓的设计本质，它们均没有对外暴露文件系统，而是提供了数据进出的服务接口。比如，Teradata提供了CLI数据导入工具，Redshift提供Copy命令从S3或者EMR上导入数据，BigQuery提供Data Transfer服务，MaxCompute提供Tunnel服务以及MMA搬站工具供数据上传和下载。这个设计可以带来多个优势：

• 引擎深度理解数据，存储和计算可做深度优化

• 数据全生命周期管理，完善的血缘体系

• 细粒度的数据管理和治理

• 完善的元数据管理能力，易于构建企业级数据中台

2. 数据需要清洗和转化，通常采用ETL/ELT方式

3. 强调建模和数据管理，供商业智能决策

              图1 第一代数仓和第二代数仓架构

数据仓库的优势也是很明显的，比如建模能够保证数据的完整性、一致性和复用性。特别是大数据环境下，指标的规范处理与预计算能够避免指标重复计算和数据查询缓慢的问题。图1左图可以看做基于关系数据库构建的第一代数据仓库，右图可以看做基于大数据平台构建的第二代数据仓库，是目前使用最广泛的架构，相比第一代数据仓库，优势是可以充分利用大数据相关技术与服务，包括存储和计算，同时也解决了半结构化、非结构化的数据存储，在应用上也支持了数据科学和机器学习等高级应用。但是随着数据量的增加和需求多样性的挖掘，原有数据仓库的劣势也逐渐表现出来：

• 随着越来越多的半结构化如xml，json格式的文档数据以及非结构化数据如图片、音频和视频数据加入，原有仅支持结构化数据的数仓开始捉襟见肘。为解决无schema数据，引入大量ETL同时也带来了作业流程长、数据质量降低的风险。

• 物联网和多媒体数据的大量产生催生了高级分析需求的爆发，如进行预测分析等场景，TensorFlow，PyTorch和XGBoost等机器学习系统都无法在数仓之上工作，与BI查询提取少量数据不同，这些系统需要使用复杂的非SQL代码处理大型数据集，而通过ODBC/JDBC读取此数据效率很低，并且无法直接访问仓库内部专有格式。

• 原有存储计算一体化的设计带来扩展问题，如基于HDFS的存储系统相比计算引擎有更高的稳定性要求和更高的运维风险；

• 存储和计算成本的增加，包括大量的原始数据的存储、基于HDFS的多副本数据存储以及数据湖和数仓的数据存两份。

• 数据湖和数仓的数据存两份导致数据的不一致性，这需要通过ETL来保证，维护代价比较高，可靠性也是个问题。

• 数据时效性不足，数据湖将大批量的数据集成起来并不容易。由于数据湖大多基于Hive来管理，而其底层HDFS存储并不支持修改，所以数据仅支持追加的模式来集成。而业务生产系统的数据变化不是只有追加的数据，还有很多更新的操作，如果要对数据湖的数据进行更新，就需要按分区先合并后重写。这样就增加了数据合并处理的难度，更多的时候只能通过一天合并一次的T+1的模式，T+1的模式也就意味着大部分数据对后端应用的可见性差了一天，当前看到的数据实际上是昨天的，意味着数仓里面的数据始终并不新鲜。

数据湖功能与架构

针对上述混部存储系统带来的稳定性以及数据存储成本问题固然可以通过云上Hadoop来实现，如AWS和阿里云的EMR（开源数据湖）底层物理服务器和开源软件版本由云厂商提供和管理，数据仍统一存放在HDFS系统上，引擎以Hadoop和Spark开源生态为主。这个架构通过云上IaaS层提升了机器层面的弹性和稳定性，使企业的整体运维成本有所下降，但企业仍然需要对HDFS系统以及服务运行状态进行管理和治理，即应用层的运维工作。同时因为存储和计算耦合在一起，稳定性不是最优，两种资源无法独立扩展，使用成本也不是最优。于是AWS开创性地引入了对象存储系统（S3），S3的架构彻底解决了计算和存储分离，真正做到一份数据，多种计算引擎，同时存储成本大大降低。S3的出现意味着数据湖的真正到来，随后阿里云和华为也都推出了自己的对象存储系统OSS和OBS。

于是大量的基于数据湖的新架构广泛应用，如下图2所示。

                        图 2 流批分离和流批一体架构

图2 上图是普遍使用的典型的lambda架构，该架构维护两套流程，一套实时数据处理链路，一套离线数据处理链路，两者合并生成最终的数据，该架构最大的问题是需要花费两套系统维护的代价，同时实时链路产生大量的小文件，由此给下游合并和去重任务的调度和计算带来极大挑战。如此一来，对象存储系统的引入虽然解决了存储计算分离的问题，而且引入的数据迁移工具使得数据的存储变得更加灵活便利，但是也引入了其他问题：

• 对象存储系统和原来的文件存储系统无法互通，形成新的数据孤岛

• 存储计算分离带来的网络性能降低

• 原来针对特定系统进行的SQL优化将不再起作用

• 数据管理和权限控制

另外，原有架构中的问题在实时数据湖环境下得以放大，比如不支持事务ACID特性，在实时数据处理方面，事务特性是必不可少的重要选项，比如实时交易订单状态变化，一条记录会产生多条不同状态的记录，此时我们希望在数据湖中能够像OLTP交易系统一样原地更新和修改。只有这样，才可能做到真正的流批一体。图2中下图才是是lake house倡导的流批一体架构，从第二代到第三代进化就是：

                  图3 第二代数仓和第三代数仓架构

该架构将离线数仓和实时应用融合为一起，具体就是：

• 为屏蔽上层使用数据的复杂度，使用统一的接口服务，比如BI报表使用统一SQL语法样式的API，对科学计算通过统一的声明式DataFrame样式的接口。

• 同时打通数仓和科学计算数据，两者公用一个元数据。

• 为了支持数据的更新删除操作，数据湖还需要支持事务功能。

• 另外作为一个基础服务层，数据湖还需要支持开放存储格式，以支持压缩和高效访问，而不是只有parquet格式。

最后，lakehouse的最佳实践是基于存算分离架构来构建。存算分离最大的问题在于网络，特别是对于高频访问的数仓数据，网络性能至关重要。各云厂家以及大数据厂家，都探索了很多的手段来解决云存储本身访问的性能问题，如提供本地缓存功能来提高数据处理的效率。 

实现lakehouse 的可选方案很多，比如Delta，Hudi，Iceberg。虽然三者侧重点有所不同，但是都具备数据湖通用的一些功能，比如：统一元数据管理、支持多元分析引擎、支持高阶分析和计算存储分离。

尽管lake house还不够完善，很多特性还在持续加入，但业界很多公司开始基于lake house构建自己的实时数据湖平台，比如图4中的腾讯某业务线基于Iceberg搭建的实时数仓。

             图4 腾讯基于Iceberg的实时数仓架构

数据湖高阶发展

到此数据湖基本有了自己的角色和定位，但是一项技术的发展壮大还不能就此停止，它还必须在完善自身功能的基础上去解决因为它出现导致的善后问题以及它出现之前的历史遗留问题。只有这样，它才能被真正广泛接受。比如对于已有的系统，特别是企业已经存在的庞大规模的基于HDFS存储的数据仓库和基于MPP架构的实时数据仓库系统，如果按照lake house架构来实行，那绝非是可能的，于是有了数仓和数据湖的另一种演化方向：打通MPP架构的数据仓库和数据湖。下面来看看业界大佬是如何做的。

亚马逊大佬的数据湖架构

                图5 AWS 数据湖架构

aws的数据湖架构可以简化为：

                  图6 AWS 数据湖架构简化图

AWS数据湖主要靠“三剑客”支撑：AWS Glue、Amazon S3和 Lake Formation。其中Glue是与数据湖配合的一款重要的服务，它可以帮助用户建立起无服务器架构的数据目录和快速完成数据的抽取、转换和加载（ETL）的服务，自动发现数据并存储 Schema，与 AWS 上运行的 Aurora、RDS、Redshift、S3 和数据库引擎天然集成。Amazon Athena可以帮助客户使用标准SQL语言，交互式查询存于Amazon S3数据湖中的数据。

Lake Formation 建立在 AWS Glue 中提供的功能基础之上。有了 Lake Formation，创建数据湖变得轻而易举，只需定义数据源，以及指定您要应用的数据访问和安全策略。接下来，Lake Formation 会帮助您从数据库和对象存储中收集数据并按目录对数据进行编目、将数据移动到新的 Amazon S3 数据湖、使用机器学习算法对数据进行清理和分类，并保护对敏感数据的访问权限。您的用户可以访问集中的数据目录，其中会描述可用数据集及其适当用法。然后，用户可以选择 Amazon Redshift、Amazon Athena 和 Amazon EMR for Apache Spark等分析和机器学习服务，以充分利用这些数据集。

可见，湖仓一体架构对于AWS是水到渠成的事情，不存在是否是下一代架构的问题，因为它已经通过Glue在元数据层面打通了包括对象存储系统S3，关系型数据库OralaDB以及数仓系统RedShift等，而且RedShift还能够支持lake house架构。

来看看阿里云大佬的数据湖架构

                          图7 阿里云数据湖架构

集群存储层：Maxcompute（前身是ODPS Hadoop集群）数据仓库集群和后来加入的数据湖（支持HDFS文件存储和OSS对象存储）分属于两个不同的集群，分别服务于数据仓库应用和科学计算（支持Hive、Spark、Flink等多引擎）。数据湖集群因为是存储计算架构分离，为了提高网络访问效率，需要在Maxcompute集群提供数据缓存。

计算服务层：Maxcompute和数据湖集群数据的元数据原本隔离，为了让两者融合，首先要做的是从元数据层打通：数据湖的数据库元数据可以直接映射到Maxcompute，从而不需要搬运数据，就可以直接访问数据湖的数据。上层业务通过Dataworks IDE屏蔽底层数据来源差异。

阿里云的数据湖和数据仓库融合设计方案需要兼顾HDFS和OSS两套系统的维护升级，以及数据仓库和数据湖的互通加速，该方案本质上是解决因为历史原因造成的技术问题，尽管它也实现了数据仓库和数据湖的打通。

华为云大佬基于经典数仓设计规范理论在数据湖上重走了一遍，一起来看看他的数据湖架构

              图8 华为云数据湖架构

数据存储层：基于对象存储OBS云原生架实现存算分离，而且相比现有的对象存储性能有较大提升。统一元数据管理实现湖仓共享存储资源池，针对同一份元数据定义支持各种场景，提供API方便各类工具和引擎（包括机器学习、Python、R等）直接有效地访问数据，这是实现湖仓一体的一个关键点；

计算引擎层：为数据湖增加了事务能力提升了数据质量；利用HetuEngine通过标准SQL访问跨域多源数据，实现湖&仓数据关联分析协同计算，简单易用; 打破数据墙，在湖内基于统一数据目录，可基于数据湖实现融合分析&AI训练推理，减少数据搬迁，实现海量数据快速价值挖掘。

运营管理层：提供统一的数据开发和治理环境，具备安全管理功能，支持多引擎任务统一开发和编排，数据统一建模和质量监测，实现湖仓一致的开发治理体验。

对比发现，AWS因为有着全局的规划和系统架构，所以在数据湖方面独领风骚，实现了从对象存储、元数据管理到交互式分析与计算都走在前列，然而瑕疵就是早先的Redshift是封闭存储系统，导致无法跟其他系统打通，存储计算成本较高，后来才加入了外表功能。另外AWS缺少用户可用的数据开发和治理平台。

阿里云作为跟进者，目前虽然也实现了打通了Maxcompute数据仓库和和数据湖OSS，并且也有了统一的数据开发平台，但总体来说还是处于打补丁阶段，其他产品还没有跟上。而华为云着重在将数仓的设计规范、流程和数据治理应用在数据湖上面，目前还处于起步阶段，很多功能还不够完善或者还停留在架构设计阶段。

中小企业的出路

虽然中小企业没有上面大佬的技术实力，但也不是建不起来数据湖，华为的这套架构很适合大家：

蓝色数据流是离线数据流，实现离线数据湖能力，数据通过批量集成，存储到Hudi，再通过Spark进行加工。

红色数据流是实时流，数据通过CDC实时捕获，通过Flink实时写入Hudi；通过Redis做变量缓存，以实现实时数据加工处理，之后送到诸如Clickhouse 、Redis、Hbase等专题集市里对外提供服务。

同时，我们还开发了HetuEngine数据虚拟化引擎，将数据湖里面的数据以及其他专题集市里的数据进行多数据源关联分析，形成逻辑数据湖。

这个架构的亮点是：

1. 借助开源的Hudi实现数据的流批一体设计，成本更低；

2. 引入HetuEngine虚拟化查询层，统一访问不同的数据库。

引进了3个湖，实时数据湖，离线数据湖和逻辑数据湖，拓宽了数据湖的概念。特别是逻辑数据湖位于用户查询端，仅仅用于存储结果数据，使数据仓库和数据湖融合的必要性大为降低。

总结

随着物联网大量异构化数据的接入和机器学习的广泛应用，原有基于建模规范化处理的数仓无法在数据处理及时性和需求确定性方面取得平衡，于是出现以对象存储为基础的“先污染后治理”的数据湖架构。以对象存储为基础的数据湖从根本上分离了计算和存储，进一步释放了存储和计算双方的生产力，同时原有的基于HDFS和MPP架构的数仓系统仍然大量存在，成为孤立的数据岛，为了进一步减少存储和计算成本，需要两者互融互通，而实现方式有两条路线：一是开源界以Hudi、Iceberg、Delta为基础框架的数据湖架构，通过支持增量更新的方式达到流批一体，二是公有云巨头以亚马逊、阿里云、华为云为代表的通过公共元数据、公共外部存储系统来实现数据的互通，但三者发展阶段差距较大。而对于中小企业，上述任务不是必须选项，在构建数据湖方面仍然有很多实现路径。但作为数仓的进一步扩展，数据湖仍然没有解决数仓面临的一系列问题，反而让这些问题变得更为严峻，比如数据接入、数据管理和权限控制、数据治理、数据血缘和资产目录等，原本这些属于数据中台的内容，逐渐下沉到数据湖层面来解决了。