SparkStreaming若需要24/7不间断的运行，那么必然要有强大的容错性保障，当出现故障的时候，即使是驱动器程序错误，也需要做到就好像没有发生任何节点失败一样。
检查点机制
Metadata checkpointing -
将Streaming的Metadata 信息存储在可靠的文件系统上（如HDFS）。主要是用于恢复Driver进程的。Metadata 包括：
- 配置信息：创建 Spark-Streaming 应用程序的配置信息，比如 SparkConf
- DStream 的操作信息：定义了 Spark-Stream 应用程序的计算逻辑的 DStream 操作信息
- 未处理完的 batch 信息：batch已经开始却没有处理完
Metadata checkpointing主要是使用StreamingContext.getOrCreate方法。
代码如下，另外教大家一种复制粘贴的好办法:paste
scala> :paste
// Entering paste mode (ctrl-D to finish)
import org.apache.spark._
import org.apache.spark.streaming._
val checkpointDirectory = "hdfs://master:8020/user/checkpoint"
def functionToCreateContext(): StreamingContext = {
val ssc = new StreamingContext(sc,Seconds(5))
val wordcount = ssc.socketTextStream("localhost", 9999).flatMap(_.split(" ")).map(word => (word, 1))
wordcount.print()
ssc.checkpoint(checkpointDirectory)
ssc
}
val context = StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext)
context.start()
context.awaitTermination()
Data checkpointing -
阶段性的存储RDD至可靠的文件系统上,供恢复时使用。这对于某些有状态的转化操作（updateStateByKey 和 reduceByKeyAndWindow）是必须的，因为这些转化操作不断的整合不同的批次，它依赖于前面的批次信息，这样就会形成一个很长的依赖链，为了防止无限的增长，就要定期将中间生成的 RDDs 保存到可靠的存储系统上来切断依赖链。
设置方法：ssc.checkpoint("hdfs://....")
scala> val ssc = new StreamingContext(sc, Seconds(5))
ssc: org.apache.spark.streaming.StreamingContext = org.apache.spark.streaming.StreamingContext@4924ad09
//设置检查点目录
scala> ssc.checkpoint("hdfs://master:8020/user/checkpoint")
scala> val pairs = ssc.socketTextStream("localhost", 7788).flatMap(_.split(" ")).map(word => (word, 1))
pairs: org.apache.spark.streaming.dstream.DStream[(String, Int)] = org.apache.spark.streaming.dstream.MappedDStream@41ff98dc
scala> val windowedWordCounts = pairs.reduceByKeyAndWindow( _+_, _-_, Seconds(15), Seconds(5))
windowedWordCounts: org.apache.spark.streaming.dstream.DStream[(String, Int)] = org.apache.spark.streaming.dstream.ReducedWindowedDStream@2f0dae44
scala> windowedWordCounts.print()
scala> ssc.start()
scala> ssc.awaitTermination()
【注意】：dstream 的 checkpoint 的周期一定要是产生 batch 的时间的整数倍，同时官方建议将 checkpoint 的事件设置为至少 10 秒，通常来说，将 checkpoint 间隔设置为窗口操作的滑动间隔的 5~10 倍是个不错的选择。
预写日志
从1.2版本开始，为了强大的容错性保障，引入了预写日志机制，一旦该机制开启了，从接收器接收到的所有数据都将写入配置检查点目录中的预写日志。这可以防止驱动程序恢复时的数据丢失，从而确保零数据丢失。但是这会影响系统的吞吐量，所以建议并行运行多个receiver，增加总吞吐量。
设置方式：spark.streaming.receiver.writeAheadLog.enable=true。
建议：若启用预写日志，则将复制持久化机制禁用掉，因为所有数据已经保存在容错的文件系统中了，不需要再用复制机制进行持久化。这可以通过将输入流的存储级别设置为StorageLevel.MEMORY_AND_DISK_SER来实现。
Exactly once的实现
streaming systems 的容错语义通常是通过系统可以处理每个记录的次数来捕获的.一般有以下三种类型的保证：
- At most once （最多一次）: 每个 record （记录）将被处理一次或根本不处理.
- At least once （至少一次）: 每个 record （记录）将被处理一次或多次.这比at-most once, 因为它确保没有数据将丢失.但可能有重复.
- Exactly once（有且仅一次）: 每个 record （记录） 将被精确处理一次 - 没有数据丢失, 数据不会被多次处理.这显然是三者的最强保证.
我们必须要清楚的是， 整个系统对exactly once的保证，绝对不可能只靠某一部分来保障。对Spark Streaming来说, Exactly once的实现，需要系统中三部分的整体保证:
Receiving the data:
输入源要保障精确一次，比如kafka中的Direct方式和Flume中的Pull方式就是用于解决exactly once的。
Transforming the data:
SparkStreaming转换处理接受到的数据。一般通过WAL（预写日志）来保障。
Pushing out the data:
输出外部系统时也要保障精确一次，因为transformed data 可能会不止一次写入外部实体中，有两种方法.
Idempotent updates （幂等更新）: 多次尝试总是写入相同的数据.例如, saveAs***Files 总是将相同的数据写入生成的文件.每次执行，HDFS文件内容将被覆盖。
Transactional updates （事务更新）: 所有更新都是事务性【ACID】的, 以便更新完全按原子进行.做法如下：
使用批处理时间（在 foreachRDD 中可用）和 RDD 的 partition index （分区索引）来创建 identifier （标识符）.该标识符唯一地标识 streaming application 中的 blob 数据.
使用该 identifier 事务地更新 external system （外部系统）（即, exactly once, atomically （一次且仅一次, 原子性的））.也就是说, 如果 identifier 尚未提交, 则以 atomically 提交 partition data 和 identifier.否则, 如果已经提交, 请跳过更新.
dstream.foreachRDD { (rdd, time) =>
rdd.foreachPartition { partitionIterator =>
val partitionId = TaskContext.get.partitionId()
val uniqueId = generateUniqueId(time.milliseconds, partitionId)
// use this uniqueId to transactionally commit the data in partitionIterator
}
}
