数据湖三剑客：Delta Lake、Hudi与Iceberg详解 | 青训营笔记这是我参与「第四届青训营」笔记创作活动

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

一、发展历史。

1.数据湖发展阶段1-Hadoop：

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

坏处:

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

2.数据湖发展阶段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!

3.数据湖发展阶段3-湖仓一体：

题外话——数据仓库

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

湖仓一体(数据湖的现状):

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

4.业界三大数据湖：

公司简介:

国外版滴滴，打车软件
在行程规划、拼车、顺风车等业务上数据量都很大
数据写入面临挑战

项目简介:

项目名称:Hudi
最初希望解决的问题:使数据写入能够更低延迟
开源时间:2016年
官网:hudi.apache.org/
Github : github.com/apache/hudi

公司简介:

流媒体
《纸牌屋》、《鱿鱼游戏》、《怪奇物语》
开发工作:存储用户观看数据，推荐剧集

项目简介:

名称: lceberg
开源时间:2018
最初希望解决的问题:摆脱Hive架构带来的问题
官网: iceberg.apache.org/
Github : github.com/apache/iceb…

公司简介：

起源于UCB，参与Spark的制作
超级独角兽
主打湖仓一体

项目简介:

项目名称:Delta Lake.
开源时间:2019 (开源了，但没完全开源)
官网:delta.io/
Github: github.com/delta-io/de…

5.关于“数据湖”：

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

二、核心技术。

设计一个简单的数据湖：

1.文件结构：

写入数据湖时：

1、按照每条数据的date进行分区
2、额外使用metadata 文件记录表信息，如右图所示

2.Time travel：

要点:

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

1.每一次写入操作，创建一个新的json文件，以递增版本号命名,记录本次新增/删除的文件。

2.每当产生N个json，做一次聚合,记录完整的分区文件信息。

3.用checkpoint记录上次做聚合的版本号。

3.Transaction：

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

以A给B转账10元为例:

Atomicity:原子性——要么A-10 B+10，要么都不变
Consistency:一致性——不可以A-10 B+5
Isolation:事务隔离——A和C同时给B转10，B最终结果应是+20
Durability:持久性——转账服务器重启,结果不变

数据湖中的ACID:

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

3.1原子性：

写入流程：

1.写入parquet 数据文件
2.写入json元数据文件

如何确保原子性？(从用户可见性入手!)

用户只会读取以版本号数字命名的son文件，每次都读取到最大的版本号作为数据集的现状
新的写入写完parquet后开始写json文件，使用hash值对json文件命名,如a2fs4hfg8ee.json
直到son文件内容写入完串,利用hdfs的renamelfAbsent能力将a2fs4hfg8ee.json替换为000006.json,到此为止commit完成，新的读取将会以000006.json作为最新版本

读写冲突已解决：

新的写入除非已经commit，否则用户读不到
用户正在读的分区，被另一个写入进行了更新，数据不会进行替换，而是共存

3.2事务隔离：

Update写入流程：

从最新的版本中，获取需要update的分区
乐观锁先把该写入的文件全落盘，然后进入写 json 阶段
分几种情况:
- 发现版本号和一开始没区别，直接写新的版本。
- 发现版本号增加了，看看新增的这些版本有没有更新我要更新的分区?
  - 没有，直接写新的版本，
  - 有，两者都更新了同一分区，得重新update了.

4.Schema Evolution：

Add/Drop/Rename

重要：

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

ID将data 和metadata 的列名做——对应!

唯确定的ID.新增列赋予新ID.删列ID不复用。
写入数据时，1D也写入数据文件
读取数据时，用ID做映射，如果
- Data中没有,metadata中有:ADD
- Data中有,metadata中没有:DROP
- Data和metadata中都有同一ID，但是name不同: RENAME
- 如果都有同一列名，而ID不同?

三、各有所长。

1.Iceberg工作重点。

用户体验：

Schema evolution
Partition evolution
Hidden partition
Time Travel
Version Rollback

性能

快速ile plan
更多的filter方式

可靠性

ACID Transaction

完全开源，由Apache孵化开发

1.1Well-designed Metadata Layer

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

1.2 Data File Filter

一些有助于ilter的数据被层层记录，比如:

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

1.3 Hidden Partition

传统的分区方式： 数据中包含了date列，则按照date分区;如果希望按照hour分区，则需要新增hour列

lceberg的分区方式:

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