Pinterest：Flink与Iceberg如何确认CDC数据分区已完整？
作者 ｜ Leela Kumili译者 ｜ 田橙Pinterest 为下一代数据库摄取框架引入了 基于事件时间的分区最终确认机制，让下游任务能够判断流式数据何时已经足够完整，可以安全消费。该方案使用 Apache Flink 衡量事件时间的推进情况，并通过 Apache Iceberg 元数据发布一个不会回退的最终确认
Pinterest 给下一代数据库摄取框架加了一套基于事件时间的分区最终确认机制。下游任务因此能判断流式数据什么时候已经足够完整、可以放心消费。做法是用 Apache Flink 衡量事件时间的推进情况，再通过 Apache Iceberg 元数据发布一个不会回退的最终确认水位线。这解决的是持续变更数据捕获（CDC）摄取里的一道难题：某个分区对应的自然时间区间已经结束，数据仍可能迟到。
Pinterest 这套摄取框架由 CDC、Kafka、Flink、Spark 和 Iceberg 组成，用来将
Pinterest 架构：Kafka CDC 事件经过 Flink 流入 CDC 
Iceberg 表
Google 架构师 Nitesh Singhal 在 LinkedIn 帖子里介绍了这一设计，他写道：
整个设计里最巧妙的一环，是这条不会回退的安全读取水位线。
新机制跑在 Flink 到 Iceberg 的 Sink 内部。每条 CDC 记录里都有一个预先配置的事件时间，系统会把它提取出来。Flink 执行检查点时，系统收集事件时间的最小值、最大值和百分位数统计信息。这些数据写进 Iceberg 的快照摘要，同时用 t-digest 把事件时间分布压缩到几百字节。
Iceberg 提交完成后，系统依据近期检查点的统计信息算出分区最终确认水位线。默认策略取可配置数量的近期提交中的最小事件时间，再向下取整到对应小时。这条水位线单调递增，迟到的记录没法让已经发布的值往回退。如果改用基于百分位数的策略，则是拿一部分完整性去换更新鲜的数据。
Pinterest 表示，水位线以 Iceberg 表属性的形式存放，下游传感器不用再搭一套单独的协调服务就能读到。Spark 执行 CDC 更新插入提交时，也会把这些元数据传播到基础表。Pinterest 强调：
最终确认不再是任务结束所带来的副产品。
这套设计借的是 Flink 和 Iceberg 已有的能力。Flink 水位线用来追踪乱序数据流中的事件时间进度，Iceberg 快照则提供持久化的表元数据。Pinterest 把两者接在一起，推导出特定于数据表的完整性信号，并让信号跟数据存在一处。
时间线展示了延迟到达的 CDC 事件、Flink 检查点、事件时间进度，以及单调递增的最终确认水位线。
Salesforce 工程师 Tharun Kumar Reddy Polu 在 LinkedIn 评论里点出了流处理与批处理之间的权衡，他写道：
流处理与批处理怎么取舍，这个设计摆得很清楚，所以它站得住脚。数据要新鲜，批处理原先给的那套保证又不能丢，难就难在这儿。
实现上，Pinterest 用的是 Flink-to-Iceberg Sink 中的扩展点。累加器负责收集记录统计信息，提交处理器则围绕 Iceberg 提交执行最终确认逻辑。另外，Apache Iceberg 有一项议题正在讨论怎么扩展 IcebergSink 来支持下游集成，其中包括水位线信息等自定义可提交元数据。
https://www.infoq.com/news/2026/10/pinterest-event-time-partition/
声明：本文为 InfoQ 翻译，不代表平台观点，也不构成投资建议，未经许可禁止转载。
