批流融合吵了十年，答案藏在水印里

CDC数据流永远不知道自己什么时候'流完了'。这个听上去像哲学问题的难题，正卡在无数数据团队的流水线上。最近，Pinterest给出了一个工程答案：用事件时间水位线来决定数仓分区何时'最终化'。与此同时，DuckDB生态在2026年10月的月报里持续做着另一件事——把'重'拆掉。一个在解决确定性问题，一个在解决成本与易用问题，两条线其实指向同一个判断：湖仓时代的基础设施，正在从'能跑就行'走向'结果可信'。

🕰️ 一个分区，到底什么时候算'写完'

先讲一个所有做过CDC入湖的人都懂的场景。

业务库的变更流源源不断写进Iceberg表，按小时或按天分区。下游的聚合作业要开始跑了，但它面对一个尴尬的问题：这个分区的数据，真的齐了吗？要不要再等等？等少了，算出来的报表缺数，明天返工；等多了，集群白烧钱，时效性一塌糊涂。很多团队最后拍出一个粗暴方案——'固定延迟一小时再跑'，本质上是用猜来换稳定。

Pinterest数据工程师Leela Kumili披露的方案，思路是把'猜'变成'算'。他们用Apache Flink持续追踪事件时间，借助事件时间水位线来判断数据完整性；然后把这个水位线通过Apache Iceberg的元数据发布出去，形成一条非回退水位线——也就是说，水位线只前进不后退，下游任何作业读到它，都能得到一个一致的判断依据：水位线越过某个分区边界了，这个分区就可以被'最终化'，下游放心处理。

这个方案的价值不在某个单点技术——Flink水位线是老概念，Iceberg元数据也是现成的——而在于把两者拼成了一个可下发的完成性信号。数据完整性不再藏在管道运营者的脑子里，而是变成了表元数据的一部分，任何下游消费者都能自助判断。

在PB级规模下，这不是锦上添花。分区晚一分钟最终化，乘以成千上万张表，就是实打实的资源浪费；分区早一分钟最终化，就是一次数据事故。翻看各大开源流批管道项目的issue区和社区讨论，这类'等还是不等'的权衡反复出现，几乎每个中大型团队都摸索过一套内部补丁，Pinterest只是把补丁升格成了框架机制。

🌊 水位线不是细节，是一份数据正确性合同

表面看，这是Pinterest的一个工程改进。往深一层看，它标记的是数据平台理念的一次转向。

过去十年，行业围绕批流融合吵得不可开交。Lambda架构维护批流两条链路，成本翻倍；Kappa架构号称一条流链路打天下，但回溯历史数据时捉襟见肘。直到Iceberg、Hudi、Delta这些开放表格式把'表'变成批流共用的地基，争论才逐渐降温。但表格式统一了存储，没解决另一个更隐蔽的问题：时间语义。

流处理世界里，事件时间（事件真正发生的时刻）和处理时间（系统处理它的时刻）是两回事。用户在凌晨0点59分点击的下单按钮，事件可能在1点05分才到达管道——它该算进昨天的分区还是今天的？只要这个问题没有机制化的答案，所谓'实时数仓'的数字就永远带着一层模糊。水位线的本质，是给这层模糊画一条明确的线：线之前的，视为完整；线之后迟到太久的，按异常处理。

所以Pinterest这条新闻真正的产业信号是：完成性本身成了平台能力。在开放表格式普及之前，完成性信号只能绑定在某个调度系统里，换调度工具就作废；现在它被写进Iceberg元数据，跟着表走，跟计算引擎解耦。这和当年'存储计算分离'的逻辑一脉相承——把最容易锁死用户的那一层，变成开放的公共协议。

换个角度看，湖仓之争的下半场，打的不是性能，是语义。性能差距可以靠硬件堆，语义模糊只能靠协议补。Pinterest的实践证明，水位线可以从Flink作业的内部状态，升级为跨系统的公共契约。

🦆 另一边，DuckDB在把'重'字拆掉

当重型湖仓在补语义课的时候，赛道另一头，轻量化的故事讲得如火如荼。

