摘要：在数字化转型进程中，用户交互行为产生的多维度数据已成为企业的重要战略资产。以短视频平台为例，基于用户点赞事件的实时推荐算法能显著提升用户活跃度和平台粘性。这类实时数据主要通过 Apache Kafka 流处理平台进行传输，通过其扇出（Fanout）机制实现多业

云布道师

在数字化转型进程中，用户交互行为产生的多维度数据已成为企业的重要战略资产。以短视频平台为例，基于用户点赞事件的实时推荐算法能显著提升用户活跃度和平台粘性。这类实时数据主要通过 Apache Kafka 流处理平台进行传输，通过其扇出（Fanout）机制实现多业务系统的并行消费。企业的数据应用需求呈现双重特性：一方面需要实时流处理能力，另一方面需要依托历史数据进行多维聚合分析。大数据分析技术经过多年演进，已从传统数据仓库架构发展为现代数据湖体系。

在数据湖技术生态中，Apache Iceberg 凭借其开放性设计已确立事实标准地位。该技术不仅获得全球企业广泛采用，还构建了包含 Apache Spark、Amazon Athena、Presto 等主流计算引擎的完整生态系统。2024 年 AWS re:Invent 大会上，基于 Iceberg 格式的 S3 Tables 服务正式发布，标志着云原生数据湖解决方案进入新阶段。

以 Apache Kafka、数据湖平台、Apache Iceberg 表格式为核心的现代化数据湖架构已成为新趋势。随之而来的挑战包括：

本文将从三个维度展开论述：首先分析 Iceberg 的技术优势及其成为行业标准的原因，其次详细阐述数据入湖的最佳实践方法，最后重点介绍 AutoMQ 如何利用阿里云 OSS 高效解决 Kafka 数据入湖问题。通过 AutoMQ 和阿里云服务的结合，用户可以轻松实现 Kafka 数据入湖的最佳实践。

小贴士：AutoMQ 是构建在对象存储上的新一代 Kafka，能实现秒级自动弹性并显著降低成本，目前服务于吉利汽车、京东、知乎、小红书、Grab 等知名企业。作为阿里云的优秀合作伙伴，AutoMQ 可通过阿里云市场直接订阅部署。

Iceberg 的优势

在并发控制机制方面，Iceberg 采用基于快照隔离的乐观并发控制（Optimistic Concurrency Control）实现 ACID 事务保障。该机制允许多个写入事务与读取事务并行执行，其核心设计假设事务冲突概率较低：在事务提交阶段通过版本号校验完成冲突检测，而非传统悲观锁的预锁定方式。这种设计有效降低锁争用，提升系统吞吐量。

具体写入流程包含以下关键步骤：

只有当元数据指针更新成功时，本次写入才被视为有效提交。

Iceberg 的读写隔离机制建立在多快照之上：每个读取操作访问的是特定时间点的快照状态，而写入操作始终作用于新生成的数据文件并创建独立快照。由于快照的不可变性，读取操作无需任何锁同步机制即可实现：

a) 不同 Reader 之间的隔离保障；

b）Reader 与 Writer 的读写隔离。这种设计使得查询性能不会因写入操作的存在而出现劣化。

在数据湖架构演进历程中，分区策略动态调整始终是核心挑战之一。传统数据湖方案实现分区优化时，需通过全表数据重分布完成物理存储结构调整，这在 PB 级数据集场景下会产生极高的计算与存储成本。

Iceberg 通过逻辑层-物理层解耦设计创新性解决了这一难题：其分区策略作为元数据层的逻辑抽象存在，与底层数据存储路径完全解耦。当进行分区策略调整时，历史数据保持原有物理分布不变，仅新写入数据按更新后的分区规则组织，从而实现零数据迁移的分区演进。该机制使得分区优化操作从小时级降至秒级，资源消耗几乎为零。

更值得关注的是 Iceberg 的 Hidden Partitioning 特性：查询层无需显式指定分区键，计算引擎通过元数据自动完成数据文件过滤。这意味着业务系统可在不影响现有查询语句的前提下，持续优化数据分布策略，实现查询逻辑与存储架构的双向解耦。

Iceberg 支持 copy-on-write （COW）和 merge-on-read （MOR）两种更新方式。COW 会将变更行所属的数据文件整个重写一遍生成新的文件，即使只更新了其中一行，该方式的查询效率最高，但需要付出较大的写入成本。而 MOR 为高频数据更新提供了更好的写入性能。当一行数据更新时，Writer 将要更新的数据特征到 DeleteFile 中，标记之前的数据被删除了，并且将更新的数据写入到 DataFile 中，通过该方式 MOR 将行更新的写入效率做到和追加写入保持一致。在查询时，计算引擎再将 DeleteFile 中的记录作为墓碑屏蔽旧的数据，完成读取时的结果合并。

