Spark应用依赖版本与集群服务端版本差异兼容性问题咨询

核心兼容性规则 #

Spark官方对同大版本的运行时兼容性有明确承诺，实际生产验证的规则如下：

• 同大版本下，仅支持服务端版本高于等于客户端版本的兼容：比如集群是3.3.x版本，客户端用3.0.x~3.3.x的同Scala版本依赖，都可以正常提交运行，核心RPC通信、公共API、序列化协议完全兼容，不会出现基础运行错误。
• 必须匹配Scala主版本：Spark依赖的后缀（比如_2.12、_2.13）对应的Scala主版本必须和集群编译用的Scala版本完全一致，哪怕Spark版本号相同，Scala版本不匹配也会出现序列化异常、类加载错误。

版本不匹配的常见问题 #

出现以下任意一种情况，都会大概率出现运行故障：

• 客户端版本高于服务端版本：哪怕同属一个大版本，只要客户端用到了更高版本才有的API、配置项，提交任务就会报NoClassDefFoundError、NoSuchMethodError、配置无法识别的错误，严重时会直接无法连接集群。
• 跨大版本混用：比如集群是2.4.x，客户端是3.x，两个大版本之间有大量API签名、RPC协议、默认配置的变更，基本无法正常运行。
• 小版本跨度超过2个以上的同大版本混用：部分跨多个小版本的特性变更可能会存在隐性不兼容，比如3.0.x客户端提交到3.4.x集群，少数边缘API的行为会和预期不一致。

分批次升级场景的适配方案 #

针对无法同时升级集群和所有应用、第三方依赖绑定旧版本Spark的场景，可以采用以下低风险方案：

• 过渡阶段优先保证集群版本高于所有应用的Spark依赖版本，且保持在同一个大版本线内，是风险最低的兼容方式。
• 若第三方依赖绑定的Spark版本过旧，可通过maven shade、sbt-assembly等插件对第三方依赖的Spark相关类做重打包隔离，避免和集群提供的Spark类冲突。
• 所有应用打包时都将spark-core、spark-sql等核心依赖的scope设为provided，不要打进应用包内，统一使用集群提供的Spark核心类，能最大程度降低版本冲突概率。

内容的提问来源于stack exchange，提问作者Amin