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

📌 一句话摘要

本文深入探讨了在 AI 时代，流数据入湖从依赖外部 ETL 作业向“零 ETL”架构演进的趋势，并以 Kafka × Table Bucket 方案为例，分析了如何通过将通用入湖能力前移至消息与存储链路，实现架构减法。

📝 详细摘要

文章首先指出，在 AI 驱动的数据应用中，企业需要同时支撑实时消费与历史分析的数据底座，Kafka + Iceberg + 对象存储成为主流组合。然而，传统的 Kafka → Flink/Spark → Iceberg 链路存在系统边界多、通用能力重复实现、运维成本高等问题。因此，“零 ETL”趋势应运而生，其核心并非消除数据处理，而是将高频、通用的入湖能力（如格式转换、Schema 演进、CDC 处理、小文件治理）收敛为平台内建能力。文章详细介绍了阿里云提出的 Kafka × Table Bucket 方案，阐述了其从记录转换、Schema 感知到 Iceberg 写入的端到端流程，并重点分析了其在低延迟与强一致、Schema 自适应演进、多层小文件治理、智能分区策略、完整 CDC/Upsert 支持以及多 Catalog 兼容等方面的关键能力。文章认为，这种架构通过协议与格式的深度融合，实现了更低的成本与更强的稳定性，并对比了与传统方案的能力差异。最后，文章指出实时日志分析、数据库变更实时入湖、IoT 多源数据汇聚和 AI 多模态训练数据 Pipeline 是优先受益的场景，并展望了该架构的未来演进方向。

💡 主要观点

- “零 ETL”的核心是架构减法，将通用入湖能力收敛为平台内建能力。 传统依赖 Flink/Spark 的外部 ETL 链路带来系统边界多、重复实现和运维成本高等问题。“零 ETL”并非不做处理，而是将格式转换、Schema 演进、CDC 处理等高频通用能力前移至消息与存储链路中，减少外部依赖。

Kafka × Table Bucket 方案通过协议与格式的深度融合，实现流批一体。 该方案将转换引擎内嵌于 Broker 进程，数据写入即入湖，天然支持流读与批读。通过 Schema 自适配、进程内绑定调度等机制，显著缩短链路，提升数据新鲜度，并降低架构复杂度。

方案通过多层机制解决了实时入湖中的稳定性与一致性问题。 通过将入湖进度内聚于 Leader 元数据、采用轻量 HA 方案、双路同步机制以及多层小文件治理（内存 Buffer、微批处理、目标文件控制、后台 Compaction），在保证低延迟的同时实现了强一致性和系统稳定性。

零 ETL 方案并非替代复杂流计算引擎，而是形成更合理的分工。 对于窗口聚合、多流 Join 等复杂计算，Flink/Spark Streaming 仍不可替代。零 ETL 擅长解决“将流数据稳定沉淀为表”的通用问题，两者形成互补，共同构成更高效的数据基础设施。

💬 文章金句

- “零 ETL”真正减掉的，并不是数据处理本身，而是那些原本需要依赖外部作业反复承担的通用入湖能力。

• 真正困难的，不是“能写”，而是“持续稳定地写”。
• 实时入湖，正在告别外部 ETL。
• 真正成熟的“零 ETL”，减少的并不只是一段处理过程，而是一层持续累积的系统复杂性。

📊 文章信息

AI 初评：88

来源：阿里云开发者

作者：阿里云开发者

分类：软件编程

语言：中文

阅读时间：37 分钟

字数：9042

标签： 数据架构, 实时入湖, 零 ETL, Iceberg, Kafka

阅读完整文章