流、表与“二元性”的幻象

简介: 本文探讨流与表的“二元性”本质,指出实现该特性需具备主键、变更日志语义和物化能力。强调Kafka与Iceberg因缺乏更新语义和主键支持,无法真正实现二元性,唯有统一系统如Flink、Paimon或Fluss才能无缝融合流与表。

本文由 Ververica 首席架构师 Giannis Polyzos 撰写,__探讨了流与表的“二元性”本质,澄清常见误解,指出 Kafka 与 Iceberg 等系统在缺乏主键和变更语义时无法真正实现该二元性,并强调统一系统对流表融合的重要性。


什么是流/表二元性?

核心思想其实很简单:

  • 流(Stream) 是一个永不停止的变更日志 📜。

  • 表(Table) 是这些变更的物化视图,即当前状态 🗄️。

👉 任何表都可以表示为一个更新流。 👉 任何更新流也可以物化成一张表。

举个例子:

  • 数据库发出 INSERT、UPDATE 和 DELETE 事件 → 这就是一个

  • 按顺序应用这些事件,就能重建出原始的

  • 反过来,捕获表的每一次变更 → 就能得到变更日志流(changelog stream)。

这就是双向映射,也就是所谓的“二元性”💡。

二元性的核心前提

要让这种“魔法”成立,必须满足以下条件:

  • 变更日志语义(Changelog semantics):流不仅要包含新增记录,还必须携带更新(UPDATE)和删除(DELETE)操作。

  • 主键(Primary keys):系统需要知道要更新哪一行。

  • 时间是一等公民:流提供事件的顺序,表则代表“在时间 T 的状态”。

  • 物化能力(Materialization):表本质上是流的一个物化视图。

  • 一致性(Consistency):重放相同的流,始终能得到相同的表。

二元性何时会失效?

事情有趣的地方就在这里。当前社区中,很多人试图将 Apache KafkaApache Iceberg 的集成描述为“流/表二元性”,但事实并非如此。我们来拆解一下:

Apache Iceberg

Iceberg 是一个优秀的开源表格式,特别适合管理仅追加(append-only) 的数据。

但请注意:

  • 不强制要求主键

  • 原生不支持流式场景下的行级更新或删除

这意味着你无法获得真正的流/表二元性——你只能拿到一系列快照(snapshots),而不是持续演化的状态。

Apache Kafka

Kafka 本质上是一个事件日志(event log)不是变更日志(changelog)

默认情况下:

  • 它只存储原始事件;

  • 没有更新或删除的概念

所以:

  • Kafka 本身 ≠ changelog 流

不过……

借助 Debezium 或 Flink CDC

  • 你可以从数据库捕获真正的变更事件(包含主键和操作类型);

  • Kafka Topic 此时才真正承载了变更日志流

  • Flink 等引擎就能基于这些流物化出表。

关键点:Kafka 本身不是 changelog,这点必须强调,因为这直接影响下游处理的复杂度。

像 Apache Flink 这样的流处理引擎,其核心正是建立在 changelog 模型之上的。

由于 Kafka 不原生提供 changelog,Flink 必须引入一个昂贵的算子(如 ChangelogNormalize)来对 Kafka 数据进行归一化处理——这会导致:

  • 状态膨胀

  • 冗余存储

更糟糕的是,这个归一化后的 changelog 无法复用。 如果你有多个作业消费同一个 Kafka Topic,每个作业都得各自重建并存储一份 changelog 状态

那么,流和表必须在同一个系统里吗?

这是我一直在思考的问题。

确实,很多系统天然支持流/表二元性,比如:

  • PostgreSQL、MySQL(通过逻辑复制)

  • Apache Beam

  • 以及我深度参与的 Apache Flink、Apache Paimon,还有最近的 Apache Fluss

所以,我倾向于认为:“最好在同一个系统内实现”。

否则,你只是在做两个无法原生支持二元性的系统之间的集成

不过,由于目前尚无“流/表二元性”的正式定义,答案也可以是:不一定

像 Flink、Kafka Streams 等系统,在同一个引擎中同时暴露流和表 API,让二元性变得无缝。 但理论上,你也可以用不同系统实现——只要保证事件顺序、主键和 changelog 语义不丢失,二元性依然成立

但基于前文分析,我认为将 Kafka + Iceberg 的组合称为“流/表二元性”是不严谨的

总结

  • 流 = 故事(所有发生过的事件)

  • 表 = 快照(当前的真实状态)

二者共同构成了现代实时分析、流处理和湖仓一体架构的基石。

但请务必警惕:

  • Kafka ≠ changelog(除非结合 CDC)

  • Iceberg ≠ 表二元性(无主键,仅支持追加)

当然,业界还有更多关于这一话题的演进和不同技术路线,但本文暂且聚焦于此。

PS:如果你正在寻找一个真正基于上述原则构建的系统,并希望获得额外能力(如直接查询流、内置缓存等),不妨关注一下 Apache Fluss

继续奔涌吧 🌊🤘


更多内容


活动推荐

复制下方链接或者扫描二维码
即可快速体验 “一体化的实时数仓联合解决方案”
了解活动详情:https://www.aliyun.com/solution/tech-solution/flink-hologres

