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

写在前面

第一次解除数据湖的概念，从技术和业务需要的角度去认识这个新的应用概念，包括湖仓一体的架构，数据仓库到数据湖的沿革等。

笔记正文

一、发展历史

1. Hadoop

• 没有记录文件的SCHEMA，经常使用Schema on Query的方式
• 难以得知数据集包含哪些文件，怎样分区组织的
• 多个程序如果都在修改这个数据集，其他程序难以配合修改

2. Hive

Transaction ACID

• Hive allows us to add column after last column only 无法在原表删除，只好重写一个表，Schema变更复杂。

3. 湖仓一体

• 数据仓库
  • 将数据从数据源提取和转换，加载到目的地
  • 数据仓库存储和计算不分离
  • 数据仓库严格控制写入数据得Schema
• 湖仓一体
  • 数据仓库对数据的严格管理实现到了低成本的分布式存储上
  • Transaction ACID
  • Schema管理
  • 存储计算分离
  • 支持多种计算引擎和文件格式
• 业界三大数据湖
  • Hudi
  • Iceberg
  • Delta Lake

二、核心技术

1. 设计一个简单的数据湖

• 要求
  • 1. 按照date分区，schema是userId, date, event, phone
  • 2. 每天写入新数据
  • 3. 需要列存格式
• 文件结构
  • 1. 按照每条数据date分区
  • 2. 使用metadata文件记录表信息
• Time Travel
  • 1. 每次写入生成一个新的元数据文件，记录变更
    • 每次写入创建一个json文件以递增版本号命名
    • N个json文件聚合，记录完整的分区文件信息
    • checkpoint记录上次做聚合的版本号
  • 2. 分区数据Update时不删除旧数据，保证新旧共存
  • 3. 元数据中存储具体的文件路径而不只是分区文件夹
• Transaction
  • ACID in data lake
    • A原子性: 本次写入要么对用户可见、要不不可见（设计）
    • C一致性: 输入什么 落盘什么（计算引擎保证）
    • I事务隔离：正确解决读写冲突与写写冲突
    • D持久性：落盘数据后重启服务器数据结果不变
• Schema Evolution
  • 用户不直接读取parquet文件本身
  • 数据湖内部读取后在schema上进行处理
  • ID将data和metadata进行一一对应

三、独到之处

1. Iceberg

• 用户体验
  • Schema evolution
  • Partition evolution
  • Hidden partition
  • Time travel
  • Version Rollback
• 性能
  • 快速 file plan
  • 更多filter方式
• 可靠性
  • ACID transaction
• 完全开源

2. Hudi

Hadoop Upsert Delete and Incremental

• Timeline Service
• Hudi Table Type
• 高效Upserts
• 索引表
• Streaming Ingestion Service
• 完全开源

3. Delta Lake

• ACID Transaction
• Schema 校验
• 流批一体
• Time travel
• Upsert/Delete
• Z-Order优化
• 开源了一部分

四、总结场景

	IceBerg	Hudi	Delta Lake
ACID Trasaction	√	√	√
Partition Evolution	√	×	×
Schema Evolution	√	Partial	Limited
Time-Travel	√	√	√

• 短期
  • Hudi满足Upserts强需求
  • 可扩展性Iceberg更优
  • Z-order优化最需要Delta
• 长期——重要的问题
  • 需要的feature是在哪个数据湖上最稳定
  • 那个数据湖能用最简单的接入（SQL）实现最完善的功能
  • 哪个数据湖有计算引擎测的支持和社区支持
  • 哪个数据湖版本管理最好，最鲁棒