根据官网文档看Spark的checkpoint机制

继续跟着官网文档学习

先思考一个根源问题: 为什么要看官网呢? 磕磕绊绊的, 看看中文的文章不好吗?

其实我一开始学大数据也是喜欢看博客看视频的讲解, 但是慢慢发现有一个现象: 我感觉大数据这方面的知识内容, 在网上完全没有像Java或者数据库/网络的知识那样有共识性. Java和计算机基础这方面的大部分知识都是类似于常识的了, 也基本没有什么不一样的声音. 而大数据的学习内容很多时候都是一家一言的理解, 好不容易理解了一篇博客, 顺着点到下一篇相关的文章, 然后又颠覆了一些概念, 无法分辨究竟是什么. 有时候好不容易找到有共识的说法, 但仔细读读又好像有抄袭拷贝的嫌疑, 也不知道究竟信不信, 就挺头疼的

这么一盘算, 不如自己直接去看官网理解的好. 虽然是英语, 但无论怎么说, 挤挤也是看得懂的. 而且有些比较好的文章和视频课里都有推荐去看官网, 也说官网写得很浅显易懂. 我刷了一段时间的官网之后也发现确实是这样的, 几乎不用生僻词, 剩下的都是看理解能力

我个人的感觉来说, 入门一个大数据组件的时候, 看看那些文章和视频是没什么问题的, 常识性的知识大家都没有什么异议. 但是如果想要搞清楚一些原理上的设计和思想, 或者是组件哪个细节上的处理, 那一定得看官网, 不然的话属实有可能读文章读得晕头转向的, 最终被误导
(但我还是想说, 有些内容是真找不到, 看别人都有一个个很官方很正式的图, 我就是找不着…)
当然了, 如果时间和精力充沛的话, 直接学习源码也是非常好的方式. 代码不会骗人, 而且Spark的源码注解都非常详细

那就继续根据官网学习吧, 也就是继续翻译:

(注: checkpoint这个词实在很难翻译, 为了不误导, 我就以原词checkpoint表示了, 把它理解为一个动词即可)

1. 第一大段: 一个Streaming程序必须24 * 7(24小时*7天)地运行. 因此, 必须能够抵御(或者说, 从中恢复)与应用程序逻辑无关的故障(系统故障/JVM崩溃). 为了实现它, Spark Streaming需要checkpoint足够的数据到可容错的存储系统(比如HDFS), 这样就可以从故障中恢复了. 有两种类型的数据会被checkpoint
   JVM crash我搜了一圈, 发现有好几种原因, 不过能理解的只有java.lang.StackOverflowError, 栈溢出. 不过没事, 不影响这里的内容理解. 然后, 这里又提到了fault-rolerant storage system, 我前几篇文章也有多次遇到这个词. 说白了, 分布式场景下, 想要数据不丢, 那就要经常用到HDFS, 因为它是一个高容错的分布式文件存储方式(而且可以根据实际情况, 灵活设置副本个数. 但极端情况下也是不够容错的, 但那样的情况属实比较极端)

2. 接第一大段的内容, 介绍了两种会被checkpoint的数据类型

   1. Metadata, 元数据. 将定义了流式计算的信息存储到像HDFS这样的容错存储中. 运行了流应用程序的driver的节点有可能发生故障, 元数据将用于从它的故障中恢复
      几个概念理一下:
      i) node: 就是指worker节点
      ii) streaming application: 就是我们手工写代码出来的流处理程序
      iii) driver: 运行(streaming application)main方法的JVM进程叫做driver, 是进程级别的概念, 它负责Job生成 & Stage划分 & Task分配等. 一个Spark应用程序只能有一个driver, 但是可以有多个executor(它也是进程级别的)

      接着开始它介绍元数据中包括的内容:

      1. 配置信息. 创建这个流应用程序的配置信息. 应该是提交时那些包括executor - memory / core等的信息
      2. DStream操作. 在streaming application定义的DStream操作们
      3. 未完成的批次. 指的是那些正在排队等待而未完成的job批次. 也就是说, 完成的job不会被checkpoint

      对于2和3两个概念, 我觉得还是有必要贴一下这两张图的:
      
      

   2. Data, 普通数据. 将计算过程中产生的RDD保存到可靠的存储中. 对于有状态的转换来说这是有必要的, 因为这些转换操作合并了来自多个批次的数据. 在这些有状态的转换中, 产生的一个个RDD依赖于上一个批次中的RDD, 依赖链会随着时间而变长. 为了避免恢复时间的无限增长(意思是依赖链越长的话, 恢复时间越久), 有状态转换的中间RDD会被checkpoint到可靠的存储中如HDFS, 以切断依赖链(这样就能缩短恢复时间!)
      啥叫有状态的转换? 是不是还有无状态的转换? 都是啥呢? 以非常经典的word count例子来说, 结合上面的DStream图:
      假设来了4波数据, 每波数据都是(a, a, a, b, b, b)
      
      先说一个经典的无状态操作: reduceByKey. 4波数据分别是(<a, 3>, <b, 3>), (<a, 3>, <b, 3>), (<a, 3>, <b, 3>), (<a, 3>, <b, 3>). 它们一批归一批, 互相不干扰
      再说一个经典的有状态操作: updateStateByKey. 4波数据分别是(<a, 3>, <b, 3>), (<a, 6>, <b, 6>), (<a, 9>, <b, 9>), (<a, 12>, <b, 12>). 它们会依赖于之前批次的结果
      有状态和无状态的操作还有很多, 但是逻辑上的区别都一样: 有否依赖于之前的处理结果

3. 接着看最后一段: 元数据的checkpoint主要是用于从driver故障(记不记得driver是运行流处理程序main方法的JVM进程? 再结合一下上面提到过的JVM crash这个词, 是不是能更好地理解了?)中恢复. 然而, 对数据或RDD进行checkpoint则是必要的, 即使是在使用有状态转换的情况下, 基本功能也是如此(这里我没理解basic function是什么意思, 应该说的是无状态的转换吧, 也就是没记录数据流的总体情况. 这个时候checkpoint好像没那么重要, 因为过去的数据有可能已经被处理掉了. 但不一定, 理解有限)

不过呢, 官网上还说了一句, 用updateStateByKey需要指定好checkpoint的目录, 也就是要把中间的数据都存储下来

按我的理解, 有状态的转换操作应该都需要指定checkpoint目录. 说到底, 既然新值和老值有承接的转换关系, 那总得有地方记录这些数据吧? 不然之后的DStream怎么根据呢? 至于basic function这个词, 属实还没懂, 先这样吧