使用 Amazon S3 Tables 优化数据湖：从Hudi 迁移到托管 Iceberg

摘要：某零售品牌因 Hudi 0.12.x 版本老化、并发冲突和全量覆盖场景低效，迁移至 Amazon S3 Tables。团队采用混合策略：DW 层用 S3 Tables 实现增量 MERGE，DM 层全量覆盖表直接写 Parquet。通过新旧并行分批迁移，最终核心作业性能提升最高 8 倍，ETL 月度成本降低 72%。

一、引言

某全球领先的零售品牌在 AWS 中国区运营着支撑核心业务的数据湖平台。随着数据规模增长，基于 Apache Hudi 0.12.x 构建的 ETL 管道面临版本老化、并发写入不稳定、运维复杂度高等挑战。本文介绍该客户如何通过迁移到 Amazon S3 Tables（AWS 原生托管的 Apache Iceberg 服务），结合按场景选择最优存储格式的混合策略，实现关键作业性能提升最高达 8 倍、ETL 月度成本降低 72%。

二、Amazon S3 Tables 介绍

Amazon S3 Tables 是 AWS 提供的托管 Apache Iceberg 表存储服务。它将 Iceberg 表格式的开放性与 S3 的规模和持久性相结合，为分析工作负载提供原生的 ACID 事务、Time Travel 和与 AWS 分析服务（Athena、Redshift、Glue）的深度集成。

S3 Tables 提供了一条低运维的迁移路径——无需自建 Hive Metastore 或管理 Iceberg Catalog，AWS 原生处理元数据管理和查询集成。

目前Amazon S3 Tables在中国区两个区域均可使用。

三、面临的挑战

客户的数据湖平台包含数十个 Airflow DAG 和数百个 AWS Glue 作业，采用 ODS / DW / DM 三层架构。核心事实表日增量约数千万行，下游驱动近 20 个分析宽表为 BI 报表提供数据。

使用 Apache Hudi 0.12.x 面临的核心挑战：

• 版本老化风险：Hudi 0.12.x 社区已停止积极维护，跨大版本升级到 0.14 或 1.0 需要大量兼容性测试，且有数据格式不兼容的风险。
• 并发写入不稳定：HiveSyncTool 在多个作业并发写入同一表时频繁报冲突错误，导致关键 Trend 类作业必须降低并行度才能稳定运行。
• DM 层架构不匹配：近 20 个 DM 表中绝大部分为全量覆盖模式（每次运行重算整表），但 Hudi 仍然使用 MERGE 语义——先读目标表再写入，产生不必要的 IO 开销。
• 计算资源利用率低：受上述问题影响，部分大表作业需分配数百 DPU 才能在可接受时间内完成。

四、解决方案：S3 tables + 按场景选格式的混合架构

4.1 方案核心

我们并没有简单地将所有表”从 Hudi 换到 Iceberg”，而是根据每张表的实际写入模式做了差异化选择：

4.2 为什么选择 Amazon S3 Tables而非自建 Iceberg

4.3 迁移策略：新旧并行，30天稳定后切换

为每个需要迁移的作业新建独立版本，旧 Hudi 版本完全不动。新版本在验证环境稳定运行 30 天后，可下线旧版。这个迁移策略可保：1. 零停机：新旧版本并行运行，业务无感知；2. 可回滚：旧版始终可用，发现问题立即切回； 3. 可验证：同源数据双跑，结果可逐行对比。

分批执行

4.4 S3 tables 实践经验

4.4.1 小文件管理

Amazon S3 Tables 每次增量提交都会产生新数据文件。如果不加控制，频繁的增量写入会导致大量小文件（实测首次全量写入曾产生数千个 ~9 MB 文件），显著影响后续查询性能。

解决方案：

1. 调整分区粒度：从 year/month/day 改为 year/month，减少分区数量

2. 显式 repartition：写入前手动控制输出文件数量和大小

# 写入前显式控制文件大小，目标 200-256 MB/文件
partition_fields = ["year", "month"]
df = df.repartition(*[col(f) for f in partition_fields])

