Spark 3迁移至Spark 4：核心变更与实战指南

Mark Do 2026年5月29日评论已关闭阅读 11,983 次

迁移概览

本文旨在梳理Apache Spark 3与Spark 4之间的关键差异，并提供切实可行的迁移规划建议。下面我们将逐一解析。

重大变更一览

Spark 4带来了多项底层调整，尤其值得关注的是对语言版本和运行时的升级。

Scala 2.12不再受支持

Spark 4彻底移除了对Scala 2.12的支持，所有基于该版本编写的作业必须重新编译到Scala 2.13。虽然过程通常较为直接，但请务必注意：作业的所有依赖项也需同步升级到Scala 2.13版本。依赖越多，工作量可能越大。

此外，Scala 2.13对collections库进行了重大API重写。由于集合库是基础组件，您的代码可能需要相应调整。幸运的是，已有免费开源工具如Scalafix可辅助迁移。您可将Scalafix添加为SBT依赖，并启用“Collection213Upgrade”规则：

sbt> scalafixEnable
sbt> scalafixAll dependency:Collection213Upgrade@org.scala-lang.modules:scala-collection-migrations:2.13.0

Java版本提升至17/21

Spark 4停止支持Java 17以下的旧版本，默认运行环境为Java 17，同时兼容Java 21。若您的Spark作业或插件依赖旧版Java，可能因Java XML、Servlet库的变更而触发适配问题，需调整代码。

值得期待的新特性

Spark 4不仅优化了默认行为，还引入了一系列强大的新功能。

默认行为变化

ANSI SQL模式默认开启：在Spark 3中，非法操作（如除零、无效类型转换）会静默返回NULL；而在Spark 4中会抛出运行时异常，以保障数据质量。这可能导致查询或管道中断，务必仔细测试。
结构化JSON日志：日志默认以JSON格式输出，便于Loki等日志基础设施处理。但现有监控告警系统可能因此失效，需提前验证。
RocksDB成为默认状态存储：结构化流中的shuffle和状态管理后端切换为RocksDB，可显著降低JVM堆压力，减少GC停顿。

全新功能亮点

VARIANT数据类型：专为JSON等半结构化数据设计，查询性能远超传统的字符串解析方案。
SQL管道语法：支持使用|>操作符串联SQL操作。
过程化SQL与脚本：新增多语句SQL脚本支持，包含局部变量和流程控制（IF/WHILE），理论上可用纯SQL完成整个ETL管道。
AI/ML能力增强：全面支持向量数据类型，并为LLM工作负载提供优化的批量推理能力。

迁移策略分步走

在了解重大变化后，我们需要制定周密的迁移计划。

基础环境升级

在修改Spark代码前，先确保底层基础设施满足新要求。

将运行时环境迁移至Java 17或21。如果使用Canonical的Kubernetes上Apache Spark解决方案，该团队已为您处理了这部分工作。
若使用Scala，将所有代码及内部库升级至Scala 2.13。
确认所有第三方连接器和插件（如Spark-RAPIDS、Kafka）已发布支持Spark 4/Scala 2.13的版本。
将Java代码中的javax.*导入替换为jakarta.*（针对Servlet和XML兼容性）。

运行时验证

ANSI SQL模式默认开启可能是最大的破坏性变更。

在当前Spark 3环境中设置spark.sql.ansi.enabled=true，提前暴露之前被NULL掩盖的除零或数值溢出错误。
将危险操作替换为“安全”替代方案，例如使用try_cast代替cast以保留返回NULL的旧行为。

启用新功能验证

接下来确保工作负载在Spark 4的新特性下平稳运行。

若使用结构化流，测试启用RocksDB（现为默认状态存储）后的作业表现。
检查CREATE TABLE语句：未指定USING子句时，Spark 4将默认使用spark.sql.sources.default指定的数据源，而非Hive。

逐步推出计划

建议按“批处理作业 → 流式作业 → 分析/决策支持工作负载”的顺序逐步迁移。每种工作负载分阶段进行，仔细验证结果、检查日志并排查差异。

总结

希望这份指南能助您顺利完成迁移。如往常一样，充分的准备是成功的关键。若想了解更多关于Canonical的Charmed Apache Spark解决方案，欢迎通过联系表单与我们沟通。

请支持IMCN发展！

谁在捐赠

微信捐赠	支付宝捐赠