Exactly Once语义在Flink中的实现|青训营笔记

子川
128 阅读5分钟

Flink中Exactly Once语义以及Check point的实现|青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第3天

一、复习前一天的主要知识点

1.Apache Flink的开源生态

  • 流批一体：支持流式计算和批式计算；
  • OLAP：Flink 可以支持 OLAP 这种短查询场景；
  • Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；
  • Gelly：图计算；
  • Stateful Function：支持有状态的 FAAS 场景；
  • ...

2.Flink支持流批一体和OLAP

（1）支持流批一体

  • 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。

（2）Flink做OLAP一体

  1. 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
  2. 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
  3. 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力；
    详见我的上一篇笔记Flink相关原理与实践|青训营笔记

二、在Flink实现Exactly Once语义以及Checkpoint

1.简单了解Exactly Once和Checkpoint

  • Application Consistency Guarantees: 作业一致性保证
    • At-most-once：每条数据消费至多一次
    • At-least-once：每条数据消费至少一次
    • Exactly-once: 每条数据都被消费且仅被消费一次
  • Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
  • Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
  • Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
  • JobManager: 负责协调和管理 Checkpoint

2.数据流和动态表

动态表：随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们

实时流的查询特点： 查询不终止，查询会不断更新 并产生一个新的动态表，这张表也可以转化成输出的实时流

动态表转化实时流

  • Append-only Stream: Append-only 流（只有 INSERT 消息）
  • Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息） image.png
  • Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息） image.png 数据流到动态表转换关系图 image.png

3.Exactly Once和Checkpoint

（1）一致性保证语义

  • At-most-once：每条数据消费至多一次，处理延迟低
  • At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
  • Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生

（2）Checkpoint

  • Checkpoint barrier 的下发
  • 算子状态制作和 barrier 传递
  • 多个上游的等待 barrier 对齐现象
  • Checkpoint 并不阻塞算子数据处
  • Checkpoint ACK和制作完成

checkpoint是flink用于持久化flink状态的机制 flink会定时将flink计算的状态持久化到hdfs中
开启checkpint的方法

// 每 1000ms 开始一次 checkpoint
env.enableCheckpointing(1000)
// 高级选项：
// 设置模式为精确一次 (这是默认值)
env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
// 确认 checkpoints 之间的时间会进行 500 ms
env.getCheckpointConfig.setMinPauseBetweenCheckpoints(500)
// Checkpoint 必须在一分钟内完成，否则就会被抛弃
env.getCheckpointConfig.setCheckpointTimeout(60000)
// 允许两个连续的 checkpoint 错误
env.getCheckpointConfig.setTolerableCheckpointFailureNumber(2)
// 同一时间只允许一个 checkpoint 进行
env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)
// 使用 externalized checkpoints，这样 checkpoint 在作业取消后仍就会被保留
//RETAIN_ON_CANCELLATION: 当任务取消时保留checkpoint
env.getCheckpointConfig.setExternalizedCheckpointCleanup(
ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION)
//指定状态后端
//EmbeddedRocksDBStateBackend eocksDb状态后端
env.setStateBackend(new EmbeddedRocksDBStateBackend(true))
//将状态保存到hdfs中，在触发checkpoint的时候将状态持久化到hdfs中
env.getCheckpointConfig.setCheckpointStorage("hdfs://master:9000/flink/checkpoint")

从Checkpoint恢复任务

//可以在网页中指定checkpint的路径恢复,路径需要带上前缀hdfs://master:9000
hdfs://master:9000/flink/checkpoint/11edbec21742ceddebbb90f3e49f24b4/chk-35
//也可以在命令行中重新提交任务，指定恢复任务的位置, 需要先上传jarr包
# -s 恢复任务的位置
flink run -t yarn-session -Dyarn.application.id=application_1658546198162_0005  -c com.shujia.flink.core.Demo15RocksDB -s hdfs://master:9000/flink/checkpoint/11edbec21742ceddebbb90f3e49f24b4/chk-35 flink-1.0.jar

推荐
了解有状态API
状态后端
有状态流处理
及时流处理

(3)端到端 Exactly-Once 实现

  • 两阶段提交协议（2PC）
  • oordinator：协作者，同步和协调所有节点处理逻辑的中心节点
  • Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点
    两阶段提交协议在Flink中的应用
  • Flink 中协作者和参与者的角色分配
  • 协作者（JobManager）发起阶段一提交
  • 各算子 Checkpoint 的制作
  • 提交阶段及 Checkpoint 的制作完成

三、总结

在这节课上主要认识了Flink中Checkpoint和Exactly Once语义的是怎样实现的，也了解了两阶段提交协议的过程，以及参与者和协调者是如何变更状态的。主要还是需要理解，这些协议语义是如何作用于Flink中。

推荐文章
两阶段协议

参考文章：
青训营学员手册
Checkpoint
个人笔记

ps:笔记记的很早发布的较晚

avatar
文章
阅读
粉丝