未能找到元数据文件_Flink 源码：Checkpoint 元数据详解

本文是 Flink 源码解析系列，通过阅读本文你能 get 到以下点：

• Flink 任务从 Checkpoint 处恢复流程概述
• Checkpoint 元数据详解
• 从源码层分析：JM 该如何合理地给每个 subtask 分配 State，让 TM 去恢复

❝

声明：笔者的源码分析都是基于 flink-1.9.0 release 分支，其实阅读源码不用非常在意版本的问题，各版本的主要流程基本都是类似的。如果熟悉了某个版本的源码，之后新版本有变化，我们重点看一下变化之处即可。

笔者阅读源码中会加很多中文注释，对源码感兴趣且有需要的同学可以关注一下笔者的 github 仓库：https://github.com/1996fanrui/flink/tree/feature/source-code-read-1-9-0

注释都在 feature/source-code-read-1-9-0 分支，之后也会持续更新

❞

阅读本文之前，强烈建议阅读《从 KeyGroup 到 Rescale》，本文讲述 KeyedState 恢复时需要用到 KeyGroup 相关知识。

一、Job 从 Checkpoint 处恢复流程概述

Flink 任务从 Checkpoint 或 Savepoint 处恢复的整体流程简单概述，如下所示：

• 首先客户端提供 Checkpoint 或 Savepoint 的目录
• JM 从给定的目录中找到 _metadata 文件(Checkpoint 的元数据文件)
• JM 解析元数据文件，做一些校验，将信息写入到 zk 中，然后准备从这一次 Checkpoint 中恢复任务
• JM 拿到所有算子对应的 State，给各个 subtask 分配 StateHandle(状态文件句柄)
• TM 启动时，也就是 StreamTask 的初始化阶段会创建 KeyedStateBackend 和 OperatorStateBackend
• 创建过程中就会根据 JM 分配给自己的 StateHandle 从 dfs 上恢复 State

由上述流程可知，Flink 任务从 Checkpoint 恢复不只是说 TM 去 dfs 拉状态文件即可，需要 JM 先给各个 TM 分配 State，由于牵扯到修改并发，所以 JM 端给各个 subtask 分配 State 的流程也是比较复杂的。本系列源码分析会陆续分析上述所有列出的流程，东西比较多。

本文从 Checkpoint 的元数据入手开始分析，同时分析一下 JM 拿到 Checkpoint 元数据后该如何合理地给每个 subtask 分配 State，让 TM 去恢复。

二、 Checkpoint 元数据介绍

开始介绍 Checkpoint 元数据，这里是从元数据的设计角度来分析。后期在分析 Checkpoint 过程的源码时，会详细介绍这些元数据是如何一步步生成的。

Checkpoint 完整的元数据

CompletedCheckpoint 封装了一次 Checkpoint 完整的元数据信息，CompletedCheckpoint 类包含的属性如下所示：

public class CompletedCheckpoint implements Serializable {
    
 private final JobID job;
 private final long checkpointID;
 private final long timestamp;
 private final long duration;

 /** 本次 Checkpoint 中每个算子的 ID 及算子对应 State 信息 */
 private final Map operatorStates;private final CheckpointProperties props;private final Collection masterHookStates;// Checkpoint 存储路径private final CompletedCheckpointStorageLocation storageLocation;// 元数据句柄private final StreamStateHandle metadataHandle;// Checkpoint 目录地址private final String externalPointer;private transient volatile CompletedCheckpointStats.DiscardCallback discardCallback;
}

CompletedCheckpoint 类的大部分属性都是见名之意的，重要的属性就是本次 Checkpoint 中每个算子的 OperatorID 及算子对应 State 信息。再次强调源码中的 OperatorState 这个类不是 Flink 中常说的 OperatorState，而是指代 Operator 算子对应的 State 信息。

算子级别的元数据

OperatorState 类的属性如下所示：

public class OperatorState implements CompositeStateHandle {
    
 private final OperatorID operatorID;
  
 // checkpoint 时算子的并行度
 private final int parallelism;

 // checkpoint 时算子的 maxParallelism
 private final int maxParallelism;

 // 当前 Operator 算子内，每个 subtask 持有的 State 信息，
 // 这里 map 对应的 key 为 subtaskId，value 为 subtask 对应的 State,
 // OperatorState 表示一个 算子级别的，OperatorSubtaskState 是 subtask 级别的。
 // 如果一个算子有 10 个并行度，那么 OperatorState 有 10 个 OperatorSubtaskState
 private final Map operatorSubtaskStates;
}

OperatorState 中包含算子对应的 OperatorID，checkpoint 时算子的并行度和 maxParallelism。

❝

注：这里专门强调是 Checkpoint 时的并行度和 maxParallelism，因为这个 OperatorState 本来就是从 Checkpoint 中恢复出来的，所以这些元数据都属于 Checkpoint 发生时 Job 的一些属性。

有可能新运行的 Job 调整了算子的并行度，当然如果新 Job 的 maxParallelism 发生变化而且是人为设定，任务是无法恢复的(至于为什么无法恢复，前面的源码已经分析过了)。

❞

OperatorState 中还使用一个 Map 保存当前 Operator 算子内每个 subtask 持有的 State 信息，这里 map 对应的 key 为 subta