首页 > 其他分享 >Flink 中 Checkpoint 的底层原理和机制

Flink 中 Checkpoint 的底层原理和机制

时间:2024-09-20 17:23:09浏览次数:12  
标签:状态 存储 快照 Barrier Flink Checkpoint 底层

        Flink 的 Checkpoint 机制是 Apache Flink 在流式处理中的一个核心特性,保证了分布式数据流处理系统的 容错性。通过定期保存 状态快照(checkpoint),即使在发生故障时,Flink 也可以恢复到之前的状态,确保处理的正确性。

为了全面解释 Flink 的 Checkpoint 底层实现,下面将从 Checkpoint 的基本原理、核心组件、执行流程以及与存储和恢复的交互细节,乃至涉及的底层代码框架等多个方面展开。

1. 基本原理

        在 Flink 中,Checkpoint 机制的基本原理是通过周期性地对流式处理中的状态进行 快照,确保在节点故障或应用重启时能够恢复到最近一次的 Checkpoint,从而保证数据的一致性和任务的进度。

        Flink 的流处理是基于有状态的操作,如窗口操作、聚合函数等,这些操作需要保存中间结果(状态)。如果发生故障,Flink 通过从最近一次 Checkpoint 恢复状态,重新处理未完成的流数据。

1.1 Flink 中的 Checkpoint 与容错模型

        Flink 使用一种叫 “Chandy-Lamport 算法”(分布式系统中的一致性快照算法)来进行容错。这个算法的思想是通过发送特殊的标记事件(称为 Barrier)来标记流处理的不同阶段,从而确保在整个分布式拓扑中保存一致性的快照。

  • Barrier 是 Checkpoint 的关键,它在数据流中被插入,用于划分不同的 Checkpoint,并将每个 Checkpoint 与其后的处理数据隔离开。
  • 每当 Checkpoint 触发时,Flink 会向所有数据源发出一个 Barrier 信号,表示应该开始记录快照。
  • 每个算子(operator)在接收到 Barrier 时,会将其内部状态保存在 Checkpoint 存储中。

2. 核心组件

        Flink 的 Checkpoint 底层实现由多个核心组件组成,包括 Checkpoint CoordinatorState BackendBarrierSource FunctionOperator、以及 Task 等。每个组件在 Checkpoint 的创建、传播、存储以及恢复过程中扮演重要角色。

2.1 Checkpoint Coordinator(检查点协调器)
  • 作用:负责管理整个 Checkpoint 流程的协调工作。包括:

    1. 定期触发 Checkpoint 事件。
    2. 向所有的源算子发出 Barrier。
    3. 收集各个算子的 Checkpoint 成果。
    4. 处理故障恢复,基于 Checkpoint 恢复各个算子的状态。
  • 触发:通过 CheckpointCoordinator#triggerCheckpoint() 触发新的 Checkpoint,生成新的 CheckpointMetaData,并通过 RpcGateway 向所有 Task 发送 Checkpoint 触发指令。

源代码解析:

   CheckpointCoordinator 是 Flink 容错机制的核心类,代码位于 org.apache.flink.runtime.checkpoint 包中。其主要功能是触发和协调 Checkpoint 过程,并确保所有算子正确保存其状态。

public class CheckpointCoordinator {

    public CompletableFuture<CompletedCheckpoint> triggerCheckpoint(
        CheckpointTriggerRequest triggerRequest) {
        // 触发 Checkpoint 相关操作
        return triggerCheckpointInternal(
            triggerRequest,
            false,
            System.currentTimeMillis());
    }
}
2.2 State Backend(状态后端)
  • 作用:负责存储和管理 Flink 的有状态算子的状态。可以通过以下三种方式进行存储:

    1. MemoryStateBackend:状态存储在内存中,适合小规模状态的应用。
    2. FsStateBackend:将状态存储在分布式文件系统(如 HDFS)中。
    3. RocksDBStateBackend:将状态存储在本地 RocksDB 数据库中,适用于大规模状态。
  • 每个 Task 在执行时,会使用 StateBackend 来管理和存储状态,并在收到 Checkpoint Barrier 后,将当前状态存储到持久化存储中。

源代码解析:

   StateBackend 接口及其实现类位于 org.apache.flink.runtime.state 包中,以下是 FsStateBackend 的代码片段:

public class FsStateBackend implements StateBackend {
    private final Path checkpointBasePath;

    @Override
    public CompletedCheckpointStorageLocation resolveCheckpoint(String checkpointPointer) throws IOException {
        // 状态存储在分布式文件系统中
        return new FsCompletedCheckpointStorageLocation(checkpointBasePath);
    }
}

