Spark文档要求将Spark和Hadoop设为provided依赖，是否为强制要求？

是否必须设置为provided？ #

不是必须的，官方文档的建议是出于集群资源优化和依赖一致性的考量，但并非强制要求。

官方之所以推荐将Spark和Hadoop依赖设为<scope>provided</scope>，核心原因是Spark集群本身已经预装了这两类核心依赖，标记为provided可以避免重复打包，大幅减小uber jar的体积，同时默认复用集群自带的依赖版本，降低版本冲突风险。

不设置provided会引发什么问题？ #

如果直接将Spark/Hadoop依赖打包进uber jar，大概率会遇到以下问题：

• 版本兼容性故障：Hadoop对版本差异极其敏感，若你打包的版本和集群预装版本不一致，极易出现NoClassDefFoundError、ClassCastException这类类加载异常，甚至直接导致任务崩溃。Spark的API在不同大版本间也存在不兼容变更，版本不匹配会让代码逻辑无法正常执行。
• jar体积臃肿：Spark和Hadoop的核心依赖包本身容量很大，打包进uber jar后会显著增加文件大小，拖慢jar包的分发、上传和集群加载速度，浪费存储资源。
• 类加载优先级冲突：集群的类加载器通常会优先加载自带的依赖库，你打包的版本可能被直接忽略，导致代码预期的特性无法生效；反之，如果你的jar包类加载优先级更高，会和集群其他组件依赖的类版本产生冲突，引发难以排查的运行时错误。

当然也存在特殊场景可以不设置provided：比如你自行搭建了集群，能完全控制所有节点的依赖版本，且需要使用集群未预装的特定版本特性；或是像AWS EMR这类托管服务，你严格使用其提供的匹配集群版本的Maven依赖进行打包，这种情况下风险会有所降低，但依然要谨慎验证兼容性。

总结 #

将Spark/Hadoop依赖设为provided是最稳妥的通用方案，能规避绝大多数依赖冲突问题；如果一定要打包进uber jar，必须确保依赖版本和集群运行环境完全一致，否则很容易出现各类兼容性故障。

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