AutoMQ x 阿里云 OSS Tables：基于 Iceberg 构建流表一体的实时入湖

实时业务产生的数据越新分析价值越高。用户行为、交易流水、设备上报和业务日志通常先写入 Apache Kafka用来支撑推荐、风控、监控和实时看板这些新鲜数据也要尽快进入 Lakehouse供报表分析、特征工程和业务分析继续使用。Kafka 到 Lakehouse 的入湖效率正在影响数据从业务现场进入分析和治理流程的速度。过去几年Kafka、Apache Iceberg 和对象存储已经成为构建现代化数据栈的一种通用范式。Kafka 负责承接实时写入Iceberg 负责把对象存储上的文件组织成开放表格式OSS 这样的对象存储提供弹性容量和低成本持久化。在这个组合里业务可以继续使用 Kafka 写入实时数据分析侧可以通过 Iceberg 表读取同一批数据底层存储则交给云上的对象存储承载提供数据可用性和持久性保障。这条路径进入生产环境后挑战主要集中在两处Kafka Topic 里的连续事件需要稳定变成 Iceberg 表数据不能长期依赖额外同步任务来维持 Topic 到 Table 的转换。Iceberg 表生成之后还需要 Catalog、元数据管理、文件清理和 Compaction 等表维护能力否则实时写入会持续放大小文件、快照和元数据压力。AutoMQ 是基于对象存储、与 Kafka 100% 兼容的新一代 Diskless Kafka面向传统 Kafka 的成本、弹性和运维痛点重新设计了存储架构。2025 年初AutoMQ 在阿里云 OSS 上发布 Table Topic 能力让 Kafka Topic 可以自动物化为 Apache Iceberg 表先解决了写入侧的问题。2026 年 5 月 20 日阿里云在阿里云峰会上发布 OSS Tables为 OSS 上的 Iceberg 表提供 Iceberg REST Catalog 兼容接口和自动化表维护能力。两者放在一起正好覆盖 Kafka Topic 转表和 Iceberg 表长期维护这两类工作。接下来先看传统实时入湖链路里这两个问题为什么会长期困扰平台团队。实时数据入湖痛点分析在传统实时入湖架构中业务系统通常先把事件写入 KafkaFlink、Spark 或 Connector 再从 Kafka 消费数据将数据转换成 Parquet 文件并提交到 Iceberg 表。这个架构分工清楚Kafka 负责流式缓冲和扇出计算任务负责转换Iceberg 负责开放表格式对象存储负责保存数据。很多团队会先选择这条路径因为它复用了现有 Kafka、Flink/Spark、Iceberg 和对象存储组件不需要一开始就改写生产链路。进入生产长期运行后实时入湖的维护成本主要集中在两类工作上Kafka Topic 的转换处理成本平台团队需要维护额外的 Flink、Spark 或 Connector 作业把 Kafka Topic 转换成 Iceberg Table。任务开发、部署、监控、Checkpoint、失败恢复和版本升级都会持续占用人力。Iceberg 表优化工作表生成之后还要持续处理 Snapshot、Compaction、文件清理和分区策略避免小文件、快照堆积和元数据膨胀影响读写性能。实时写入如果提交过于频繁会持续生成 Snapshot 和元数据文件攒批不足会产生大量小文件进而放大 Manifest、查询计划和对象存储 API 调用成本分区粒度过细也会让文件数量和元数据压力重新回到系统里。这两类工作都不属于业务逻辑却会长期留在平台团队的日常维护清单里。实时入湖的难点早已超过“选择Kafka 和 Iceberg”本身。Kafka 写入路径、Iceberg Commit、Catalog 管理和对象存储表维护要一起处理这些责任一旦分散到多套系统里平台团队就要分别看写入进度、处理提交失败、维护 Catalog、清理无效文件并定期做 Compaction。实时数据高效入湖在 AutoMQ x OSS Tables 的实时入湖链路中数据源写入 AutoMQ TopicTable Topic 在 AutoMQ 内部完成流数据到 Iceberg 表的物化OSS Tables 在 OSS 对象桶上提供 Iceberg REST Catalog 和自动化表维护。整条路径较传统方案大幅简化只经过两个服务AutoMQ和 OSSKafka Producer、CDC、日志或 IoT 数据源持续写入 AutoMQ TopicAutoMQ 把流式数据攒批、转换为 Parquet File 并提交为OSS Tables 的 Iceberg 表OSS Tables 提供 Catalog和持续的存储侧数据优化下游 Spark、Flink、Trino 或 BI 系统通过 Iceberg 接口读取表数据。AutoMQ 侧流到表的物化能力内置在集群内部。TableWorker 负责把 Kafka Record 转换成 Parquet File 并写入对象存储TableCoordinator 负责管理同步进度和中心化提交——Iceberg 每次 Commit 都会产生新的 Snapshot 和元数据变化由 TableCoordinator 统一控制提交节奏避免 Worker 独立高频提交带来的提交冲突和元数据膨胀。Schema 方面Kafka Schema 作为数据进入表之前的约束来源上游 Schema 变化时 Iceberg 表结构跟随演进不需要在消息、流处理作业和目标表之间手动对齐。对于 Binlog 或 CDC 场景主键和操作类型还可以映射到 Iceberg 的 Upsert 语义让 OLTP 变化直接以表格式进入 OLAP 分析层。OSS Tables 侧表数据写入后由存储集群接管数据维护。OSS Tables 提供对表格数据的压缩、快照管理和未引用文件清理保持数据读写的性能处于最优。因为表数据维护直接在 OSS存储集群完成不需要把数据从 OSS 读到计算侧处理后再写回不占用业务带宽。这样一来实时入湖链路不再需要把每个环节都交给平台团队自己装配。Kafka 生态继续从 Topic 写入Iceberg 生态继续按开放表格式查询OSS 则从”存放文件的地方”变成”存储表数据的地方”。架构层需要解决的问题传统做法AutoMQ x OSS Tables新方案优势流式写入层业务继续使用 Kafka 协议写入数据进入湖表前不打断实时链路Kafka 外部 Flink/Spark/Connector 同步任务Kafka 写入路径内置流到表的物化能力AutoMQ 内置流表自动转化能力无需用户关心转换逻辑简化使用能力丰富支持avro/json/protobuf多种格式适配debezium 格式满足 CDC 场景需求减少组件数量AutoMQ和OSS端到端保障数据入湖的高性能表管理层Iceberg 表需要 Catalog、元数据事务和表维护自建或额外接入外部 Catalog、Hive Metastore、Iceberg REST Catalog 等服务OSS提供托管 Catalog 和表优化能力Compaction 不再消耗计算与存储间带宽和对象存储 QPS团队无需关注业务逻辑以外的维护工作存储底座流数据和表数据都要落在低成本、弹性、开放的存储层上Kafka 本地盘/云盘 对象存储分别承载对象存储同时承载流存储和表存储统一的共享存储层无需维护异构存储介质维护成本更低基于 OSS 拥有几乎无限的存储容量免容量管理、存储成本更低Table Topic 效果演示AutoMQ 是阿里云合作伙伴并已上架阿里云云市场。在阿里云环境中用户可以通过阿里云云市场 Marketplace 搜索 AutoMQ并借助计算巢将 AutoMQ 环境部署到自己的 VPC 中。集群启用 Table Topic 后业务仍然按 Kafka 协议写入 TopicAutoMQ 在后台把这些记录物化为 Iceberg 表。接下来我们将通过一个例子演示 AutoMQ Table Topic 配合 OSS Table 使用的实时入湖效果。具体的代码可以通过 Github 获取在你的本地环境中亲自体验整个流程。在本示例中测试脚本先会向 AutoMQ 写入 Avro 格式数据用来模拟业务事件持续进入 Kafka。上游应用仍然使用 Kafka 协议生产消息不需要因为入湖链路改变写入方式。数据写入后AutoMQ 将这些记录转换为 Parquet DataFile并完成 Iceberg Commit。Spark 在这里作为下游查询引擎用来读取生成的 Iceberg 表验证这批数据已经进入 Lakehouse 查询路径。从 OSS Tables 的 Table Bucket 视角看AutoMQ 写出的数据已经按照 Iceberg 表结构进入 OSS。Catalog、表元数据和后续表维护由 OSS Tables 管理下游 Spark、Flink、Trino 或 BI 系统可以继续通过 Iceberg 接口读取这些表。这三张截图放在一起可以看到一条更短的实时入湖路径。业务侧仍然按 Kafka 协议生产消息不需要为了入湖改 Producer 或旁路写文件AutoMQ 在集群内部完成攒批、Parquet DataFile 生成和 Iceberg Commit把 Topic 数据持续写成 Iceberg 表OSS Tables 管理 Catalog、表元数据和表维护下游分析系统继续通过 Iceberg 接口读取。总结AutoMQ Table Topic 解决的是 Kafka 数据如何实时成为 Iceberg 表OSS Tables 解决的是这些表如何在 OSS 上被托管和持续优化。前者让流数据入表后者让表在对象存储上长期可运营——这也是“OSS Tables 补齐最后一块拼图”的含义。对平台团队来说新方案带来四项收益零额外同步任务AutoMQ 内置 Topic→Table 物化不需要维护 Flink/Spark 转换作业的部署、监控和故障恢复。零额外数据维护计算负担和带宽OSS Tables 在存储侧完成 Compaction 和文件清理不需要配置 Spark 集群不占用业务带宽。Schema 自动演进AutoMQ Schema Registry 统一管理表结构变更CDC 场景直接映射 Iceberg Upsert 语义。架构简化两个全托管服务组合平台团队不需要自建任何实时入湖组件。想基于 AutoMQ 评估 Kafka 到 Iceberg 的实时入湖路径可以通过阿里云市场订阅 AutoMQ或者通过 AutoMQ 官方网站 联系我们。您也可以通过OSS Tables 官方网站 进一步了解 OSS Tables。