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
}
}