2.3 Barrier(屏障)
  • 作用:作为 Checkpoint 流程中的同步机制,Barrier 是 Flink 的 Checkpoint 触发时在数据流中插入的特殊事件。Barrier 用于确保算子的状态在快照时刻的一致性。
  • Barrier 从源任务开始,沿着数据流传播。当一个算子接收到 Barrier 时,会暂停处理后续数据,进行状态保存,并将 Barrier 传递给下游算子。
源代码解析:

Barrier 是 Flink 的 StreamBarrier,代码位于 org.apache.flink.runtime.io.network.api 包中。

public class CheckpointBarrier extends AbstractEvent {
    private final long id;  // Checkpoint ID
    private final long timestamp;

    public CheckpointBarrier(long id, long timestamp) {
        this.id = id;
        this.timestamp = timestamp;
    }
}

2.4 Source Function
  • 作用:数据源(Source)是 Flink 数据处理任务的起点,负责生成并向下游发送数据记录。Source 还负责在 Checkpoint 过程中保存其自身状态(如读取的偏移量等),以便在故障发生时能够从相同的偏移量继续处理。
  • 当 CheckpointCoordinator 触发 Checkpoint 时,Source 也会记录自身状态。

3. 执行流程

Flink 的 Checkpoint 流程涉及多个阶段,从 Checkpoint 触发到状态存储的完成,具体流程如下:

3.1 Checkpoint 触发
  • CheckpointCoordinator 定期触发 Checkpoint,通过 RPC 向所有任务的执行单元发送 Barrier
  • 源任务收到 Checkpoint 触发请求后,会在数据流中插入 Barrier
3.2 Barrier 传播
  • Barrier 从源任务开始向下游传播,每个任务节点接收到 Barrier 后会将自身状态快照记录到状态后端(State Backend),然后将 Barrier 发送给下游任务。
3.3 状态保存
  • 每个有状态的任务(如 Window、KeyedState 等)在接收到 Barrier 时会触发状态快照的存储。
  • 快照可以是:
    • 内存快照:存储在内存中的状态。
    • 持久化存储:存储在分布式文件系统或 RocksDB 中的状态。
3.4 Checkpoint 完成
  • 当 CheckpointCoordinator 收到所有任务的状态保存结果后,会将这次的 Checkpoint 记录为 CompletedCheckpoint,标志着一次 Checkpoint 的成功完成。
  • 如果某个任务在 Checkpoint 过程中失败,Flink 会自动回滚到上一次成功的 Checkpoint,并重新处理故障期间的数据。

4. 故障恢复与 Checkpoint 恢复

当 Flink 任务发生故障时,Flink 会从最近一次成功的 Checkpoint 恢复。

4.1 恢复过程
  • Flink 的 CheckpointCoordinator 在故障恢复时会选择最新的 Checkpoint,并将该 Checkpoint 中保存的状态分发给相应的任务。
  • 每个任务从其对应的状态开始恢复,并且从保存的偏移量开始重新读取数据源。
4.2 状态恢复
  • 恢复时,各任务会从 State Backend 中获取之前保存的状态,Source 也会恢复到上次保存的偏移量。
  • 状态恢复后,任务重新开始处理数据,确保系统容错。

5. 底层代码结构分析

Flink 的 Checkpoint 实现分布在多个包中,主要涉及的类和接口包括:

  • CheckpointCoordinator:负责管理和触发 Checkpoint。
  • StateBackend:管理和存储任务的状态。
  • CheckpointBarrier:在数据流中插入的特殊事件,用于标识 Checkpoint 的边界。
  • CompletedCheckpoint:记录成功完成的 Checkpoint。

Flink 的 Checkpoint 机制核心代码位于 org.apache.flink.runtime.checkpoint 包中,负责协调、存储和恢复 Checkpoint 的逻辑。

总结

        Flink 的 Checkpoint 机制通过使用 Barrier 同步算法状态后端分布式协调 等底层组件来实现流式处理中的容错性。Flink 的 Checkpoint Coordinator 负责协调整个 Checkpoint 流程,Barrier 用于确保全局的一致性,而 State Backend 则负责存储各个算子的状态。在故障恢复时,Flink 能够通过最近一次的 Checkpoint 恢复状态,确保数据处理的正确性和一致性。

标签:状态,存储,快照,Barrier,Flink,Checkpoint,底层
From: https://blog.csdn.net/goTsHgo/article/details/142375827

