有赞大数据平台的调度系统演进 - WXOPEN Club

概述

2017年，我们引入Airflow搭建了有赞大数据平台（DP）的调度系统，并完成了全量离线任务的接入。随着公司业务的飞速发展，DP的日均调度任务数也从7000+来到了60000+：

随着调度规模的迅速增长，DP的调度系统也遭遇了一些问题与挑战，本文会基于DP调度系统的现有架构，详细介绍DP调度系统升级的原因、选型过程和改造方案的设计和实施。

DP调度系统现状

1、DP调度系统架构设计

我们团队在17年的时候调研了当时的主流的调度系统（Azkaban/Oozie/Airflow等），最终决定采用 Airflow 1.7作为DP的任务调度模块，并结合公司的业务场景和需求，做了一些深度定制，给出了如下的解决方案：

架构设计：我们采用了Airflow + Celery + Redis + MySQL的部署方案，Redis作为调度队列，通过Celery可以实现任意多台Worker的分布式部署（水平扩展）。
调度的HA方案：Airflow 1.7的调度节点存在单点问题，为了实现调度的高可用，我们采用了Airflow Scheduler Failover Controller，该服务会新增一个Standby Scheduler，Standby节点会周期性地监听 Active 节点的健康情况，一旦发现 Active Scheduler 不可用的情况，则Standby切换为Active 。这样就保证了Scheduler 的高可用。
Worker节点负载均衡策略：为了提升Worker节点利用率，我们按CPU密集/内存密集区分任务类型，并安排在不同的Celery队列配置不同的slot，保证每台机器CPU/内存使用率在合理范围内。

2、Airflow的痛点问题

随着业务的发展，调度规模的增长，DP的调度系统也遇到了一些痛点问题，主要有以下几点：

因为过于深度的定制化开发，脱离了社区版本，导致我们版本升级成本极高，升级到2.0的成本不亚于引入新的调度系统。
Airflow是Python技术栈，因为我们团队还是Java技术栈为主，技术栈差异带来的是较高的迭代成本和运维成本。
Airflow的1.X版本存在的性能问题和稳定性问题，这其中也是我们生产环境中实际碰到过的问题和踩过的坑：

性能问题：Airflow对于Dag的加载是通过解析Dag文件实现的，因为Airflow2.0版本之前Scheduler只有单点进行Dag文件的扫描解析，并加载到数据库，导致一个问题就是当Dag文件非常多的时候，Scheduler Loop扫一次Dag Folder会存在巨大延迟（超过扫描频率）
稳定性问题：Airflow Scheduler Failover Controller本质还是一个主从模式，Standby节点通过监听Active进程是否存活来判断是否切换，如涉及到Scheduler节点进行并发写表操作产生Deadlock等阻塞进程的情况，则会误判进而导致调度故障发生。

调度系统升级选型

1、Airflow VS DolphinScheduler

针对这几个痛点问题，我们在今年也有了升级DP调度系统的想法，一开始的想法是直接升级到Airflow2.0版本，但因为脱离了社区版本，评估下来升级成本有点高，于是也做了其他开源调度组件的调研，然后DolphinScheduler进入了我们的视野，同样都是Apache顶级的开源调度组件项目，我们也基于当前使用的Airflow版本（1.7）对两者进行了包括稳定性、易用性、功能和扩展性等多方位的比对：

性能对比

相同条件下DS（1.3.8）调度吞吐性能是Airflow（1.7）的2倍左右（DS2.0版本性能方面有大幅提升，较之前1.3版本提升了十几倍，因当时调研时还未发布2.0版本，因此后续还需要进行DS2.0的对比压测）。

部署

DS为Java技术栈，可以接入公司的OPS标准化部署流程，简化发布流程，解放运维人力。
DS支持K8S、Docker部署，扩展性强。

功能新增/增强

DS的调度管理界面更具易用性。
DS支持Worker分组，能够实现资源隔离提升Worker利用率。
DS实现分布式调度，调度能力随集群规模线性增长。
任务、告警组件支持插件化（DS-2.0版本）。

稳定性与可用性

DS去中心化的多Master多Worker设计架构，支持服务动态上下线，具有高可靠与高可扩展性。

社区生态

DolphinScheduler社区在国内整体活跃度较高，经常会有技术交流，技术文档比较详细，版本迭代速度也较快。

经过综合评估后，我们决定接入DolphinScheduler，进行DP调度系统的升级重构。

接入方案设计

1、DolphinScheduler接入架构设计

我们首先整理了DS接入的核心需求点，有以下几点：

切换成本：尽可能保证用户使用无感知，降低切换成本。
稳定性：生产环境要求稳定性大于一切，上线过程需要尽可能保证平稳，不影响生产环境的任务调度，因此需要实现调度系统可动态切换（支持线上灰度）。
功能补齐：测试与发布的工作流配置隔离、适配DP现有的任务类型、跨Dag全局补数能力等。

在保证核心需求的前提下，我们进行了DP-DS的架构设计：

保留DP现有前端web界面与服务层逻辑
重构调度管理界面（原先嵌入Airflow原生界面）
任务生命周期管理/调度管理等操作通过DS API交互
利用DS的project冗余工作流配置，实现测试、发布的配置隔离

2、DolphinScheduler改造方案设计

完成架构设计后，需要落实到具体的改造方案中，因此我们也基于工作流/任务状态转移、测试、发布等核心流程进行了改造方案的设计。

DS工作流定义状态梳理

我们梳理了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的插件化能力去补齐。

调度自动回补策略（Catchup机制）

调度自动回补机制是DP实际生产环境中的一个核心能力，其使用场景是当调度系统异常或者资源不足时，可能会导致部分任务错过当前调度触发时间，当恢复调度后，通过Airflow的Catchup机制会自动补齐未被触发的调度执行计划。对于Catchup机制原理可以看一下下图示例：

图1：是一个小时级工作流的调度执行信息，这个工作流在6点准时调起，并完成任务执行，当前状态也是正常调度。

图2：该工作流在6点完成调度后一直到8点期间，调度系统出现异常，导致7点和8点该工作流未被调起。

图3：当9点恢复调度后，因为catchup机制，调度系统会自动回补之前丢失的执行计划，也就是实现调度的自动回补。

Catchup机制在Dag数量较大的时候有比较显著的作用，当因为Scheduler节点异常或者核心任务堆积导致工作流错过调度触发时间时，不需要人工去手动补数重跑，系统本身的容错机制就支持自动回补未被调起的任务。同时这个机制还应用在了DP的跨Dag全局补数能力中。

跨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月完成生产环境的工作流全量迁移。