Paimon的时效性和一致性是如何保证的？

提到Paimon的时效性与一致性，就必须要提到Paimon的快照文件，快照（snapshot）文件是读取Paimon表数据的入口。消费者可以通过快照文件，查询在该快照文件产生时刻的Paimon表中的具体数据。因此，通过读取不同的快照文件，消费者可以查询Paimon表在不同时间点的状态，在流作业中实现消费位点的修改，以及在批作业中实现time travel功能。

如何保证时效性？

数据写入Paimon表时，Paimon writer算子会首先将数据缓存在内存以及临时文件中。在Flink作业创建检查点（Checkpoint）后，才会将临时文件进行提交（Commit），并产生快照（Snapshot）文件。下游的流式消费者将监听Paimon表的快照文件列表，发现新的快照文件后，才会读取该快照文件对应的变更数据。

因此，Paimon的时效性受快照文件产生频率的影响，而在Flink作业没有反压的情况下，产生快照文件的时间间隔等同于Flink作业创建检查点的时间间隔（checkpoint interval）。也就是说，Paimon表的时效性等同于Flink作业创建检查点的时间间隔。然而，创建检查点的时间间隔过小，可能会对Flink作业的运行效率产生负面影响。在使用Paimon表时，我们建议将Flink作业创建检查点的时间间隔设置为1分钟至10分钟。且根据业务的接受程度，应尽可能提高这一时间间隔，以进一步提高Paimon表的读写效率。

如何保证一致性？

Paimon使用两阶段提交协议将数据进行原子化的提交。对于同时写入同一张Paimon表的两个Flink作业：

不修改同一个分桶内的数据时，两个作业中的提交操作可同时进行，并保证sequential级别的一致性。
（强烈不推荐），如果两个作业同时修改同一个分桶内的数据，Paimon将通过作业失败重启（Failover）的方式解决数据冲突，且只能保证Snapshot Isolation级别的一致性。也就是说，Paimon表的最终状态可能是两个作业结果数据的混合，不会有数据丢失。

详细解释一下Paimon的Snapshots系统表

Paimon 的 Snapshots 系统表主要用于记录表的快照信息。快照是数据在某个特定时间点的状态表示，对数据的版本控制、时间旅行（Time - Travel）以及流处理中的状态管理等功能都非常关键。

我们可以通过sql直接查询snapshots表：

SELECT * FROM mycatalog.mydb.`mytbl$snapshots`;

Snapshots系统表常用的列:

Paimon如何清理过期数据？为什么要清理过期数据？

首先，大量的数据写Paimon会产生大量的快照和旧版本数据，这些数据占用了大量的存储空间，在增加存储成本的同时会影响查询性能。

Paimon本身提供了以下几种方式控制数据的过期。

1.通过调整快照文件的过期时间

我们简单用一句话总结：要么保留我指定的快照个数，要么保留我指定的时间。这里要注意，这个时间不能太短，否则数据很快失效，影响查询。

2.设置分区过去时间

如果你用的是分区表，那么可以参考Hive的数据过期方式，指定分区的过去时间即可。

分区过期行为由下表三个表参数共同决定：

3.手动清理孤儿文件

Paimon在更新和删除的过程中，在系统中失去关联属性，会产生部分「孤儿文件」，这些废弃文件无法通过快照过期删除，可以通过手动执行命令的方式清理。例如下面的命令：

CALL ``.sys.remove_orphan_files('.');

事实上，我们在部署Paimon集群的过程中可以加入一些定时清理的策略，删除这些垃圾文件。

Paimon是如何管理快照过期的？

Paimon writer 每次提交时会生成1-2个快照。每个快照会添加一些新的数据文件，并且将一些旧的数据文件标记为已删除状态。不过，被标记的这些数据文件并不会真正被删除，因为Paimon还支持回溯到更早的快照，只有当快照过期时，它们才会真正被删除。

Paimon在提交新变更时，会自动执行过期操作，快照过期由以下表属性来控制：

默认情况下，Paimon会同步删除过期快照。当有大量文件需要删除时，会导致上游产生反压。为避免这种情况，用户可以通过将：snapshot.expire.execution-mode 设置为 "异步"(async)来使用异步过期模式。

Paimon快照同步过期和异步过期分别有什么优劣势？

同步过期模式（sync）

优点

操作顺序性明确：严格按照顺序执行，一个操作完成后才会进行下一个，这使得系统的操作流程比较直观。例如，在数据一致性要求较高的场景下，能够确保在删除过期快照相关文件后，系统状态是稳定的，不会出现旧文件还没删除完就进行新操作而导致数据混乱的情况。
数据一致性保障程度高：因为是同步操作，对于依赖快照状态进行数据处理（如数据查询、分析等）的业务逻辑来说，能够比较准确地获取到最新的、符合预期的有效快照状态。

缺点

性能问题：当有大量文件需要删除时，由于需要等待删除操作完成，可能会导致操作耗时较长。例如，如果有大量的过期快照需要处理，系统会花费较多时间在文件删除上，这可能会使整个系统的响应速度变慢。
可能产生反压：这种模式可能会导致对上游操作符产生反压。比如，上游的数据写入操作可能会因为等待过期快照删除而被阻塞，影响数据的正常流入和处理流程。

异步过期模式（async）

优点

提高系统响应速度：避免了因为等待大量文件删除而导致的系统阻塞，使得系统能够更快地响应其他操作。例如，在高并发的数据处理场景下，即使有大量的过期快照需要处理，也不会影响新数据的写入、查询等操作，系统可以并行处理这些任务，提高整体的处理效率。
减少反压风险：由于文件删除在后台进行，不会阻塞上游操作，降低了对上游操作符产生反压的可能性，使得数据能够更流畅地在系统中流动。

缺点

数据一致性维护复杂：因为文件删除是异步的，在某些时刻可能会出现数据不一致的情况。例如，在文件还没删除完时进行数据查询，可能会查询到部分已经标记为过期但还没删除的文件。这就需要在系统设计和业务逻辑中采取额外的措施来确保数据的一致性，如使用合适的缓存策略或者数据版本控制机制。
操作管理难度增加：相比于同步模式，异步模式下文件删除操作在后台进行，需要更好地管理和监控这些异步任务。例如，需要考虑异步删除任务失败后的重试机制、资源占用情况等，以确保系统的稳定运行。

本文来自公众号：大数据技术与架构