相关文章

  • flink 启动Job加载外部jar都有哪些方法?
    flink启动Job加载外部jar都有哪些方法在ApacheFlink版本中,启动Job时加载外部Jar包有几种不同的方法。这些方法允许用户引入自定义的UDF(用户定义函数)或其他依赖项。以下是几种常见的方法:1.使用flinkrun命令直接启动你可以通过命令行工具flinkrun来指定你的Job......
  • 如何基于Flink CDC与OceanBase构建实时数仓,实现简化链路,高效排查
    本文作者:阿里云FlinkSQL负责人,伍翀,ApacheFlinkPMCMember&Committer众多数据领域的专业人士都很熟悉ApacheFlink,它作为流式计算引擎,流批一体,其核心在于其强大的分布式流数据处理能力,同时巧妙地融合了流计算与批计算的能力,因此成为了众多企业在进行流式计算业务时的首......
  • 集合框架底层使用了什么数据结构
    1.是什么        集合框架(CollectionFramework)是Java标准库的一部分,它提供了一系列接口和实现类,用于处理不同类型的集合。这些集合可以用于存储和操作对象,如列表、集合、映射等。集合框架的底层数据结构是多种多样的,具体取决于集合实现类的选择。1.List(列表)Array......
  • Flink-cdc丢失数据排查
    一、获取任务信息任务id:i01f51582-d8be-4262-aefa-000000任务名称:ods_test1234丢失的数据时间:2024-09-1609:28:47 二、数据同步查看日志1、筛选日志筛选2024-09-1609:28:47到5分钟后数据2、查找快照id,筛选内容Committedsnapshot7258609197164498019(BaseRowDelt......
  • 大数据-128 - Flink 并行度设置 细节详解 全局、作业、算子、Slot
    点一下关注吧!!!非常感谢!!持续更新!!!目前已经更新到了:Hadoop(已更完)HDFS(已更完)MapReduce(已更完)Hive(已更完)Flume(已更完)Sqoop(已更完)Zookeeper(已更完)HBase(已更完)Redis(已更完)Kafka(已更完)Spark(已更完)Flink(正在更新!)章节内容上节我们完成了如下的内容:ManageOperatorStateStateBackendCheckpoint......
  • 大数据-124 - Flink State 01篇 状态原理和原理剖析:状态类型 执行分析
    点一下关注吧!!!非常感谢!!持续更新!!!目前已经更新到了:Hadoop(已更完)HDFS(已更完)MapReduce(已更完)Hive(已更完)Flume(已更完)Sqoop(已更完)Zookeeper(已更完)HBase(已更完)Redis(已更完)Kafka(已更完)Spark(已更完)Flink(正在更新!)章节内容上节我们完成了如下的内容:Flink并行度Flink并行度详解Flink并行度......
  • 大数据-123 - Flink 并行度 相关概念 全局、作业、算子、Slot并行度 Flink并行度设置
    点一下关注吧!!!非常感谢!!持续更新!!!目前已经更新到了:Hadoop(已更完)HDFS(已更完)MapReduce(已更完)Hive(已更完)Flume(已更完)Sqoop(已更完)Zookeeper(已更完)HBase(已更完)Redis(已更完)Kafka(已更完)Spark(已更完)Flink(正在更新!)章节内容上节我们完成了如下的内容:FlinkTimeWatermarkJava代码实例测试简单介......
  • 【编程底层原理】Java执行CAS后底层由谁执行cmpxchg指令?CPU?是否会导致从用户态切换
    Java中的CAS操作是由Java虚拟机(JVM)提供的原子类实现的,这些原子类利用了底层硬件的CAS指令,比如x86架构中的cmpxchg指令。以下是这个过程的一些关键点:原子类封装:Java的java.util.concurrent.atomic包提供了一系列的原子类,如AtomicInteger、AtomicLong等,它们封装了CAS操作,使得......
  • 到底什么是黑洞路由?底层原理是什么?
    什么是黑洞路由?黑洞路由(BlackholeRouting)是一种网络管理技术,用于处理不希望到达目的地的网络流量。当网络设备(如路由器或交换机)接收到指向黑洞路由的流量时,这些流量会被丢弃,不会被转发到任何实际的目的地。黑洞路由通常用于应对网络攻击(如DDoS攻击)或其他不希望的流量。黑......
  • 密码哈希竞赛是干什么的?底层原理是什么?
    密码哈希竞赛(PasswordHashingCompetition,PHC)密码哈希竞赛(PHC)是一个旨在推动开发更安全的密码哈希算法的国际性竞赛。这项竞赛始于2013年,目标是为了找到一种更好的方法来保护存储的密码,尤其是在大规模数据泄露事件中保护用户的密码安全。PHC的背景传统的密码哈希算法,......