Spark Streaming的容错和数据无丢失机制

Spark Streaming的容错和数据无丢失机制

原文链接：Improved Fault-tolerance and Zero Data Loss in Spark Streaming（译者/彭根禄）

实时的流式处理系统必须是7*24运行的，同时可以从各种各样的系统错误中恢复，在设计之处，Spark Streaing就支持driver和worker节点的错误恢复。然后，在使用某些数据源的时候，错误恢复时输入数据可能会丢失。在spark 1.2中，加入write ahead logs（日志）这个初步方案用来改进恢复机制，保证数据的无丢失。

背景

spark和rdd的设计保证了集群中worker节点的容错性。spark streaming构建在spark之上，所以它的worker节点也是同样的容错机制，然后Spark Streaming应用的高可用性要求应用的driver进程也要有容错性，它是应用的主要进程用于协调所有的worker节点，因为用户应用的计算模式是可变的导致driver的容错性非常棘手，然后Spark Streaming会对实时流中的每一批数据进行运行同样的Spark计算，这样就可以定期的保存应用的状态到一个可靠的存储中，driver重启的时候恢复这些状态。

对于一些文件的数据源，driver的恢复机制可以保证数据无丢失，因为所有的数据都保存在HDFS或S3上面，对于一些像kafka,flume等数据源，接收的数据保存在内存中将有可能丢失，这是因为spark应用分布式运行的，如果driver进程挂了，所有的executor进程将团灭，保存在这些进程所持有内存中的数据将会丢失。为了避免这些数据的丢失，在spark streaming 1.2中 引入了一个write ahead logs。

Write Ahead Logs

WAL使用在文件系统和数据库中用于数据操作的持久性，先把数据写到一个持久化的日志中，然后对数据做操作，如果操作过程中系统挂了，恢复的时候可以重新读取日志文件再次进行操作。

对于像kafka和flume这些使用接收器来接收数据的数据源。接收器作为一个长时间的任务运行在executor中，负责从数据源接收数据，如果数据源支持的话，向数据源确认接收到数据，然后把数据存储在executor的内存中，然后driver在exector上运行任务处理这些数据。

如果wal启用了，所有接收到的数据会保存到一个日志文件中去（HDFS), 这样保存接收数据的持久性，此外，如果只有在数据 写入到log中之后接收器才向数据源确认，这样drive重启后那些保存在内存中但是没有写入到log中的数据将会重新发送，这两点保证的数据的无丢失。

配置

启动WAL需要做如下的配置

1：给streamingContext设置checkpoint的目录，该目录必须是HADOOP支持的文件系统，用来保存WAL和做Streaming的checkpoint

2：spark.streaming.receiver.writeAheadLog.enable 设置为true

当WAL被启动了以后，所有的接收器接收的数据可以很稳定的恢复，推荐的内存备份可以关闭了（给输入流设置合适的持久化级别），因为WAL保存在可容错的文件系统上，数据已经备份了。

此外，如果想要恢复缓冲的数据，必须使用支持应答的数据源（flume,kafka,kinses)。 当数据存储到日志以后那些支持应答接收器可以向数据源确认。内置的flume和kafka接收器已经实现了这些功能

最后，值得注意的是WAL开启了以后会减少Spark Streaming处理数据的吞吐，因为所有接收的数据会被写到到容错的文件系统上，这样文件系统的吞吐和网络带宽将成为瓶颈。可以通过添加更多接收器或使用更好的软件。

实现细节

下面讲解下WAL的工作原理。过一下Spark Streaming的架构

当一个Spark Streaming应用启动了(例如driver启动), 相应的StreamingContext使用SparkContet去启动receiver,receiver是一个长时间执行的作业，这些接收器接收并保存这些数据到Spark的executor进程的内存中，这些数据的生命周期如下图所示

1：蓝色的箭头表示接收的数据，接收器把数据流打包成块，存储在executor的内存中，如果开启了WAL，将会把数据写入到存在容错文件系统的日志文件中

2：青色的箭头表示提醒driver, 接收到的数据块的元信息发送给driver中的StreamingContext, 这些元数据包括：executor内存中数据块的引用ID和日志文件中数据块的偏移信息

