实时业务产生的数据越新，分析价值越高。用户行为、交易流水、设备上报和业务日志通常先写入 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 表长期维护这两类工作。接下来先看传统实时入湖链路里，这两个问题为什么会长期困扰平台团队。
实时数据入湖痛点分析
在传统实时入湖架构中，业务系统通常先把事件写入 Kafka，Flink、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 Topic，Table Topic 在 AutoMQ 内部完成流数据到Iceberg 表的物化，OSS Tables 在 OSS 对象桶上提供 Iceberg REST Catalog 和自动化表维护。整条路径较传统方案大幅简化，只经过两个服务，AutoMQ和 OSS：Kafka Producer、CDC、日志或 IoT 数据源持续写入 AutoMQ Topic；AutoMQ 把流式数据攒批、转换为 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 写入路径内置流到表的物化能力 |
|
表管理层 |
Iceberg 表需要 Catalog、元数据事务和表维护 |
自建或额外接入外部 Catalog、Hive Metastore、Iceberg REST Catalog 等服务 |
OSS提供托管 Catalog 和表优化能力 |
|
存储底座 |
流数据和表数据都要落在低成本、弹性、开放的存储层上 |
Kafka 本地盘/云盘 + 对象存储分别承载 |
对象存储同时承载流存储和表存储 |
|
Table Topic 效果演示
AutoMQ 是阿里云合作伙伴，并已上架阿里云云市场。在阿里云环境中，用户可以通过阿里云云市场 Marketplace 搜索 AutoMQ，并借助计算巢将 AutoMQ 环境部署到自己的 VPC 中。集群启用 Table Topic 后，业务仍然按 Kafka 协议写入 Topic，AutoMQ 在后台把这些记录物化为 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。
