AWS Glue 3.0 到 5.0 版本升级实践：中国区大规模 ETL 平台的迁移方法论¶

Ch11.115 AWS Glue 3.0 到 5.0 版本升级实践：中国区大规模 ETL 平台的迁移方法论¶

📊 Level ⭐⭐ | 9.7KB | entities/aws-glue-30-到-50-版本升级实践中国区大规模-etl-平台的迁移方法论.md

AWS Glue 3.0 到 5.0 版本升级实践：中国区大规模 ETL 平台的迁移方法论¶

摘要：本文分享了在 AWS 中国区将近70个 AWS Glue ETL 作业从 3.0 版本升级至 5.0 版本的完整实践经验。文章涵盖升级范围评估、中国区特有的依赖管理策略、分批部署方法论、真实性能对比数据以及典型问题的排查与解决。升级后整体 DPU 消耗降低约30%，部分作业性能提升超过60%。

01 一、引言

02 二、升级范围评估

03 三、中国区环境适配

04 四、分批部署

05 五、性能对比

06 六、问题与解决方案

07 七、架构优化

08 八、总结

一、引言¶

某大型零售企业在 AWS 中国区运行着一套基于 AWS Glue 构建的数据处理平台，承载了会员分析、渠道销售、门店运营及商品绩效等多个业务域的 ETL 工作负载。该平台日常运行约70个 Glue 作业，月度 DPU 消耗近4000 DPU-Hours，涵盖从轻量级数据同步到重型多表关联聚合等多种处理场景。

推动本次升级的核心动因有三个方面。其一，AWS Glue 5.0 提供了更新的 Spark 运行时和更多新特性，部分新能力仅在 Glue 5.0 上提供，因此客户开始评估升级至更新版本。其二，AWS Glue 5.0 基于 Apache Spark 3.5 构建，引入了自适应查询执行的深度优化、Shuffle 机制的改进以及 Catalyst 优化器的增强，根据 AWS 在 Spark 3.5 和 Glue 5.0 发布时披露的基准测试，部分分析型工作负载可获得性能提升。其三，客户提出了年度云资源成本优化目标，ETL 平台作为计算资源消耗的主要来源之一，降本增效成为技术团队的优先事项。

综合以上因素，我们制定了分阶段、低风险的升级方案，并在为期三周的实施窗口内完成了全量作业的版本迁移。

二、升级范围评估¶

在正式实施前，我们对全部作业进行了系统化的分类评估，依据输出格式、依赖复杂度和业务重要性三个维度建立了升级决策矩阵。

直接升级：约60至70个作业，输出格式为 Parquet 或 CSV，不依赖第三方 Connector，Spark SQL 语法与 Glue 5.0 具备较高兼容。此类作业构成平台的绝大多数工作负载，是本次升级的主体。

暂缓升级：约8个作业，输出格式为 Apache Hudi，使用 Hudi 0.12.x 版本。Hudi 0.12.x 尚未官方支持 Spark 3.5，直接升级存在兼容性风险，因此相关作业继续保留在 Glue 3.0 环境中运行

架构重构： 1组高 DPU 消耗的作业群，因其存在全量扫描的设计缺陷，无论在哪个 Glue 版本上运行均面临资源效率问题。我们决定将其从版本升级范围中分离，通过架构层面的重新设计（从全量处理迁移至增量处理）从根本上解决性能瓶颈。

我们遵循的核心原则是风险隔离：将确定性高、影响面可控的变更批量实施，同时将不确定性高的变更隔离处理，避免一次性升级带来的系统性风险。

三、中国区环境适配¶

2.1 Python 依赖离线化¶

AWS Glue 作业在执行时需要加载 Python 第三方库。在全球区，Glue Worker 可通过 –additional-python-modules 参数直接从 PyPI 安装依赖。然而在中国区，由于 Glue Worker 的网络环境限制，直接访问 PyPI 或海外镜像源存在连通性不稳定的问题。

我们采用的方案是将所有 Python 依赖预编译为 .whl 格式文件，上传至 S3 存储桶，通过 –additional-python-modules 参数引用这些离线依赖，避免运行时访问外部 PyPI。对于编译环境，我们使用与 Glue 5.0 运行环境一致的基础镜像进行一致性构建，确保二进制兼容性。此外，在本地开发与 CI/CD 构建环节，我们配置了国内镜像源作为 pip 的备选下载通道。

2.2 JAR 依赖隔离¶

Glue 5.0 内置的 Spark 3.5 运行时包含了大量更新的依赖库（如 Jackson、Guava、Netty 等），与用户自定义 JAR 包中的同名库可能产生版本冲突。我们通过设置 –user-jars-first 参数调整类加载优先级，并逐个验证第三方 Connector 的兼容性，避免因依赖版本差异导致运行时异常。

2.3 VPC 端点验证¶

所有 Glue 作业均运行在客户 VPC 内的私有子网中，通过 VPC Endpoint 访问 AWS 服务。升级前我们逐一验证了以下端点的连通性与策略配置：

S3 Gateway Endpoint：确认路由表关联正确，Bucket Policy 允许从 VPC Endpoint 发起的请求
Glue Interface VPC Endpoint：确认安全组入站规则允许 HTTPS 443 端口访问
CloudWatch Logs Interface Endpoint：确认日志组的 Resource Policy 配置正确

以上工作虽然不直接涉及代码变更，但对于中国区环境而言属于必要的前置条件。

四、分批部署¶

我们从简单到复杂、从低风险到高风险渐进推进。首批选择逻辑最简单、数据量最小的作业，验证基础兼容性，中间批次覆盖中等复杂度的多表 JOIN 作业，后续批次处理高 DPU 消耗的重型作业，最后一批为低频执行的长尾作业。

批次 | 作业数 | 类型特征 | 关键事项

---|---|---|---
第一批 | 约10个 | 轻量级 ETL，单表转换 | 基础兼容性验证，确认运行时环境正常

第二批 | 约12个 | 中等复杂度，多表 JOIN | 验证 AQE 对 JOIN 策略的影响

第三批 | 约15个 | 高 DPU 日报作业 | 发现磁盘空间不足问题，引入 S3 Shuffle

第四批 | 约14个 | 会员积分类作业 | 个别轻量作业出现性能回退，评估后接受

第五批 | 约12个 | 商品与门店类作业 | 运行稳定，未发现新问题

第六批 | 约6个 | 低频执行的月度/季度作业 | 收尾确认，全量回归验证

升级前将所有 Glue 3.0 作业的完整配置（包括 Job Parameters、Connection、Security Configuration 等）导出为 JSON 格式并存储至版本控制系统。回滚操作可通过一条命令在数分钟内完成。

五、性能对比¶

作业类型 | 升级前 DPU | 升级后 DPU | 耗时变化 | 优化幅度

---|---|---|---|---
渠道销售报表 | ~4 | ~1.3 | 14分→5分 | 超过60%

门店销售月报 | ~8.5 | ~4 | 11分→6分 | 约52%

渠

关联¶

相关概念: Harness Engineering