FFA2024分论坛-核心技术.pdf

《FFA2024分论坛-核心技术.pdf》由会员分享，可在线阅读，更多相关《FFA2024分论坛-核心技术.pdf（246页珍藏版）》请在三个皮匠报告上搜索。

1、抛弃并行度设置:Flink 智能扩展，资源消耗最小化范瑞Shopee Flink Runtime 负责人Apache Flink PMC Memeber为什么需要并行度全托管？01估算合适的并行度02高效扩缩容03生产实践&深度优化04收益分析&未来规划05为什么需要并行度全托管?手动设置并行度的痛点资源利用率易用性1 万+作业按照流量和负载评估，人力成本极高并行度过低Lag业务逻辑变更重新评估固定的并行度流量波动(小时，天，月)新用户不了解如何设置并行度并行度过高资源浪费!只 scale up 不 scale down!Lag 报警后 scale up仅针对流作业估算合适的并行度多少并行度足

2、够？Source 处理一条数据需要 10 ms单线程的处理能力：每秒 100 records Kafka topic 输入速率：每秒 700 records并行度 7 就足够了=Source 输入速率单线程的处理能力700100=7 合理吗？多少并行度合适？!预期负载：70%实际负载=输入速率/总处理能力70%=700/1000合适的并行度=期望的总处理能力单线程的处理能力1000100=输入速率/预期负载单线程的处理能力700/0.7100=10期望的总处理能力?下游 Task 的输入速率=上游 Task 的输出速率期望的总处理能力重启耗时输入速率期望的总处理能力当前的Lag基础处理能力=输

3、入速率/预期负载追 Lag 能力=重启后的 Lag预期的追 lag 耗时当前 Lag+重启耗时*输入速率预期的追 lag 耗时=单线程的处理能力*实际负载=老作业实际总处理速率Total Records 差值时间差(单线程的处理能力*并行度)Busy 率就是实际负载单线程的处理能力=Total Records 差值时间差*并行度*实际负载=估算合适的并行度预期的负载预期的负载范围追赶 Lag重启耗时FLIP-271:Autoscaling 1Autoscaler doc 2flink-kubernetes-operator repo 3Autoscaler Configuraions 4Par

4、allelism 的逻辑上限：任何 task 的并行度=maxParallelismKafka source 的并行度=topic 的分区数Metric 窗口大小（默认分析最近 15 分钟 Metric 来估算并行度）用户可配置 Parallelism 的上限和下限并行度调整的倍数高效扩缩容启动作业耗时启动Flink Client启动 JM生成 Graph申请所有TM启动所有TM部署TaskYarn/K8s 启动作业耗时:50s+12 s痛点：手动重启作业，断流时间 2 分钟!申请资源 启动进程原地扩缩容流程申请扩容的 TM启动扩容的 TMCancelTask部署Task!断流时间 2 秒原地

5、扩容流程：CancelTask部署Task异步释放空闲的 TM!断流时间 2 秒原地缩容流程：优化大状态的恢复效率Flink 2.0 存算分离状态存储Adaptive SchedulerFLIP-138:Declarative Resource management 5FLIP-160:Adaptive Scheduler 6Adaptive Schedulerjobmanager.scheduler:adaptive设置并行度的区间:lowerBound,upperBound3,10Default Scheduler设置并行度为 5固定的，不支持修改资源=实际并行度，则取消 trigger(

6、避免无效扩缩容)优化天级缩容的频率天级缩容的业务目标：按照每天高峰期申请资源扩容保持敏感(默认 15 分钟)scale-down.interval=24 h24 h 内估算的所有并行度 80lowerBound=1upperBound=80（期望的并行度）实际：50-5151-6262-80FLIP-472:Aligning timeout logic in the AdaptiveScheduler WaitingForResources and Executing states 20(Flink 2.0)FLIP-322:Cooldown period for adaptive sched