当使用sparkstreaming处理流式数据的时候，它的数据源搭档大部分都是Kafka，尤其是在互联网公司颇为常见。 当他们集成的时候我们需要重点考虑就是如果程序发生故障，或者升级重启，或者集群宕机，它究竟能否做到数据不丢不重呢？

也就是通常我们所说的高可靠和稳定性，通常框架里面都带有不同层次的消息保证机制，一般来说有三种就是：

at most once 最多一次
at least once 最少一次
exactly once  准确一次

在storm里面是通过ack和Trident，在sparkstreaming里面，如果是1.3版本之前是通过Receiver方式读取kafka数据，1.3之后通过Direct Approach方式直接读取kafka的数据，直接分配每个Batch及RDD最新的Topic partition offset，任务运行后使用kafka的Simple Consumer API去获取那一段的offset的数据，这样的好处是避免了原来Receiver接受数据宕机带来的数据可靠性风险，相当于原来的数据是在内存中而现在的数据是在kafka的磁盘中，通过偏移量可随时再次消费数据，从而实现了数据的Exactly Once处理，此外还有个不同之处在于1.3之后，使用的checkpoint保存当前消费的kafka的offset，而之前用zk保存的，这就是今天这篇文章重点吐槽的地方。

在sparkstreaming如何做到数据不丢失呢？

1. 使用checkpoint
2. 自己维护kafka偏移量

checkpoint配合kafka能够在特定环境下保证不丢不重，注意为什么要加上特定环境呢，这里有一些坑，checkpoint是对sparkstreaming运行过程中的元数据和 每次rdds的数据状态保存到一个持久化系统中，当然这里面也包含了offset，一般是HDFS,S3，如果程序挂了，或者集群挂了，下次启动仍然能够从checkpoint中恢复，从而做到生产环境的7*24高可用。

但是checkpoint的最大的弊端在于，一旦你的流式程序代码或配置改变了，或者更新迭代新功能了，这个时候，你先停旧的sparkstreaming程序，然后新的程序打包编译后执行运行，会发现两种情况：
（1）启动报错，反序列化异常
（2）启动正常，但是运行的代码仍然是上一次的程序的代码。

为什么会出现上面的两种情况，这是因为checkpoint第一次持久化的时候会把整个相关的jar给序列化成一个二进制文件，每次重启都会从里面恢复；但是当你新的 程序打包之后序列化加载的仍然是旧的序列化文件，这就会导致报错或者依旧执行旧代码。
有的同学可能会说，既然如此，直接把上次的checkpoint删除了，不就能启动了吗？ 确实是能启动，但是一旦你删除了旧的checkpoint，新启动的程序，只能从kafka的smallest或者largest的偏移量消费，默认是从最新的，如果是最新的，而不是上一次程序停止的那个偏移量 就会导致有数据丢失，如果是老的，那么就会导致数据重复。不管怎么样搞，都有问题。
请参考官网：https://spark.apache.org/docs/2.1.0/streaming-programming-guide.html#upgrading-application-code

针对这种问题，spark官网给出了2种解决办法：

（1）旧的不停机，新的程序继续启动，两个程序并存一段时间消费。
评价：仍然有丢重复消费的可能
（2）停机的时候，记录下最后一次的偏移量，然后新恢复的程序读取这个偏移量继续工作，从而达到不丢消息。
评价：官网没有给出具体怎么操作，只是给了个思路

第二种思路是正确的，但还需要自己维护一个offset状态，这样以来checkpoint这个功能只能在程序写好之后不允许再次变动，但可以重启的情况保证高可靠。

但实际情况是大多数公司的代码都会频繁迭代和升级，与checkpoint刚好相悖，这样以来checkpoint的作用便显的有点没用了，既然还是需要自己维护offset状态， 那么不用checkpoint也罢，完全自己维护offset状态到zk中即可。所以果断弃用checkpoint，采用自己维护offset。其原理如下：

1. 首次启动，先从zk中找是否有上次存储的偏移量，如果没有就从最新的消费，然后保存偏移量至zk中。
2. 如果从zk中找到了偏移量，那么就从指定的偏移量处开始消费处理，每个批处理处理完毕后，都会更新新的offset到zk中， 这样以来无论是程序故障，还是宕机，再次启动后都会从上次的消费的偏移量处继续开始消费，而且程序的升级或功能改动新版本的发布都能正常运行 并做到了消息不丢。
3. 需要注意的是，虽然上游能够做到准确一次的消费，但是下游的落地存储输出，比如写入hbase，redis，mysql，es等等如果失败了，整条消息依旧会失败，这个完全要靠自己的设计了，要么记录log，针对特定数据记录，如果失败定期 重新打入kafka走程序恢复或者手动恢复。
4. 或者设计存储的时候，有复合主键，把偏移量提前，就算重复消费，但主键一样，最终只会有一条数据落地，这个要分场景和具体业务结合使用了。

回到主题，自己维护kafka的offset状态，如何做？ github上已经有大神贡献了，我们只需要拿过来稍加改动即可，使用自己维护的offset之后，就没有必要再使用 checkpoint，github连接如下,有兴趣的朋友可以了解下：

https://github.com/cpbaranwal/Spark-Streaming-DirectKafka-Examples/blob/master/src/main/scala/CustomDirectKafkaExample.scala
使用zk维护offset也是比较不错的选择，如果将checkpoint存储在HDFS上，每隔几秒都会向HDFS上进行一次写入操作而且大部分都是小文件，且不说写入性能怎么样，就小文件过多，对整个Hadoop集群都不太友好。因为只记录偏移量信息，所以数据量非常小，zk作为一个分布式高可靠的的内存文件系统，非常适合这种场景。

后面文章中有代码，并附有github。。。

所有参考链接：
http://aseigneurin.github.io/
http://aseigneurin.github.io/2016/05/07/spark-kafka-achieving-zero-data-loss.html
http://why-not-learn-something.blogspot.jp/2016/08/upgrading-running-spark-streaming.html
http://www.binwang.me/2015-11-03-the-proper-way-to-use-spark-checkpoint.html
https://github.com/cpbaranwal/Spark-Streaming-DirectKafka-Examples/blob/master/src/main/scala/CustomDirectKafkaExample.scala
https://github.com/ippontech/spark-kafka-source