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

在 AI 驱动的数据应用场景中，企业越来越需要一套同时支撑实时消费、历史沉淀与多引擎复用的数据底座。Kafka、Iceberg 开放表格式与对象存储的组合，正成为流数据入湖的重要方向。但传统依赖 Flink、Spark 等外部 ETL 作业的方式，也带来了链路长、系统边界多、运维复杂等问题。本文围绕“零 ETL”这一趋势，讨论流数据入湖为什么需要做架构减法，并结合 Kafka × Table Bucket 的实践，分析一种将通用入湖能力前移到消息与表存储链路中的方案，如何在降低复杂度的同时，兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。

过去几年，企业数据体系的演进路径已逐渐清晰：从传统离线数仓走向实时数仓，再从“流批并立”走向统一的数据湖与开放表格式。进入 AI 时代后，这一趋势进一步加快——越来越多的数据场景同时提出实时处理与历史分析的双重要求。

无论是模型训练、特征工程、在线推理，还是经营分析、用户洞察、风控审计，企业都需要一套既能承接实时数据、又能沉淀长期数据资产的数据底座。前者强调低延迟与持续处理能力，后者强调低成本、可治理与多引擎复用能力。当两类能力被要求在同一份数据上同时实现，数据就必须在更短的链路上完成接入、沉淀和复用。

在这一背景下，Kafka + Iceberg（开放表格式）+ 对象存储已成为一类常见的架构组合：Kafka 承接持续变化的数据流，Iceberg 将数据组织为可治理、可查询、可演进的表，对象存储承载海量历史数据并提供低成本、可扩展的存储底座。自 2024 年 AWS 推出 S3 Tables 之后，围绕“流式接入 + 开放表格式 + 对象存储”的架构方向也变得更加明确。

图 1：流式接入、开放表格式与对象存储正在形成新的数据底座组合

随着 Lakehouse 架构成为大数据领域的主流范式，将流式数据实时或近实时地写入开放表格式（Iceberg / Delta Lake / Hudi）已成为刚需。Kafka 作为主流的流数据总线，其与数据湖的集成能力直接影响架构选型。从近两年的产品演进和用户需求看，实时入湖领域大致呈现出四个趋势：

• 开放格式优先：Iceberg 凭借其开放的元数据标准、多引擎兼容及良好的 Schema 演进能力，在跨云数据湖与开放生态场景中的采用率持续提升，已成为开放表格式中的核心选项之一。

• 零 ETL 诉求：越来越多的用户倾向于减少数据搬运环节，希望消息系统更直接地将数据持久化为开放表格式，以降低架构复杂度与延迟。

• 存算分离深化：无论是 Kafka 存储层还是数据湖存储层，存算分离已成为降本增效的核心架构演进方向。

• Serverless 化：流处理与消息服务的 Serverless 化降低了运维门槛，按需计费模式成为不少中小企业与新业务的首选。

从竞争格局来看，当前 Kafka 入湖市场可划分为三大阵营，技术路径与商业取向差异明显：

事实上，真正困难的并不在于“Kafka 能否将数据写入表”，而在于“能否稳定、高效、低成本地完成写入”。

一方面，实时数据天然连续且碎片化，如果写入策略不合理，就容易带来小文件、分区失衡、元数据膨胀、写放大与 Compaction 压力；另一方面，上游字段变化、类型变更与 CDC 语义，又会与表格式对 Schema、一致性与事务的要求发生碰撞——Schema 如何演进、Update / Delete 如何表达、写入失败后如何恢复，都是生产环境中的关键问题。

从落地价值看，这类方案之所以受到持续关注，在于它同时解决了三类现实诉求：通过云原生架构降低整体建设和运维成本；让实时接入与长期分析更接近“流湖一体”的协同方式；并在保留用户自有对象存储数据主权的前提下，借助托管化能力降低小文件治理、Schema 演进与链路维护的负担。

这也意味着，流数据入湖的核心命题正在改变：不再是“要不要采用这套技术组合”，而是“能否通过架构减法收敛链路复杂度，把通用入湖能力尽量前移为平台能力”。从当下的演进方向看，答案越来越清晰——实时入湖，正在告别外部 ETL。

如果说第一部分回答的是“为什么要做架构减法”，那么这一部分回答的就是：实时入湖链路中，真正被减掉的是什么。

传统的流数据入湖路径通常是：Kafka → Flink / Spark Streaming → 开放表 → 对象存储。这条链路已经相当成熟，在需要复杂清洗、实时聚合、状态计算与多流关联的场景中，依然是有效方案。

