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

serendipity__
209 阅读5分钟

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

数据湖三剑客：Delta Lake、Hudi 与 Iceberg 详解

发展历史

1.1 数据湖发展阶段一 —— Hadoop

image.png

  • 数据湖最开始的概念——分布式存储HDFS
  • 使用目录来区分不同的数据集
  • /douyin
    • /20220623
    • /20220624
  • /toutiao
  • 好处:
  • 同一公司/组织可以使用共享存储
  • 数据访问方便，灵活性高

image.png

  • 坏处:（数据沼泽）
  1. 没有记录文件的schema (包括列名、列类型) , 经常使用Schema on Query的方式
  2. 难以得知数据集包含了那些文件，是通过什么样的分区组织的
  3. 如果多个程序都在修改这个数据集(修改数据、修改表结构)，其他程序难以配合做修改

1.2 数据湖发展阶段二——Hive

image.png

  • 数据湖的演进—— Hive Metastore
  • 对数据湖中的数据集进行集中"定义”
    • 数据湖中存在了哪些数据集
    • 它们都存储在什么目录
    • 数据集的schema是什么样子的
    • 数据集有哪些分区，每个分区的目录是什么

image.png

1.3 数据湖发展阶段三 —— 湖仓一体

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

image.png

image.png

image.png

  • 湖仓一体（数据湖的现状）
  • 结合了数据湖和数据仓库的优势
  • 将数据仓库中对于数据的严格管理直接实现到了低成本的分布式存储之上
  • Key Features：
    • Transaction ACID
    • Scheme管理
    • 存储计算分离
    • 支持多种计算引擎和文件格式

image.png

1.4 业界三大数据湖

image.png

image.png

image.png

二、核心技术

2.1 文件结构

写入数据湖时

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

2.2 Time travel

要点：

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

2.3 Transaction

ACID.是指数据库在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性。 以A给B转账10元为例:

  1. Atomicity: 原子性——要么A-10 B+10,要么都不变
  2. Consistency: 一致性——不可以A-10 B+5
  3. Isolation: 事务隔离 —— A和C同时给B转10. B最终结果应是+20
  4. Durbility: 持久性——转账服务器重启，结果不变 数据湖中的ACID:
  5. Atomicity: 原子性-本次写入要么对用户可见，要么不可见(需要设计)
  6. Consistency: 一致性-输入是什么，落盘的就是什么(由计算引|擎保证)
  7. Isolation: 事务隔离-正确解决读写冲突和写写冲突(需要设计)
  8. Durability: 持久性-落完数据后，即便服务器重启结果不变(由存储引|擎保证)

2.3.1 原子性

写入流程

写入parquet数据文件 写入json元数据文件

如何确保原子性？

  1. 用户只会读取以前版本号数字命名的json文件，每次都读取到最大版本号作为数据集的现状
  2. 新的写入写完parquet后开始写json文件，使用hash值对json文件命名。
  3. 知道json文件内容写入完毕，利用hdfs的renamelfAbsent能将文件名字替换。

2.3.2 事务隔离

update写入流程

  1. 从最新的版本中，获取update的分区
  2. 乐观锁先把写入的五年间全落盘，然后进入写json阶段

image.png

三、各有所长

3.1 Lceberg工作重点

  • 用户体验
      1. Schema evolution
      1. Partition evolution
      1. Hidden partition
      1. Time Travel
      1. Version Rollback
  • 性能
    • 1.快速file plan
    • 2.更多的filter方式
  • 可靠性
      1. ACID Transaction
  • 完全开源，由Apache孵化开发

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 Serivce & Upset & Incremental

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

3.2.2 Copy on Write

image.png

3.2.3 Merge On Read

image.png

3.3 Dalta Lake工作重点

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

四、总结场景

4.1 三个数据湖异同

image.png

4.2 三个数据湖的热度

image.png

image.png

4.3 技术选型

短期来看:每个项目都有一些属于自己的功能:

  • 如果强需求Upserts,也许Hudi是最好的选择
  • 如果希望可扩展性强，那么设计优良的lceberg是最好的选择
  • 如果希望用上Z-Order等优化，那么掏钱买Databricks的企业版Delta是不二之选 长期来看:数据湖取代Hive,成为HDFS上的表格式标准是必然的，在选择之前问自己四个问题:
  1. 我需要的feature在哪个数据湖上是最稳定的
  2. 哪一个数据湖能够用最简单的接入方式(SQL) 用上最完善的功能
  3. 哪一个数据湖有计算引擎侧的支持和社区的支持
  4. 哪一个数据湖的版本管理做的最好，最鲁棒

字节跳动数据湖场景举例 —— Feature Store

➢初心

  1. instance pb样本读放大、不能列裁剪=>很难落许多特征进样本
  2. instance pb样本写放大、copy- on-write ->很难做特征回溯调研 ➢收益
  3. 支持落原始特征做特征调研
  4. 解决读放大、 支持列裁剪
  5. 解决写放大、 支持merge on-read
  6. 支持特征schema校验
  7. 列式存储优化存储空间
  8. Arrow 格式优化序列化开销

image.png

avatar
文章
阅读
粉丝