flink Checkpoint优化

一、设置最小时间间隔

当flink应用开启Checkpoint功能，并配置Checkpoint时间间隔，应用中就会根据指定的时间间隔周期性地对应用进行Checkpoint操作。默认情况下Checkpoint操作都是同步进行，也就是说，当前面触发的Checkpoint动作没有完全结束时，之后的Checkpoint操作将不会被触发。在这种情况下，如果Checkpoint过程持续的时间超过了配置的时间间隔，就会出现排队的情况。如果有非常多的Checkpoint操作在排队，就会占用额外的系统资源用于Checkpoint，此时用于任务计算的资源将会减少，进而影响到整个应用的性能和正常执行。

在这种情况下，如果大状态数据确实需要很长的时间来进行Checkpoint，那么只能对Checkpoint的时间间隔进行优化，可以通过Checkpoint之间的最小间隔参数进行配置，让Checkpoint之间根据Checkpoint执行速度进行调整，前面的Checkpoint没有完全结束，后面的Checkpoint操作也不会触发。

• streamExecutionEnvironment.getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds)

通过最小时间间隔参数配置，可以降低Checkpoint对系统的性能影响，但需要注意的事，对于非常大的状态数据，最小时间间隔只能减轻Checkpoint之间的堆积情况。如果不能有效快速地完成Checkpoint，将会导致系统Checkpoint频次越来越低，当系统出现问题时，没有及时对状态数据有效地持久化，可能会导致系统丢失数据。因此，对于非常大的状态数据而言，应该对Checkpoint过程进行优化和调整，例如采用增量Checkpoint的方法等。

用户也可以通过配置CheckpointConfig中setMaxConcurrentCheckpoints()方法设定并行执行的checkpoint数量，这种方法也能有效降低checkpoint堆积的问题，但会提高资源占用。同时，如果开始了并行checkpoint操作，当用户以手动方式触发savepoint的时候，checkpoint操作也将继续执行，这将影响到savepoint过程中对状态数据的持久化

二、预估状态容量

除了对已经运行的任务进行checkpoint优化，对整个任务需要的状态数据量进行预估也非常重要，这样才能选择合适的checkpoint策略。对任务状态数据存储的规划依赖于如下基本规则：

1.正常情况下应该尽可能留有足够的资源来应对频繁的反压。

2.需要尽可能提供给额外的资源，以便在任务出现异常中断的情况下处理积压的数据。这些资源的预估都取决于任务停止过程中数据的积压量，以及对任务恢复时间的要求。

3.系统中出现临时性的反压没有太大的问题，但是如果系统中频繁出现临时性的反压，例如下游外部系统临时性变慢导致数据输出速率下降，这种情况就需要考虑给予算子一定的资源

4.部分算子导致下游的算子的负载非常高，下游的算子完全是取决于上游算子的输出，因此对类似于窗口算子的估计也将会影响到整个任务的执行，应该尽可能给这些算子留有足够的资源以应对上游算子产生的影响。

三、异步Snapshot

默认情况下，应用中的checkpoint操作都是同步执行的，在条件允许的情况下应该尽可能地使用异步的snapshot，这样讲大幅度提升checkpoint的性能，尤其是在非常复杂的流式应用中，如多数据源关联、co-functions操作或windows操作等，都会有较好的性能改善。

在使用异步快照需要确认应用遵循以下两点要求：

1.首先必须是flink托管状态，即使用flink内部提供的托管状态所对应的数据结构，例如常用的有ValueState、ListState、ReducingState等类型状态。

2.StateBackend必须支持异步快照，在flink1.2的版本之前，只有RocksDB完整地支持异步的Snapshot操作，从flink1.3版本以后可以在heap-based StateBackend中支持异步快照功能

四.压缩状态数据

flink中提供了针对checkpoint和savepoint的数据进行压缩的方法，目前flink仅支持通过用snappy压缩算法对状态数据进行压缩，在未来的版本中flink将支持其他压缩算法。在压缩过程中，flink的压缩算法支持key-group层面压缩，也就是不同的key-group分别被压缩成不同的部分，因此解压缩过程可以并发执行，这对大规模数据的压缩和解压缩带来非常高的性能提升和较强的可扩展性。flink中使用的压缩算法在ExecutionConfig中进行指定，通过将setUseSnapshotCompression方法中的值设定为true即可。

五.观察checkpoint延迟时间

checkpoint延迟启动时间并不会直接暴露在客户端中，而是需要通过以下公式计算得出。如果改时间过长，则表明算子在进行barrier对齐，等待上游的算子将数据写入到当前算子中，说明系统正处于一个反压状态下。checkpoint延迟时间可以通过整个端到端的计算时间减去异步持续的时间和同步持续的时间得出。