Structured_Sink_容错语义 | 学习笔记

开发者学堂课程【大数据Spark2020版（知识精讲与实战演练）第五阶段：Structured_Sink_容错语义】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/692/detail/12159

Structured_Sink_容错语义

内容介绍

一．从 source 到 sink 的流程

二．错误恢复语义

三．Sink 的容错

 

一．从 source 到 sink 的流程

理解流程会了解到如何将错误恢复，有助于解决问题

 

1.StreamExecution

整体流处理器，从 source 捕获数据，把内容添加到 think 落地数据

2. Source

接口，有3种方法

（1）getoffset（） 获取当前访问进度

（2）getBatch（） 获取某一批次的数据

（3）commit（ ）  给出确认，将offset向前移动

3. Sink

接口

AddBatch（）处理批次，通过批次写入 kafka 等。

4. 过程

（1） 在每个 StreamExecution 的批次开始, StreamExecution 会向 Source 询问当前 Source 最新进度 ，即最新的 offset

（2） StreamExecution 将 Offset 放入 WAL  内

（3）StreamExecution 从 Source 获取 start offset, end offset 区间内的数据

（4）StreamExecution 触发计算逻辑 logicalPlan 的优化与编译

（5）计算结果写出给 Sink

调用 Sink. addBatch(batchId: Long, data: DataFrame) 完成

此时才会由 Sink 的写入操作 开始触发实际的数据获取和计算过程

5. 在数据完整写出到 Sink 后, StreamExecution 通知 Source 批次 id ;写入到 batchCommitLog, 当前批次结束。

 

二．错误恢复语义

1.目标和步骤

目标

理解 Structured Streaming 中提供的系统级别容错手段

步骤

（1）端到端

（2）三种容错语义

（3）Sink 的容错

2.端到端

Source 可能是 Kafka,HDFS

Sink 也可能是 Kafka,HDFS,MySQL 等存储服务

消息从 Source 取出，经过 Structured Streaming 处理，后落地到 Sink 的过程，叫做端到端

3.三种容错语义

（1）at-most-once

在数据从 Source 到 Sink 的过程中，出错了，（不能保证一定发送成功）Sink可能没收到数据，但是不会收到两次，叫做 at-most-once

一般错误恢复的时候，不重复计算，则是 at-most-once

(2) at-least-once

（不保证重复）

在数据从 Source 到 Sink 的过程中，出错了，Sink 定会收到数据，但是可能收到两次，叫做 at-least-once

一般错误恢复的时候，重复计算可能完成也可能未完成的计算，则是 at-least-once

3.exactly-once

在数据从 Source 到 Sink 的过程中，虽然出错了，Sink 定恰好收到应该收到的数据，一条不重复也一条都不少，即是 exactly-once

想做到 exactly-once 是非常困难的

 

三．Sink 的容错

故障恢复一般分为 Driver 的容错和 Task 的容错

1. Driver 的容错

指的是整个系统都挂掉了

2. Task 的容错

指的是一个任务没运行明白，重新运行一次

3.因为 Spark 的 ExeC 金 tor 能够非常好的处理 Task 的容错，以我们上要讨论Driver 的容错，如果出错的时候

(1)读取 WAL offsetlog 恢复出最新的 offsets

当 StreamExecution 找到 Source 获取数据的时候，会将数据的起始放在 WAL offsetlog 中，当出错受恢夏的时就可以从中获取当前处理批次的数据起始，例Kafka offset

(2)读取 batchCommitLog 决定是否需要重做近：个批次

当 Sink 处理完批次的数据写入时，公将当前的批次 ID 存入 batchCommitLog ,当出箭的时候家以从中取出进行到哪一个批次了，和 WL 对比即可得当前批次是否处理完

(3)如果有必要的话，当前批次数据重做

·如果上次执行在(5)结来前即失效，那么本次执行里 Sik 应该光整写出计算结果

·如果上次执行在(5)结束后才尖效，那么木次执行里 Sik 可以重新写出计算结果（覆盖上次结果），也可以跳过写出计算结果（因为上次执行已经完整写出过计算结果了）

这样即可保证每次执行的计算结果，在 Sink 这个层面，是不重不丢的，即使中问发生过失效和恢复，所以 Structured

Streaming 可以做到 exactly-once

4.容错所需要的存储

(1)存储

offsetlog 和 batchCommitLog 关于错误恢复

//记录当前批次出现的问题

offsetlog 和 batchCommitLog 需要存储在可靠的空间里

offsetlog 和 batchCommitLog 存储在 Checkpoint

WAL 其实也存在于 Checkpoint 中

//设置 Checkpoint 为容错

(2)指定 Checkpoint

只有指定了 Checkpoint 路径的时候，对应的容错功能才可以开启

5.需要的外部支持

如果要做到 exactly-once, 只是 Structured Streaming 能做到还不行，还需要Source 和 Sink 系统的支特

(1)Source 需要支持数据重放

当有必要的时候，Structured Streaming 需要根据 start 和 end offset 从 Source 系统中再次茯取数据，这叫做重放

(2)Sink 需要支持幂等写入

果需要重做整个批次的时候，Sik 要支持给定的 ID 写入数据，这叫幂等写入，一个ID 对应一条数据进行写入，如果前面已经写入，则替换或者丢充，不能重复

所以 Structured Streaming 想要做到 exactly-once, 则也需要外部系统的支持

6. Source

7.区别

Structured Streaming 是流式型，另一个是静态型