AI 时代，实时入湖正在告别 ETL：从 Kafka 到 Iceberg 的架构减法

📌 一句话摘要

本文深入探讨了在 AI 时代，如何通过将通用入湖能力前移至消息与表存储链路，实现从 Kafka 到 Iceberg 的“零 ETL”架构减法，以降低复杂度、提升实时性与一致性。

📝 详细摘要

文章围绕“零 ETL”这一趋势，系统阐述了流数据实时入湖为何需要做架构减法。作者首先指出，在 AI 驱动的数据应用中，企业需要同时支撑实时消费与历史沉淀的数据底座，而 Kafka + Iceberg + 对象存储的组合已成为主流方向。然而，传统依赖 Flink、Spark 等外部 ETL 作业的方式带来了链路长、系统边界多、运维复杂等问题。文章详细分析了“零 ETL”的核心思路：将消息解码、Schema 映射、位点管理、事务提交、小文件控制等通用入湖能力，从外部 ETL 作业中剥离，前移至更靠近 Kafka 主链路的平台内建能力中。文章以阿里云 ApsaraMQ for Kafka × OSS Tables 的实践为例，介绍了 Kafka × Table Bucket 的零 ETL 入湖工作原理，包括记录转换、Schema 感知与演进、Iceberg 写入与事务提交等核心数据流。同时，文章重点阐述了该方案在稳定性、一致性、Schema 自适应演进、多层小文件治理、智能分区策略、完整 CDC/Upsert 支持以及多 Catalog API 兼容等方面的关键能力。最后，文章分析了该架构在实时日志分析、数据库变更实时入湖、IoT 多源数据汇聚和 AI 多模态训练数据 Pipeline 等典型场景中的优先受益价值，并指出“零 ETL”的本质是减少系统复杂性，而非完全替代复杂流计算引擎。

💡 主要观点

- “零 ETL”的核心是架构减法，将通用入湖能力收敛为平台内建能力。 传统入湖依赖 Flink/Spark 等外部 ETL 作业，带来链路长、系统边界多、运维复杂等问题。“零 ETL”并非消除数据处理，而是将消息解码、Schema 映射、事务提交等高频、通用的入湖逻辑，从外部作业中剥离，前移至消息系统与表存储的链路中，从而降低架构复杂度。

Kafka × Table Bucket 方案通过内嵌转换引擎，实现了更短、更稳的入湖路径。 该方案将转换引擎和表写入能力内嵌到更靠近 Kafka Broker 的执行链路中，减少了网络往返和独立调度。数据从 Kafka 分区到 Iceberg 表的转换可在同一进程内完成，同步任务与 Broker 生命周期绑定，使资源调度与故障恢复收敛在同一体系内。

方案在稳定性、一致性和可治理性上进行了系统性设计。 通过将入湖进度内聚于 Leader 元数据、采用双路同步机制缓解延迟-吞吐权衡、以及多层递进式小文件治理（从内存 Buffer 合并到后台 Compaction），该方案在实现低延迟的同时，保证了强一致性和长期运行的稳定性。

零 ETL 方案与复杂流计算引擎是分工关系，而非替代关系。 零 ETL 擅长解决“将流数据稳定沉淀为表”的通用问题，适用于日志分析、CDC 同步等场景。但对于需要窗口聚合、多流 Join 或复杂状态管理的场景，Flink、Spark Streaming 仍然不可替代。两者形成更合理的分工：复杂计算交给专门引擎，通用入湖交给平台内建能力。

💬 文章金句

- 真正困难的，不是“能写”，而是“持续稳定地写”。

• “零 ETL”真正减掉的，并不是数据处理本身，而是那些原本需要依赖外部作业反复承担的通用入湖能力。
• 让实时入湖更接近平台原生能力，而不是一批外部任务的拼装结果。
• 真正成熟的“零 ETL”，减少的并不只是一段处理过程，而是一层持续累积的系统复杂性。

📊 文章信息

AI 初评：86

来源：InfoQ 中文

作者：InfoQ 中文

分类：软件编程

语言：中文

阅读时间：34 分钟

字数：8350

标签： 数据工程, 实时入湖, 零 ETL, Kafka, Iceberg

阅读完整文章