Spark Streaming之容错机制以及事务语义

我们知道RDD本身是一个不可变的，可重新计算的、分布式的数据集。每一个RDD都会记住确定好的操作血缘关系。

如果因为某些原因，导致某个worker节点失败，则导致RDD的某个partition数据丢失了，那么那个partition可以通过对原始的容错数据集应用操作血缘，来重新计算。因为HDFS本身是容错文件系统的，所以在HDFS的数据不会丢失，最坏情况无非重新计算而已。

 

但是对于SparkStreaming,在大多数情况下，都是通过网络接收的数据，要让Spark Streaming程序中，所有生成的RDD,都达到与普通的Spark程序的RDD相同的容错性，接受到的数据必须复制到多个Worker节点上的Executor内存中，默认复制因子是2.

 

# Worker节点的失败：任何一个运行了Executor的Worker节点失败，都会导致该节点上所有在内存中的数据丢失，如果有Receiver运行在该Worker节点的Executor中，那么缓存的、等待复制的数据，都会丢失

# Driver节点的失败：SparkContext和StreamingContext就丢失，如果我们开启Driver的checkpoint机制，这个时候该应用程序的所有Executor的数据都会丢失。

 

Spark Streaming容错语义：

流式计算系统的容错语义，通常是以一条记录能够被处理的多少次来衡量。有三种类型的语义：

1 最多一次：每一条记录可能会处理一次，或者根本不处理，可能有数据丢失

2 至少一次：每一条记录会被处理一次或者多次，这种语义比最多一次强点，他确保数据零丢失，但是会导致数据重复消费

3 一次仅且一次：每一条记录只处理一次，没有数据丢失

 

 

接收数据的容错语义：

1 基于文件的数据源

如果所有输入的数据都在一个容错的文件系统中，比如HDFS, Spark Streaming一定可以从失败中进行恢复，并且处理所有数据，这就提供了一次仅且一次的语义。

 

2 基于Receiver的数据源

对于基于Receiver的数据源，容错语义依赖于失败场景和Receiver类型

可靠的Receiver: 这种Receiver会在接收了数据，并且将数据复制之后，对数据源执行确认操作。如果Receiver在数据接收和复制完成之前就失败了，那么数据源对于缓存的数据会接收不到确认，此时Receiver重启之后，数据源会重新发送数据，没有数据丢失

 

不可靠的Receiver: 这种Receiver不会发送确认操作，因此当worker或者driver节点失败的时候，可能会导致数据丢失

 

针对不可靠的Receiver可能发生数据丢失问题，那么Spark引入了预写日志的机制,这样就可以保证数据零丢失。这种情况会提供至少一次保障。

计算数据容错：所有接受的数据一定只会被计算一次，这是基于RDD基础语义所保障的，即使有失败，只要接收到的数据还是可以访问的，最后一个计算出来的数据一定是相同的

 

推送数据容错：output操作默认只能保证至少一次的语义，因为依赖于输出类型以及底层的系统语义支持，比如是否有事务机制来确保一次仅且一次的语义