1.1 简介

Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，推出新一代的 Streaming Lakehouse 技术，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。Flink 社区内部孵化了 Flink Table Store （简称 FTS ）子项目，一个真正面向 Streaming 以及 Realtime的数据湖存储项目。2023年3月12日，FTS进入 Apache 软件基金会 (ASF) 的孵化器，改名为 Apache Paimon (incubating)。

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

1）读/写：Paimon 支持多种读/写数据和执行 OLAP 查询的方式。

（1）对于读取，它支持以下方式消费数据：

Ø 从历史快照（批处理模式）

Ø 从最新的偏移量（在流模式下）

Ø 以混合方式读取增量快照

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

2）生态系统

除了Apache Flink之外，Paimon还支持Apache Hive、Apache Spark、Trino等其他计算引擎的读取。

3）内部

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

4）统一存储

对于 Apache Flink 这样的流引擎，通常有三种类型的连接器：

Ø 消息队列：例如 Apache Kafka，在源阶段和中间阶段都使用它，以保证延迟保持在秒级。

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

Ø 批量存储：例如Apache Hive，它支持传统批处理的各种操作，包括INSERT OVERWRITE。

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

Ø 在批处理执行模式下，它就像一个Hive表，支持Batch SQL的各种操作。查询它以查看最新的快照。

Ø 在流执行模式下，它的作用就像一个消息队列。查询它的行为就像从历史数据永不过期的消息队列中查询流更改日志。

1.2 核心特性

1）统一批处理和流处理

批量写入和读取、流式更新、变更日志生成，全部支持。

2）数据湖能力

低成本、高可靠性、可扩展的元数据。 Apache Paimon 具有作为数据湖存储的所有优势。

3）各种合并引擎

按照您喜欢的方式更新记录。保留最后一条记录、进行部分更新或将记录聚合在一起，由您决定。

4）变更日志生成

Apache Paimon 可以从任何数据源生成正确且完整的变更日志，从而简化您的流分析。

5）丰富的表类型

除了主键表之外，Apache Paimon还支持append-only表，提供有序的流式读取来替代消息队列。

6）模式演化

Apache Paimon 支持完整的模式演化。您可以重命名列并重新排序。

1.3 基本概念

1.3.1 Snapshot

快照捕获表在某个时间点的状态。用户可以通过最新的快照来访问表的最新数据。通过时间旅行，用户还可以通过较早的快照访问表的先前状态。

1.3.2 Partition

Paimon 采用与 Apache Hive 相同的分区概念来分离数据。

分区是一种可选方法，可根据日期、城市和部门等特定列的值将表划分为相关部分。每个表可以有一个或多个分区键来标识特定分区。

通过分区，用户可以高效地操作表中的一片记录。

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

1.3.3 Bucket

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

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

桶是读写的最小存储单元，因此桶的数量限制了最大处理并行度。不过这个数字不应该太大，因为它会导致大量小文件和低读取性能。一般来说，建议每个桶的数据大小为1GB左右。

1.3.4 Consistency Guarantees一致性保证

Paimon writer使用两阶段提交协议以原子方式将一批记录提交到表中。每次提交在提交时最多生成两个快照。

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

1.4 文件布局

一张表的所有文件都存储在一个基本目录下。 Paimon 文件以分层方式组织。下图说明了文件布局。从快照文件开始，Paimon 读者可以递归地访问表中的所有记录。

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

1.4.1 Snapshot Files

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

快照文件是一个 JSON 文件，包含有关此快照的信息，包括：

正在使用的Schema文件

包含此快照的所有更改的清单列表（manifest list）

1.4.2 Manifest Files

所有清单列表（manifest list）和清单文件（manifest file）都存储在清单（manifest）目录中。

清单列表（manifest list）是清单文件名（manifest file）的列表。

清单文件（manifest file）是包含有关 LSM 数据文件和更改日志文件的文件信息。例如对应快照中创建了哪个LSM数据文件、删除了哪个文件。

1.4.3 Data Files

数据文件按分区和存储桶分组。每个存储桶目录都包含一个 LSM 树及其变更日志文件。目前，Paimon 支持使用 orc（默认）、parquet 和 avro 作为数据文件格式。

1.4.4 LSM Trees

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

1.4.4.1 Sorted Runs

LSM 树将文件组织成多个Sorted Run。Sorted Run由一个或多个数据文件组成，并且每个数据文件恰好属于一个Sorted Run。

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

正如您所看到的，不同的Sorted Run可能具有重叠的主键范围，甚至可能包含相同的主键。查询LSM树时，必须合并所有Sorted Run，并且必须根据用户指定的合并引擎和每条记录的时间戳来合并具有相同主键的所有记录。

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

1.4.4.2 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。