读Flink源码谈设计:Exactly Once

泊浮目
English
本文首发于泊浮目的语雀:https://www.yuque.com/17sing
版本日期备注
1.02022.2.2文章首发
1.02022.2.14更新3.4部分,增强注释部分
1.22022.2.27更新3.6部分,删除部分对于1.14版本不适的描述
1.32022.3.8fix typo
本文基于Flink 1.14代码进行分析。

0.前言

将Flink应用至生产已有一段时间,刚上生产的时候有幸排查过因数据倾斜引起的Checkpoint超时问题——当时简单的了解了相关机制,最近正好在读Flink源码,不如趁这个机会搞清楚。

在这里,我们首先要搞清楚两种Exactly-Once的区别:

  • Exactly Once:在计算引擎内部,数据不丢失不重复。本质是通过Flink开启检查点进行Barrier对齐,即可做到。
  • End to End Exactly Once:这意味着从数据读取、引擎处理到写入外部存储的整个过程中,数据都是不丢失不重复的。这要求数据源可重放,写入端支持事务的恢复和回滚或幂等。

1. 数据倾斜为什么会引起Checkpoint超时

做Checkpoint时算子会有一个barrier的对齐机制(为何一定要对齐后面会讲到)。以下图为例讲解对齐过程:

当两条边下发barrier时,barrier1比barrier2先到达了算子,那么算子会将一条边输入的元素缓存起来,直到barrier2到了做Checkpoint以后才会下发元素。

每个算子对齐barrier后,会进行异步状态存储,然后下发barrier。每个算子做完Checkpoint时,会通知CheckpointCoordinator。当CheckpointCoordinator得知所有算子的Checkpoint都做完时,认为本次Checkpoint完成。

而在我们的应用程序中,有一个map算子接受了大量数据,导致barrier一直没有下发,最终整个Checkpoint超时。

2. Checkpoint的原理

其具体原理可以参考Flink团队的论文:Lightweight Asynchronous Snapshots for Distributed Dataflow。简单来说,早期流计算的容错方案都是周期性做全局状态的快照,但这有两个缺点:

  • 阻塞计算——做快照时是同步阻塞的。
  • 会将当前算子未处理以及正在处理的record一起做进快照,因此快照会变得特别大。

而Flink是基于Chandy-Lamport 算法来扩展的——该算法异步地执行快照,同时要求数据源可重放,但仍然会存储上游数据。而Flink的方案提出的方案在无环图中并不会存储数据。

在Flink中(无环有向图),会周期性的插入Barrier这个标记,告知下游算子开始做快照。这个算法基于以下前提:

  • 网络传输可靠,可以做到FIFO。这里会对算子进行blockedunblocked操作,如果一个算子是blocked,它会把从上游通道接收到的所有数据缓存起来,直接收到unblocked的信号才发送。
  • Task可以对它们的通道进行以下操作:block, unblock, send messages, broading messages
  • 对于Source节点来说,会被抽象成Nil输入通道。

3. Checkpoint的实现

在Flink中,做Checkpoint大致由以下几步组成:

  1. 可行性检查
  2. JobMaster通知Task触发检查点
  3. TaskExecutor执行检查点
  4. JobMaster确认检查点

接下来,让我们跟着源码来看一下里面的具体实现。

3.1 可行性检查

