如何做Spark 版本兼容

本文探讨了如何解决Spark不同版本间的API兼容性问题,特别是在1.6到2.0的升级过程中遇到的挑战。介绍了动态编译、反射及Scala语言特性的应用,并提供了具体的代码实例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们知道Spark2.0 ,Spark 1.6还有Spark 1.5 三者之间版本是不兼容的,尤其是一些内部API变化比较大。如果你的系统使用了不少底层的API,那么这篇文章或许对你有帮助。我们介绍的兼容相关一些技巧,主要包括动态编译以及反射等方式,也用到了Scala的一些语言特性。

案例

在Spark 1.6 时,大部分机器学习相关的类使用的向量还是

org.apache.spark.mllib.linalg.Vector

而到2.0后,已经基本都变更成

org.apache.spark.ml.linalg.Vector

同理对应的Vectors object 也是。这就造成了一个比较大的困难,比如下面的代码就很难做到兼容了,切换Spark就无法通过编译:

//定义一个函数,将一个字符串转化为Vector
val t = udf { (features: String) =>

      if (!features.contains(":")) {
        val v = features.split(",|\\s+").map(_.toDouble)
        Vectors.dense(v)
      } else {
        val v = features.split(",|\\s+").map(_.split(":")).map(f => (f(0).toInt, f(1).toDouble))
        Vectors.sparse(vectorSize, v)
      }

    }

//Dataframe转化为只有label 和 features列。
training.select(
      col("label") cast (org.apache.spark.sql.types.DoubleType),
      t(col("features")) as "features"
)

无论你怎么写,都没办法在Spark 1.6 和 Spark 2.0 同时表现正常,总是会报错的,因为 Vector,Vectors等类的包名都发生了变化。

在Spark中,你可以通过 org.apache.spark.SPARK_VERSION 获取Spark的版本。
我们定义一个类:

object SparkCompatibility {  
def sparkVersion = {     org.apache.spark.SPARK_VERSION  }

动态编译

Scala 是可以很方便的动态源码的,对于而且代码也很简单,大体如下:

object ScalaSourceCodeCompiler {


  def compileCode(code: String): Any = {
    import scala.reflect.runtime.universe._
    val cm = runtimeMirror(Utils.getContextOrSparkClassLoader)
    val toolbox = cm.mkToolBox()
    val tree = toolbox.parse(code)
    val ref = toolbox.compile(tree)()
    ref
  }

这种效果和Spark Shell里是类似的,ref 是里面的一个返回值。正常情况,你可以写两份代码,一份Spark 1.6. 一份Spark 2.0 ,然后在运行时决定编译那份代码。然而这种方式有一个缺点,尤其是在Spark中很难避免,如果compileCode 返回的值ref是需要被序列化到Executor的,则反序列化会导致问题,因为里面生成的一些匿名类在Executor中并不存在。除此之外,这种方法是实现兼容最有效的办法。

原先我考虑过使用Spark 内部的CodeGen代码,大致如下:


