概述
2017年,我们引入Airflow搭建了有赞大数据平台(DP)的调度系统,并完成了全量离线任务的接入。随着公司业务的飞速发展,DP的日均调度任务数也从7000+来到了60000+:
随着调度规模的迅速增长,DP的调度系统也遭遇了一些问题与挑战,本文会基于DP调度系统的现有架构,详细介绍DP调度系统升级的原因、选型过程和改造方案的设计和实施。
DP调度系统现状
1、DP调度系统架构设计
我们团队在17年的时候调研了当时的主流的调度系统(Azkaban/Oozie/Airflow等),最终决定采用 Airflow 1.7作为DP的任务调度模块,并结合公司的业务场景和需求,做了一些深度定制,给出了如下的解决方案:
2、Airflow的痛点问题
随着业务的发展,调度规模的增长,DP的调度系统也遇到了一些痛点问题,主要有以下几点:
调度系统升级选型
1、Airflow VS DolphinScheduler
针对这几个痛点问题,我们在今年也有了升级DP调度系统的想法,一开始的想法是直接升级到Airflow2.0版本,但因为脱离了社区版本,评估下来升级成本有点高,于是也做了其他开源调度组件的调研,然后DolphinScheduler进入了我们的视野,同样都是Apache顶级的开源调度组件项目,我们也基于当前使用的Airflow版本(1.7)对两者进行了包括稳定性、易用性、功能和扩展性等多方位的比对:
性能对比
部署
功能新增/增强
稳定性与可用性
社区生态
经过综合评估后,我们决定接入DolphinScheduler,进行DP调度系统的升级重构。
接入方案设计
1、DolphinScheduler接入架构设计
我们首先整理了DS接入的核心需求点,有以下几点:
在保证核心需求的前提下,我们进行了DP-DS的架构设计:
2、DolphinScheduler改造方案设计
完成架构设计后,需要落实到具体的改造方案中,因此我们也基于工作流/任务状态转移、测试、发布等核心流程进行了改造方案的设计。
我们梳理了DS工作流定义状态,因为DS的工作流定义与定时管理是会区分两个上下线状态,而DP平台的工作流配置和定时配置状态是统一的,因此在任务测试和工作流发布流程中,我们需要对DP-DS的流程串联做相应的改造。
任务运行测试流程中,原先的DP-Airflow流程是通过dp的Master节点组装dag文件并通过DP Slaver同步到Worker节点上再执行Airflow Test命令执行任务测试。
在切换为DP-DS后所有的交互都基于DS-API来进行,当在DP启动任务测试时,会在DS侧生成对应的工作流定义配置并上线,然后进行任务运行,同时我们会调用ds的日志查看接口,实时获取任务运行日志信息。
对于工作流上线(发布)流程,原先的DP-Airflow流程主要还是拼接并同步Dag文件到指定目录由scheduler节点进行扫描加载。
在切换为DP-DS后主要就是工作流定义配置+定时配置以及上线状态的同步。
通过任务测试和工作流发布这两个核心操作的流程可以看到,因为工作流的元数据维护和配置同步都是基于DP Master来管理,只有在上线和任务运行的时候才会与调度系统(Airflow、DS)进行交互,我们也基于这点实现了工作流维度下调度系统的动态切换,方便我们后续的线上灰度 。
3、DolphinScheduler能力补齐
对于DP现有调度系统的一些定制化能力,我们计划后续在DS侧进行针对性的补齐,下面列举几个目前对于DP平台相对核心的功能以及对应的改造方案设计。
目前DP平台的任务类型主要有16种,主要包含数据同步类的任务和数据计算类的任务,因为任务的元数据信息会在DP侧维护,因此我们对接的方案是在DP服务端构建任务配置映射模块,将DP维护的Task信息映射为DS侧的TaskParmeter格式,通过DS-API调用实现任务配置信息的传递。对于DS侧的适配改造针对不同的任务类型有两个适配方案:
DS已支持的任务类型(Hive SQL任务、DataX任务、Spark任务等):只需要基于我们的实际使用场景对DS对应的任务模块做一些定制化的改造。
DS未支持的任务类型(Kylin任务、算法训练任务、DataY任务等):我们计划后续通过DS的插件化能力去补齐。
调度自动回补机制是DP实际生产环境中的一个核心能力,其使用场景是当调度系统异常或者资源不足时,可能会导致部分任务错过当前调度触发时间,当恢复调度后,通过Airflow的Catchup机制会自动补齐未被触发的调度执行计划。对于Catchup机制原理可以看一下下图示例:
图1:是一个小时级工作流的调度执行信息,这个工作流在6点准时调起,并完成任务执行,当前状态也是正常调度。
图2:该工作流在6点完成调度后一直到8点期间,调度系统出现异常,导致7点和8点该工作流未被调起。
图3:当9点恢复调度后,因为catchup机制,调度系统会自动回补之前丢失的执行计划,也就是实现调度的自动回补。
Catchup机制在Dag数量较大的时候有比较显著的作用,当因为Scheduler节点异常或者核心任务堆积导致工作流错过调度触发时间时,不需要人工去手动补数重跑,系统本身的容错机制就支持自动回补未被调起的任务。同时这个机制还应用在了DP的跨Dag全局补数能力中。
跨Dag全局补数的使用场景一般出现在核心上游表产出异常导致下游商家展示数据异常,一般这种情况下都需要能快速重跑整个数据链路下的所有任务实例来恢复数据正确性。我们的方案就是通过改造了Airflow的Clear功能,通过元数据的血缘解析获取到指定节点当前调度周期的所有下游实例,通过规则剪枝策略过滤部分无需重跑实例,最后启动clear Downstream清除任务实例信息,利用Catchup机制进行自动回补,同时通过任务全局优先级和数据依赖保证任务的顺序执行。DS因为没有跨Dag全局补数的能力,因此我们基于Airflow的全局补数原理,对DS侧进行了相应的改造。与DP现有的补数流程基本保持一致。
现状&规划
1、接入现状
DP平台目前已经在测试环境中部署了部分DS服务,并迁移了全量工作流,实现QA环境的调度任务双跑。对接DolphinScheduler API后,因为用户体系是直接在DP Master上进行维护,因此DS平台在用户层面统一使用admin用户。同时所有的工作流配置信息会基于Project区分测试环境和正式环境。
2、未来规划
目前,DP平台还处于接入DolphinScheduler的灰度测试阶段,计划于今年12月进行工作流的全量迁移,同时会在测试环境进行分阶段全方位测试,包括调度性能测试和压力测试。确定没有任何问题后,我们会在明年1月进行生产环境灰度测试,并计划在3月完成生产环境的工作流全量迁移。