问题在于，并不是所有场景都需要一条完整的外部计算链路。很多时候，企业真正要解决的，是把 Kafka 中持续到来的数据稳定、连续地写成可查询、可管理的表。如果只是为了完成这一步，仍维护 Flink 或 Spark Streaming 作业，就意味着额外承担三类系统复杂度：

• 系统边界增加：数据从 Kafka 流出，再由外部任务消费、转换、写入与提交，中间至少跨越一次独立运行时和一套独立调度体系。链路越长，故障面越大，恢复路径也越复杂。

• 通用能力重复实现：消息解码、Schema 映射、位点管理、事务提交、小文件控制、失败恢复，本质上都是实时入湖中的共性工程问题，却常常需要在每条 ETL 作业中分别实现与维护。

• 平台成本持续上升：为支撑这些入湖任务，企业还要维护额外的流计算集群、监控体系、发布流程与排障机制。随着链路数量增加，这部分成本会不断累积。

图 2：面向流数据入湖的零 ETL 一体化方案示意

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

• 一层额外的数据搬运链路；

• 一批重复实现的工程逻辑；

• 一部分与业务价值无关的运维复杂度。

图 3：传统外部 ETL 链路与内建入湖方案的能力差异

从这个角度看，“零 ETL”更像是一种架构思路的变化：不是继续通过外部系统拼装链路，而是把通用入湖能力尽量收敛为基础设施的内建能力。对用户来说，这类能力更接近“零代码、配置即生效”的交付方式，而不再以独立 ETL 任务的形式存在。

如果说“零 ETL”的核心是把通用入湖能力收敛为平台能力，那么 Kafka × Table Bucket 的关键，就是让“从消息到表”的路径更短、更稳。

这里可以把 Table Bucket 理解为对象存储上的表承载能力。它不是简单地把文件写入对象存储，而是以表的方式组织、管理与提供数据，使数据既保留对象存储低成本、可扩展的特性，又具备面向计算与治理的结构化能力。

从逻辑上看，这类零 ETL 入湖路径通常可以分为三层：

与传统“Kafka → 外部 ETL → 表”的三段式架构相比，最大的变化在于：原本依赖外部作业完成的一部分通用入湖逻辑，被前移到了更靠近 Kafka 的链路中。

更进一步，转换引擎和表写入能力可以以内嵌方式运行在更靠近 Broker 的执行链路中，减少网络往返、独立调度与额外 ETL 集群带来的复杂度。在部分实现中，数据从 Kafka 分区到 Iceberg 表的转换可以在同一进程内完成，同步任务也可以与 Broker 生命周期绑定，使资源调度与故障恢复收敛在同一体系中。

图 4：Kafka × Table Bucket 的零 ETL 入湖整体架构

一条消息从写入 Kafka，到能被下游计算引擎查询到，中间会经过三个关键阶段。

第一阶段：记录转换

消息进入 Kafka 后，首先会被转换为适合表写入的结构化对象。这个过程通常由 RecordProcessor 一类组件完成，包括 Key / Value 反序列化、Transform 链处理与记录组装。它支持 String、Avro Registry、Protobuf 等多种 Converter，也可以通过 Flatten、Debezium 等转换链对嵌套结构进行展开或对 CDC 事件进行解包。最终，Key、Value、Headers 与 topic、partition、offset、timestamp 等元信息，会被整合为完整的结构化记录。

第二阶段：Schema 感知与演进

在真正写入表之前，系统需要比较当前记录的 Schema 与目标表的 Schema。如果发现兼容性变更——例如新增可选字段、必填字段变为可选、类型向上提升（int → long、float → double）——可以先刷新当前批次，再应用新 Schema 并继续写入。这样一来，常见的 Schema 变化就不再需要完全依赖人工干预。

第三阶段：Iceberg 写入与事务提交

完成转换与 Schema 处理后，数据会根据目标表与分区策略写入对象存储上的列式文件：

• Append 模式：使用 PartitionedWriter/UnpartitionedWriter 直接追加写入；

• Upsert 模式：同时生成 DataFile（数据文件）和 DeleteFile（删除标记文件），支持 Insert/Update/Delete 三种 CDC 操作。

当文件达到设定阈值（例如 64MB 这类可配置目标大小）后自动切换新文件，以降低文件过碎的风险。最终，通过表级事务原子提交生成新的 Snapshot，让下游获得一致可见的数据视图。

图 5：从 Kafka 消息到对象存储表的端到端写入路径

兼顾低延迟与强一致

实时入湖要真正可用，衡量标准并不只是“能不能写进去”，还包括在低延迟要求下能否保持稳定的一致性与可恢复性。尤其在分布式环境中，数据写入、元数据提交、进度管理与故障切换之间的协调，往往决定了链路能否长期稳定运行。