应用迭代的同时，底层的数据也会跟着演进。Iceberg 的 Schema 演进支持 Add、Drop、Rename、Update 和 Reorder，并且与 Partition 演进类似，在 Schema 演进的时候，所有的历史 DataFile 都不需要被重写。

Iceberg 数据入湖最佳实践

避免高频 Commit：Iceberg 每次 Commit 都会生成新的 Snapshot，这些 Snapshot 信息都会维护在 MetadataFile 中。高频率 Commit 不更仅容易触发 Commit 冲突，而且会造成 MetadataFile 膨胀，导致存储和查询成本增加。建议控制 Commit 间隔在 1 min 以上，并且由中心化的 Coordinator 进行提交。

避免生成大量小文件：每个 DataFile 对应一个 ManifestEntry，小文件数量多会导致 ManifestFile 体积激增，进而导致元数据存储成本上升和查询计划生成速度下降。对象存储是按照 API 调用次数计费，过多的小文件也会导致查询时 API 的调用成本上升。建议通过数据攒批写入来减少小文件的生成，后期也可以通过 Compaction 来将小文件合并。阿里云 OSS 提供了有竞争力的 PUT 和 GET 类 API 价格，并每月都提供了海量免费额度，可有效降低 API 费用。

采取合适的 Partition 策略：

加速查询：将高频筛选的字段（如时间、地区）优先作为分区键，在查询时通过分区裁剪减少扫描的数据量。

成本：在查询效率和存储成本之间平衡。分区粒度过细会产生过多小文件，导致存储效率下降。

Table Topic：阿里云上实时数据入湖的最佳选择

AutoMQ Enterprise（1.4.0版本） Table Topic 在 Kafka Topic 的基础上，将流格式存储进一步扩展成 Iceberg 表格式存储。数据的生产者仍旧使用 Kafka 协议向 AutoMQ 写入数据，数据可以是数据库 BinLog、ClickStream 和 IoT 等数据。AutoMQ 首先会将写进来的数据低延迟写入到流格式存储，后台经过攒批后将流格式的数据转换成 Iceberg 表格式的数据。至此 AutoMQ 通过 Iceberg 将 Kafka 里面的流数据以表格式共享给下游的数据湖计算引擎。企业无需再去维护复杂的 ETL 任务，仅需要使用 Kafka API 向 AutoMQ 写入数据，AutoMQ 会无感将数据入湖。数据产生即就绪，业务创新零等待。

上游的数据源使用的是 Kafka 协议，而不是直接面向的的 Iceberg。这么做有如下 2 个好处：

数据源生态：企业现有的 Kafka 生产者（如 Flink CDC、Logstash、Debezium）可直接接入，节省定制化开发成本。例如 MySQL 的BINLOG 通过 Debezium 写入 Table Topic 后，AutoMQ 自动完成 Avro 到 Iceberg Schema 的映射与转换

低延迟 & 高吞吐：数据进入 AutoMQ 后首先会存储到 Stream Storage，AutoMQ 的 Stream Storage 具有毫秒级延迟和 GB 级吞吐的特征，因此企业可以获得低延迟和高吞吐的数据入湖能力。

AutoMQ 通过深度集成 Kafka Schema 构建自动化数据治理闭环，从根本上解决传统入湖流程中的 Schema 管理顽疾。其设计利用 Kafka 原生的 Schema 注册机制作为数据质量闸门：当生产者发送数据时，Schema 验证层会即时拦截不符合预定义结构的脏数据（如字段类型错误、必填字段缺失等），将数据质量问题阻拦在入湖起点。

当上游业务系统发生 Schema 变更（如 MySQL 源表新增「用户等级」字段），AutoMQ 能够实时感知 Kafka 消息中的 Schema 版本迭代，自动完成 Iceberg 表结构的协同演进，同时保持数据持续写入不中断。这一过程完全无需人工介入，彻底消除了传统流程中多系统间 Schema 手动对齐的操作风险。

相较于传统架构中 Flink/Spark任务与表结构的强耦合（每个同步任务需硬编码目标表 Schema），AutoMQ 实现了 Schema 管理的范式转移——将原先分散在数据管道脚本、数仓元数据库、流计算引擎等多处的 Schema 定义收敛为 Kafka Schema 单一源头。这种中心化管控模式不仅减少了的元数据维护工作量，更确保了从实时接入到湖仓存储的全链路 Schema 一致性。

