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

166 阅读3分钟

这是我参与「第四届青训营」笔记创作活动的第2天,学习内容为《数据湖三剑客Delt Lake、Hudi、Iceberg详解》,内容包括 数据湖基本概念和发展历史、数据湖核心技术、数据湖三剑客特点

一. 数据湖的基本概念

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

二. 发展历史

Hadoop

  1. 数据湖最开始的概念---分布式存储HDFS
  2. 好处:同一公司/组织可以使用共享存储;数据访问方便,灵活性高
  3. 坏处:没有记录文件的schema、难以得知数据集包含哪些文件,是通过什么样的分区组织的、如果多个程序都在修改这个数据集,其他程序难以配合做修改

Hive

  1. 数据湖的演进---Hive Metastore(元数据存入mysql中)
  2. 对数据湖中的数据集进行集中定义
  3. 问题:

image.png

湖仓一体

  1. 引出问题: 什么是数据仓库?

答:

  • 数据仓库将数据从数据源提取和转换,加载到目的地
  • 数据仓库存储+计算不分离
  • 动数据仓库严格控制写入数据的schema
  1. 数据仓库与数据湖对比:

image.png

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

三. 数据湖核心技术

1.文件结构

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

2.Time travel

  • 每次写入都生成一个新的元数据文件,记录变更(以递增版本号命名,记录本次新增/删除的文件)
  • 分区数据在Update时,不删除旧数据,保证新旧共存
  • 元数据中存储具体的文件路径,而不仅仅是分区文件夹
  • 每当产生N个json,做一次聚合,记录完整的分区文件信息
  • 用checkpoint记录上次做聚合的版本号

3. Transaction

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

  • 一致性:输入是什么,落盘就是什么(计算引擎保证)
  • 持久性:落完数据后,即便服务器重启结果不变(存储引擎保证)
  • 原子性:本次写入要么对用户可见,要么不可见(需要设计)
  • 事务隔离:正确解决读写冲突和写写冲突(需要设计)

4.Schema Evolution

  • ** 用户并不直接读取parquet文件本身,而是通过数据湖接口读取**
  • ** 数据湖内部会读取应该读的parquet,并在schema上做进一步处理**
  • ID将data和metadata的列名做一一对应
  • 唯一确定的ID,新增列赋予新ID,删列ID不复用
  • 写入数据时,ID也写入数据文件
  • 读取数据时,用ID做映射

四. 各有所长

lcberg 重点

image.png

Well-designed Metadata Layer、Data File Filter

image.png

Hidden Partition

  • 传统的分区:数据中包含date列,按照date分区,如果希望按照hour分区,需要新增hour列
  • 数据中包含timestamp列,设置好partition transform方式,iceberg会转换为对应的分区
  • 按需进行partition evolution

Timeline Serivce & Upsert & Incremental

image.png

Copy on Write

image.png

Merge on Read

image.png

Delta Lake 重点

  • ACID Transaction
  • Schema校验(不是evolution)
  • 流批一体
  • Time Travel
  • Upsert/Delete
  • Z-Order优化
  • 只开源了一部分,由Databricks自己主导开发,Z-order 等优化的实现未开源

流批一体

image.png