更理想的方式，是将关键状态内聚在主链路中，而不是依赖外挂 KV 或其他外部状态系统。比如，将入湖进度维护在 Kafka Leader 元数据中，可以减少系统耦合并降低不一致风险。与之配套的，则是更轻量化的高可用机制：节点切换或扩容时，新节点能够更快接管同步任务。

具体能力体现在几个方面：

• 存算分离 × 轻量化 HA：计算与数据持久化解耦后，计算层摆脱 ISR 重量级协议束缚，转而采用轻量 HA 方案。Follower Replica 仅作计算热备，保留最少元数据、处理最少变更请求；新节点在故障切换与弹性扩容时可快速接管。
  

• 双路同步缓解入湖场景的“延迟-吞吐”权衡：实时入湖的核心矛盾在于提交频率——频繁提交延迟低，但元数据与 flush 开销大；攒批提交吞吐高，却牺牲新鲜度。此类方案将同步链路拆为两条路径：增量预同步在提交间隙持续完成数据读取、转换与文件写入；强一致同步触发时只需提交少量增量即可完成 Iceberg 事务，从而实现延迟与吞吐同向提升。
  

• 提供嵌入式与独立式两种架构模式：嵌入式模式可以实现更低的资源开销，但同进程运行会增加 GC 压力，对消息收发延迟产生潜在影响；独立式模式资源成本较高，但由于进程隔离，可减少对核心收发链路的干扰。双模式设计旨在精准匹配不同客户的功能诉求与业务负载特征。
  

• 入湖进度内聚于 Leader 元数据：入湖进度直接维护在 Kafka Leader 元数据中，彻底去除对外挂 KV 等外部系统的依赖，保证了强一致性，同时消除系统间耦合。

图 6：低延迟与强一致并不矛盾，

关键在于状态收敛方式

Schema 不一致是 Kafka 入湖链路中最常见、也最容易引发运维负担的问题之一。更合理的方式，是将常见的兼容性变更收敛为系统能力：

图 7：将高频 Schema 变化前移为平台能力

小文件问题是实时入湖中最常见的性能隐患之一。实时数据连续且零散到达，如果写入时缺少控制，很容易在对象存储中产生大量小文件，进而带来元数据膨胀、查询规划变慢与 Compaction 压力增大等连锁问题。因此，小文件治理不能只依赖后置 Compaction，而应在写入阶段尽量减少问题。

更完整的做法是采用多层递进式治理机制，在前置和后置两个层面同时治理：

通常 L1 ~ L3 在入湖引擎侧完成，L4 由后台离线 Compaction 承担。

合理的分区策略直接影响后续查询能否有效裁剪数据范围，减少全表扫描和无效 I/O。这类方案通常支持 7 类主流分区方式：字段直接分区、Year / Month / Day / Hour 时间分区、Bucket 分区与 Truncate 分区，并支持多维组合分区。

# 示例：按地区 + 天双维分区partition_by: "region, day(timestamp)"
# 示例：高基数 ID 哈希分桶partition_by: "bucket(user_id, 10)"
# 示例：邮箱前缀归类partition_by: "truncate(email, 5)"

类似 bucket(user_id, 10) 或 truncate(email, 5) 这样的策略，更适合高基数或前缀归类场景。

图 9：分区设计决定查询裁剪效率与长期组织方式

对于数据库变更同步等场景，实时入湖不只是追加新数据，还需要处理 Insert、Update、Delete 等状态变化。如果平台能够直接识别这些语义并映射为表级 Upsert 或 Delete，那么对象存储上的表就能更接近实时地呈现当前业务状态。

# CDC 入湖典型配置transforms: debezium_unwrapwrite_mode: upserttable_format: iceberg-v2

这类能力通常会与 Debezium 等 CDC 工具适配，自动解包变更事件，并借助 Iceberg 的 Equality Delete 机制生成对应的数据文件与删除标记，在读取阶段自动合并为最新视图。

零 ETL 方案若要成为基础设施能力，除了链路更短之外，还必须具备较好的开放兼容性——不仅要能把数据写进去，还要能平滑融入企业既有的数据生态。这类方案通常需要兼容多种 Catalog 接口：

• Iceberg REST Catalog：开放生态主流标准；

• OSS Tables 兼容 Catalog：面向 S3 Tables 迁移场景。

再往下游看，当表能力建立在开放接口与开放格式之上时，Spark、Trino、Flink、DuckDB 等不同计算与查询引擎，都可以围绕同一份数据开展分析与处理。

