Spark Dataset.map为何要求全链路对象可序列化？如何规避非必要序列化

Spark在提交map这类需要在Worker节点执行的算子前，会在Driver端执行两步操作：

• 遍历算子依赖的所有闭包引用，递归检查所有引用链上的对象是否可序列化
• 将校验通过的闭包序列化后，分发到各个Worker节点反序列化执行

这个序列化检查不会做业务逻辑层面的可达性分析，不会判断某个对象是不是真的会在Worker端的计算逻辑里被调用，只要对象在闭包的引用链上能被遍历到，就会要求它实现java.io.Serializable接口。

这个报错的本质是Scala语言的闭包持有规则+Spark闭包清理器的遍历逻辑共同导致的：
在同一段脚本/同个作用域里同时定义了非序列化的testRepository实例、调用读表方法、又链式调用map算子时，字节码层面生成的闭包会持有作用域内所有变量的引用。testRepository虽然没有直接参与map的计算逻辑，但因为和map算子同属一个闭包作用域，被闭包遍历逻辑扫到，就抛出了NotSerializableException。

• 方案1：划清Driver端逻辑和Worker端逻辑的引用边界，把读表操作放在独立代码块内执行，块执行完成后testRepository实例就会失去引用，不会被后续算子的闭包捕获。

// 块内逻辑全部在Driver端执行，块结束后临时repo实例会被回收
val inputDs = {
  val tempRepo = new TestRepository()
  tempRepo.readTable(db, tableName)
}

// 后续算子的闭包完全接触不到TestRepository实例，不会触发序列化检查
val result = inputDs
  .map(testInstance.doSomeOperation)
  .count()

• 方案2：将Worker端执行的处理逻辑放到Scala单例对象（object）中，单例的方法是静态实现的，不会持有外部作用域的变量引用，从根源上减少闭包捕获的无关对象。

// 单例对象的逻辑是静态的，不会关联外部非序列化实例
object RowProcessor {
  def doSomeOperation(row: MyTableSchema): MyTableSchema = {
    row
  }
}

val inputDs = new TestRepository().readTable(db, tableName)
val result = inputDs
  .map(RowProcessor.doSomeOperation)
  .count()

• 方案3：显式解除非序列化对象的引用，在提交算子前将持有TestRepository实例的变量置空，让闭包遍历器无法摸到该实例。

val testRepository = new TestRepository()
val inputDs = testRepository.readTable(db, tableName)
// 显式清空引用，标记该对象已失效
val testRepository = null

val result = inputDs
  .map(testInstance.doSomeOperation)
  .count()

• 方案4：优先使用Spark SQL原生函数实现数据转换，原生函数由Catalyst优化器直接生成执行逻辑，不需要序列化Scala闭包分发到Worker，自然不会触发JVM层面的序列化检查。

注意：不要为了绕序列化检查强行给所有类加Serializable接口，尤其是持有数据库连接、SparkSession这类Driver端专属资源的类，这类类即使实现了序列化接口，分发到Worker端反序列化后也无法正常工作，反而会抛出更难排查的连接错误。

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