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

狂野的拉布拉多哎
561 阅读9分钟

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

01 发展历史

Hadoop->Hive->湖仓一体 数据湖+数据仓库

1.1 Hadoop

  • 数据湖最开始的概念——分布式存储HDFS

  • 使用目录来区分不同的数据集

    • /douyin

      • /20220623
      • /20220624

    • /toutiao

  • 好处

    • 同一公司/组织可以使用共享存储
    • 数据访问方便，灵活性高

  • 坏处:

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

1.2 Hive

  • 数据湖的演进Hive Metastore

  • 对数据湖中的数据集进行集中 “定义”

    • 数据湖中存在了哪些数据集
    • 它们都存储在什么目录
    • 数据集的schema是什么样子的
    • 数据集有哪些分区，每个分区的目录是什么

  • 如果这张hive表是静态的，没有新增写入，则所有读取方都能很便捷的使用

  • 问题来了:

    • 假设Reader A和B都正在读取分区/20220623下的文件
    • 此时Writer B开始重写/20220623分区，一些文件被删了，一些文件增加了，一些文件还在修改中
    • Reader A和B读到的文件可能是不同的!

  • 我们需要 Transaction ACID !

  • 问题又来了

    • 分区/20220623下存储了schema为date | userld | phoneNumber 的数据
    • 需要注意:Hive allows us to add column after last column only
    • 根据合规，我需要删掉phoneNumber，但是在 Hive表上做不到。只好重写一张表(耗费资源)我们需要支持更多样的schema 变更!

  • And more!

1.3 湖仓一体

什么是数据湖？

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

什么是数据仓库?

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

image.png

image.png

湖仓一体（数据湖的现状）︰

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

1.4 业界三大数据湖

image.png

image.png

image.png

1.5 关于“数据湖”：

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

02 核心技术

2.1 文件结构

写入数据时

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

image.png

image.png

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：持久性——转账服务器重启，结果不变

image.png

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上做进一步处理

image.png

3 各有所长

3.1 lceberg

lceberg是什么？

lceberg是一个Well-designed Metadata Layer

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

image.png lceberg工作重点

  • 用户体验

    • Schema evolution
    • Partition evolution
    • Hidden partition
    • Time Travel
    • Version Rollback

  • 性能

    • 快速file plan
    • 更多的filter方式

  • 可靠性

    • ACID Transaction
    • 完全开源，由Apache孵化开发

Data files Filter

  • 一些有助于filter 的数据被层层记录，比如:
  1. Manifest file记录了每个data file的分区范围
  2. Manifest list记录了每个manifest file的分区范围分区可以被快速定位!可以做manifest list级别裁剪。
  3. Manifest file记录了每个data file每一列的最大值，最小值可以通过其他的列(Userld)做data file 级别裁剪

lceberg的分区方式:

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

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．索引表:快速定位一条数据的位置
  4. Streaming Ingestion Service6．完全开源，由Apache孵化

Timeline Serivce & Upsert & Incremental

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

image.png

Copy on Write

image.png

Merge On Read

image.png

3.3 Delta Lake

Delta Lake工作重点

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

流批一体

image.png

04 总结场景

4.1 回顾：三个数据湖的异同。

image.png

4.2 三个数据湖的热度。

091c9e90d1a84eed2eba2aae1f12b6b.jpg

4.3 技术选型

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

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

长期来据湖取代Hive为HDFS上的表格式标准是必然的，在选择之前问自己四个间题：

  • 我需要的feature在那个数据湖上是最稳定的
  • 哪一个数掘湖能够用最简单的接入方式 (sSQL)用上最完善的功能
  • 那一个数据湖有计算引擎侧的支持和社区的支持
  • 哪一个数据湖的版本管理做的最好，最鲁棒

Feature Store：

Feature Store 在字节的诞生

初心

  • instance pb样本读放大、不能列裁剪=>很难落许多特征进样本
  • 2.instance pb 样本写放大、 copy-on-write=>很难做特征回溯调研

收益：

  • 支持落原始特征做特征调研
  • 解决读放大、 支持列裁剪
  • 解决写放大、 支持merge-on-read
  • 支持特征 schema 校验
  • 列式存储优化存储空间
  • Arrow 格式优化序列化开销

Feature Store及其平台：

  • 基于Apache Iceberg 做了大量定制与优化

  • 站内存储约220 PB 训练样本

    • 最大单表30PB 15K个特征
    • 相比 instance pb 样本能节省约 30%~50%空间

  • 平台端到端体验完整、用户使用成本低

    • 控制面板、特征监控、 数据维护(样本回潮、 TTL、脏数据处理等)

  • 对特征回溯及特征调研场景做了专门强化

    • 支持Update 语义操作和数据分支

批流一体:近实时的数据写入与数据就绪(Readiness)

  1. 例子:消息队列直接入湖、流式 Upsert
  2. 应用:能同时训最新（流式)和历史(批式)

更强的算力:要求更快的读数据

  1. 例子:分布式任务扫描、向量化读与读时合并、统一内存格式(Apache Arrow)
  2. 应用:数据读取不应成为训练瓶颈

总结： 在本节课的学习中，我了解到了数据湖的发展过程，知道了数据湖的最新发展状态是湖仓一体，湖仓一体是一种结合了数据湖和数据库又是的新范式，在用于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。湖仓一体是一种更开放的新型架构。

avatar
文章
阅读
粉丝