Flink 优化(七)

内存

        1.taskmanager.memory.jvm-overhead.fraction 0.1 JVM开销线程堆栈、IO、编译、缓存等  进程总大小*当前
        taskmanager.memory.jvm-overhead.min 192m
        taskmanager.memory.jvm-overhead.max 1g
        2.
        taskmanager.memory.jvm-network.fraction 0.1 网络操作进行的内存   进程总大小*当前(堆外)
        taskmanager.memory.jvm-network.min 192m
        taskmanager.memory.jvm-network.max 1g
        taskmanager.memory.managed.fraction 0.4 排序缓存hash等
        taskmanager.memory.managed.min 192m
        taskmanager.memory.jvm-metaspace.size=256m  元空间
        taskmanager.memory.framework.heap.size 128m  框架内存堆内
        taskmanager.memory.framework.off-heap.size 128m 框架内存堆外
        task=内存剩下

        yarn有资源调度策略：只顾内存分配的。所以有时候会看到申请的资源和拿到的资源不一致

并发度

        单一并行度   最高QPS/单一并行度*1.2   
        source：和kafka分区一致/(fafka分区增加是不可逆的操作)
        transform：keyby之前(和source保持一致)  keyby以后(2的整数倍)
        sink：和kafka保持一致就可以

状态调优

        State性能访问：
            性能损失(HeapStateBackend：10% RocksDBStateBackend：1%)
            state.backend.latency-track.keyed-state-enabled:true  启用访问状态的性能监控
            state.backend.latency-track.sample-interval:100 采样间隔
            state.backend.latency-track.history-size:128 保留采样数据
            state.backend.latency-track.state-name-as-variable:true 将状态名作为变量
        增量检查和本地恢复：
            state.backend.incremental:true 增量检查
            state.backend.local-recovery:true 本地恢复
            state.backend.rocksdb.localdir:1,2,3, 多磁盘(多个磁盘)
        预定义选项：
            state.backend.rocksdb.predefined-options:DEFAULT,SPINNING_DISK_OPTIMIZED,
                SPINNING_DISK_OPTIMIZED_HIGH_MEM,FLASH_SSD_OPTIMIZED
            backend.setPredefinedOptions(上面的参数)
        block缓存：state.backend.rocksdb.block.cache-size:64m
        write buffer大小：state.backend.rocksdb.writebuffer-size:128m(一个statues一个列簇)
        level阈值：state.backend.rocksdb.compaction.level.max-size-level-base:320m
        每一个列簇write buffer数量：state.backend.rocksdb.writebuffer.count:5
        后台线程数(flush sst文件合并)：state.backend.rocksdb.thread.num:4
        sst文件合并最小数：state.backend.rocksdb.writebuffer.number-to-merge:3
        (非必要)分区索引：state.backend.rocksdb.memory.partitioned-index-filters:true  //只保留最上层的索引在内存

checkpoint

        间隔分钟级别，HDFS 5-10min，两个间隔时间4-8min
        checkpoint慢原因：1.增量checkpoint  2.作业反压数据倾斜 
        3.Barrier对齐慢 4.火焰图分析 5.同步阶段慢(异步)

       ulimit -n 文件描述符限制

反压问题

        flinkjobUI ：BackPressure   inPoolUage输入数据  outPoolUage输出数据
            (上游反压第一个为OK的状态，下游反压第一个反压的节点)
        env.disableOperatorChaining()//禁用操作链 方便查看反压
        外部依赖：旁路缓存，异步查询

数据倾斜

        flinkjobUI：subtask  (bytesrecived 大小是否一致) 确认是否数据倾斜
        keyby以前出现数据倾斜：消费数据时候rebalance，重分区平衡数据
        keyby以后出现数据倾斜：双重聚合(存在问题：数据重复/后面还是会倾斜)  
            本地搞一个状态，来一条存储一条。定时器和size格式，做一个预聚合。
        keyby以后出现数据倾斜：窗口输出一次一个结果，窗口累计进行
            第一阶段：keyby，开窗，聚合 第二阶段：去掉随机数，按照key和windowend再次聚合

其他

    链路延迟：metrics.latecy.interval=30000(flinkwebui不存在)
    对象重用：pipline.object-reuse=true( 只被下游一个处理 或者 下游不能改变数据的值)
    滑动窗口优化：(窗口长度/步长) 多个滚动窗口聚合
    kafka：kafka动态获取分区，空闲源(watermark不会起作用).withldleness(Duration.ofMinutes(5)) 
        auto.offset.reset (新的消费组，和消费标记丢弃了)

finkSQL

        空闲状态保存时间：
            左右表的数据不会清理、要么设置TTL，或者inervaljoin
        group agg：
            MiniBatch缓存一定的数据，再处理减少对State的访问
                config.setString("table.exec.mini-batch.enabled","true")//开启（blink才能用）
                config.setString("table.exec.mini-batch.allow-latency","5s")//间隔时间
                config.setString("table.exec.mini-batch.size","20000")//规定条数
            LocalGlobal：将agg分成local Global 两个阶段(基于MiniBatch)
                config.setString("table.optimizer.agg-phase-strategy","TWO_PHASE")//
            Split Distinct：两层group 
                table.optimizer.distinct-agg.split.enabled=true
                table.optimizer.distinct-agg.split.bucket-num=1024=true //打散的数目 1024
            count(distinct id) filter(where flag in ('phone','android')) //自动转换为case when