---

数据湖的概念

数据湖是一种存储系统，底层包括不同的文件格式及湖表格式，可存储大量非结构化和半结构化的原始数据。

数据消费者可以访问该数据进行数据分析，包括 BI、报表和机器学习模型训练。

---

数据湖 vs 数据仓库 vs Lakehouse

• 数据仓库和数据湖的结合形成了 Lakehouse，
• 数据仓库和流结合形成了 Streaming Warehouse
• 数据仓库、数据湖、流三者结合可能是下一个需要进一步延伸和研究的方向。

Lakehouse 同时具备数据湖和数据仓库的特性，目前这个方向已经逐渐走向成熟。

与数据湖相比，Lakehouse 集成了计算框架和 SQL 查询引擎，添加了数据治理能力，支持 Catalog 表管理和先进的作业编排。

① 业界进展（Databricks 2.0）-湖上建仓

业界在 LakeHouse 里面有两个方向，一个是湖上建仓，比如 Databricks2.0 的 Lakhouse 系统平台，主要是依赖于 Delta Lake 统一的数据湖存储格式，在此基础上统一了元数据，并基于 Spark 引擎统一提供的批流一体处理能力，实现在数据湖上建设数仓。

---

② 业界进展（Snowflake EDW 2.0）-仓外挂湖

另外一个是仓外挂湖。业界的发展主要是以 Snowflake 为代表，主要是在它的 EDW2.0 系统里面实现了一个仓外挂湖。比如已经有了 Hive 的数仓存储体系，再引入数据湖的格式，并实现了通过 Hive 对数据湖进行读和写，这种方式就叫做仓外挂湖。

Snowflake 也有一套完整的数据仓库系统，它有自己的计算引擎和存储格式、Cache 等一系列系统，在这些系统之上引入了数据湖的格式，比如引入 Iceberg。

---

LakeHouse 的演进

（1）Lakehouse 的演进路线

主流的三种开源技术是 Hudi、Iceberg 和 Databricks，它们分别在 2016 年、2017 年和 2019 年被开源出来。

2021 年 Lakehouse 技术首次进入 Gartner 成熟度曲线，Lakehouse 技术在曲线中处于起步阶段，意味着 Lakehouse 未来会有非常大的发展空间。

Lakehouse 在通用数据基础设施蓝图（2.0）中也处于核心地位，位于存储、查询和计算之间，贯通通用数据基础设施蓝图的上下游。

Hudi是一个用于大数据处理的开源库，支持增量数据处理和实时数据流处理。

Iceberg是一个开源表格式，旨在解决Apache Hive表的限制。

Databricks是一个基于Apache Spark的云端数据处理平台。

Lakehouse则是一种新兴的数据架构，结合了数据湖和数据仓库的优点，旨在提供更好的数据管理和查询能力。

Gartner成熟度曲线是一个用于评估技术成熟度的模型，可以帮助企业了解技术的发展趋势和使用价值。通用数据基础设施蓝图则是一种用于设计企业数据架构的框架，旨在提供一个可扩展、可靠和安全的数据基础设施。

---

（2）Lakehouse 的设计原则

Lakehouse 的设计原则由国内阿里、腾讯、云粒、数梦、滴普、亚信、比智、甲骨文、巨杉、深算院、新华三等公司在 2020 年共同起草，分为功能性设计要素和非功能性设计要素两类。

其中，

• 功能性设计要素包括：一体化架构、存算分离、事务和数据一致性、全数据类型。
• 非功能性设计要素包括：弹性高可用、加强的数据治理、尽量少的数据冗余、高并发支持、运维可观测性、高开放性。

• 一体化架构：指将数据仓库和数据湖融合在一起，实现数据的统一管理和使用。
• 存算分离：指将存储和计算分离，以提高计算效率和灵活性。
• 事务和数据一致性：指保证数据在不同操作之间的一致性，避免数据出现错误或重复。
• 全数据类型：指支持多种数据类型，包括结构化、半结构化和非结构化数据。
• 弹性高可用：指系统能够在出现故障或负载增加时自动扩容和恢复，保证系统的可用性和稳定性。
• 数据治理：指对数据进行管理和监控，确保数据的质量和安全。
• 数据冗余：指在系统中存储多份相同的数据，以提高系统的可靠性和容错性。
• 高并发支持：指系统能够同时处理大量请求，保证系统的响应速度和吞吐量。
• 运维可观测性：指系统能够实时监控和分析运行状态，帮助运维人员及时发现和解决问题。
• 高开放性：指系统能够与其他系统或应用进行集成和交互，提高系统的灵活性和互操作性。

---

2. 数据湖重要组成部分

1. 数据湖物理存储层

数据湖的存储层主要包括大数据生态的 HDFS 文件系统、主流的云原生对象存储。数据湖物理存储需要具备同时支持 HDFS 生态和云原生的生态。

---

2. 数据湖文件格式

数据湖文件格式主要包括 Avro、Parquet、ORC 等主流的文件格式。
其中，

• Avro 是行级别的，有利于写
• Parquet 和 ORC 是列级别的，更方便读（支持列裁剪和过滤）
  

---

3. 数据湖表格式

（1）数据湖表格式的功能特点

功能特点主要包括以下几个方面：

• ① DML 和 SQL 支持

  直接在分布式文件上提供 Merge Into、Update 和 Delete 操作。除了 SQL，有些还支持Scala/Java 和 Python API

