引入Paimon的背景和主要解决的问题

从各家公司分享的内部应用来看，大多数场景都是Lambda架构同时存在。离线批处理架构最大的问题是存储和时效，存储上Hive本身能力有限，大部分场景是insert overwrite，并且基本不关心文件组织形式。

Paimon为代表的湖框架可以精细管理每一个文件，除了简单的insert overwrite，具备比较强大的ACID能力，能够流式写入实现分钟级更新。

以Flink+MQ为主的实时链路，主要的问题包括：

所以我们可以定性的给Paimon解决的问题下一个结论：统一流批链路，提升时效的同时降低成本。

核心场景和解决方案

在各大公司的分享中，都提到了关于使用Paimon代替传统的Hive ODS层，将Paimon作为整个业务数据库的统一镜像表，提高数据链路的时效性并优化存储空间。

实际生产链路带来的好处如下：

这里值得一提的是，Shopee开发了基于Paimon Branch的「日切功能」。简单的说即按照天进行数据切分，避免全量分区的数据冗余存储问题。

此外，Paimon社区也提供了一套工具，可以帮助大家进行schema evolution，将MySQL甚至Kafka的数据同步到Paimon中，上游增加列，Paimon表也会跟着增加列。

Paimon主键表作为维度表场景，在各大公司都有成熟应用，实际生产环境经过很多次考验。

Paimon作为维度表的场景分为两类，一类是实时维度表：通过Flink任务接业务数据库实时更新；另一类是离线维度表，也就是通过Spark离线任务T+1更新，也是维度表的绝大数据场景。

Paimon维度表同样可以支持Flink Streamin SQL任务和Flink Batch任务。

我们在之前的文章Paimon生产环境问题小总结也提到过维度表优化的场景。

Paimon和其他的很多框架一样，支持Partial Update，LSM Tree架构使得Paimon有很高的点查与合并性能，但是这里要特别注意几个点：

性能瓶颈，在超大规模数据更新或者超多列更新场景，后台合并性能会有明显的下降，需要谨慎测试后使用；
Sequence Group排序，当业务有多个流进行拼接时，会给每个流定义一个单独的 Sequence Group，对每个Sequence Group排序字段需要合理选择，甚至会有多个字段排序情况；

在蚂蚁计算 PV/UV 指标的例子中，之前是使用 Flink 的全状态链路来实现的，但后来发现大量业务难以迁移到这种模式，因此将其替换为 Paimon。

利用 Paimon 的 upsert（更新或插入）更新机制来进行去重，并且利用 Paimon 的轻量级日志 changlog 来消费数据，为下游提供实时的 PV（Page View，页面浏览量）和 UV 计算。

在整体资源消耗方面，Paimon方案使得整体CPU使用率下降了60%，同时checkpoint的稳定性也得到了显著提升。此外，由于Paimon支持point-to-point(端到端)写入，任务的回滚和重置时间也大幅减少。整体架构因为变得更加简单，因此在业务研发成本上也实现了降低。

因为Spark和Paimon集成度很高，通过Spark或Flink进行一些ETL操作，将数据写入Paimon中，基于Paimon进行z-order排序、聚簇，甚至构建文件级索引，然后通过Doris或StarRocks进行OLAP查询，这样就可以达到全链路OLAP的效果。

基本上面内容就是各大公司落地的主要场景，当然还有一些其他场景我们后续再持续补充。

文章内容来自：大数据技术与架构