Spark Streaming的WAL机制

WAL(Write Ahead Logs)是Spark中的一个保障HA(High Available)的机制, 在Hbase中也有应用到

抛开带着很多专业词的场景假设, 我觉得应该把技术上的事情用尽可能简单的逻辑表达清楚, 这样能更好地发现一些本质上的共性和设计思想

我们不如从逻辑上去思考一下, 为什么要有WAL这个机制:

首先, 分布式情况下, 无论是计算还是存储, 设计都应该做好HA, 即假设节点故障是不可避免的, 总是有可能发生的. 毕竟分布式如果节点机器很多的话, 真的是没法假设全部机器都没有问题对吧
假设处理过程中有节点宕机了或是网络出问题了, 也许计算任务可以重新分配给其他节点(如MapReduce的容错机制), 但是数据的完整性和实时性不能共存

具体点说, 以MapReduce为例: MapReduce的数据是静态的数据源, 并不是动态的, 所以就算传输的数据丢失了, 还可以找回来重发, 但MapReduce的场景就是离线处理, 对实时性没有那么高, 发生磁盘IO也问题不大. 相比之下, 在实时处理的场景中, 让一堆数据先落地存储一次, 再发到各个节点, 并不是一个高性能的主意. 但如果不这么做, 数据丢失是不可避免的

虽然Spark有着checkPoint的容错机制, 但checkPoint保存的是任务执行进度, 跟数据的初始接收并没有什么关系啊(数据是要分发到Executor上以Task为单位进行处理的, checkPoint介入的并不是这个数据分发的过程, 而是Task执行的过程)

所以, WAL的设计就显得非常有价值了. 它用较小的log(记录下数据的操作)存储来代替数据存储, 尽可能地兼顾数据的完整性和实时性. 且既然要保证完整性, 那还是要假设存放这个log的机器会宕机. 好吧, 这样一看HDFS是挺好的选择, 而不是随便存放在某个单台机器上

具体WAL是怎么实现的, 以及什么时候触发的, 可以参考一下这篇文章:https://www.jianshu.com/p/5e096df2618d