• ② Schema Evolution

  Table format 的一个关键特性，意味着在不破坏任何内容甚至扩大某些类型的情况下添加新列。

• ③ ACID 事务、回滚、并发控制

  ACID 事务确保所有更改都成功提交或回滚。确保永远不会以不一致的状态结束。有不同的并发控制，例如保证读取和写入之间的一致性。

• ④ 时间旅行

  数据湖表格式会将存储在数据湖中的大数据版本化并形成多版本。可以访问该数据的任何历史版本，在意外写入或删除错误的情况下回滚数据。

• ⑤ 文件布局优化

  随着时间的推移摄入的小文件会增加，但查询数千个小文件很慢，文件布局优化可以将文件碎片重新整理为更大的文件，从而在许多方面提高性能。

• ⑥ 统一批流处理

  数据架构无需在批处理和流式中区分，它们都以相同的表视图对外暴露，复杂性更低，速度更快。无论是从流还是批处理中读取都能获取一致的数据快照。

（2）数据湖表格式-社区活跃度

Delta Lake、Apache Iceberg 和 Apache Hudi 是目前最突出的开源数据湖 Table Format 产品。

Delta Lake 2.0 在发布之后一路飙升，Star 的活跃数最高。起源最早的是 Hudi，其次是 Iceberg。

---

（3）数据湖表格式-读写特性

数据湖表格式在读写上需要关心的几个点:

• 一是增量查询（Incremental Query），它在构建流数仓或批数仓时是一个非常重要的特性。
• 二是时间旅行（Time Travel），我们能用它对数据进行回溯和重放，去做数据的回补。
• 三是并发（Concurrency），不同的 Job 可以同时操作一张表。
• 四是主键（Primary Keys），有了它可以像传统数据库一样更好地去做更新，比如进行 Upsert 操作。

（4）数据湖表格式-表服务

表服务主要关心 Compaction 和 Cleaning，还有 Schema Evolution 等能力。

---

（5）数据湖表格式-平台能力

平台能力主要关注数据质量检测（Data Quality Validation）、数据写入监控指标（Monitoring）的成熟度等。

（6）数据湖表格式-生态支持

---

3. 数据湖应用场景

1. DB 数据入仓/湖

• 第一种是像 MySQL 这种传统数据库通过 Binlog 发布到消息队列 Pulsar，再通过计算引擎去消费它，并存储到数据湖。
• 第二种是通过 FlinkCDC 的 Connector 组件写入到数据湖。
• 第三种是通过 DTS 这种数据传输服务写入到数据湖里面，这样做的好处是能够将 T+1 数据新鲜度提升到 5 分钟。

---

2. 近实时 OLAP

主要是通过消费 MQ 里面的数据，通过 Flink 或者 Spark 计算引擎对数据进行加工和处理，写入到数据湖。通过 Presto、StarRocks 等 OLAP 引擎去进行实时查询，用来支撑分钟级别的查询场景。

---

3. 近实时 ETL

主要特点是利用数据湖的增量、多版本查询、TimeTravel 等能力进行构建。

• 首先通过计算引擎消费 MQ 数据并把依次写入到 ODS 层、DWD 层、DWS 层，DWD 层可以通过流读 DWS 层写入到 DWD 层，DWS 亦是如此。
• 最后通过 DWS 层把数据写入到我们需要分析的服务里面。

---

4. 湖仓一体

湖仓一体是在构建近实时 ETL 场景的基础之上，按照完整的数据仓库分层模型去建设数仓。因为数据湖组件实现了批流一体的存储，再通过批流一体的计算引擎，把数据写入到第三方的结果数据库中，从而提供 API 或者其它的服务的能力，去构建湖仓一体。

---

4. 数据湖探索

1. Stream Warehouse

现在的湖仓只能做到近实时、分钟级，如果想做到像 MQ 一样实时的级别，就需要借助 MQ 的能力。

Stream Warehouse 的实现上会有两种方式。第一种是在 MQ 中引入湖组件，第二种是两者的缝合，第三种是湖组件中引入 MQ。

以第一种 MQ 中引入湖组件为例，使用 Pulsar 作为 MQ，生产端和消费端会产生相应的数据写入到 Ledger 中，通过 Ledger 持久化所需要的消息文件。中间过程是已经关闭的 Ledger 数据会进行 Offloader 离线读取，写入到 Hudi 这样的湖组件中。热备的数据继续走 Ledger（MQ 体系），冷备的数据通过 Hive 或者 Presto 去读 Hudi，从而达到同时兼顾实时的场景。

---

Stream Warehouse主要是 Flink 社区提出的，主要包括两个组件：LogStore 和 FlieStore。LogStore 主要是使用 MQ 消息中间件（Pulsar），FlieStore 主要是使用一种 LSM 的文件格式。写的时候双写 LogStore 和 FlieStore，读的时候通过先读 FlieStore，再读 LogStore 方式去回放和流读数据湖的数据。

---

2. Fairhouse

Fairhouse 其实是 Sundeck 提出的一个新的框架或体系，大概会在 2025 年初步完成实现。相比于 Lakehouse，Fairhouse 的架构变成了三层，原来 Lakehouse 的 Query Engines 这一层拆分成计算引擎层和 API 层。

比如原来通过 Trino SQL+ Trino Engine 去访问数据湖的方式，变成了调用 Trino SQL 的 API，然后由计算引擎层决定是用 Spark 引擎或 Velox 引擎去执行，对计算引擎的选择更加智能，这样做会更加公平。