迁移概览
本文旨在梳理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.0Java版本提升至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解决方案，欢迎通过联系表单与我们沟通。
延伸阅读
关注微信号：智享开源 ，及时了解更新信息。
原文链接：https://ubuntu.com//blog/migrating-from-apache-spark-3-to-spark-4
扫码关注公众号：智享开源
评论功能已经关闭!