AutoMQ 为了提升查询时的数据过滤效率，支持同时对多个 Columns 进行分区，支持 year、month、day、hour、bucket 和 truncate 分区转换函数。

AutoMQ 支持数据以 Upsert 模式进行同步，AutoMQ 会根据设置的 Table 主键和Record 指定的 CDC 操作来进行增删改。当 AutoMQ 接收到 Update 操作的 Record 时，AutoMQ 会首先将主键以 EqualityDelete 写入到 DeleteFile 中，标记历史记录失效，然后再在 DataFile 里追加更新的记录。

通过 AutoMQ Table Topic，企业可以将数据库的 BinLog 写入到 AutoMQ，AutoMQ 会将 BinLog 数据通过 Upsert 写入到 Iceberg 表。数据库服务于在线 OLTP 业务，Iceberg 服务于 OLAP 数据分析，通过 AutoMQ Table Topic 可以保持两者之间保持数据分钟级的新鲜度。

AutoMQ 不像使用 Spark / Flink / Connector 等同步组件需要编写同步任务脚本和运维同步任务。用户仅仅需要在创建 Topic 时打开 Table Topic 开关。

AutoMQ 的 Topic Topic 能力内置在进程中，主要模块为 Coordinator 和 Worker：Coordinator：管理 Table 同步进度和中心化提交。Coordinator 每个 Table Topic 独立占有一个，绑定到 Topic 的分区 0。Coordinator 根据用户设置的提交间隔触发提交，避免了每个 Worker 独立提交导致的提交冲突和元数据膨胀，降低存储成本和提升查询性能。

Wokrer：负责将 Kafka Record 转换成 Parquet 数据文件上传到阿里云对象存储 OSS。Table Topic 每一个分区在同进程内都有由对应的 Worker 绑定负责。Coordinator 和 Worker 与分区绑定，在进程中内置具有以下好处：

运维简单：无需额外维护一套组件，只需要关心 AutoMQ 集群的生命周期，无需管理同步任务。

同步伸缩：AutoMQ 的消息写入能力与 Table Topic 同步能力同步匹配伸缩。当业务高峰来临，只需要根据流量上涨比例扩容 AutoMQ 集群即可。

在传统数仓同步架构中，采用 Spark、Flink 或各类 Connector 工具进行数据传输时，其分区调度机制通常存在显著的云环境适配性问题。由于 Worker 节点或 Executor 资源的分配策略未与云服务商可用区（AZ）拓扑结构对齐，导致同一分区的读写操作频繁跨越不同物理区域。这种设计缺陷在 AWS、GCP 等按流量计费的云平台中尤为突出（阿里云不会对跨 AZ 流量收取费用）——据统计，跨可用区数据传输成本往往占据企业大数据基础设施总支出的 80% 以上。

针对这一行业痛点，AutoMQ 提出了进程内绑定调度策略。通过将 Worker 节点与特定可用区的数据分区进行深度耦合，系统实现了计算资源与存储资源的拓扑感知。数据流转时 Worker 无需通过复杂网络路径获取数据，而是以本地方法调用的方式直接从内存缓冲区捕获实时写入的数据流，随后通过上传至阿里云 OSS 存储桶。这种数据传输机制可减少 90% 以上的跨区带宽消耗，为企业构建出兼具高性能与成本效益的云原生数据管道。

本文系统解析了 Apache Iceberg 作为云原生数据湖核心技术的核心优势与最佳实践。Iceberg 通过快照隔离实现高性能 ACID 事务，借助逻辑-物理解耦的分区演进机制实现零成本存储优化，并支持 COW/MOR 两种更新模式平衡查询与写入效率。在数据入湖实践中，需关注高频提交规避与小文件治理，结合动态分区策略提升查询性能。针对实时数据入湖挑战，AutoMQ Table Topic 创新性地融合 Kafka 协议与 Iceberg 表格式，通过流批自动转换、Schema 自适配及进程内绑定调度实现分钟级数据新鲜度。其免 ETL 任务设计显著降低运维复杂度，独有的拓扑感知机制更减少 90% 跨可用区流量成本，为企业构建高吞吐、低延迟、低成本的一体化数据湖方案提供了新范式。阿里云 OSS 的 AZ 间流量免费，提供有竞争力的 PUT 和 GET 类 API 价格，和每月的 API 免费额度，可有效降低云上 AutoMQ 方案的运行成本。

来源：凌云时刻