    def compileCode3[T](codeBody: String, references: Array[Any]): T = {
      val code = CodeFormatter.stripOverlappingComments(
        new CodeAndComment(codeBody, Map()))
  
      val c = CodeGenerator.compile(code)
      c.generate(references).asInstanceOf[T]
    }

不幸的是,这个API本身也在变化,譬如CodeAndComment就是只有2.0才有的。

分离项目方式

将API有变化的部分,独立出来。比如前面我们提到的,对于Vector相关的API,1.6 和2.0 是不同的,那么我们可以剥离出两个工程,每个工程适配对应的版本,然后发布jar包,在Maven中根据Profile机制,根据Spark版本引入不同的适配包。这种方式相对来说比较繁琐。不过目前StreamingPro采用这个方案同时兼容spark 2.2.0/1.6.0

反射的方法

下面是我用来解决Vector 包名变化的代码:

def vectorizeByReflect(vectorSize: Int) = {

    val clzzName =
      if (org.apache.spark.SPARK_VERSION.startsWith("2")) {
        "org.apache.spark.ml.linalg.Vectors"
      } else {
        "org.apache.spark.mllib.linalg.Vectors"
      }

    val reslutClzzName = if (org.apache.spark.SPARK_VERSION.startsWith("2")) {
      "org.apache.spark.ml.linalg.Vector"
    } else {
      "org.apache.spark.mllib.linalg.Vector"
    }
    def dense(v: Array[Double]) = {
      Class.forName(clzzName).getMethod("dense", classOf[Array[Double]]).invoke(null, v)
    }

    def sparse(vectorSize: Int, v: Array[(Int, Double)]) = {
      val method = Class.forName(clzzName).getMethod("sparse", classOf[Int], classOf[Seq[(Int, Double)]])
      val vs: Integer = vectorSize
      method.invoke(null, vs, v.toSeq)
    }

    val t = functions2.udf(reslutClzzName, (features: String) => {
      if (!features.contains(":")) {
        val v = features.split(",|\\s+").map(_.toDouble)
        dense(v)
      } else {
        val v = features.split(",|\\s+").map(_.split(":")).map(f => (f(0).toInt, f(1).toDouble))
        sparse(vectorSize, v)
      }
    })

    t
  }

我们根据不同版本,动态加载对应的类,然后通过反射来调用方法,从而避免编译时错误。然而通过反射,就无法使用类似的代码了:

val t = udf {
 .....
}

因为 udf 函数要求能够推导出输入和返回值是什么。而如果通过反射,因为返回值我们无法确定(有可能是org.apache.spark.ml.linalg.Vector,也有可能是org.apache.spark.mllib.linalg.Vector),这个时候就无法通过编译了。于是我们改写了udf的是实现,然而这个实现也遇到了挫折,因为里面用到比如UserDefinedFunction类,已经在不同的包里面了,我们依然通过放射的方案解决:

def udf[RT: TypeTag, A1: TypeTag](className: String, f: Function1[A1, RT]): Any = {

    if (SparkCompatibility.sparkVersion.startsWith("2")) {
      val inputTypes = Try(ScalaReflection.schemaFor(typeTag[A1]).dataType :: Nil).toOption
      val dufReg = Class.forName("org.apache.spark.sql.types.UDTRegistration").
        getMethod("getUDTFor", classOf[String]).invoke(null, className).asInstanceOf[Option[Class[_]]]
      val udt = dufReg.get.newInstance().asInstanceOf[UserDefinedType[_]]
      Class.forName("org.apache.spark.sql.expressions.UserDefinedFunction").
        getConstructor(classOf[AnyRef], classOf[DataType], classOf[Option[Seq[DataType]]]).
        newInstance(f, Schema(udt, nullable = true).dataType, inputTypes)
    } else {
      val inputTypes = Try(ScalaReflection.schemaFor(typeTag[A1]).dataType :: Nil).toOption.get.toSeq
      val udt = org.apache.spark.util.Utils.classForName(className)
        .getAnnotation(classOf[SQLUserDefinedType]).udt().newInstance().asInstanceOf[UserDefinedType[_]]
      Class.forName("org.apache.spark.sql.UserDefinedFunction").
        getConstructor(classOf[AnyRef], classOf[DataType], classOf[Seq[DataType]]).
        newInstance(f, Schema(udt, nullable = true).dataType, inputTypes)

    }
  }

很丑陋,对不对。这里还有一个问题,虽然udf返回的都是UserDefinedFunction对象,然而他们也是版本不兼容的,也就是我们无法让编译器确定返回的值是什么。我们使用了另外一个Scala语法的技巧,如下:

val t = functions2.udf(reslutClzzName, (features: String) => {
      if (!features.contains(":")) {
        val v = features.split(",|\\s+").map(_.toDouble)
        dense(v)
      } else {
        val v = features.split(",|\\s+").map(_.split(":")).map(f => (f(0).toInt, f(1).toDouble))
        sparse(vectorSize, v)
      }
    }).asInstanceOf[{def apply(exprs: Column*): Column}]

核心在最后一行,我们声称返回的对象满足这个签名:

{def apply(exprs: Column*): Column}

这个时候,就可以直接使用了:

training.select(  
col("label") cast (org.apache.spark.sql.types.DoubleType),  
t(col("features")) as "features")

总结

Spark 1.6 和2.0 内部API变化很大,然而对普通用户的API兼容性还是不错的。做版本兼容似乎并不是一件容易的事情。所以当使用StreamingPro做机器学习相关工作时,我只兼容了Spark 1.6,2.0,而抛弃了 1.5版本。但是对于普通的ETL以及流式计算,三个版本都是支持的。

<think>好的,用户问的是Spark和Hadoop的版本兼容性,我需要先理清楚这两个系统的版本之间的关系。首先,我应该回忆一下Spark和Hadoop各自的版本发展情况,特别是它们之间的依赖关系。记得Spark在运行的时候需要Hadoop的客户端库,尤其是HDFS和YARN这些组件,所以版本兼容性挺重要的。 接下来,我需要确认不同版本Spark支持哪些Hadoop版本。比如,Spark 3.x通常支持Hadoop 3.x及更高,而Spark 2.x可能主要支持Hadoop 2.x。但具体的情况可能更复杂,比如一些次要版本可能会有差异。这时候可能需要查阅Spark官方文档的兼容性说明,确保信息的准确性。 然后,用户可能想知道他们应该怎么选择合适的组合。比如,如果用户已经用了Hadoop 3.2.1,那么他们应该选哪个Spark版本?这时候需要指出Spark 3.3.x或更高版本支持Hadoop 3.3及更高,可能还有向后兼容的情况。此外,用户可能需要注意某些特性是否在特定版本中被弃用或移除,比如Hadoop 2.x的支持在Spark 3.0之后的情况。 另外,用户可能想知道如何在实际中配置Spark以适配不同的Hadoop版本。比如,下载预编译的Spark时,需要选择对应的Hadoop版本,或者在编译Spark时指定参数。这部分需要给出具体的例子,比如Maven命令中的`-Phadoop`参数。 还要考虑用户可能遇到的常见问题,比如版本不匹配导致的错误,这时候需要提醒用户检查版本对应关系,并参考官方文档。另外,可能提到社区支持和长期维护的情况,比如Hadoop 2.x已经逐渐被淘汰,建议用户升级到Hadoop 3.x和Spark 3.x以获得更好的支持和性能。 最后,总结一下关键点,确保用户能有一个清晰的步骤来选择适合的版本组合,并避免常见的兼容性问题。需要保持回答结构清晰,分点列出,方便用户理解。同时,确保所有数学公式和代码部分都按照系统级指令正确使用LaTeX格式,比如独立公式用$$...$$,行内用$...$,不过在这个问题中可能用到的数学公式不多,但如果有的话需要正确应用格式。</think>### Spark与Hadoop版本兼容性详解 #### 1. **核心依赖关系** Spark本身不依赖Hadoop,但在以下场景需要Hadoop支持: - **存储层**:访问HDFS(Hadoop Distributed File System)时需Hadoop客户端库。 - **资源调度**:使用YARN(Hadoop资源管理器)时需Hadoop相关依赖。 #### 2. **版本对应规则** 以下是常见的Spark与Hadoop版本兼容关系(截至2023年): | Spark版本 | 官方支持的Hadoop版本 | 特殊说明 | |------------|-----------------------------|-----------------------------| | **Spark 3.x** | Hadoop 3.3+, 2.7+(部分兼容) | 推荐Hadoop 3.3+,支持Kerberos增强 | | **Spark 2.4** | Hadoop 2.6-2.10, 3.0-3.2 | 最高支持Hadoop 3.2.x | | **Spark 2.3** | Hadoop 2.6-2.9 | 不支持Hadoop 3.x | #### 3. **关键注意事项** - **向后兼容性** Spark通常可兼容旧版Hadoop客户端(如Spark 3.3支持Hadoop 2.7+),但部分新功能(如Hadoop 3.x的纠删码)需版本匹配。 - **编译适配** 若需自定义Hadoop版本,需通过Maven参数指定: ```bash ./dev/make-distribution.sh --tgz -Phadoop-3.3 -Pkubernetes ``` - **依赖冲突** 新旧版本混合使用时可能引发JAR包冲突(如`guava`版本差异),需通过`spark.driver.extraClassPath`调整类加载顺序。 #### 4. **实际场景建议** - **Hadoop 3.x集群** 选择Spark 3.3+,避免使用`hadoop-lzo`等非官方组件导致兼容问题。 - **Hadoop 2.x集群** 若需Spark 3.x,需升级Hadoop至2.7+,并测试YARN调度稳定性。 - **无Hadoop环境** 可使用Spark独立模式(Standalone),仅需`hadoop-aws`等库访问云存储(如S3)。 #### 5. **验证兼容性步骤** 1. **检查Hadoop版本** ```bash hadoop version ``` 2. **下载匹配的Spark预编译包** 从[Spark官网](https://spark.apache.org/downloads.html)选择对应Hadoop版本: ``` spark-3.4.1-bin-hadoop3.tgz ``` 3. **测试读写HDFS** 运行示例作业验证基础功能: ```bash ./bin/spark-shell --master yarn ``` #### 6. **常见问题** - **错误:`NoSuchMethodError`** 通常因Hadoop JAR版本不匹配,需统一集群与Spark的Hadoop依赖版本。 - **警告:`NativeCodeLoader`** 缺少Hadoop本地库(如Snappy压缩),需安装`hadoop-native`包并配置`LD_LIBRARY_PATH`。 #### 7. **未来趋势** - Hadoop 3.x已成为主流,Spark 4.0可能停止支持Hadoop 2.x。 - 云原生存储(如S3、ADLS)逐渐减少对Hadoop HDFS的直接依赖。 **总结**:建议采用 **Spark 3.x + Hadoop 3.3+** 组合,并通过预编译包或统一依赖版本规避兼容性问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值