相关实践学习
基于Hologres+Flink搭建GitHub实时数据大屏
通过使用Flink、Hologres构建实时数仓,并通过Hologres对接BI分析工具(以DataV为例),实现海量数据实时分析.
实时计算 Flink 实战课程
如何使用实时计算 Flink 搞定数据处理难题?实时计算 Flink 极客训练营产品、技术专家齐上阵,从开源 Flink功能介绍到实时计算 Flink 优势详解,现场实操,5天即可上手! 欢迎开通实时计算 Flink 版: https://cn.aliyun.com/product/bigdata/sc Flink Forward Asia 介绍: Flink Forward 是由 Apache 官方授权,Apache Flink Community China 支持的会议,通过参会不仅可以了解到 Flink 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 Flink 生态的生产实践经验,是 Flink 开发者和使用者不可错过的盛会。 去年经过品牌升级后的 Flink Forward Asia 吸引了超过2000人线下参与,一举成为国内最大的 Apache 顶级项目会议。结合2020年的特殊情况,Flink Forward Asia 2020 将在12月26日以线上峰会的形式与大家见面。
相关文章
|
3月前
|
存储 SQL 缓存
Delta Join:为超大规模流处理实现计算与历史数据解耦
Delta Join(FLIP-486)是Flink流式Join的范式革新,通过将历史数据存储与计算解耦,实现按需查询外部存储(如Fluss、Paimon),避免状态无限增长。它解决了传统Join在高基数场景下的状态爆炸问题,显著降低资源消耗:状态减少50TB,成本降10倍,Checkpoint从小时级缩短至秒级,恢复速度提升87%。兼容标准SQL,自动优化转换,适用于海量数据实时关联场景,推动流处理迈向高效、稳定、可扩展的新阶段。
426 1
Delta Join:为超大规模流处理实现计算与历史数据解耦
|
4月前
|
人工智能 运维 监控
Flink 智能调优:从人工运维到自动化的实践之路
本文由阿里云Flink产品专家黄睿撰写,基于平台实践经验,深入解析流计算作业资源调优难题。针对人工调优效率低、业务波动影响大等挑战,介绍Flink自动调优架构设计,涵盖监控、定时、智能三种模式,并融合混合计费实现成本优化。展望未来AI化方向,推动运维智能化升级。
713 8
Flink 智能调优:从人工运维到自动化的实践之路
|
4月前
|
存储 分布式计算 运维
云栖实录|驰骋在数据洪流上:Flink+Hologres驱动零跑科技实时计算的应用与实践
零跑科技基于Flink构建一体化实时计算平台,应对智能网联汽车海量数据挑战。从车机信号实时分析到故障诊断,实现分钟级向秒级跃迁,提升性能3-5倍,降低存储成本。通过Flink+Hologres+MaxCompute技术栈,打造高效、稳定、可扩展的实时数仓,支撑100万台量产车背后的数据驱动决策,并迈向流批一体与AI融合的未来架构。
331 3
云栖实录|驰骋在数据洪流上:Flink+Hologres驱动零跑科技实时计算的应用与实践
|
3月前
|
运维 API 开发工具
打造可编程可集成的实时计算平台:阿里云实时计算 Flink被集成能力深度解析
本文由阿里云Flink团队李昊哲主讲,系统介绍Flink四层开放架构:通过OpenAPI、Git集成、多语言SDK等能力,实现控制面、数据面、开发面与运维面的全面开放。助力企业构建可编程、可嵌入、可治理的实时计算平台,推动数据开发工程化升级。
184 1
|
5月前
|
存储 JSON 数据处理
Flink基于Paimon的实时湖仓解决方案的演进
本文源自Apache CommunityOverCode Asia 2025,阿里云专家苏轩楠分享Flink与Paimon构建实时湖仓的演进实践。深度解析Variant数据类型、Lookup Join优化等关键技术,提升半结构化数据处理效率与系统可扩展性,推动实时湖仓在生产环境的高效落地。
607 1
Flink基于Paimon的实时湖仓解决方案的演进
|
2月前
|
人工智能 数据处理 Apache
Forrester发布流式数据平台报告:Flink 创始团队跻身领导者行列,实时AI能力获权威认可
Ververica,由Apache Flink创始团队创立、阿里云旗下企业,首次入选Forrester 2025流式数据平台领导者象限,凭借在实时AI与流处理领域的技术创新及全场景部署能力获高度认可,成为全球企业构建实时数据基础设施的核心选择。
146 10
Forrester发布流式数据平台报告:Flink 创始团队跻身领导者行列,实时AI能力获权威认可
|
2月前
|
消息中间件 Java Kafka
在 OpenAI 打造流处理平台:超大规模实时计算的实践与思考
本文介绍OpenAI构建流处理平台的实践与挑战。面对Kafka高可用、Python生态兼容、云环境限制等问题,团队基于PyFlink打造跨区域流处理架构,集成Kafka HA组、自研代理与控制平面,支撑实时Embedding生成、特征计算等场景,并推动开源协作与平台自动化演进。
149 1
在 OpenAI 打造流处理平台:超大规模实时计算的实践与思考
|
3月前
|
存储 缓存 Java
重构一个类,JVM竟省下2.9G内存?
通过重构核心类,将 `HashMap<Long, HashSet<String>>` 优化为 `Long2ObjectOpenHashMap<int[]>`,结合数据分布特征与紧凑存储,JVM 堆内存从 3.13GB 降至 211MB,降幅达 94%,验证了高效数据结构在海量场景下的巨大价值。
384 24
重构一个类,JVM竟省下2.9G内存?

热门文章

最新文章