DuckDB 2026年10月生态月报透露的信息量不小：DuckDB 2.0引入了PEG解析器，SQL解析层重写（参见DuckDB 2.0发布公告）；异步S3读取优化了对象存储场景下的查询体验（相关配置说明见官方httpfs扩展文档）；DuckLake——那个用数据库存放元数据、把数据文件甩给对象存储的轻量湖仓方案——持续做维护打磨（项目主页：ducklake.select）。生态侧，有人在DuckDB和MotherDuck的SQL里直接输入AI问题让系统作答（参考MotherDuck文档），OpenStreetMap数据被做成了开箱即用的分析就绪版本，浏览器里能直接查Microsoft的OneLake，还出现了原生Mac应用。

把这些散点串起来，能看出一条清晰的路线：把分析能力从'集群'里解放出来。传统MPP数仓要求你先搭一套分布式系统，才有资格跑SQL；DuckDB的路线是，一个进程、一个文件、甚至一个浏览器标签页，就能对百GB级数据做严肃分析。DuckLake进一步补上了多人协作的短板——元数据进数据库、数据进对象存储，单机引擎也能玩出湖仓的协作体验。

两条路线看似相反，实则互为镜像：Pinterest在重型管道里追求'精确的最小等待'，DuckDB在轻量引擎里追求'零门槛的最大覆盖'。它们共同的敌人，是那种'搭一套庞然大物、结果数字还不一定对'的中庸状态。

🗺️ 一张图看懂：谁在领跑，谁在跟随

把当前湖仓与分析赛道的主要玩家放进四象限，格局会更直观。以技术门槛（工程复杂度与语义能力）和商业价值（对企业数据底座的重要性）为轴：

Apache Iceberg站在右上角的逻辑很硬：它已经从Netflix的开源项目变成了事实上的表格式标准，Snowflake、Databricks、AWS都在押注，Pinterest把水位线写进它的元数据，等于又给这个标准加了一块语义拼图。Apache Flink则是流处理语义层的守门人，事件时间的护城河一时难以撼动。DuckDB处在象限中部偏上的位置——门槛不高，但商业价值正在被AI场景快速放大。

值得注意的是月报里那个细节：在SQL里直接问AI问题。这背后是Data for AI与AI for Data的合流——数据平台既要为模型准备高质量训练数据，又在把LLM当作新的查询接口。当分析师用自然语言问数时，答案的'确定性'比交互的'花哨'重要一百倍。这时候，事件时间水位线这样的语义机制，反而成了AI问数能不能给出可信答案的底层前提。

💡 给工程团队的三个务实判断

不想聊概念，聊点能落地的。第一，如果你的CDC入湖还在用固定延迟等分区，值得评估水印方案。Pinterest的路径证明，Flink加Iceberg元数据的组合不需要发明新组件，核心工作量在管道改造和下游约定。第二，不要为了轻而轻。DuckDB路线适合单团队、单项目的分析场景，企业级核心数仓的语义治理和权限体系仍然离不开重型平台，混合架构大概率是未来三年的常态。第三，把'数据完整性'当成产品能力来建设，而不是运维同学人肉兜底的脏活。

小结

批流融合吵了十年，最后的答案不在哪个引擎赢，而在语义协议胜出：Pinterest把水位线从Flink内部状态变成Iceberg公共元数据，DuckDB把分析门槛从集群降到一个进程。一重一轻，殊途同归——数据基础设施的下一轮竞争，比拼的不是谁的机器更多，而是谁能对'这个数字可信吗'给出机制化的回答。2027年，值得盯住两件事：水位线类语义协议会不会被更多厂商写进表格式标准，以及AI问数的普及会不会反过来倒逼每家企业补上事件时间这门课。

`infographic

{"type":"timeline","title":"2027年值得追踪的两个信号","items":[{"label":"水位线语义协议进表格式标准","description":"Iceberg、Hudi、Delta社区是否吸收事件时间完成性信号，完成性从工程实践升级为规范"},{"label":"AI问数倒逼事件时间补课","description":"自然语言问数普及后，企业是否补齐时间语义治理，让'数字可信'有机制可依"},{"label":"轻量引擎与湖仓协作融合","description":"DuckLake类方案的多人协作能力演进，单机引擎与对象存储组合能否承接更多企业场景"}]}

`

参考信源：DuckDB 2.0发布公告（duckdb.org/blog/announcing-duckdb-20）、DuckDB httpfs扩展文档（duckdb.org/docs/stable/extensions/httpfs/overview.html）、DuckLake官方站点（ducklake.select）、MotherDuck文档（motherduck.com/docs）、Pinterest工程博客水位线方案披露（Leela Kumili）。