flink Checkpoint优化

1、设置最小时间间隔

当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过程当中对状态数据的持久化

2、预估状态容量

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

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

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

3.系统中出现临时性的反压没有太大的问题，可是若是系统中频繁出现临时性的反压，例以下游外部系统临时性变慢致使数据输出速率降低，这种状况就须要考虑给予算子必定的资源

4.部分算子致使下游的算子的负载很是高，下游的算子彻底是取决于上游算子的输出，所以对相似于窗口算子的估计也将会影响到整个任务的执行，应该尽量给这些算子留有足够的资源以应对上游算子产生的影响。

3、异步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延迟时间能够经过整个端到端的计算时间减去异步持续的时间和同步持续的时间得出。