实时流处理系统必须全天候运行，这就要求它们能够从系统中的各种故障中恢复过来。从一开始，apachespark流媒体就包含了从驱动程序和工作机故障中恢复的支持。但是，对于某些数据源，在从故障中恢复时，输入数据可能会丢失。在apachespark1.2中，我们为Spark流添加了对预写日志（也称为日志）的初步支持，以改进这种恢复机制，并为更多的数据源提供更可靠的零数据丢失保证。在这个博客中，我们将详细介绍这个特性是如何工作的，以及开发人员如何使它能够在Spark流媒体应用程序中获得这些保证。背景Spark及其RDD抽象被设计成无缝地处理集群中任何工作节点的故障。由于Spark流是建立在Spark上的，所以它对工作节点具有相同的容错能力。然而，Spark流应用程序的高运行时间要求应用程序也必须从驱动程序进程的故障中恢复，驱动程序进程是协调所有工作人员的主要应用程序进程。使Spark驱动程序具有容错性是很困难的，因为它是一个具有任意计算模式的任意用户程序。然而，Spark流应用程序在计算中有一个固有的结构——它在每一个微批数据上周期性地运行相同的Spark计算。这种结构允许我们定期将应用程序状态保存（也称为检查点）到可靠的存储中，并在驱动程序重新启动时恢复状态。对于像文件这样的源，这个驱动程序恢复机制足以确保零数据丢失，因为所有数据都可靠地存储在HDFS或S3这样的容错文件系统中。然而，对于Kafka和Flume这样的其他源，一些在内存中缓冲但尚未处理的接收数据可能会丢失。这是因为Spark应用程序是如何以分布式方式运行的。当驱动程序进程失败时，运行在独立/yarn/mesos集群中的所有执行器也将被终止，同时它们内存中的所有数据也将被杀死。在Spark流的情况下，从Kafka和Flume等源接收的所有数据都被缓冲在执行器的内存中，直到它们的处理完成。即使重新启动驱动程序，也无法恢复此缓冲数据。为了避免这种数据丢失，我们在apachespark1.2版本的Spark流中引入了预写日志。提前写入日志预写日志（也称为日志）用于数据库和文件系统，以确保任何数据操作的持久性。首先将操作的意图写入持久日志，然后将操作应用于数据。如果系统在应用操作的过程中失败，它可以通过读取日志并重新应用它原本打算执行的操作来恢复。让我们看看如何使用这个概念来确保接收到的数据的持久性。像卡夫卡这样的接收器和数据源。它们在执行器中作为长时间运行的任务运行，负责从源接收数据，如果源支持，则确认接收到的数据。它们将接收到的数据存储在执行器的内存中，然后驱动程序在执行器上运行任务来处理这些任务。启用预写日志时，所有接收到的数据也会保存到容错文件系统中的日志文件中。这使得接收到的数据在Spark Streaming中的任何故障都能持久。此外，如果接收器仅在数据已被预写日志之后才正确地确认接收到数据，则在驱动程序重新启动后，源可以重新发送缓冲但未保存的数据。这两者结合起来可以确保没有数据丢失—所有数据要么从日志中恢复，要么由源重新发送。配置如果执行以下操作需要，可以启用预写日志。使用设置检查点目录streamingContext.checkpoint（目录路径）。此目录可以设置为任何与hadoopapi兼容的文件系统，用于保存流式检查点和预写日志。设置SparkConf属性spark.streaming.receiver.writeAheadLog.enable设置为true（默认值为false）。启用日志后，所有接收器都可以从恢复可靠接收到的数据中受益。建议禁用内存中的复制（通过在输入流中设置适当的持久性级别），因为用于预写日志的容错文件系统可能也在复制数据。此外，如果您想恢复甚至是缓冲数据，您将不得不使用一个支持acking的源（如Kafka、Flume和Kinesis），并实现一个可靠的接收器，在数据可靠地存储在日志中时正确地确认源。内置的卡夫卡和水槽轮询接收器已经是可靠的。最后，值得注意的是，启用预写日志可能会稍微降低数据接收吞吐量。由于所有接收到的数据都将写入容错文件系统，文件系统的写入吞吐量和用于复制的网络带宽可能成为潜在的瓶颈。在这种情况下，要么创建更多的接收器来提高接收数据的并行性，要么使用更好的硬件来提高容错文件系统的吞吐量。实施细节让我们更深入地了解预写日志是如何工作的。在上下文中，让我们浏览一下Spark流的一般架构。当Spark流应用程序启动（即驱动程序启动）时，相关的StreamingContext（所有流功能的起点）使用SparkContext作为长时间运行的任务启动接收器。这些接收器接收流数据并将其保存到Spark的内存中进行处理。通过用户接收到的这些数据的生命周期如下（参见下图）。接收数据（蓝色箭头）–接收器将数据流分成块，存储在执行器的内存中。此外，如果启用，数据也会写入容错文件系统中的预写日志。通知驱动程序（绿色箭头）–接收到的块的元数据被发送到驱动程序中的StreamingContext。此元数据包括—（i）块的引用ID，用于在执行器内存中定位其数据；（ii）日志中块数据的偏移量信息（如果启用）。处理数据（红色箭头）–每个批处理间隔，StreamingContext使用块信息生成RDD和它们上的作业。SparkContext通过运行任务来处理执行器中的内存块来执行这些作业。检查点计算（橙色箭头）–为了恢复，流计算（即使用StreamingContext设置的数据流）定期检查到同一容错文件系统中的另一组文件。重新启动失败的驱动程序时，会发生以下情况（请参阅下一个图表）。恢复计算（橙色箭头）–检查点信息用于重新启动驱动程序、重建上下文并重新启动所有接收器。恢复块元数据（绿色箭头）–将恢复继续处理所需的所有块的元数据。重新生成未完成的作业（红色箭头）–对于由于失败而未完成处理的批处理，将使用恢复的块元数据重新生成RDD和相应的作业。读取保存在日志中的块（蓝色箭头）–执行这些作业时，块数据直接从预写日志中读取。这将恢复可靠地保存到日志中的所有必要数据。重新发送未确认的数据（紫色箭头）–失败时未保存到日志中的缓冲数据将由源再次发送。因为它没有被接收者承认。因此，有了预写日志和可靠的接收器，Spark Streaming可以保证不会因为驱动程序故障（或者就此而言，任何故障）而丢失输入数据。未来方向关于预写日志的一些可能的未来方向如下。像卡夫卡这样的系统可以复制数据以提高可靠性。启用预写日志可以有效地复制同一数据两次—一次由Kafka复制，另一次通过Spark Streaming复制。Spark的未来版本将包括对Kafka的本地容错支持，从而避免了第二个日志。写入预写日志时的性能改进（尤其是吞吐量）。信用实现这一功能的主要功劳是以下几点。如来Das（Databricks）——总体设计和实现的主要部分。Hari Shreedharan（Cloudera）–写入和读取预写日志。Saisai Shao（Intel）–对内置Kafka支持的改进。进一步参考有关检查点和预写日志的更多信息，请参阅Spark流编程指南。就这个话题展开聚会讨论联合JIRA–SPARK-3129免费试用Databricks。今天就开始吧