参考代码:CheckpointCoordinator#startTriggeringCheckpoint

  1. 确保作业不是处于关闭中或未启动的状态(见CheckpointPlanCalculator#calculateCheckpointPlan)。
  2. 生成新的CheckpointingID,并创建一个PendingCheckpoint——当所有Task都完成了Checkpoint,则会转换成一个CompletedCheckpoint。同时也会注册一个线程去关注是否有超时的情况,如果超时则会Abort当前的Checkpoint(见CheckpointPlanCalculator#createPendingCheckpoint)。
  3. 触发MasterHook。部分外部系统在触发检查点之前,需要做一些扩展逻辑,通过该实现MasterHook可以实现通知机制(见CheckpointPlanCalculator#snapshotMasterState)。
  4. 重复步骤1,没问题的话通知SourceStreamTask开始触发检查点(见CheckpointPlanCalculator#triggerCheckpointRequest)。

3.2 JobMaster通知Task触发检查点

CheckpointPlanCalculator#triggerCheckpointRequest中,会通过triggerTasks方法调用到Execution#triggerCheckpoint方法。Execution对应了一个Task实例,因此JobMaster可以通过里面的Slot引用找到其TaskManagerGateway,发送远程请求触发Checkpoint。

3.3 TaskManager执行检查点

TaskManager在代码中的体现为TaskExecutor。当JobMaster触发远程请求至TaskExecutor时,handle的方法为TaskExecutor#triggerCheckpoint,之后便会调用Task#triggerCheckpointBarrier来做:

  1. 做一些检查,比如Task是否是Running状态
  2. 触发Checkpoint:调用CheckpointableTask#triggerCheckpointAsync
  3. 执行检查点:CheckpointableTask#triggerCheckpointAsync。以StreamTask实现为例,这里会考虑上游已经Finish时如何触发下游Checkpoint的情况——通过塞入CheckpointBarrier来触发;如果任务没有结束,则调用StreamTask#triggerCheckpointAsyncInMailbox。最终都会走入SubtaskCheckpointCoordinator#checkpointState来触发Checkpoint。
  4. 算子保存快照:调用OperatorChain#broadcastEvent:保存OperatorState与KeyedState。
  5. 调用SubtaskCheckpointCoordinatorImpl#finishAndReportAsync,:异步的汇报当前快照已完成。

3.4 JobMaster确认检查点

|-- RpcCheckpointResponder
  \-- acknowledgeCheckpoint
|-- JobMaster
  \-- acknowledgeCheckpoint
|-- SchedulerBase
  \-- acknowledgeCheckpoint
|-- ExecutionGraphHandler
  \-- acknowledgeCheckpoint
|-- CheckpointCoordinator
  \-- receiveAcknowledgeMessage

在3.1中,我们提到过PendingCheckpoint。这里面维护了一些状来确保Task全部Ack、Master全部Ack。当确认完成后, CheckpointCoordinator将会通知所有的Checkpoint已经完成。

|-- CheckpointCoordinator
  \-- receiveAcknowledgeMessage
  \-- sendAcknowledgeMessages  //通知下游Checkpoint已经完成。如果Sink实现了TwoPhaseCommitSinkFunction,将会Commit;如果因为一些原因导致Commit没有成功,则会抛出一个FlinkRuntimeException,而pendingCommitTransactions中的将会继续保存失败的CheckpointId,当检查点恢复时将会重新执行。

3.5 检查点恢复

该部分代码较为简单,有兴趣的同学可以根据相关调用栈自行阅读代码。

|-- Task
  \-- run
  \-- doRun
|-- StreamTask
  \-- invoke
  \-- restoreInternal
  \-- restoreGates
|-- OperatorChain
  \-- initializeStateAndOpenOperators
|-- StreamOperator
  \-- initializeState
|-- StreamOperatorStateHandler
  \-- initializeOperatorState
|-- AbstractStreamOperator
  \-- initializeState
|-- StreamOperatorStateHandler
  \-- initializeOperatorState
|-- CheckpointedStreamOperator
  \-- initializeState #调用用户代码

3.6 End to End Exactly Once

端到端的精准一次实现其实是比较困难的——考虑一个Source对N个Sink的场景。故此Flink设计了相应的接口来保障端到端的精准一次,分别是:

  • TwoPhaseCommitSinkFunction:想做精准一次的Sink必须实现此接口。
  • CheckpointedFunction:Checkpoint被调用时的钩子。
  • CheckpointListener:顾名思义,当Checkpoint完成或失败时会通知此接口的实现者。

目前Source和Sink全部ExactlyOnce实现的只有Kafka——其上游支持断点读取,下游支持回滚or幂等。有兴趣的同学可以阅读该接口的相关实现。

4. 小结

本文以问题视角切入Checkpoint的原理与实现,并对相关源码做了简单的跟踪。其实代码的线路是比较清晰的,但涉及大量的类——有心的同学可能已经发现,这是单一职责原则的体现。TwoPhaseCommitSinkFunction中的实现也是典型的模版方法设计模式。

阅读 1.6k

泊浮说
作者是个热爱分享交流的人,所以有了这个专栏。你的点赞是我最大的更新动力。

ZStack Committer、Flink Contributor,患有严重的代码洁癖症。致力于构建可靠、可维护、可扩展的软件系...

4.8k 声望
1.3k 粉丝
0 条评论

ZStack Committer、Flink Contributor,患有严重的代码洁癖症。致力于构建可靠、可维护、可扩展的软件系...

4.8k 声望
1.3k 粉丝
文章目录
宣传栏