AWS Glue 6.0升级:AI辅助Spark作业迁移实践
DataHot 速览
AWS Glue 6.0基于Apache Spark 4.1和Python 3.13,引入ANSI SQL默认开启、移除Parquet旧配置等行为变化,可能导致现有PySpark作业运行失败。AWS Glue控制台提供生成式AI升级分析,可自动识别不兼容项、迭代修复并通过数据质量检查验证,同时给出推荐变更。新版本还支持Iceberg v3、Spark Declarative Pipelines、实时模式和Arrow原生Python UDF,宣称性能提升最高36%。本文以日度电商订单分析作业从Glue 5.1升级到6.0为例,展示具体迁移流程。
为什么值得关注:数据从业者关注Spark版本升级和AI辅助迁移,可降低ETL作业升级风险并了解AWS Glue 6.0新能力。
本文目录 16 节
译文
AI 逐段翻译将 PySpark 作业升级到新的 Apache Spark 主要版本可能会引入破坏性变更。已移除的配置键、更严格的类型转换以及 Python 库不兼容可能导致运行时失败或静默行为差异。随着 AWS Glue 6.0 现在运行 Apache Spark 4.1 和 Python 3.13,您需要一种可靠的方法来迁移现有作业,同时验证正确性。
在本文中,我们将逐步介绍如何将 PySpark ETL 作业从 AWS Glue 5.1 升级到 AWS Glue 6.0。我们使用 AWS Glue 控制台中的 Apache Spark 生成式 AI 升级功能。升级分析会自动识别不兼容性,迭代解决它们,通过数据质量检查验证结果,并呈现建议的更改供您审查。AWS Glue 6.0 还提供了高达 36% 更好的性价比*,以及 Iceberg v3、Spark 声明式管道、实时模式和 Arrow 原生 Python UDF。
AWS Glue 6.0 有哪些变化
AWS Glue 6.0 运行 Apache Spark 4.1,其中引入了与 AWS Glue 5.1 中使用的 Spark 3.5 运行时相比的多项行为更改:
| 行为 | Spark 3.5 (AWS Glue 5.1) | Spark 4.1 (AWS Glue 6.0) |
| ANSI SQL 模式 | 默认禁用 | 默认启用 |
| 旧版 Parquet datetime 配置 | 支持 | 已移除(重命名) |
| Python 运行时 | 3.11 | 3.13 |
除了版本兼容性,AWS Glue 6.0 还引入了:
- Apache Iceberg v3 具有 VARIANT Shredding,用于高效处理半结构化数据。
- Spark 声明式管道 — 代理可编写的 ETL。
- 实时模式 — 个位数毫秒级流式延迟。
- Arrow 原生 Python UDF (PyArrow) 以提高性能。
- 内置可观测性 具有结构化指标和增强的 Spark UI。
- 与 AWS Glue 5.1 相比,性价比提升高达 36%*。
这些运行时更改意味着,您现有的 AWS Glue 作业在 AWS Glue 6.0 上运行时,可能会遇到已移除的配置键、更严格的类型转换行为或 Python 包版本不兼容。手动修复这些问题既耗时又容易出错。以下各节展示了生成式升级分析如何自动处理这些情况。
示例作业
我们的示例是一个每天在 AWS Glue 5.1 上运行的电子商务订单分析管道:
该作业的功能:
- 从 Parquet 文件中摄取 10,000 个订单,包含 INT96 时间戳(包括来自旧系统迁移的 1900 年之前的日期)。
- 通过将字符串价格转换为数值并计算包含折扣和税的明细总额来计算收入指标。
- 使用
mapInPandas以及 pandas 和 scikit-learn 通过最近度、频率和货币(RFM)评分对客户进行细分。 - 将增强结果写回 Amazon Simple Storage Service (Amazon S3)。
作业配置 (AWS Glue 5.1):
Glue version: 5.1
Worker type: G.1X
Workers: 10
Python modules: pandas==2.2.2, scikit-learn==1.5.0, numpy==1.26.4
Spark configs:
spark.sql.legacy.parquet.datetimeRebaseModeInWrite=LEGACY
spark.sql.legacy.parquet.int96RebaseModeInWrite=LEGACY
spark.sql.parquet.datetimeRebaseModeInRead=LEGACY
spark.sql.parquet.int96RebaseModeInRead=LEGACY此作业在 AWS Glue 5.1 上成功运行。以下各节将逐步介绍在将此作业升级到 AWS Glue 6.0 时,升级分析如何识别和解决不兼容性。开始之前,请确认您已具备先决条件。
先决条件
- 一个可访问 AWS Glue 控制台的 AWS 账户。
- 一个版本为 5.1 或更早版本的现有 AWS Glue 作业,且至少有一次成功运行。
- 一个用于存储升级分析结果的 Amazon S3 路径。
从控制台运行升级分析
以下步骤将使用 AWS Glue 控制台逐步介绍升级分析工作流。
步骤 1:选择您的作业
在 AWS Glue Studio 控制台中导航到您的作业。在开始升级分析之前,确认该作业在 AWS Glue 5.1 上有成功的运行历史。

