Spark Streaming容错
检查点机制-checkpoint
什么是检查点机制？
Spark Streaming 周期性地把应用数据存储到诸如HDFS 或Amazon S3 这样的可靠存储系统中以供恢复时使用的机制叫做检查点机制
检查点机制的作用
控制发生失败时需要重算的状态数
Spark Streaming通过lineage重算，检查点机制则可以控制需要在lineage中回溯多远
提供驱动器程序容错
如果流计算应用中的驱动器程序崩溃了，你可以重启驱动器程序，并让驱动器程序从检查点恢复，这样SparkStreaming就可以读取之前运行的程序处理数据的进度，并从那里继续。
checkpoint 两种类型的数据：
Metadata（元数据） checkpointing - 保存定义了 Streaming 计算逻辑至类似 HDFS 的支持容错的存储系统。用来恢复 driver，元数据包括：
1.配置 - 用于创建该 streaming application 的所有配置
2.DStream 操作 - DStream 一些列的操作
3.未完成的 batches - 那些提交了 job 但尚未执行或未完成的 batches。
RDD Data checkpointing - 保存已生成的RDDs至可靠的存储。
metadata checkpointing 主要用来恢复 driver；而 RDD数据的 checkpointing 对于stateful 转换操作是必要的。
对于window和stateful操作必须checkpoint(Spark Streaming会检查并给出提示)。
通过StreamingContext的checkpoint来指定目录，默认按照batch Duration来做checkpoint。
通过DStream的checkpoint指定当前DStream的间隔时间。
间隔必须是slide interval的倍数。
检查点机制-checkpoint的形式
checkpoint 的形式是将类 Checkpoint的实例序列化后写入外部存储，值得一提的是，有专门的一个线程来做将序列化后的 checkpoint 写入外部存储的操作。类 Checkpoint 包含以下数据：
除了 Checkpoint 类，还有 CheckpointWriter 类用来导出 checkpoint，CheckpointReader 用来导入 checkpoint。
检查点机制-checkpoint的局限
Spark Streaming 的 checkpoint 机制看起来很美好，却有一个硬伤。
前面提到最终刷到外部存储的是类 Checkpoint 对象序列化后的数据。那么在 Spark Streaming application 重新编译后，再去反序列化 checkpoint 数据就会失败。这个时候就必须新建 StreamingContext。
针对这种情况，在我们结合 Spark Streaming + kafka 的应用中，需要自行维护了消费的 offsets，这样一来即使重新编译 application，还是可以从需要的 offsets 来消费数据。对于其他的情况需要大家根据实际需求自行处理。
Driver节点容错
如果你想让你的application能从driver失败中恢复，你的application要满足：
若application为首次重启，将创建一个新的 StreamContext 实例
如果application是从失败中重启，将会从 checkpoint 目录导入 checkpoint 数据来重新创建 StreamingContext 实例
def createStreamingContext() = {...val sparkConf = new SparkConf().setAppName(“xxx")val ssc = new StreamingContext(sparkConf , Seconds(1))ssc.checkpoint(checkpointDir)ssc}...val ssc = StreamingContext.getOrCreate(checkpointDir, createStreamingContext _)
除调用 getOrCreate 外， 你还需要编写在驱动器程序崩溃时重启驱动器进程的代码。
在 yarn 模式下，driver 是运行在 ApplicationMaster 中，若 ApplicationMaster 挂掉，yarn 会自动在另一个节点上启动一个新的 ApplicationMaster。
Spark standalone模式下：
./bin/spark-submit --deploy-mode cluster --supervise --master spark://... App.jar
Worker节点容错
为了应对工作节点失败的问题，Spark Streaming 使用与Spark 的容错机制相同的方法，根据不同的输入源，分两种情况：
使用可靠输入源—如HDFS
由于输入数据是可靠的，所有数据都可以重新计算，因此不会丢失数据
使用基于网络接收的输入源—例如Kafka、Flume等
接收到的数据会在集群的不同节点间复制(默认复本数为2)
一个工作节点失效，在恢复时可以从另一个工作节点的数据中重新计算
如果是接收数据的工作节点失效，那就可能丢失数据(数据已经收到但是还未复制到其他节点，也没有处理完是失效了)
处理保证
所有转换操作为精确一次保证(Spark Streaming 工作节点的容错保障)
输出操作在把结果保存到外部存储时，写结果的任务可能因故障而执行多次，一些数据可能也就被写了多次
可以使用事务操作来写入外部系统（即原子化地将一个RDD分区一次写入），或者设计幂等的更新操作（即多次运行同一个更新操作仍生成相同的结果）。比如Spark Streaming 的saveAs...File 操作会在一个文件写完时自动将其原子化地移动到最终位置上，以此确保每个输出文件只存在一份。