paimon-01 概况

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

读写：paimon支持多种读写数据和执行 OLAP查询的方式

• 对于读取，它支持以下方式消费数据
  • 从历史快照（批处理模式）
  • 从最新的偏移量（流处理模式）
  • 以混合方式读取增量快照
• 对于写入，它支持来自数据库变更日志CDC的流式同步或来自离线数据的批量插入、覆盖

生态系统

除了flink之外paimon还支持hive spark trino等其他计算引擎的读取

内部

在底层，paimon将列式文件存储在文件系统/对象存储上，并使用LSM树结构来支持大量数据更新和高性能查询

统一存储

对于flink这样的流引擎通常有三种类型的连接器

• 消息队列：比如kafka 在源阶段和中间阶段使用它，以保证延迟保持在秒级
• OLAP系统：比如clickhouse 它以流的方式接收处理后的数据并为用户的即席查询提供服务
• 批量存储：比如hive 它支持传统批处理的各种操作，包括insert overwrite

paimon提供表抽象，它的使用方式与传统数据库没有什么区别

• 在批处理执行模式下，它就像一个hive表支持batch sql的各种操作，查询它以查看最新的快照
• 在流执行模式下，它的作用就像一个消息队列，查询它的行为就像从历史数据永不过期的消息队列中查询流更改日志

核心特性

• 统一批处理和流处理
  • 批量写入和读取、流式更新、变更日志生成，全部支持
• 数据湖能力
  • 低成本、高可靠性、可扩展的元数据。
  • paimon具有作为数据湖存储的所有优势
• 各种合并引擎
  • 按照喜欢的方式更新记录
  • 保留最后一条记录、进行部分更新或将记录聚合在一起
• 变更日志生成
  • paimon可以从任何数据源生成正确且完整的变更日志，从而简化流的分析
• 丰富的表类型
  • 除了主键表之外，paimon还支持append-only表，提供有序的流式读取来替代消息队列
• 模式演化 schema revolution
  • paimon支持完整的模式演化，可重命名列并重新排序
  • 同步表变更

基本概念

Snapshot

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

用户可以通过最新的快照来访问表的最新数据，通过时间旅行

用户还可以通过较早的快照访问表的先前状态

Partition

paimon采用与hive相同的分区概念来分离数据

通过分区，用户可以搞笑的操作表中的记录

如果定义了主键 则分区键必须是主键的子集

Bucket

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

桶的范围由记录中一列或多列的哈希值确定，用户可以通过提供bucket-key选项来指定分桶列。如果未指定则主键（如果已定义）或完整记录将用作存储桶键bucket-key

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

一般建议每个桶的数据大小1G左右

一致性保证

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

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

对于任意两个同时修改表的writer，只要他们不修改同一个存储桶，他们提交的都是可序列化的，如果他们修改同一个存储桶，则仅保证快照隔离。也就是最终状态可能是两次提交的混合，但不会丢失任何更改。

文件布局

一张表的所有文件都存储在一个基本目录下

paimon文件以分层方式组织。

Snapshot Files

所有快照文件都存储在快照目录中

快照文件时一个json文件，包含有关此快照的信息

• 正在使用的schema文件
• 包含此快照的所有更改的清单列表manifest list

Manifest Files

所有清单列表manifest list和清单文件manifest fie都存储在清单manifest目录中

• 清单列表 manifest list时清单文件名manifest file的列表
• 清单文件manifest file是包含有关LSM数据文件和更改日志文件的文件信息
  • 对应快照中创建了哪个LSM数据文件、删除了哪个文件

Data Files

数据文件按分区和存储桶分组。

每个存储桶目录都包含一个LSM树及其变更日志文件

paimon支持orc（默认）、parquet和avro作为数据文件格式

LSM Trees

paimon采用LSM树（日志结构合并树）作为文件存储的数据结构

Sorted Runs

LSM树将文件组成多个Sorted Runs。 SortedRun由一个或多个数据文件组成，并且每个数据文件恰好属于一个sorted run.

数据文件中的记录按其主键排序，在Sorted Run中数据文件的主键范围永远不会重叠

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

写入LSM树的新记录将首先缓存在内存中。当内存缓冲区满时，内存中的所有记录将被排序并刷新到磁盘。

Compaction

当越来越多的记录写入LSM树，Sorted Run的数量将会增加

由于查询LSM树需要将所有Sorted Run合并起来 太多Sorted Run将导致查询性能较差 甚至内存不足

为了限制Sorted Run的数量 我们必须偶尔将多个Sorted Run合并成为一个大的Sorted Run这个过程成为Compaction

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

paimon采用了类似于rocksdb通用压缩的compaction策略

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

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