图 1:作业在 AWS Glue 5.1 上的运行状态
步骤 2:启动升级分析
从作业的 Actions 菜单中选择 Upgrade with generative AI。配置以下内容:
- 目标 AWS Glue 版本: 6.0。
- 结果 S3 路径: 分析存储其工件和推荐的 S3 位置。

图 2:Actions 菜单中的 Upgrade with generative AI 选项
配置目标 AWS Glue 版本和 S3 结果路径,然后选择 Run。

图 3:Upgrade with generative AI 窗口,用于设置目标 AWS Glue 版本和结果路径
选择 Run。分析首先在 AWS Glue 5.1 上运行您的作业以建立基线。然后,它迭代地在 AWS Glue 6.0 上测试作业,识别失败,应用推荐的修复,并验证作业。如果升级分析无法在其尝试预算内解决不兼容性,分析将停止并报告未解决的问题以供手动审查。您的原始作业保持不变。
注意:升级分析会多次执行您的作业(一次基线运行加一次或多次验证尝试),每次运行都会消耗数据处理单元(DPU)。对于大型或长时间运行的作业,请考虑使用运行配置选项来指定较少的 worker 或较小的数据集,以优化分析成本。
步骤 3:监控进度
控制台会显示分析在多次验证尝试中的进度。每次尝试要么成功,要么以特定错误失败,升级分析使用该错误信号来确定并应用适当的修复,以便进行下一次尝试。

图 4:跨多次验证尝试的升级分析进度
升级分析发现并修复的内容
分析在四次验证尝试中完成,识别并解决了三个不同的不兼容性。升级对已知配置更改使用确定性迁移规则,对运行时或代码错误使用自动化诊断。
迭代 1:移除的 Parquet 旧版配置
分析首先清理在 Spark 4.1 中移除的任何 Spark 配置。我们的作业使用了 spark.sql.legacy.parquet.datetimeRebaseModeInWrite 和 spark.sql.legacy.parquet.int96RebaseModeInWrite,这些配置不再存在。
应用的迁移规则: 具有 spark.sql.legacy前缀已在 Spark 4.1 中移除。它们已重命名为非遗留等效名称,并保留原始值。
建议更改:
Before:
spark.sql.legacy.parquet.datetimeRebaseModeInWrite=LEGACY
spark.sql.legacy.parquet.int96RebaseModeInWrite=LEGACY
After:
spark.sql.parquet.datetimeRebaseModeInWrite=LEGACY
spark.sql.parquet.int96RebaseModeInWrite=LEGACY读取端配置(datetimeRebaseModeInRead、int96RebaseModeInRead)已使用正确的非遗留名称,无需更改。
然而,应用此修复后,验证运行仍然失败,因为在 AWS Glue 6.0 镜像上安装 Python 模块时遇到错误。
迭代 2:Python 模块版本不兼容
固定的模块版本(pandas==2.2.2、scikit-learn==1.5.0、numpy==1.26.4)无法在 AWS Glue 6.0 的 Python 3.13 环境中安装。
错误:
LAUNCH ERROR | Installation of Additional Python Modules failed建议更改:升级分析将版本规范从精确固定更新为最低版本约束,允许 pip 为 Python 3.13 解析兼容版本:
Before: pandas==2.2.2, scikit-learn==1.5.0, numpy==1.26.4
After: pandas>=2.1.0, scikit-learn>=1.3.0, numpy>=1.24.0模块成功安装后,作业在 AWS Glue 6.0 上启动,但遇到运行时错误。
迭代 3:ANSI 模式严格类型转换
Spark 4.1 默认启用 ANSI SQL 模式(spark.sql.ansi.enabled=true)。我们的收入计算将字符串价格转换为双精度浮点数,但约 1.8% 的记录包含上游系统提供的非数字占位符值,例如“N/A”、“pending”或“null”。从业务角度来看,这意味着 1.8% 的收入订单被静默排除在收入指标之外。此数据质量问题在原始管道中不可见。
在 AWS Glue 5.1(ANSI 模式关闭)上,cast("N/A" as double) 静默返回 null。在 AWS Glue 6.0(ANSI 模式开启)上,这会引发异常:
错误:
NumberFormatException: [CAST_INVALID_INPUT] The value 'null' of the type
"STRING" cannot be cast to "DOUBLE" because it is malformed. Correct the
value as per the syntax, or change its target type. Use try_cast to
tolerate malformed input and return NULL instead. SQLSTATE: 22018应用的迁移规则: 自 Spark 4.1 起,spark.sql.ansi.enabled 默认开启。转换格式错误的值现在会引发 CAST_INVALID_INPUT,而不是返回 NULL。升级分析通过将脚本更新为使用 try_cast() 来解决此问题,该方法对格式错误的输入安全返回 NULL,同时保留作业其余部分的 ANSI 模式保护。
建议更改:
之前(AWS Glue 5.1):
F.col("unit_price").cast("double")之后(AWS Glue 6.0,由升级分析修复):
F.expr("try_cast(unit_price as double)")这是一个有针对性的修复,处理已知的脏数据,而不会全局禁用 ANSI 模式,从而在整个作业中保持溢出检测和类型安全。
最终验证和数据质量检查
应用所有三项修复后,分析在 AWS Glue 6.0 上最后一次运行作业,并在 AWS Glue 5.1 基线输出和 AWS Glue 6.0 输出之间执行数据质量比较。
结果: 作业成功完成,所有数据验证均通过,源输出与目标输出之间未检测到不匹配项。

