数据湖三剑客:Delta Lake、Hudi与lceberg详解 | 青训营笔记

Matrix8295
421 阅读4分钟

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

0 引言

  • 数据湖三阶段:Hadoop、Hive、湖仓一体
  • 湖仓一体项目解决的关键问题:Transaction、Schema变更、冲突解决
  • 不同湖仓一体项目的独到之处
  • 三个湖仓一体项目的对比，数据湖在字节跳动中的应用

数据湖思维导图.png

1 发展历史

数据湖发展阶段：Hadoop、Hive、湖仓一体

其中Hadoop的缺点：没有记录文件的schema(包括列名、列类型)，难以了解数据集分区信息，如果多个程序都在修改这个数据集（修改数据、修改表结构)其他程序难以配合做修改。

Hive缺点：不太能支持Transaction ACID和多样的schema变更

数据仓库定义：

  • 数据仓库将数据从数据源提取和转换，加载到目的地
  • 数据仓库存储+计算不分离
  • 数据仓库严格控制写入数据的schema

业界三大数据湖：lceberg、Hudi、Delta Lake

湖仓一体的主要特征：Transaction ACID、Schema管理、存储计算分离、支持多种计算引擎和文件格式。

湖仓一体.png

Iceberg Github 地址
Hudi GitHub 地址
Delta Lake Github 地址（部分开源）

2 核心技术

2.1 文件结构

文件结构.png
写入数据湖时按照每条数据的date进行分区，额外使用metadata文件记录表信息（JSON格式）。

2.2 Time travel

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

步骤：

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

2.3 Transaction

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

  • Atomicity：原子性–指整个数据库事务是不可分割的工作单位
  • Consistency：一致性–指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
  • Isolation：事务隔离–指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间
  • Durability：持久性–指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来

写入parquet数据文件或json元数据文件时，新的写入除非已经commit否则用户读不到。用户正在读的分区，被另一个写入进行了更新，数据不会进行替换，而是共存。这样解决了原子性问题中的读写冲突。

写写冲突主要发生在update/inssert/delete中，利用事务隔离可以尽量避免。

2.4 Schema Evolution

在Add/Drop/Rename时，用户并不直接读取parquet文件本身，而是通过数据湖接口读取，如：Dataset<Row> ds = simpleDataLake.read(mytable).option(date=2020-01-01)，数据湖内部会读取应该读的parquet，并在schema上做进一步处理。

3 各有所长

3.1 lceberg

lceberg.png

  • Metadata files定义了表结构，存储了snapshot信息，分区列信息等
  • Manifest lists存储了一个snapshot中所有manifest的信息
  • Manifests存储了一些data files的信息
  • Data files就是具体的数据文件

Manifest list记录了每个manifest file的分区范围，分区可以被快速定位，可以做manifest list级别裁剪。
Manifest file记录了每个data file的分区范围，并且记录了每个data file每一列的最大值、最小值可以通过其他的列(Userld)做data file 级别裁剪。

lceberg的分区方式：

  • 数据中包含timestamp列，设置好partition transform方式
  • 设置为date时,iceberg帮你转化为date分区
  • 设置为hour时，iceberg帮你转化为hour分区
  • Iceberg记录了这层转化关系，并且按你的需要进行partition evolution

3.2 Hudi

Hudi工作重点：

  1. Timeline service: Hudi管理transaction的方式。
  2. Hudi Table Type: Copy on Write /Merge on Read。
  3. 高效的Upserts: update or insert。 4．索引表：快速定位一条数据的位置。
  4. Streaming Ingestion Service。

Hudi.png

  • Timeline Service:记录的信息类似于metadata。
  • Upsert:每一条样本都有一个主键PK，当Upsert一条数据时，如果现有的数据中有这个PK，则update这条数 据。否则直接insert这条数据。
  • Incremental:某个时间点后新增的数据。

3.3 Delta Lake

Delta Lake工作重点：

  1. ACID Transaction
  2. Schema校验(不是evolution)
  3. 流批一体
  4. Time Travel
  5. Upsert/Delete
  6. Z-Order优化等

4 总结场景

4.1 三个数据湖的异同

三个数据湖的异同.png

4.2 技术选型

  • 如果强需求Upserts，也许Hudi是最好的选择
  • 如果希望可扩展性强，那么设计优良的Iceberg是最好的选择
  • 如果希望用上Z-Order等优化，那么掏钱买Databricks的企业版Delta是不二之选

考虑：feature在数据湖稳定性、可以简单接入SQL、支持计算引擎、鲁棒性好

引用参考

【大数据专场 学习资料四】第四届字节跳动青训营

avatar
文章
阅读
粉丝