目录
5. Sources 、Sinks与 Exactly—once
四、StreamExecution：持续查询的运转引擎
现在我们将目光聚焦到 continuous query 的驱动引擎（即整个 Structured Streaming 的驱动引擎） StreamExecution 上来。
1. StreamExecution 的初始状态
我们前文刚解析过，先定义好 Dataset/DataFrame 的产生、变换和写出，再启动 StreamExection 去持续查询。这些 Dataset/DataFrame 的产生、变换和写出的信息就对应保存在 StreamExecution 非常重要的 3 个成员变量中：
-
sources: streaming data 的产生端（比如 kafka 等） -
logicalPlan: DataFrame/Dataset 的一系列变换（即计算逻辑） -
sink: 最终结果写出的接收端（比如 file system 等）
StreamExection 另外的重要成员变量是：
-
currentBatchId: 当前执行的 id -
batchCommitLog: 已经成功处理过的批次有哪些 -
offsetLog,availableOffsets,committedOffsets: 当前执行需要处理的 source data 的 meta 信息 -
offsetSeqMetadata: 当前执行的 watermark 信息（event time 相关，本文暂不涉及、另文解析）等
我们将 Source, Sink, StreamExecution 及其重要成员变量标识在下图，接下来将逐个详细解析。
2. StreamExecution 的持续查询
一次执行的过程如上图；这里有 6 个关键步骤：
（1）StreamExecution 通过 Source.getOffset() 获取最新的 offsets，即最新的数据进度；
（2）StreamExecution 将 offsets 等写入到 offsetLog 里
这里的 offsetLog 是一个持久化的 WAL (Write-Ahead-Log)，是将来可用作故障恢复用
（3）StreamExecution 构造本次执行的 LogicalPlan
a 、将预先定义好的逻辑（即 StreamExecution 里的 logicalPlan 成员变量）制作一个副本出来
b 、给定刚刚取到的 offsets，通过 Source.getBatch(offsets) 获取本执行新收到的数据的 Dataset/DataFrame 表示，并替换到 a中的副本里
c、经过 a, b 两步，构造完成的 LogicalPlan 就是针对本执行新收到的数据的 Dataset/DataFrame 变换（即整个处理逻辑）了
（4）触发对本次执行的 LogicalPlan 的优化，得到 IncrementalExecution
逻辑计划的优化：通过 Catalyst 优化器完成
物理计划的生成与选择：结果是可以直接用于执行的 RDD DAG
逻辑计划、优化的逻辑计划、物理计划、及最后结果 RDD DAG，合并起来就是 IncrementalExecution
（5）将表示计算结果的 Dataset/DataFrame (包含 IncrementalExecution) 交给 Sink，即调用 Sink.add(ds/df)
（6）计算完成后的 commit
a、通过 Source.commit() 告知 Source 数据已经完整处理结束；Source 可按需完成数据的 garbage-collection
b 、将本次执行的批次 id 写入到 batchCommitLog 里
3. StreamExecution 的持续查询（增量）
Structured Streaming 在编程模型上暴露给用户的是，每次持续查询看做面对全量数据（而不仅仅是本次执行信收到的数据），所以每次执行的结果是针对全量数据进行计算的结果。
但是在实际执行过程中，由于全量数据会越攒越多，那么每次对全量数据进行计算的代价和消耗会越来越大。
Structured Streaming 的做法是：
-
引入全局范围、高可用的 StateStore
-
转全量为增量，即在每次执行时：
-
先从 StateStore 里 restore 出上次执行后的状态
-
然后加入本执行的新数据，再进行计算
-
如果有状态改变，将把改变的状态重新 save 到 StateStore 里
-
-
为了在 Dataset/DataFrame 框架里完成对 StateStore 的 restore 和 save 操作，引入两个新的物理计划节点 —— StateStoreRestoreExec 和 StateStoreSaveExec
所以 Structured Streaming 在编程模型上暴露给用户的是，每次持续查询看做面对全量数据，但在具体实现上转换为增量的持续查询。
4. 故障恢复
通过前面小节的解析，我们知道存储 source offsets 的 offsetLog，和存储计算状态的 StateStore，是全局高可用的。仍然采用前面的示意图，offsetLog 和 StateStore 被特殊标识为紫色，代表高可用。
由于 exectutor 节点的故障可由 Spark 框架本身很好的 handle，不引起可用性问题，我们本节的故障恢复只讨论 driver 故障恢复。
如果在某个执行过程中发生 driver 故障，那么重新起来的 StreamExecution：
-
读取 WAL offsetlog 恢复出最新的 offsets 等；相当于取代正常流程里的 (1)(2) 步
-
读取 batchCommitLog 决定是否需要重做最近一个批次
-
如果需要，那么重做 (3a), (3b), (4), (5), (6a), (6b) 步
-
这里第 (5) 步需要分两种情况讨论
-
(i) 如果上次执行在 (5) 结束前即失效，那么本次执行里 sink 应该完整写出计算结果
-
(ii) 如果上次执行在 (5) 结束后才失效，那么本次执行里 sink 可以重新写出计算结果（覆盖上次结果），也可以跳过写出计算结果（因为上次执行已经完整写出过计算结果了）
-
-
这样即可保证每次执行的计算结果，在 sink 这个层面，是 不重不丢 的 —— 即使中间发生过 1 次或以上的失效和恢复。
5. Sources 、Sinks与 Exactly—once
可以看到，Structured Streaming 层面的 Source，需能根据 offsets 重放数据[2]。所以：
也可以看到，Structured Streaming 层面的 Sink，需能幂等式写入数据[3]。所以：
所以在 Structured Streaming 里，我们总结下面的关系[4]：
这里的 end-to-end 指的是，如果 source 选用类似 Kafka, HDFS 等，sink 选用类似 HDFS, MySQL 等，那么 Structured Streaming 将自动保证在 sink 里的计算结果是 exactly-once 的 —— Structured Streaming 终于把过去需要使用者去维护的 sink 去重逻辑接盘过去了！:-)
五、全文总结
自 Spark 2.0 开始，处理 structured data 的 Dateset/DataFrame 被扩展为同时处理 streaming data，诞生了 Structured Streaming。
Structured Streaming 以“无限扩展的表格”为编程模型，在 StreamExecution 实际执行中增量执行，并满足 end-to-end exactly-once guarantee.
在 Spark 2.0 时代，Dataset/DataFrame 成为主要的用户 API，同时满足 structured data, streaming data, machine learning, graph 等应用场景，大大减少使用者需要学习的内容，爽爽地又重新实现了一把当年的 "one stack to rule them all" 的理想。
扫一扫
1796
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
