从分钟到秒级：我们用 Fluss + Paimon 替换掉 Kafka + Iceberg，实时宽表终于不用 Flink 死扛了

从分钟到秒级我们用 Fluss Paimon 替换掉 Kafka Iceberg实时宽表终于不用 Flink 死扛了 更新于 2026-05-21 | ️ Fluss · Paimon · 湖流一体 · 实时数仓 · 架构升级摘要上一代湖仓一体架构中Kafka Iceberg 的组合存在数据冗余、实时更新代价高、Lambda 架构维护负担重三大痛点。本文完整复盘我们引入 Apache Fluss Apache Paimon 构建「湖流一体」新底座的全过程从组件替换逻辑、核心数据流设计、性能实测收益到迁移方案毫无保留。如果你也在被实时宽表和流批两套代码折磨这篇实战经验或许能帮你省下半年折腾。引言当 Iceberg 的分钟级延迟成为业务天花板上一代数据中台我们基于 Apache Iceberg 构建了经典的湖仓一体架构。存算分离、多引擎共享、ACID 事务——这些能力稳定支撑了两年多的业务增长。但最近半年三个问题越来越尖锐实时宽表场景下Merge-On-Read 的写放大让集群不堪重负。Kafka 和 Iceberg 两份存储数据冗余 一致性校验运维成本居高不下。流批两套代码的 Lambda 架构需求一变动两个地方都要改开发速度跟不上业务节奏。我们意识到湖仓一体的分钟级延迟已经成为实时风控、秒级报表、AI 特征供给这些新场景的硬瓶颈。是时候在数据湖之上加一层真正的实时流存储了。经过调研和 POC我们选定了 Fluss Paimon 的组合。这篇文章就是这次架构升级的完整复盘。一、旧架构Iceberg Kafka 做了很多事但每件事都留了尾巴老读者都知道我们的计算引擎层跑在 Kubernetes 上核心组件如下Spark 批处理 ────┐ Flink 流处理 ────┼──→ Iceberg 表MinIO 对象存储 Trino 即席查询 ──┘ ↑ Hive Metastore MySQL 元数据 实时链路单独一套Kafka → Flink → Iceberg这套架构做了很多事但每件事都留了尾巴痛点具体表现对团队的影响数据冗余实时链路 Kafka 存一份离线 Iceberg 再存一份两份数据可能不一致半夜对账成了常规操作实时更新代价高Iceberg 的 Merge-On-Read 在大量 Upsert 场景下写放大严重宽表拼接任务经常 OOMLambda 维护重实时和离线两套代码改一个逻辑两个地方都要动新需求交付周期长延迟只能到分钟级Commit 间隔 小文件合并端到端延迟很难压到 30 秒以内实时风控场景无法接受元数据压力HMS 在高频 DDL 下成为瓶颈偶尔雪崩影响全局说白了Kafka 负责“快”Iceberg 负责“稳”但它们之间有一条缝。这条缝靠 Flink 来粘合而 Flink 的状态越积越重维护成本越来越高。二、新架构Fluss Paimon让流和湖长在一起我们的目标很明确用一个可查询的流存储替换 Kafka既能像消息队列一样快又能像表一样被 SQL 直接查询。用一个与流存储深度集成的湖格式替换 Iceberg让热数据自动归档为冷数据查询时自动联合。尽量不改变上层应用DolphinScheduler 调度、自研 PSC 采集引擎、Trino 即席查询、Kyuubi 批处理入口全部保留。新架构的核心变化只有两处原Kafka → Flink → Iceberg → MinIO 新Fluss热数据→ 自动归档 → Paimon冷数据→ MinIO但这两处变化解决了上一代架构的所有尾巴。新架构分层总览应用层数据门户、BI、指标中心 ↓ JDBC 服务层即席查询、API 网关、结果缓存 ↓ JDBC 治理层元数据、质量、脱敏、权限、审计 ↓ JDBC 调度开发层DolphinScheduler 自研采集引擎 PSC SQL 编辑器 ↓ JDBC / Flink SQL 计算引擎层Kyuubi / Trino / Spark / Flink ├── 实时写入 → Fluss 集群流存储秒级新鲜度 │ ↓ 自动分层归档 └── 批量/即席查询 → Paimon 表湖格式冷数据高性能分析 ↓ 存储层MinIOParquet 文件 MySQL元数据三、Fluss 和 Paimon到底分别解决了什么3.1 Fluss不只是 Kafka 的替代品Fluss 是阿里巴巴开源的新一代流存储系统定位超越消息队列Fluss 的能力对 Kafka 的升级主键表 UpsertKafka 是日志Fluss 是表。原生支持按主键更新和删除列式存储基于 Arrow查询只读需要的列网络开销降低 10 倍自动归档到 Paimon热数据自动下沉冷热分层查询自动联合Flink 一等公民原生 Flink SQL Connector读写和 CDC 订阅都比 Kafka 稳定SQL 可查询无需额外 OLAP 引擎Fluss 自身就支持 SQL 点查和即席分析3.2 Paimon为流而生的湖格式Paimon 的前身是 Flink Table Store与 Flink 生态深度绑定Paimon 的能力对 Iceberg 的升级CDC 原生支持Iceberg 消费 CDC 需要额外处理Paimon 直接消费变更日志主键表 Compaction后台自动合并不需要手动的 Compaction 作业标签快照类似 Iceberg 的时间旅行但创建和管理更轻量流式读写同一张表可以被流任务写入同时被批任务读取互不阻塞3.3 组合后的化学反应Flink SQL (实时写入) ↓ Fluss 主键表 (秒级可见支持 Upsert 和点查) ↓ 自动归档按时间或数据量 Paimon 表 (历史数据列存高性能分析) ↓ Trino / Spark 查询时自动 Union 两部分数据一句话以前 Flink 既要管实时写入又要管状态拼接现在 Fluss 管写入和热数据Paimon 管冷数据和归档Flink 的压力被大幅卸载。四、三个关键技术细节部分列更新、Delta Join、流式裁剪4.1 部分列更新实时宽表不用再写复杂 Flink 作业以前的宽表拼接需要 Flink 多流 Join状态膨胀到几百 GB动不动就 OOM。现在利用 Fluss 的部分列更新能力订单表、用户表、商品表分别写入 Fluss 主键表的不同列Fluss 自动按主键合并查询时直接得到完整宽表Flink 作业只需简单的单表写入不再维护大状态实测下来同一场景的 Flink 作业内存消耗从 120GB 降到了 18GB。4.2 Delta Join内存和 CPU 消耗下降超 86%传统双流 Join 需要维护两个流的状态而利用 Fluss 的实时 KV 点查一条流当主表另一条流通过索引直接查询 Fluss 中的维表数据状态只需维护一份。某风控宽表场景Delta Join 替代双流 Join 后TaskManager 堆内存从 32G 降至 4GCPU 利用率降低 86%。4.3 流式列裁剪即席查询不再扫全表Kafka 查询本质是消费全量消息而 Fluss 的 Arrow 列式存储让 Trino 查询时只读取需要的列。结合主键索引和分区裁剪百亿级表的单条点查延迟压到了 50 毫秒以内。五、新旧架构核心对比维度旧Kafka Iceberg新Fluss Paimon数据新鲜度分钟级秒级/亚秒级存储冗余Kafka Iceberg 双份Fluss 一份自动归档实时更新MERGE INTO 写放大主键表原生 Upsert宽表拼接Flink 多流 Join状态重部分列更新Flink 轻量化查询效率Kafka 全行扫描列式存储 列裁剪架构模式Lambda流批独立Kappa流批统一开发效率两套代码统一 SQL宽表开发效率提升 60%六、迁移方案我们的分步走策略6.1 数据迁移历史 Iceberg 表通过 Spark 作业批量转换为 Paimon 表。Paimon 提供从 Iceberg 迁移的兼容工具格式转换可以离线完成。6.2 实时链路切换原来Kafka → Flink → Iceberg的链路改为Flink → Fluss写入。Flink 作业需要修改 Sink Connector但 SQL 逻辑基本不变。切换时采用双跑验证确认数据一致性后再下线旧链路。6.3 对上游应用的影响DolphinScheduler 调度任务仅调整数据源配置任务编排逻辑不变。自研 PSC 采集引擎离线采集链路不受影响仍写 Iceberg 或 Paimon 均可。Trino 即席查询增加 Paimon 连接器和 Fluss 连接器前端 SQL 编辑器无需改动。七、结语从 Iceberg 到 Paimon从 Kafka 到 Fluss不是追逐新技术而是业务倒逼的结果。当实时风控要求秒级响应当宽表拼接把 Flink 集群压到报警边缘当两份数据的对账脚本越来越长——我们就知道架构必须往前走一步。Fluss Paimon 的组合让我们的数据新鲜度从分钟级跃升到秒级同时 Flink 作业的内存占用大幅降低。更重要的是流和湖的边界终于被打破了。如果你也在做实时数仓或湖仓升级点个赞让更多同行看到这套方案。你们团队目前用 Kafka Iceberg 还是已经升级了遇到过什么坑评论区聊聊。⭐收藏本文下次做实时架构选型时直接翻出来对比。延伸阅读【运维必备】Docker/K8s/Linux 高频命令速查手册持续更新延伸阅读从 Hadoop 到湖流一体数据底座的三次革命与终极选型指南延伸阅读揭秘大型数据中台湖仓一体架构如何支撑万亿级数据流转延伸阅读再见组件地狱我们将 7 个开源引擎替换成一个华为云 GaussDB(DWS)数据中台彻底变轻了