3. 定期 Compaction：配置每周调度合并小文件

# Compaction 调度示例（每周日凌晨），优化后单文件平均大小从 9 MB 提升到 224 MB。

4.4.2 write.distribution-mode 配置注意事项

在 S3 Tables 中使用 createOrReplace 方式写入时，table properties 中设置的 write.distribution-mode=hash 会被忽略。

解决方案：不依赖 table property，在 create_or_replace() 前手动执行 df.repartition(*partition_fields)。

4.4.3 MERGE 操作的主键去重

当使用 MERGE INTO 时，如果 source DataFrame 中存在重复主键，会触发 MERGE_CARDINALITY_VIOLATION 错误。

解决方案：在执行 MERGE 前对 source 进行主键去重：

df_source = df_source.dropDuplicates(pk_cols)

4.4.4 全量覆盖表不适合S3 tables

五、性能对比

5.1 DW 层增量作业：核心事实表增量运行所需 DPU 减半，运行时间持平

5.2 DM 层：对于需要增量合并的 DM 表，迁移到 S3 Tables 后性能显著提升（相同资源配置）

5.3 DM 层全量覆盖表：对于不需要增量合并的全量覆盖表，Parquet 比 Iceberg 更快

*: 因为 Iceberg 的 MERGE 语义导致了全表扫描 + 写入放大，而不是 Iceberg 格式本身慢。

六、成本效益

整体 Glue ETL 月度成本降低约 72%，年化节省显著。成本节省的主要来源并非格式切换本身，而是 S3 Tables的高效 IO 使得大表可以用更少的 DPU 在更短时间内完成。其中两张最大的 DM 表通过资源降配（DPU 降低 2-6 倍），合计贡献了总节省的 72%。

七、数据质量验证

迁移过程中，我们通过以下方法确保数据正确性：

1. 双跑验证：Hudi 和 S3 Tables/Parquet 作业同时运行（消费相同数据源）
2. Athena 基准对比：查询 Hudi 表聚合数据作为正确性基准
3. 逐日对比 Job：开发专用对比作业，检查行数、金额总量、分维度明细
4. 差异溯源：所有发现的微小差异（如 0.05% 行数差）均可追溯到上游数据版本差异，非迁移代码逻辑问题

八、经验总结

1. 按写入模式选择格式，不要一刀切：增量合并（Upsert/MERGE）场景选 S3 Tables；全量覆盖场景选 Parquet 直写。混合方案比”全部 Iceberg”更优。

2. S3 Tables 小文件需主动管理：配置合理分区粒度 + 显式 repartition + 定期 Compaction 是三件必做的事。

3. “新建并行”是大规模迁移最安全的策略：不修改现有代码，新建独立版本双跑验证，稳定后切换。零停机、可回滚。

4. 迁移是资源右配的机会：格式切换后，务必重新评估每个作业的 DPU 配置。大部分成本节省来自”用对格式后发现原来不需要那么多资源”。

5. 数据正确性验证先于性能优化：先确保结果正确（双跑 + 逐行对比），再追求性能和成本。

➡️ 下一步行动：

相关产品：

• Amazon S3 Tables— 在 Amazon S3 中使用完全托管的 Apache Iceberg 表大规模存储表格数据
• Amazon Glue — 简单、可扩展的无服务器数据集成
• Amazon Athena — 使用 SQL 在 S3 中查询数据
• Amazon Redshift — 经济高效的数据仓库

相关文章：

• S3 Tables 实战：两种方案，把 MySQL 数据实时”搬”进 S3 Tables
• 快速打通AWS Marketplace SaaS集成流程 （实战指南）
• 向量存储成本降低 85%：用 Amazon S3 Vectors 构建企业级多平台统一知识库
• 用 Kiro CLI 自动搭建 FluentBit 日志采集方案：两种 EKS 埋点数据落地 S3 Parquet 的实战对比
• 推出 S3 Files：使 S3 存储桶能够以文件系统形式直接访问

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用