Spark Streaming揭秘 Day13
数据安全容错(Driver篇)
书接上回，首先我们要考虑的是在Driver层面，有哪些东西需要维持状态，只有在需要维持状态的情况下才需要容错，总的来说，一共有三个组件需要容错：
- 数据层面:ReceiverBlockTracker,专门负责管理整个SparkStreaming运行数据的元数据，主要用来跟踪数据，需要状态。
- 逻辑层面:DStream和DStreamGraph，表达依赖关系，在恢复的时候需要恢复计算逻辑级别的依赖关系。
- 作业生成层面:JobGenerator,表明正在怎么基于RBT和DStreams的关系生成作业，消费了哪些数据，进行到了哪些程度，都需要容错。
在Driver层面，主要也是采用checkpoint和WAL两个容错机制。
ReceiverBlockTracker容错
ReceiverBlockTracker，会管理SparkStreaming运行过程中的所有数据，指针指向具体数据。所有操作都会保存在WAL中，所以当失败后可以恢复。
在ReceiverBlockTracker中，核心是如下的两个数据结构：
- 未分配队列streamIdToUnallocatedBlockQueues：存储所有已接收但是还没有分配给具体Batch的Block，会被具体Receiver调用。
- 已分配队列timeToAllocatedBlocks：表示已分配的Block，会被JobGenerator调用。需要注意的是，这是个HashMap，所以可以存很多Batch Duration的Blocks，可以支持window或者state操作。
所以，我们可以围绕数据的三个阶段展开：
阶段一：addBlock方法主要负责收集数据写入未分配队列
我们可以看到，当收到Executor端传过来的数据，第一步通过writeToLog方法进行元数据的容错处理。需要注意，在这里并没有判断啥调用条件，具体的容错方式是在writeToLog方法内部判断的。
阶段二：allocateBlocksToBatch方法主要负责将未分配队列数据写入已分配队列
在获取所有未分配数据的时候，采用dequeue方法，其中隐含的会进行一个union操作，按照streamID(表示不同的输入数据来源)进行汇总。
同时，在获取数据后，首先做writeToLog，在成功写入WAL之后，才会把元数据放入已分配队列中。
阶段三：CleanUpOldBatchs将过期数据进行销毁
我们可以看到，在实际执行销毁前，也会调用writeToLog进行灾备。
综上所述，在数据管理层面，数据生成、消费、销毁的时候都做灾备!!!
writeToLog
这是进行容错的核心方法，方法本身也是比较简洁的。
首先，会通过isWriteAheadLogEnabled方法进行备份方式在判断，我们发现，其最终是调用了如下的方法。可以看到其核心就是使用到了checkpoint目录，也就是说备份其实是基于checkpoint机制进行的。
实际备份其实就是以WAL的方法进行文件写入，writeToLog目前程序出错时可以recover,但是程序升级时不行，可以通过覆写代码，将WAL保存在其他的地方。
总结来说，checkpoint提供了数据的存放位置，而WAL则是具体的数据组织方法。
欲知后事如何，且听下回分解
DT大数据每天晚上20：00YY频道现场授课频道68917580