1.1

技术促进数据在数据湖上真正实时流动起来并为用户提供实时离线一体化的开发体验。

Flink

Flink

Realtime的数据湖存储项目。

2023年3月12日FTS进入

Apache

Paimon是一个流数据湖平台具有高速数据摄取、变更日志跟踪和高效的实时分析的能力。

1读/写Paimon

2对于写入它支持来自数据库变更日志CDC的流式同步或来自离线数据的批量插入/覆盖。

2生态系统

OLAP系统例如Clickhouse它以流方式接收处理后的数据并为用户的即席查询提供服务。

批量存储例如Apache

在流执行模式下它的作用就像一个消息队列。

查询它的行为就像从历史数据永不过期的消息队列中查询流更改日志。

1.2

按照您喜欢的方式更新记录。

保留最后一条记录、进行部分更新或将记录聚合在一起由您决定。

4变更日志生成

Paimon还支持append-only表提供有序的流式读取来替代消息队列。

6模式演化

快照捕获表在某个时间点的状态。

用户可以通过最新的快照来访问表的最新数据。

通过时间旅行用户还可以通过较早的快照访问表的先前状态。

1.3.2

分区是一种可选方法可根据日期、城市和部门等特定列的值将表划分为相关部分。

每个表可以有一个或多个分区键来标识特定分区。

1.3.3

未分区表或分区表中的分区被细分为存储桶以便为可用于更有效查询的数据提供额外的结构。

桶的范围由记录中的一列或多列的哈希值确定。

用户可以通过提供bucket-key选项来指定分桶列。

如果未指定bucket-key选项则主键如果已定义或完整记录将用作存储桶键。

桶是读写的最小存储单元因此桶的数量限制了最大处理并行度。

不过这个数字不应该太大因为它会导致大量小文件和低读取性能。

一般来说建议每个桶的数据大小为1GB左右。

1.3.4

writer使用两阶段提交协议以原子方式将一批记录提交到表中。

每次提交在提交时最多生成两个快照。

对于任意两个同时修改表的writer只要他们不修改同一个存储桶他们的提交都是可序列化的。

如果他们修改同一个存储桶则仅保证快照隔离。

也就是说最终表状态可能是两次提交的混合但不会丢失任何更改。

1.4

文件以分层方式组织。

下图说明了文件布局。

从快照文件开始Paimon

下面简单介绍文件布局不同操作对应文件如何变化学习完Flink基本操作后再来理解2.10进行分析。

1.4.1

数据文件和更改日志文件的文件信息。

例如对应快照中创建了哪个LSM数据文件、删除了哪个文件。

1.4.3

Run由一个或多个数据文件组成并且每个数据文件恰好属于一个Sorted

Run可能具有重叠的主键范围甚至可能包含相同的主键。

查询LSM树时必须合并所有Sorted

Run并且必须根据用户指定的合并引擎和每条记录的时间戳来合并具有相同主键的所有记录。

写入LSM树的新记录将首先缓存在内存中。

当内存缓冲区满时内存中的所有记录将被排序并刷新到磁盘。

1.4.4.2

然而Compaction是一个资源密集型过程会消耗一定的CPU时间和磁盘IO因此过于频繁的Compaction可能会导致写入速度变慢。

这是查询和写入性能之间的权衡。

Paimon

默认情况下当Paimon将记录追加到LSM树时它也会根据需要执行Compaction。

用户还可以选择在“专用Compaction作业”中独立执行所有Compaction。