3：红色箭头表示处理数据，每一个批处理间隔，StreamingContext使用块信息用来生成RDD和jobs.  SparkContext执行这些job用于处理executor内存中的数据块

4：黄色箭头表示checkpoint这些计算，以便于恢复。流式处理会周期的被checkpoint到文件中

实现细节
让我们更深入地探讨一下这个问题，弄清预写日志到底是如何工作的。首先，我们重温一下常用的Spark Streaming的架构。
在一个Spark Streaming应用开始时（也就是driver开始时），相关的StreamingContext（所有流功能的基础）使用SparkContext启动接收器成为长驻运行任务。这些接收器接收并保存流数据到Spark内存中以供处理。用户传送数据的生命周期如下图所示（请参考下列图示）。
 
 
接收数据（蓝色箭头）——接收器将数据流分成一系列小块，存储到executor内存中。另外，在启用以后，数据同时还写入到容错文件系统的预写日志。
通知driver（绿色箭头）——接收块中的元数据（metadata）被发送到driver的StreamingContext。这个元数据包括：（i）定位其在executor内存中数据位置的块reference id，（ii）块数据在日志中的偏移信息（如果启用了）。
处理数据（红色箭头）——每批数据的间隔，流上下文使用块信息产生弹性分布数据集RDD和它们的作业（job）。StreamingContext通过运行任务处理executor内存中的块来执行作业。
周期性地设置检查点（橙色箭头）——为了恢复的需要，流计算（换句话说，即 StreamingContext提供的DStreams ）周期性地设置检查点，并保存到同一个容错文件系统中另外的一组文件中。

 

当一个失败的driver重启以后，恢复流程如下

1：黄色的箭头用于恢复计算，checkpointed的信息是用于重启driver,重新构造上下文和重启所有的receiver

2:  青色箭头恢复块元数据信息，所有的块信息对已恢复计算很重要

3：重新生成未完成的job(红色箭头），会使用到2恢复的元数据信息

4：读取保存在日志中的块(蓝色箭头），当job重新执行的时候，块数据将会直接从日志中读取，

5：重发没有确认的数据（紫色的箭头）。缓冲的数据没有写到WAL中去将会被重新发送。

 

• 恢复计算（橙色箭头）——使用检查点信息重启driver，重新构造上下文并重启接收器。
• 恢复元数据块（绿色箭头）——为了保证能够继续下去所必备的全部元数据块都被恢复。
• 未完成作业的重新形成（红色箭头）——由于失败而没有处理完成的批处理，将使用恢复的元数据再次产生RDD和对应的作业。
• 读取保存在日志中的块数据（蓝色箭头）——在这些作业执行时，块数据直接从预写日志中读出。这将恢复在日志中可靠地保存的所有必要数据。
• 重发尚未确认的数据（紫色箭头）——失败时没有保存到日志中的缓存数据将由数据源再次发送。因为接收器尚未对其确认。

因此通过预写日志和可靠的接收器，Spark Streaming就可以保证没有输入数据会由于driver的失败（或换言之，任何失败）而丢失。

 

未来的发展方向

有关预写日志的某些未来发展方向包括：

• 类似Kafka这样的系统可以通过复制数据保持可靠性。允许预写日志两次高效地复制同样的数据：一次由Kafka，而另一次由Spark Streaming。Spark未来版本将包含Kafka容错机制的原生支持，从而避免第二个日志。
• 预写日志写入性能的改进（尤其是吞吐率）。

文章参与人员

该特性（预写日志）的主要实现者如下：

• Tathagata Das (Databricks)——整体设计以及大部分实现。
• Hari Shreedharan (Cloudera)——预写日志的写入和读出。
• 邵赛赛 (Intel)——内置Kafka支持的改进。

进一步研究的参考

• 关于检查点和预写日志更多的信息，请参考Spark Streaming Programming Guide
• Spark的Meetup talk中有关的主题
• JIRA – SPARK-3129

原文链接：Improved Fault-tolerance and Zero Data Loss in Spark Streaming（译者/彭根禄）