Flink｜《Flink 官方文档 - Operators - 状态与容错 - 大状态与 Checkpoint 调优》学习笔记

学习文档：《Flink 官方文档 - Operators - 状态与容错 - 大状态与 Checkpoint 调优》

学习笔记如下：

Flink 应用想要在大规模场景下可靠地运行，必须要满足如下两个条件：

• 应用程序需要能够可靠地创建 checkpoints
• 在应用故障后，需要有足够的资源追赶数据输入流

  监控状态和 Checkpoints

  • 算子收到第一个 checkpoint barrier 的时间：当触发 checkpoint 的耗费时间一直很高时，说明 checkpoint barrier 需要很长时间爱你才能从 source 到达 operators，这通常说明系统处于反压下运行。
  • Alignment Duration，在处理第一个和最后一个 checkpoint barrier 之间的时间：在非对齐 checkpoint 下，精确一次和至少一次语义的 checkpoint 的 subtask 处理来自上游 subtasks 的所有数据，不会有任何中断。但是多余精确一次语义的的对齐 checkpoint， 已经收到 checkpoint barrier 的通道会被阻止继续发送数据，直到所有剩余的通道都赶上并接收到它们的 checkpoint barrier。

    理想状态下，这两个值都应该很低。较高的数值意味着由于存在反压，导致 checkpoint barriers 在作业中的移动速度较慢，这会导致端到端延迟增加。需要注意的是，在出现瞬态反压、数据倾斜或网络问题时，这些数据偶尔会很高。

    使用不对齐的 checkpoints 可用于加快 checkpoint barriers 的传播，但是并不能解决导致反压的根本问题，即端到端记录延迟仍然很高。

    checkpoint 调优

    应用程序可以配置定期触发 checkpoint。当 checkpoint 完成时间超过 checkpoint 间隔时，在正在进行的 checkpoint 完成之前，不会触发下一个 checkpoint。

    当 checkpoint 完成时间爱你经常超过 checkpoint 基本间隔时，系统将不断地进行 checkpoint。这可能意味着过多的资源被不断地束缚在 checkpointing 中，这种情况对使用 checkpointed 状态的流式应用程序的影响较小，但可能对整体应用程序性能产生应吸纳过。

    为防止这种情况，应用程序可以定义 checkpoint 之间的最小等待时间：

    【配置】定义 checkpoint 之间的最小等待时间

    StreamExecutionEnvironment.getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds);
    

    此持续时间是指从最近一个 checkpoint 结束到下一个 checkpoint 开始之间必须经过的最小时间间隔。如下图：

    

    可以配置应用程序允许同时进行多个 checkpoint。对于 Flink 中状态较大的应用程序，这通常会使用过多的资源到 checkpointing。当手动触发 savepoint 时，它可能与正在进行的 checkpoint 同时进行。

    RocksDB 调优

    增量 checkpoint

    在减少 checkpoints 花费的时间方面，开启增量 checkpoint 应该是首选方案。与完整 checkpoint 相比，增量 checkpoint 可以显著减少 checkpointing 时间，因为增量 checkpoint 仅存储与先前完成的 checkpoint 不同的增量文件，而不是存储全量数据备份。

    将计时器存储到 JVM 堆中

    当作业只有少量计时器时时（没有窗口，且在 ProcessFunction 中不使用计时器），将这些计时器放在堆中可以提高性能。但需要谨慎使用此功能，因为基于堆的计时器可能会增加 checkpointing 时间，并且自然无法扩展到内存之外。

    RocksDB 内存调优

    RocksDB State Backend 的性能在很大程度上取决于它可用的内存量，增加内存在很大程度上可以提高其性能。

    在默认情况下，RocksDB State Backend 将 Flink 的托管内存用于 RocksDB 的缓冲区和缓存。以下是关于 RocksDB 内存调优相关的方法：

    • 尝试提高性能的第一步应该是增加托管内存的大小。在容器、进程规模较大的情况下，这通常会大大提升性能，而不需要通过调整 RocksDB 的递增参数引入复杂性。除非应用程序本身逻辑需要大量的 JVM 堆，否则大部分总内存通常都可以用于 RocksDB。默认的托管内存比例 (0.4) 时保守的，当 TaskManager 的内存为很多 GB 时，通常是可以增加托管内存比例。
    • 在 RocksDB 中，写缓冲区的数量取决于应用程序中所拥有的状态数量（数据流中所有算子的状态）。每个状态对应一个列族。因此，具有多状态的应用程序通常需要更多的内存才能获得相同的性能。
    • 可以尝试设置 state.backend.rocksdb.memory.managed: false 来使用列族内存的 RocksDB 与使用托管内存的 RocksDB 的性能对比。与使用托管内存（固定内存池）相比，不使用托管内存意味着 RocksDB 分配的内存与应用程序中的状态数成比例。根据经验，非托管模式的上限约为 140MB * 跨所有 tasks 的状态 * slots 个数。计时器也算作状态。
    • 如果应用程序有许多状态，并且存在频繁的 MemTable 刷新（即写端瓶颈）；在不能给 RocksDB 提供更多内存的前提下，可以增加写缓冲区的内存比例。
    • 可以通过 RocksDBOptionFactory 来调整 RocksDB 的列族选项（块大小、最大后台刷新线程等），以减少具有多种状态的 MemTable 刷新次数。

      示例：设置 RocksDB 的后天刷新线程以及块大小的样例。

      public class MyOptionsFactory implements ConfigurableRocksDBOptionsFactory {
          @Override
          public DBOptions createDBOptions(DBOptions currentOptions, Collection handlesToClose) {
              // increase the max background flush threads when we have many states in one operator,
              // which means we would have many column families in one DB instance.
              return currentOptions.setMaxBackgroundFlushes(4);
          }
          @Override
          public ColumnFamilyOptions createColumnOptions(
              ColumnFamilyOptions currentOptions, Collection handlesToClose) {
              // decrease the arena block size from default 8MB to 1MB. 
              return currentOptions.setArenaBlockSize(1024 * 1024);
          }
          @Override
          public OptionsFactory configure(ReadableConfig configuration) {
              return this;
          }
      }
      

      容量规划

      容量规划：确定 Flink 作业应该使用多少资源才能可靠地运行。容量规划的基本经验法则如下：

      • 应该有足够的资源保障正常运行时不出现反压。
      • 在无故障时间内无反压运行程序所需的资源之上，能够提供一些额外的资源。这些资源用来 “追赶” 在应用程序恢复期间积累的输入数据。这通常取决于恢复操作需要多长时间以及故障恢复的速度。
      • 在负载峰值、追赶阶段或外部系统出现临时减速时，临时反压通常是允许的。
      • 在某些操作下（如大窗口）会导致其下游算子的负载激增：在有窗口的情况下，下游算子可能在构建窗口时几乎无事可做，而在触发窗口时有负载要做。下游并行度的规划需要考虑窗口的输出量以及处理这种峰值的速度。

        为了方便以后增加资源，需确保流应用程序的最大并行度设置为一个合理的数字，因为最大并行度定义了当使用 savepoint 扩缩容程序时可以设置的程序并行度的上限。这是因为 Flink 的内部以键组（key groups）的最大并行度为粒度跟踪分布式状态。

        压缩

        Flink 为所有的 checkpoint 和 savepoint 提供可选的压缩。目前，压缩总是使用 snappy 压缩算法。压缩作用于 keyed state 下 key-groups 的粒度，即每个 key-groups 可以单独解压缩。

        【配置】开启压缩

        ExecutionConfig executionConfig = new ExecutionConfig();
        executionConfig.setUseSnapshotCompression(true);
        

        压缩选项对增量快照没有影响，因为它们使用的是 RocksDB 的内部格式，该格式始终使用 snappy 压缩。

        Task 本地恢复

        在 Flink 的 checkpointing 中，每个 task 都会生成其状态快照，然后将其写入分布式存储。每个 task 通过发送一个描述分布式存储中的位置状态的句柄，向 jobmanager 确认状态的成功写入。JobManager 收集所有 tasks 的句柄并将它们绑定到一个 checkpoint 对象中。在恢复时，JobManager 打开最新的 checkpoint 对象并将句柄发送回相应的 tasks，然后可以从分布式存储中恢复它们的状态。

        在这里使用分布式存储来存储状态由两个重要的优势：

        • 存储是容错的
        • 分布式存储中的所有状态都可以被所有节点访问，并且可以很方便地重新分配（用于重新扩缩容）

          但是使用分布式存储状态也有一个很大的缺点，即所有 tasks 都必须通过网络从远程位置读取它们的状态。在许多场景中，恢复可能会将失败的 tasks 重新调度到与前一次运行相同的 TaskManager 中，但我们仍然必须读取远程状态。这可能导致大状态的恢复时间较长。

          针对这个问题，Flink 提出了 Task 本地状态恢复的方案。其主要思想如下：对于每个 checkpoint，每个 task 不仅将 task 状态写入分布式存储中，而且还在 task 本地存储中保存状态快照的次要副本。对于每个 task 可以重新调度到之前的位置进行恢复的 task，我们可以从本地的次要副本中恢复，从而避免远程读取状态的成本。

          许多故障并不是节点故障，即使是节点故障通常一次也只影响一个或非常少的节点，在恢复过程中，大部分 task 很可能会重新部署到它们以前的位置，使用它们的本地状态存储。这就是 task 本地恢复能够有效地减少恢复时间的原因。

          在每个 checkpoint 创建和存储次要本地状态副本时，可能会有一些额外的成本。

          

          主要（分布式存储）和次要（task 本地）状态快照的关系

          Task 本地的状态会被始终视为次要副本，checkpoint 状态始终以分布式存储中的副本为主。

          • 对于 checkpointing，主副本必须成功，次要副本生成失败则不会使 checkpoint 失败。
          • 只有主副本由 JobManager 确认和管理，次要副本属于 TaskManager，并且它们的生命周期可以独立于主副本。例如，可以保留 3 个最新的 checkpoint 的主副本而只保留最新 checkpoint 的次要副本。
          • 对于恢复，如果匹配的次要副本可用，则 Flink 将始终首先尝试从 task 本地状态恢复。如果在次要副本恢复过程中发现任何问题，Flink 将重试从主副本恢复 task。仅当主副本失败时，恢复才会失败。在这种情况下，根据配置，Flink 仍可能回退到旧的 checkpoint。
          • Task 本地副本可能仅包含完整 task 状态的一部分（例如写入一个本地文件时出现异常）。在这种情况下，Flink 会首先尝试在本地恢复部分，非本地状态从主副本恢复。主状态必须始终是完整的，并且是 task 本地状态的超集。
          • Task 本地状态具有与主状态不同的格式，它们不需要相同字节。例如，task 本地状态甚至可能是在堆对象组成的内存中，而不是存储在任何文件中。
          • 如果 TaskManager 丢失，则其所有 task 的本地状态都会丢失。

            配置 task 本地恢复

            Task 本地恢复默认禁用，可以通过 Flink 的 CheckpointingOptions.LOCAL_RECOVERY 配置中指定的键 state.backend.local-recovery 来启用。设置为 true 时启用，false 时禁用。

            目前，非对齐 checkpoint 不支持 task 本地恢复。

            不同的 State Backend 的 Task 本地恢复

            目前，task 本地恢复仅涵盖 keyed state backends。通常来说，keyed state 时状态的最大部分。在将来，Flink 还将支持算子状态和计时器（Timers）。

            • HashMapStateBackend：支持 keyed state 的 task 本地恢复。在实现上，会将状态复制到本地文件。这会引入额外的写入成本并占用本地磁盘空间。将来，Flink 可能还会提供一种将 task 本地状态保存在内存中的实现。
            • EmbeddedRocksDBStateBackend：支持 keyed state 的 task 本地恢复。对于全量 checkpoints，状态被复制到本地文件。这会引入额外的写入成本并占用本地磁盘空间。对于增量快照，本地状态基于 RocksDB 的原生 checkpointing 机制；这种机制也被用作创建主副本的第一步，这意味着在这种情况下，创建次要副本不会引入额外的成本，我们只是保留本地 checkpoint 目录，而不是在上传到分布式存储后将其删除。这个本地副本可以与 RocksDB 的工作目录共享现有文件（通过硬链接），因此对于现有文件，增量快照的 task 本地恢复也不会消耗额外的磁盘空间。使用硬链接还意味着 RocksDB 目录必须与所有可用于存储本地状态和本地恢复目录位于同一节点上，否则建立硬链接可能会失败（参见 FLINK-10954）。目前，当 RocksDB 目录配置在多个物理设备上时，这也会阻止使用本地恢复。

              Allocation-preserving 调度

              Task 本地故障恢复通过 allocation-preserving 调度 task，其工作原理如下：每个 task 都会记住其先前的分配，并请求完全相同的 slot 来重新启动恢复。如果此 slot 不可用，task 将向 resourceManager 请求一个新的 slot。这样，如果 TaskManager 不再可用，则无法返回其先前位置的 task 不会将其他正在恢复的 task 踢出之前的 slot。

              这样做的理由是，只有当 TaskManager 不再可用时，前一个 slot 才会消失，在这种情况下，一些 tasks 无论如何都必须请求新的 slot。

              通过以上调度策略，可以让绝大多数的 tasks 有机会从它们的本地状态中恢复，从而避免了从其他 tasks 处获取它们之前的 slots 的级联效应。