上述能力叠加后，Kafka × Table Bucket 的价值不只是技术可行性，更在于它对当下数据基础设施的适配程度。它真正值得关注的，并不只是减少了一条 ETL 作业，而是从协议层到存储层重新收敛实时入湖能力。

这类融合架构首先改变的是“流”与“表”长期割裂的状态。传统模式下，Kafka 承接流式数据，Iceberg 组织分析表，中间需要借助外部 ETL 系统完成格式转换、Schema 对齐与提交控制；而在融合架构中，这些能力被尽量内嵌到更靠近主链路的位置。

具体来看，它带来三点变化：

• 流批自动转换：数据写入即入湖，天然支持流读与批读，无需维护两套代码路径。

• Schema 自适配：自动感知并处理上游 Schema 变更，支持 ADD_FIELD、MAKE_OPTIONAL、PROMOTE_TYPE 及嵌套结构递归演进，显著减少人工干预。

• 进程内绑定调度：转换引擎与 Broker 进程内联，计算与存储深度协同，在缩短链路的同时提升数据新鲜度。相比传统外部 ETL 任务，这类方式更容易将数据可见性收敛到分钟级，在条件合适时还可以进一步逼近秒级。

图 11：从协议到存储的能力收敛，是这类架构的核心价值

这类架构的第二个价值，在于用更轻的方式完成原本依赖外部 ETL 作业承担的通用入湖任务。

一方面，零 ETL 的轻量化架构直接打通了 Kafka 流式协议与 Iceberg 表格式，减少了 Flink / Spark Streaming 这类中间任务链带来的开发与运维成本。另一方面，依托托管化能力，用户更接近“零代码、一键开启、配置即生效”的使用方式，显著缩短入湖链路的交付周期。

更关键的是，围绕稳定性与成本，这类架构通常会内建一整套优化机制：

• 多层小文件治理：从内存 Buffer 合并、32MB 微批处理、64MB 目标文件大小到后台 Compaction，分层控制文件组织质量。

• 更低 TCO：通过云原生架构与存算协同，减少额外计算链路与重复系统建设带来的综合成本；在通用实时入湖场景下，成本结构更接近“Kafka + 对象存储”的二元组合，而不是“Kafka + ETL + 对象存储”的三重成本。

• 更稳定的生产表现：通过进度内聚、轻量 HA、事务提交与托管化恢复机制，提升链路在故障切换与持续运行中的稳定性。

从上表的对比可以看出，零 ETL 方案在通用入湖场景下显著简化了架构；只是在涉及窗口聚合、多流 Join 或复杂状态计算时，仍需要专门的流计算引擎配合。

在前述价值之外，这类方案能否成为基础设施能力，还取决于它能否覆盖足够多的真实场景。从当前能力看，它已经具备较强的通用性：

• 多格式兼容：支持 Avro、Protobuf、String 等多种序列化格式，适配主流数据生产场景。

• 完整 CDC 支持：原生集成 Debezium 解包，支持 Insert / Update / Delete 三类操作，适合数据库到数据湖的实时同步。

• 灵活分区策略：支持 7 种分区方式与多维组合，覆盖日志、用户画像、IoT 设备等典型分析场景。

• 多 Catalog 适配：REST、OSS Tables 等 Catalog 可直接对接，更容易融入现有技术生态。

当然，也需要对它的边界保持清醒判断。零 ETL 很适合解决“将流数据稳定沉淀为表”这类通用问题，但这并不意味着复杂流计算引擎会被替代。如果业务场景需要窗口聚合、多流 Join、维表关联、复杂事件处理或大规模状态管理，那么 Flink、Spark Streaming 仍然不可替代；而零 ETL 更擅长解决的是“如何让实时数据更自然地沉淀为湖上的表”。

从这个意义上说，两者并不是简单替代关系，而是更合理的分工：复杂计算交给专门的流计算引擎，通用入湖交给平台内建能力，长期数据资产沉淀交给对象存储与开放表。这种分工本身，就是一种架构减法。

并不是所有场景都需要同一种入湖方式。但从实际落地看，有四类场景会优先从 Kafka × Table Bucket 这种零 ETL 路径中受益。

图 12：零 ETL 入湖的典型场景

日志是最典型的流式数据之一。应用日志、访问日志、安全日志与系统日志通常先通过 Filebeat / FluentBit 等工具采集到 Kafka，再由不同系统消费。如果这些数据能够按天或按业务维度直接写成对象存储上的表，下游就可以通过 Trino、Spark 等引擎直接查询，既保留实时接入能力，也更适合长期留存与分析。

