转载自：https://mp.weixin.qq.com/s/EQgDUSf3TK0oVg1xmg-49Q
Checkpoint是Spark Streaming中的核心机制，它为应用程序的7*24小时LongRunning提供保证。Spark Checkpoint是基于JVM Serializable机制来实现，它会定时将整个Checkpoint对象从内存中序列化到外部存储（如HDFS），在应用程序异常重启时，对它进行反序列化，从而恢复到重启之前的状态。
但是基于JVM Serializable机制来实现Checkpoint存在一个缺陷：Checkpoint相关联的内部类或者业务类，在进行升级时，可能导致Checkpoint无法反序列化，进而导致升级失败。在Spark的Structured Streaming中，为规避该问题而采用Json来序列化相关数据https://databricks.com/blog/2017/01/19/real-time-streaming-etl-structured-streaming-apache-spark-2-1.html。
跟进 Structured Streaming来将传统的Streaming升级到使用Json序列化会是一件工作量很大的事情。因此我们从JVM Serializable机制本身出发来定位和解决这个问题。
1. JVM序列化机制
在JVM中，继承Serializable的类可以在运行时，通过ObjectOutputStream将对象从内存中以字节的形式序列化到流中，或者通过ObjectInputStream从流中反序列化出一个Object对象。
对于序列化，ObjectOutputStream会将对象的类名，SerialVersionUID，成员变量的描述信息，以及成员变量的值以一定的格式写到字节流中。如果成员变量为其他对象的引用，会递归的进行序列化。
对于反序列化，ObjectInputStream首先会读取字节流中类名，驱动JVM类加载器加载相应类到内存中，再从流中读取已序列化的SerialVersionUID，并与刚加载类的SerialVersionUID进行比较，如果它们相同，就继续后面的反序列化操作，否则会反序列失败，报InvalidClassException异常。
即使加载类与老的序列化类的Class字节码不同，只要SerialVersionUID相同，反序列化依然会成功的。如果新加载的类中添加了成员变量，将填充为默认值，被移除的成员变量将会被跳过。
2. 如何解决
反序列化成功或失败只受SerialVersionUID的值影响。对于Spark Streaming，只要我们对Checkpoint相关联的可序列化类都强制标记上SerialVersionUID，即可解决上述问题。
通过对Checkpoint类以及它的成员属性进行递归查找，确定Spark内部相关联的序列化类有：
通过使用JVM自带的serialver工具，获取未标记版本的类的SerialVersionUID。
serialver [-classpath classpath] [-show] [classname…]
并将这些SerialVersionUID手动的设置到相应类中，比如Checkpoint类：
经过测试，该方案可行。
3. 后序
在Oracle官方API文档http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html，对SerialVersionUID是这样描述的：
However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization.
即为了提高SerialVersionUID的独立性和确定性，官方强烈建议在一个可序列化类中显示的定义SerialVersionUID，为它赋予明确的值。
对于Spark 社区来说，既然存在这样一个缺陷，为什么不跟进将每个可序列化类都强制标记上SerialVersionUID呢？在(SPARK-13084)https://issues.apache.org/jira/browse/SPARK-13084中有这样的讨论：
Serialversionuid is generally a bad idea. It opens up a worse problem: you claim compatibility when something isn’t because you forget to update the field. I don’t think it’s expected that a serialized RDD is compatible across any different versions. I would be against this in general
即社区并没有希望Spark版本之间是二进制兼容的，比如说：不希望Spark 1.4版本序列化的数据可以跑在Spark 1.5的版本上，也不希望Spark 1.4版本的Driver与Spark 1.5的Executor之间进行通信。
但是对于公司的平台来说，需要在Spark社区版本的基础上，进行升级来满足一些特定需求，此时小版本之间的序列化兼容成为一个必要的属性。
4. 延伸阅读
如果不显式设置，SerialVersionUID如何确定？在《Java Object Serialization Specification》http://docs.oracle.com/javase/7/docs/platform/serialization/spec/class.html#4100是这样描述的：
但是Spark是基于Scala开发的。除了上述相同的语法元素会影响SerialVersionUID以外，Scala自身一些语法元素也可能影响SerialVersionUID。
1. 修改类的访问权限（public，private）不影响SerialVersionUID。
2. 新增和删除val常量会影响SerialVersionUID。
3. 闭包会被编译为可序列化类，并且其SerialVersionUID永远为0，对闭包元素的修改都不影响SerialVersionUID。
4. case class会被编译为可序列化类，其SerialVersionUID影响因素与普通类相同。
5. 增加或删除伴身对象的字段或者方法，如果它与伴身类中成员同名，即不会影响伴身类的SerialVersionUID，否则会影响。
6. 伴身对象中定义的private字段或方法不会影响伴身类的SerialVersionUID。