Pinterest针对下一代数据库构建的事件时间分区最终确认机制，旨在解决流式CDC摄取中数据延迟到达的问题。该方案通过Apache Flink实时监控事件时间推进，结合Apache Iceberg元数据发布不会回退的确认水位线，保障下游安全消费。Pinterest整合了CDC、Kafka、Flink、Spark及Iceberg，支持PB级数据与数千条流水线，变更分析15分钟至1小时内完成。其核心设计突破在于摒弃批处理依赖，以Flink-Iceberg Sink为集成点，利用事件时间统计与水位线实现数据完整性与新鲜度的平衡。系统通过Flink检查点收集事件时间信息，以压缩存储形式存入Iceberg快照，最终输出单调递增的确认水位线，无需额外协调服务。这种设计既保留了流式数据的新鲜度，又保留了批处理的完整性保证，精准呈现流批协作的核心权衡。未来Apache Iceberg有望扩展Sink集成能力，进一步完善此类数据确认机制。
--91likeyou---
其中最巧妙的部分，是这个不会回退的安全读取水位线。
新机制运行在 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，以支持下游集成，其中包括水位线信息等自定义可提交元数据。
：
🔥 热词：#flink的table的sink写入数据解析异常的数据如何导出 · #flink如何保存缓存的数据 · #flink数据会落地到hadoop吗 · #flink日志数据清洗例子 · #flink从数据库读取数据 · #flink是做数据预处理的吗 · #flink同步数据 · #flink处理的数据