一、前言

随着大数据技术的飞速发展,实时处理能力变得越来越重要。在众多实时处理框架中,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。

01.jpg

  • 调度器支持通过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层面做到资源的均衡。

02.jpg

在同一个任务使用原生社区调度器和使用我们自研调度器,我们得出了一些数据效果,从Tm维度来看CPU使用均衡了许多。

从CPU使用率上来看,明显均衡了很多,减少了不均衡分配带来的性能瓶颈问题。

03.jpg

TaskManager热迁移

背景:在日常生产运维中,经常有需要迁移热点机器或故障机器的底层场景,Flink缺乏这部分的热迁移能力。

  • 自研Scheduler为我们解决了这一问题,我们支持了热迁移TaskManager

    • 同样使用DwScheduler提供的六个回调接口以及触发资源变更的请求来完成Tm的热迁移

    • 热迁移的Service只需要对应地实现下它的功能,不必关心调度的流程

04.jpg

从投入生产迁移Tm资源的断流耗时情况来看,几乎能做到断流1~5s内的快速迁移:

05.jpg

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参数适当调整。

06.jpg

TmRestart重启,可根据任务异常情况、作业配置等按需重启Tm进程,支持修改JVM的参数。

四、总结

本文主要介绍了以下内容:

  • Flink调度器的基本生产优化和改造。

  • 重建Flink资源模型和支持热迁移等功能的特性介绍。

  • Flink的Task分配策略优化和重启逻辑新特性TmRestart。

*文 / 天然卷

本文属得物技术原创,更多精彩文章请看:得物技术

未经得物技术许可严禁转载,否则依法追究法律责任!

Logo

助力广东及东莞地区开发者,代码托管、在线学习与竞赛、技术交流与分享、资源共享、职业发展,成为松山湖开发者首选的工作与学习平台

更多推荐