得物Flink内核探索实践
随着大数据技术的飞速发展,实时处理能力变得越来越重要。在众多实时处理框架中,Apache Flink以其强大的流处理能力和丰富的功能集,受到了广泛关注和应用。在实时业务日益增长的趋势下,这促使我们深入探索Flink的内核,以更好地保障Flink任务的维护。本次分享将重点介绍得物在Flink内核方面的探索与实践,探讨如何通过深度优化和定制,实现更加高效和稳定的数据处理能力。
一、前言
随着大数据技术的飞速发展,实时处理能力变得越来越重要。在众多实时处理框架中,Apache Flink以其强大的流处理能力和丰富的功能集,受到了广泛关注和应用。在实时业务日益增长的趋势下,这促使我们深入探索Flink的内核,以更好地保障Flink任务的维护。本次分享将重点介绍得物在Flink内核方面的探索与实践,探讨如何通过深度优化和定制,实现更加高效和稳定的数据处理能力。
二、读者收益
通过阅读本次分享,读者将获得以下收益:
-
深入理解Flink内核:了解Flink的核心架构和关键组件,掌握Flink内核的运行机制。
-
优化实践:学习得物在Flink优化方面的实战经验,包括如何通过参数调优和内核定制,提升系统性能。
-
问题解决方案:掌握处理Flink常见问题的方法和技巧,提高在实际项目中应对复杂场景的能力。
-
实时处理案例:通过实际案例,了解如何在复杂业务场景中应用Flink,实现高效的实时数据处理。
-
最佳实践:获得得物在Flink应用中的最佳实践建议,帮助在实际项目中少走弯路,提高开发效率。
无论你是刚接触Flink的初学者,还是有一定经验的开发者,相信通过本次分享,都能有所收获,进一步提升在实时数据处理方面的能力。
三、自研特性
自研调度器
Apache Flink是一个开源的流处理框架,调度器是其重要的一部分。
在调度器上,我们新增了一款集合社区各款调度器优点的DwScheduler。
SchedulerNG (interface)
|
+-- SchedulerBase (implements SchedulerNG)
|
+-- DefaultScheduler (extends SchedulerBase 默认资源调度器)
|
+-- AdaptiveBatchScheduler (extends DefaultScheduler 自适应批调度器)
|
+-- SpeculativeScheduler (extends AdaptiveBatchScheduler 预测执行调度器)
|
|
+-- DwScheduler (extends DefaultScheduler 自研调度器)
|
+-- AdaptiveScheduler (implements SchedulerNG 自适应调度器)
-
在流任务生产环境中目前现有的调度并不很理想,在生产中我们常常遇到一些问题,例如:
-
任务JobGraph与资源调度没有直接的联系,难于变化和修改;
-
不能以TaskManager维度均衡分配所有task到所有slot上;
-
1.18以前没有直接动态扩缩容的接口、1.18以后也没有整体算子同时扩缩容的能力;
-
流任务调度器没有可以迁移task/Tm的迁移计算节点的能力。
-
-
DwScheduler整合了社区调度器的各项优点,并提供了很多适应我们生产情况的特性:
-
建立了JobGraph与资源之间的直接联系,用JSON可修改和表示流图信息和资源并进行调度;
-
能够均衡调度所有task到所有TaskManager上;
-
支持动态扩缩容各个算子,并且热更新资源规格的能力;
-
支持热迁移task/Tm的能力。
-
下面主要从上述的这四个特性上来重点讲解我们的成果。
简化资源调度
背景:常规通过配置任务的高级参数进行提交任务,不利于资源的拓展,以及用户想设置多个SlotSharingGroup也无法通用地实现。
SQL/DataStream任务都可通过我们的Flink编译器Generator编译完成后生成一个流图资源信息JSON。
-
调度器支持通过JobResourceProfile JSON信息来进行资源申请。
-
JobResourceProfile的信息用户可自由编辑,同样我们也提供了便捷的UI给用户操作算子和流图的以及资源的配置。
-
我们支持配置算子的并行度、最大并行度、SlotSharingGroup,以及资源的CPU、MEM、堆外内存部分我们也做了合理的管理让用户只需要配置一个比例,自动化设置资源的堆外各项参数降低OOM的风险,简化了用户对资源配置的操作难度。
-
-
支持接收新的资源资源JobResourceProfile JSON重新调度任务,支持同时扩缩容多个Operator算子的并行度。
-
在JobManager里我们提供了接收资源变更的Handler;
-
DwScheduler可以接收多元化的Service发起过来的资源变更请求;
-
并且它提供了六个回调接口,不同的Service可以通过实现它来执行不同的逻辑。
-
default void preRequestResource() {}
default void postRequestResource(Throwable throwable) {}
default void preRestart() {}
default void postRestart() {}
default void preDeploy() {}
default void postDeploy(Throwable throwable) {}
Flink支持通过资源JobResourceProfile+JobGraph流图提交任务,JM支持动态接收新的JobResourceProfile更新任务资源,可以按标签申请不同的资源机型。
均衡调度Task
背景:Flink的task分配是基于slot维度进行全局调度的,即使配置了cluster.evenly-spread-out-slots 也同样会有在Tm维度上的task分配不均衡的问题。
使用自研调度器的情况下,能够使用JobResourceProfile提前计算出每个TaskManager应该分配多少task,在此基础上我们实现了自己的DwSlotSharingStrategy,可以有效的按TaskManager来分配task个数,而不仅仅是在slot层面做到资源的均衡。
在同一个任务使用原生社区调度器和使用我们自研调度器,我们得出了一些数据效果,从Tm维度来看CPU使用均衡了许多。
从CPU使用率上来看,明显均衡了很多,减少了不均衡分配带来的性能瓶颈问题。
TaskManager热迁移
背景:在日常生产运维中,经常有需要迁移热点机器或故障机器的底层场景,Flink缺乏这部分的热迁移能力。
-
自研Scheduler为我们解决了这一问题,我们支持了热迁移TaskManager
-
同样使用DwScheduler提供的六个回调接口以及触发资源变更的请求来完成Tm的热迁移
-
热迁移的Service只需要对应地实现下它的功能,不必关心调度的流程
-
从投入生产迁移Tm资源的断流耗时情况来看,几乎能做到断流1~5s内的快速迁移:
TmRestart重启策略
背景:Flink社区只提供了FullRestart、RegionRestart,往往在生产环境中我们经常会遇到各种不可抗力Cancel用户的代码会超时或堆外有泄漏的情况。
-
为解决这一问题,我们在Restart层面增加了一种TmRestart策略:
-
我们将Tm Pod的主进程修改为常驻Shell,可以在Cancel超过一定时间能快速退出进程进行重启,也可以根据JM请求的重启参数直接触发TmRestart;
-
修改Pod的主进程我们需要解决一些问题如:信号量传递给子进程、进程返回码的协调与重新拉起;
-
另外我们也通过Shell主进程对Tm进程的IO探活、Process D监控等等;
-
在重启过程中会对zk有一定的重连,我们改造了这部分代码,尝试无法链接上一次的JM地址失败后才会去访问zk获取最新的leader地址。
-
-
同时我们也可以调整重新拉起的Tm进程的JVM参数
- 在特殊场景通过对Tm退出的异常原因进行分析,列如k8s判定是OOM或是容器等待内存回收的延时分布次数过高,判断重新拉起的Tm是否应该进行JVM参数适当调整。
TmRestart重启,可根据任务异常情况、作业配置等按需重启Tm进程,支持修改JVM的参数。
四、总结
本文主要介绍了以下内容:
-
Flink调度器的基本生产优化和改造。
-
重建Flink资源模型和支持热迁移等功能的特性介绍。
-
Flink的Task分配策略优化和重启逻辑新特性TmRestart。
*文 / 天然卷
本文属得物技术原创,更多精彩文章请看:得物技术
未经得物技术许可严禁转载,否则依法追究法律责任!
更多推荐
所有评论(0)