Spark Streaming源码解读之Driver容错安全性

本期内容 :

• ReceivedBlockTracker容错安全性
• DStreamGraph和JobGenerator容错安全性

　　　Driver的安全性主要从Spark Streaming自己运行机制的角度考虑的，如对源数据保存方面使用了WAL方式，驱动层面的容错安全主要使用的是CheckPoint ，

　　但是仅仅是WAL和CheckPoint在生成环境下不是完全足够的。

　　　Spark Streaming 的Driver容错为什么是这两个方面 ：

　　　1、 ReceiverBlockTracker主要管理整个Spark Streaming的运行数据的源数据的，从容错的角度讲，源数据是否很重要，否则出错的话数据都不正常何谈其它呢

　　　2、 DStream和JobGenerator 这个是框架的核心层面，具体调度到什么层面了，这是从业务与运行的角度考虑的

　　　Driver哪些需要维持状态的：

　　　1、 ReceiverBlockTracker跟踪数据毫无疑问是需要维持状态，所以就需要容错

　　　2、 DStreams表达了依赖关系，在其恢复的时候需要恢复计算逻辑级别的依赖关系

　　　3、 JobGenerator 表明你正在基于ReceiverBlockTracker的数据及DStreams构成的依赖关系产生Job的过程，消费了哪些数据、进行到什么程度等状态部分

　　　　

　　　ReceiverBlockTracker ：管理SparkStreaming的运行过程中指针指向的数据，一般都是在Executor上面的，并且把数据分配给每个Batches

　　　　　

　　　

　　Receiver接收到数据后是怎么处理的 ：

　　　　1、先进行WAL(冷备份)，然才会写入内存中，整个Spark Streaming作业中的调度或者Generator是基于GetReceivedBlockQueue中的数据，来观察每个Streaming接收到的数据

　　　　2、 放入内存中是被当前运行的Spark Streaming的调度器JobGenerator去使用的，JobGenerator不可能直接使用WAL,WAL是一个磁盘的存储架结构，而是使用内存的缓存数据结构。

　　　　　

　　　　　

　　　　　

　　　　　

　　　　　

　　　　　Spark Streaming是以窗口为作业划分标志，如频率以10S，在10S时间段接收到的所有数据保存在StreamIdToUnallocatedBlockQueues数据结构中，当计算时需要把，

　　　所有的数据提取出来 ,最后就变成StreamIDToBlocks ，Spark Streaming处理中可以有不同的数据来源同时进行处理 。

　　　　　

　　最终可以在AllocatedBlock 中获取数据，他有很多时间窗口的Blocks，Window操作或者状态操作都需要依赖这些信息，如果需要10分钟期间数据，根据数据结构把这些Bachelor集合起来就行了 。

　　随着时间的推移，会不断的产生数据，同时也不可能一直保持数据不变，需要对旧有的数据进行清理：

　　　　　

　　　　　

　　CheckPoint ： Job开始进行一次CheckPoint，Job结束后也来一次CheckPoint

　　　　

　　　　

　　　　

　　UpdateCheckPoint ：

　　　　

　　　　

　　GenerateJobs ：

　　　　

　　ClearMetadata ：