图 5:最终分析状态,附有 Amazon S3 中结果输出路径的链接
查看升级摘要
分析会生成一份详细摘要,存储在你的 S3 结果路径中。此摘要记录每次验证尝试、遇到的错误、应用的迁移规则以及建议的配置更改:
s3://amzn-s3-demo-bucket/scripts/auto-upgrade/ja-{analysis-id}/
summary/
summary.md # Full iteration-by-iteration report
data_validation_summary.md # Data quality comparison results
artifact/
attempt_N/
script/main.py # Recommended script (if modified)
job_config_modifications.json # Recommended parameter changes
requirements.txt # Updated dependency versions以下是升级摘要(summary.md)的片段,显示建议的更改和验证尝试详细信息:
摘要记录每次验证尝试、应用的更改以及数据质量结果。

图 6:升级摘要片段,显示验证尝试详细信息、数据质量和分析结果
查看建议后,接受更改以将作业升级到 AWS Glue 6.0。这会使用建议的配置更新作业定义,包括重命名的 Spark 配置、更新的模块版本以及任何脚本修改。由于分析已在 AWS Glue 6.0 上验证作业并确认数据质量与原始数据保持一致,你的作业已准备好投入生产。
查看建议后,你可以将升级后的脚本应用到你的作业。

图 7:将升级后的脚本应用到作业的选项
选择 应用 以确认升级。

图 8:确认将作业升级到 AWS Glue 6.0 的“应用”按钮
应用后,作业定义会反映新的 AWS Glue 版本。

图 9:应用升级后作业的 AWS Glue 版本
AWS Glue 6.0 中的 Python 虚拟环境
AWS Glue 6.0 引入了 --python-virtual-env-storage-prefix,这是一个服务托管的虚拟环境,具有 S3 缓存功能,简化了 Python 依赖管理。
对于使用 --additional-python-modules 的现有作业,无需采取任何操作。当你的作业在 AWS Glue 6.0 上运行时,AWS Glue 会自动处理到虚拟环境的转换。你的作业无需任何更改即可继续工作。
对于 AWS Glue 6.0 上的新作业,我们建议使用虚拟环境方法:
{
"DefaultArguments": {
"--python-virtual-env-storage-prefix": "s3://amzn-s3-demo-bucket/glue-venv-cache/",
"--additional-python-modules": "pandas>=2.1.0,scikit-learn>=1.3.0,numpy>=1.24.0"
}
}工作原理:
- 首次运行时,AWS Glue 将你的模块安装到虚拟环境中,打包,并将结果缓存到你指定的 S3 路径(大约增加 15–30 秒的启动时间)。
- 在后续运行中,AWS Glue 会下载并提取缓存的虚拟环境,而不是运行
pip install。 - 当你的模块列表、版本或 AWS Glue 版本更改时,缓存会自动失效。
这种方法提供首次运行后更快的冷启动,无需 Docker 镜像管理(与 --python-virtual-env 不同),且完全由服务管理,无维护负担。
结论
生成式升级分析识别并解决了我们的 AWS Glue 5.1 作业中三个不同的兼容性问题,因此该作业现在可以在使用 Apache Spark 4.1 的 AWS Glue 6.0 上成功运行:
- 升级分析将 Parquet 日期时间配置中遗留的键(在 Spark 4.1 中已移除)重命名为当前等效名称。
- 升级分析将不兼容 Python 3.13 的 Python 模块版本规范更新为灵活的最低版本约束。
- 升级分析针对新的 ANSI SQL 模式默认值(该模式在数据格式错误时会导致运行时失败)进行了有针对性的修复,使用
try_cast()来安全处理非数值,同时保留 ANSI 模式保护。
分析验证了升级后的作业产生的输出与原始作业一致,并将所有更改作为建议呈现,供您在应用到作业之前进行审查。
后续步骤
- 查看AWS Glue 6.0 文档了解新功能和更改的完整列表。有关新内容的详细演练,请参阅Introducing AWS Glue 6.0 for Apache Spark。
- 阅读Apache Spark 4.1 迁移了解其他行为更改。
- 通过控制台在您的 AWS Glue 作业上尝试升级分析。
- 参阅Python 虚拟环境文档获取详细的设置指导。
- 要重现此演练,请从任何现有的 AWS Glue 作业开始,该作业运行在 5.1 或更低版本上,并且具有成功的运行历史。无需额外的示例代码或 CloudFormation 模板。
审查并接受升级更改后,您可以删除存储在 S3 结果路径中的分析结果。
*基于 3TB TPC-DS 基准测试,比较 AWS Glue 6.0 与 AWS Glue 5.1。
这篇内容对你有用吗?
反馈只用于改善内容筛选,不等同于收藏