【概述】
这是hudi系列的第一篇文章,先从核心概念,存储的文件格式加深对概念的理解,后续再逐步对使用(spark/flink入hudi,hudi同步hive等)、原理(压缩机制,索引,聚族等)展开分享~
【什么是数据湖】
简单来说,数据湖技术是计算引擎和底层存储格式之间的一种数据组织格式,用来定义数据、元数据的组织方式,并实现以下的功能:
支持事务(ACID)
支持流批一体
支持schema演化和schema结束
支持多种底层数据存储HDFS、OSS、S3
从实现上来说,基于分布式文件系统之上,以传统关系型数据库的方式对外提供使用。
开源的数据湖实现有Hudi、IceBerg、Delta。
【hudi介绍】
Apache hudi代表Hadoop Upserts Deletes Incrementals。能够使HDFS数据集在分钟级的延时内支持变更,也支持下游系统对这个数据集的增量处理。
hudi数据集通过自定义的InputFormat兼容当前hadoop生态系统,包括Hive、Presto、Trino、Spark、Flink,使得终端用户可以无缝的对接。
Hudi会维护一个时间轴(这个是hudi的核心),在每次执行操作时(如写入、删除、压缩等),均会带有一个时间戳。通过时间轴,可以实现在仅查询某个时间点之后成功提交的数据,或是仅查询某个时间点之前的数据。这样可以避免扫描更大的时间范围,并非常高效地只消费更改过的文件。
上面是一些理论上的介绍,简单的使用,官网也有对应的例子,这里就不再啰嗦,下面我们介绍下hudi的一些核心概念,hudi的持久化文件及文件格式。
【相关概念】
1. 表类型
hudi中表有两种类型
MOR(Merge on Read)
在读取时进行合并处理的表。通常而言,写入时其数据以日志形式写入到行式存储到文件中,然后通过压缩将行式存储文件转为列式存储文件。读取时,则可能需要将存储在日志文件中的数据和存储在列式文件中的数据进行合并处理,得到用户期望查询的结果。
COW(Copy on Write)
在写入的时候进行拷贝合并处理的表。每次写入时,就完成数据的合并处理,并以列式存储格式存储,即没有增量的日志文件。
两者的一些对比
权衡 |
COW |
MOR |
数据延迟 |
更高 |
更低 |
更新代价(I/O) |
更高 |
更低 |
parquet文件大小 |
更小 |
更大 |
写放大 |
更高 |
更低(取决于压缩策略) |
2. 时间轴
hudi维护了在不同时间点中(instant time)在表上的所有(instant)操作的时间轴,这有助于提供表的即时视图,同时还能有效的提供顺序检索数据。
instant由以下组件组成:
instant action:对数据集(表)的操作类型(动作)。
instant time:通常是一个时间戳,它按照操作开始时间的顺序单调递增。
state:当前的状态
关键的操作类型包括:
commit
原子的将一批数据写入数据集(表)中
cleans
清除数据集(表)中不再需要的老版本文件
delta_commit
增量提交,表示将一批记录原子的写入MOR类型的表中,其中一些/所有数据可能仅被写入增量日志文件中
compaction
通常而言,是将基于行式的日志文件移动更新到列式文件中。
rollback
表明提交或增量提交不成功后的回滚,此时会删除写过程中产生的任意分区文件。
savepoint
将某些文件组标识为"已保存",这样在清理时不会进行删除。在灾备或数据恢复的场景中,有助于恢复到时间轴上的某个点。
任意给定的instant只能处于下面的其中一个状态:
REQUESTED:指明一个动作已经被调度,但还未进行执行
INFLIGHT:指明一个动作正在被执行
COMPLETED:指明时间轴上的一个已完成的动作
状态由requested->inflight->complete进行转换。
3. 视图
hudi支持三种类型的视图:
读优化视图(Read Optimized Queries)
该视图仅将最新文件切片中的基本/列文件暴露给查询,并保证与非hudi列式数据集相比,具有相同的列式查询性能。简单而言,对于MOR表来说,仅读取提交或压缩后的列式存储文件,而不读取增量提交的日志文件。
增量视图(Incremental Queries)
对该视图的查询只能看到从某个提交/压缩后写入数据集的新数据。该视图有效地提供了更改流,来支持增量数据。
实时视图(Snapshot Queries)
在此视图上的查询将某个增量提交操作中数据集的最新快照。该视图通过动态合并最新的基本文件来提供近实时的数据集。
视图类型和表的关系为:
COW | MOR |
|