SparkStreaming 性能、稳定、容错与语义

Spark Streaming程序怎么做到不丢数据

答：因为Spark Streaming在接收数据的时候有两种模式，第一种是基于Receiver模式，第二种是Kafka Direct模式，两者不丢数据的处理方式不一样，所以我们需要了解掌握这两种模式不丢数据的处理策略：

基于Receiver模式：

在这种模式下，我们可以使用checkpoint + WAL + ReliableReceiver的方式保证不丢失数据，就是说在driver端打开chechpoint，用于定期的保存driver端的状态信息到HDFS上，保证driver端的状态信息不会丢失；在接收数据Receiver所在的Executor上打开WAL，使得接收到的数据保存在HDFS中，保证接收到的数据不会丢失；因为我们使用的是ReliableReceiver，所以在Receiver挂掉的期间，是不会接收数据，当这个Receiver重启的时候，会从上次消费的地方开始消费。

所以我们可以总结Spark Streaming的checkpoint机制包括driver端元数据的checkpoint以及Executor端的数据的checkpoint（WAL以及updateStateByKey等也需要checkpint）,Executor端的checkpoint机制除了保证数据写到HDFS之外，还有切断很长的RDD依赖的功效

Driver端checkpoint

　　　　　　　　　　　　待定：：

Executor端checkpoint

　　　　　　　　　　　　待定：：

 

Kafka Direct模式：

这种模式下，因为数据源都是存储在Kafka中的，所以一般不会丢数据，但是有一种情况下可能会丢失数据，就是当Spark Streaming应用失败后或者升级重启的时候因为没有记住重启之前消费的topic的offset，使得重启后Spark Streaming从topic的最新的offset开始消费(这个是默认的行为)，这样就导致Spark Streaming消费不到失败或者重启过程中Kafka接收到的消息，解决这个问题的办法有三个：

1、使用Spark Streaming自带的Driver端checkpoint机制，因为Driver端checkpoint机制会定期的保存Driver端的状态信息，当然也包括当前批次消费的Kafka中topic的offset信息啦，这样下次重启的时候就可以从checkpoint文件中直接读取上次消费到的offset信息，然后从这个offset开始消费。但是Driver端的checkpoint机制有一个很明显的缺陷，因为Driver端的checkpoint机制保存的Driver端的状态信息还包含DStreamGraph的状态信息，说白了就是将Driver端的代码序列化到checkpoint文件中，这样的话，如果我们对代码做了很大的改动或者升级的话，那么升级后的代码和checkpoint文件中的代码不兼容，这样的话会导致重启失败，解决这个问题的方法就是每次升级的时候将checkpoint文件清除掉，但是这样做的话也清除了保存在checkpoint文件中上次消费到的offset信息，这个不是我们想要的，所以这种方式不可取

2、我们可以在每一个批次开始之前将我们消费到的offset手动的保存到其他第三方存储系统中，可以是zookeeper或者Hbase，如下：

这样就是实现了手动的保存我们每一个批次消费到的topic的offset信息

 

3、也可以直接调用Kafka中高级的API，将消费的offset信息保存到zookeeper中

当重启Spark Streaming应用的时候，Spark Streaming会自动的从zookeeper中拿到上次消费的offset信息