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

简介: 本文探讨流与表的“二元性”本质,指出实现该特性需具备主键、变更日志语义和物化能力。强调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日以线上峰会的形式与大家见面。
相关文章
|
15天前
|
存储 SQL 缓存
Delta Join:为超大规模流处理实现计算与历史数据解耦
Delta Join(FLIP-486)是Flink流式Join的范式革新,通过将历史数据存储与计算解耦,实现按需查询外部存储(如Fluss、Paimon),避免状态无限增长。它解决了传统Join在高基数场景下的状态爆炸问题,显著降低资源消耗:状态减少50TB,成本降10倍,Checkpoint从小时级缩短至秒级,恢复速度提升87%。兼容标准SQL,自动优化转换,适用于海量数据实时关联场景,推动流处理迈向高效、稳定、可扩展的新阶段。
164 1
Delta Join:为超大规模流处理实现计算与历史数据解耦
|
2月前
|
人工智能 运维 监控
Flink 智能调优:从人工运维到自动化的实践之路
本文由阿里云Flink产品专家黄睿撰写,基于平台实践经验,深入解析流计算作业资源调优难题。针对人工调优效率低、业务波动影响大等挑战,介绍Flink自动调优架构设计,涵盖监控、定时、智能三种模式,并融合混合计费实现成本优化。展望未来AI化方向,推动运维智能化升级。
589 7
Flink 智能调优:从人工运维到自动化的实践之路
|
24天前
|
运维 API 开发工具
打造可编程可集成的实时计算平台:阿里云实时计算 Flink被集成能力深度解析
本文由阿里云Flink团队李昊哲主讲,系统介绍Flink四层开放架构:通过OpenAPI、Git集成、多语言SDK等能力,实现控制面、数据面、开发面与运维面的全面开放。助力企业构建可编程、可嵌入、可治理的实时计算平台,推动数据开发工程化升级。
111 1
|
2月前
|
存储 分布式计算 运维
云栖实录|驰骋在数据洪流上:Flink+Hologres驱动零跑科技实时计算的应用与实践
零跑科技基于Flink构建一体化实时计算平台,应对智能网联汽车海量数据挑战。从车机信号实时分析到故障诊断,实现分钟级向秒级跃迁,提升性能3-5倍,降低存储成本。通过Flink+Hologres+MaxCompute技术栈,打造高效、稳定、可扩展的实时数仓,支撑100万台量产车背后的数据驱动决策,并迈向流批一体与AI融合的未来架构。
219 2
云栖实录|驰骋在数据洪流上:Flink+Hologres驱动零跑科技实时计算的应用与实践
|
26天前
|
消息中间件 安全 NoSQL
阿里云通过中国信通院首批安全可信中间件评估
近日,由中国信通院主办的 2025(第五届)数字化转型发展大会在京举行。会上,“阿里云应用服务器软件 AliEE”、“消息队列软件 RocketMQ”、“云数据库 Tair”三款产品成功通过中国信通院“安全可信中间件”系列评估,成为首批获此认证的中间件产品。此次评估覆盖安全可信要求、功能完备性、安全防护能力、性能表现、可靠性与可维护性等核心指标,标志着阿里云中间件产品在多架构适配与安全能力上达到行业领先水平。
387 202
|
29天前
|
机器学习/深度学习 运维 监控
当系统开始“自愈”:聊聊大数据与AIOps的真正魔力
当系统开始“自愈”:聊聊大数据与AIOps的真正魔力
154 10
|
29天前
|
缓存 监控 Java
用 Spring Boot 3 构建高性能 RESTful API 的 10 个关键技巧
本文介绍使用 Spring Boot 3 构建高性能 RESTful API 的 10 大关键技巧,涵盖启动优化、数据库连接池、缓存策略、异步处理、分页查询、限流熔断、日志监控等方面。通过合理配置与代码优化,显著提升响应速度、并发能力与系统稳定性,助力打造高效云原生应用。
383 3
|
3月前
|
存储 JSON 数据处理
Flink基于Paimon的实时湖仓解决方案的演进
本文源自Apache CommunityOverCode Asia 2025,阿里云专家苏轩楠分享Flink与Paimon构建实时湖仓的演进实践。深度解析Variant数据类型、Lookup Join优化等关键技术,提升半结构化数据处理效率与系统可扩展性,推动实时湖仓在生产环境的高效落地。
425 1
Flink基于Paimon的实时湖仓解决方案的演进
|
4月前
|
消息中间件 存储 Kafka
Apache Flink错误处理实战手册:2年生产环境调试经验总结
本文由 Ververica 客户成功经理 Naci Simsek 撰写,基于其在多个行业 Flink 项目中的实战经验,总结了 Apache Flink 生产环境中常见的三大典型问题及其解决方案。内容涵盖 Kafka 连接器迁移导致的状态管理问题、任务槽负载不均问题以及 Kryo 序列化引发的性能陷阱,旨在帮助企业开发者避免常见误区,提升实时流处理系统的稳定性与性能。
422 0
Apache Flink错误处理实战手册:2年生产环境调试经验总结
|
26天前
|
SQL 分布式计算 大数据
【跨国数仓迁移最佳实践8】MaxCompute Streaming Insert:大数据数据流写业务迁移的实践与突破
本系列文章将围绕东南亚头部科技集团的真实迁移历程展开,逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第八篇,MaxCompute Streaming Insert:大数据数据流写业务迁移的实践与突破。 注:客户背景为东南亚头部科技集团,文中用 GoTerra 表示。
266 38

热门文章

最新文章