这是我参与「第四届青训营 」笔记创作活动的第10天

1. 发展历史

1.1. 数据湖发展阶段 - Hadoop

1.2. 数据湖发展阶段 - Hive

1.3. 数据湖发展阶段 - 湖仓一体、

1.4. 业界三大数据湖

1.5. 关于“数据湖”

• 数据相关概念比较新，一直处在演进当中
• 一开始是HDFS，裸pb、txt日志等等，叫数据湖
• 后来出现了Iceberg、Hudi、Delta Lake了，数据湖概念就基本等于这些产品了
• 也更贴近于Lakehouse的概念

2. 核心技术

2.1. 文件结构

写入数据时

1. 按照每条数据的date进行分区
2. 额外使用metadata文件记录表信息

2.2. Time travel

要点：

1. 每次写入都生成一个新的元数据文件，记录变更
2. 分区数据在Update时，不要删除旧数据，保证新旧共存
3. 元数据中存储的具体文件路径，而不仅仅是分区文件夹

• 每一次写入操作，创建一个新的json文件，以递增版本号命名，记录本次新增/删除的文件
• 每当产生N个json，做一次聚合，记录完整的分区文件信息
• 用checkpoint记录上次做聚合的版本号

2.3. Transaction

ACID，是指数据库在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特征

以A个B转账10元为例子：

1. Atomicity：原子性——要么A-10 B+10，要么都不变
2. Consistency：一致性——不可以A-0 B+5
3. Isolation：事务隔离性——A和C同时转给B10元，B最终应该+20
4. Durability：持久性——转账服务器重启，结果不变

2.3.1. 原子性

写入流程：

1. 写入parquet数据文件
2. 写入json文件

如何确保原子性？

1. 用户只会读取以版本号数据命名的json文件，每次读取到最大的版本号作为数据集的现状
2. 新的写入写完parquet后开始写json文件，使用hash值对json文件命名，如a2fs4hg8ee.json
3. 直到json文件内容写入完毕，利用hdfs的renameIfAbsent能力将其替换为000006.json，到此位置commit完成，新的读取将会以000006.json作为最新版本

2.3.2. 事务隔离

Update写入流程：

1. 从最新的版本中，获取需要Update的分区
2. 乐观锁先把该写入的文件全落盘，然后进入写json阶段
3. 分几种情况：
   1. 发现版本号和一开始没区别，直接写新的版本
   2. 发现版本号增加了，看看新增的这些版本有没有更新我要更新的分区
      1. 没有，直接写新的版本
      2. 有，两者都更新了同一分区，得重新update了

2.4. Schema Evolution

Add/Drop/Rename

重要：

• 用户并不直接读取parquet文件本身，而是通过数据湖接口读取，如

Dataset<Row> ds = simpleDataLake.read(mytable).option(data=2020-01-01)

• 数据湖内部会读取应该读的parquet，并schema上做进一步处理

3. 各有所长

3.1. Iceberg 工作重点

用户体验

1. Schema evolution
2. Partition evolution
3. Hidden partition
4. Time Travel
5. Version Rollback

性能：

1. 快速的file plan
2. 更多的filter方式

可靠性：

1. ACID transaction

完全开源，由Apache孵化开发

3.1.1. Well-designed Metadata Layer

3.1.2. Data File Filter

3.1.3. Hidden Partition

3.2. Hudi

Hadoop Upsert Delete and Incremental

Hudi工作重点：

1. Timeline service：Hudi管理transaction的方式
2. Hudi Table Type：Copy on Write / Merge on Read
3. 高效的Upserts：update or insert
4. 索引表：快速定位一条数据的位置
5. Streaming Ingestion Service
6. 完全开源，由Apache孵化

3.2.1. Timeline service & Upsert & Incremental

3.2.2. Copy on Write

3.2.3. Merge on Read

3.3. Delta Lake 工作重点

1. ACID Transaction
2. Schema 校验（不是evolution）
3. 流批一体
4. Time Travel
5. Upsert / Delete
6. Z-Order 优化
7. 只开源了一部分，由Databricks自己主导开发，Z-order等优化的实现未开源

3.3.1. 流批一体

4. 总结场景

4.1. 三个数据湖的异同

4.2. 三个数据湖的热度

4.3. 技术选型

4.3. 字节跳动数据湖场景举例 - Feature Store