partition_by: "day(timestamp), service_name"write_mode: appendtarget_file_size: 64MB

这类场景的共同特点是写入持续、查询维度相对稳定、保留周期较长，因此非常适合通过更短的链路直接沉淀为表。

数据库变更同步是零 ETL 最具代表性的场景之一。通过 Debezium 等工具将 MySQL Binlog 或 PostgreSQL WAL 中的变更事件写入 Kafka 后，如果平台能够识别 Insert、Update、Delete 三种 CDC 语义，并将其映射为对象存储表上的 Upsert 或 Delete，那么数据湖中的表就不仅保存了一串变更事件，还能够更接近实时地呈现当前业务状态。

在实现上，这类场景通常会开启类似 debezium_unwrap + upsert 的模式，并映射为数据文件与删除标记文件的组合。

对这类场景来说，关键价值不只是“把变更写进去”，而是尽量在入湖阶段就保留主键语义、删除语义与可查询的当前视图。

IoT 与埋点数据通常具有四个共同特征：吞吐高、来源多、字段变化频繁、历史保留需求强。这类场景很容易把平台拖入“链路越来越多、作业越来越重”的状态。如果将通用入湖能力收敛在 Kafka 与 Table Bucket 之间，再利用对象存储承接海量历史数据，就能更好地平衡实时接入、成本控制与长期分析需求。

# 高吞吐、时序化场景的组合分区partition_by: "bucket(device_id, 50), day(timestamp)"

下游既可以用 Spark 做大规模分析，也可以用 DuckDB 做轻量查询。

在模型训练过程中，需要同时管理海量路测图片、视频片段、点云数据以及对应的标注元数据。过去，非结构化数据存放在对象存储，结构化元数据存放在数据库，向量检索依赖独立的向量数据库，三类数据分散在不同系统，数据关联和版本回溯极为困难。

依托阿里云 OSS「对象 + 向量 + 表格」的完整数据存储体系，路测原始数据写入 OSS 对象桶，Embedding 与召回索引落入 OSS 向量桶，Kafka 实时采集的车辆标注信息、传感器元数据则通过入湖能力写入 OSS Table Bucket。三桶数据共享同一套账号、权限与审计体系，训练样本的筛选与版本回溯可在单一平台完成，数据准备效率提升数倍，为模型快速迭代奠定了坚实基础。

“零 ETL”很容易被理解为一个功能概念，仿佛它意味着数据不再需要转换，或者所有处理都会收敛到同一条链路中。但从数据基础设施演进的角度看，它真正要解决的问题更具体：不是让数据不经过处理，而是让那些高频、通用、重复出现的入湖能力，不再依赖外部系统反复建设。

在流数据入湖这件事上，这一点尤为重要。企业面对的不是一次性项目，而是一条会长期运行、持续扩展、不断演进的基础设施链路。只要系统边界过多、处理路径过长、状态管理过于分散，复杂度就会在规模增长中逐步暴露出来。

因此，Kafka × Table Bucket 所代表的，并不只是“把数据写进对象存储上的表”，而是用一条更短的路径，将消息接入、格式转换、Schema 适配、CDC 处理、事务提交与文件组织等通用能力尽量收敛在一起，让实时入湖更接近平台原生能力，而不是一批外部任务的拼装结果。

这背后反映出的，是 AI 时代数据架构的一个更普遍趋势：数据链路更短，数据资产更开放，表能力与存储能力更靠近，平台能力尽量内聚而不是持续外扩。

从这个意义上说，真正成熟的“零 ETL”，减少的并不只是一段处理过程，而是一层持续累积的系统复杂性。这正是下一阶段数据基础设施最值得关注的变化。

在可预见的下一阶段，这类能力还会继续沿三个方向演进：

• 更丰富的 Transform 与更智能的运维能力；

• 与查询、计算、治理体系进一步打通；

• 持续适配 Iceberg 等开放表格式演进，并兼容更多面向 AI 场景的新型格式。

关于实现

本文讨论的 Kafka × Table Bucket 零 ETL 入湖能力，目前已在阿里云 ApsaraMQ for Kafka × OSS Tables 上具备相应实现，完成了初步实践验证，并已对外开启邀测。

用户可在不引入额外 ETL 作业的前提下，将 Kafka Table Topic 以 Iceberg 开放表格式持久化到 OSS Table Bucket，并通过 Iceberg REST Catalog 与 Spark、Trino、Flink、DuckDB 等开放生态对接。文中提及的多层小文件治理、Schema 自适应演进、CDC Upsert 与多 Catalog 兼容等能力，也已在该方案中实现。