Flink调优

Flink JVM 进程的进程总内存（Total Process Memory）包含了由 Flink 应用使用的内存（Flink 总内存）以及由运行 Flink 的 JVM 使用的内存。 其中，Flink 总内存（Total Flink Memory）包括 JVM 堆内存（Heap Memory）、托管内存（Managed Memory）以及其他直接内存（Direct Memory）或本地内存（Native Memory）。https://ci.apache.org/projects/flink/flink-docs-release-1.12/zh/deployment/memory/mem_setup_tm.html#managed-memory

checkpoint性能的两个重要指标
    1.time
        barrier触发checkpoint的时间很高时，说明System处理一个backpressure中。
    2.align duration
        应用接收它的第一个barrier到最后一个算子接收到这个barrier的时间。在unalign期间，所有任务不间断的处理数据。对于align的exactly-once checkpoints，已经接收到barrier的channel，将不再接收数据，直至所有的channel赶上来，
    引起原因有：backpressure,data skew,network

 Tuning Checkpoint
    默认checkpoint是串行执行的，当前一个checkpoint延期超过了checkpoint时间间隔，下一个checkpoint在上一个checkpoint完成后，立即执行。
    为了解决这个问题，设置checkpoint之间的最小时间间隔
    StreamExecutionEnvironment.getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds)

 Tuning RockDB
    1.增量checkpoint，减少checkpoint的时间。增量checkpoint只保存正对于上一次checkpoint变化的
        1.1 在 flink-conf.yaml 中设置：state.backend.incremental: true 或者
        1.2 RocksDBStateBackend backend = new RocksDBStateBackend(filebackend, true);
    2.定时器默认保存在RockDB中的，如果定时器小的情况下，把定时器保存到heap中
        在 flink-conf.yaml,配置state.backend.rocksdb.timer-service.factory:heap

    3.调优RocksDB的内存
        默认RocksDB采用 managed memory 来存储 Buffer 和 caches，Flink 对同一个任务槽上的所有 RocksDB 实例使用共享的 cache 以及 write buffer manager。
        共享 cache 将对 RocksDB 中内存消耗的三个主要来源（块缓存、索引和bloom过滤器、MemTables）设置上限。
        state.backend.rocksdb.memory.managed:true
        Flink还提供了两个参数来控制写路径（MemTable）和读路径（索引及过滤器，读缓存）之间的内存分配。当您看到 RocksDB 由于缺少写缓冲内存（频繁刷新）或读缓存未命中而性能不佳时，可以使用这些参数调整读写间的内存分配。
        state.backend.rocksdb.memory.write-buffer-ratio，默认值 0.5，即 50% 的给定内存会分配给写缓冲区使用。
        state.backend.rocksdb.memory.high-prio-pool-ratio，默认值 0.1，即 10% 的 block cache 内存会优先分配给索引及过滤

 Capacity评估

 压缩
    默认情况checkpoint是不压缩的，目前可采用的压缩为snappy，压缩的最粒度为 key-group的状态，每个key-group独立压缩。
    ExecutionConfig executionConfig = new ExecutionConfig();
    executionConfig.setUseSnapshotCompression(true);
    压缩对于增量checkpoint没有作用，因为RocksDB内部就采用的是snappy

 Task-Local Recovery
    在Flink的checkpoint中，每个task生成一个状态的snapshot存储到分布式系统中。每个task发送一个描述了状态存储在分布式系统的位置的handle给JobManage。JobManage收集所有task的handle信息，放入到一个checkpoint对象。
    一旦故障恢复，JobManager 打开最新的Checkpoint对象，发送相应的handle到相应Task。
    使用分布式系统存储状态有两个优势，第一，存储是容错的；第二，所有node分布式的访问所有状态。
    分布式系统的缺点：所有的task必须从远端读取数据，通过网络。
    Flink’s configuration
        state.backend.local-recovery:CheckpointingOptions.LOCAL_RECOVERY