数据平台调度升级改造，从Azkaban平滑过渡到Apache DolphinScheduler

1 . !"!! 数据平台调度升级改造 从Azkaban平滑过渡到Dolphin 讲师： 卢栋 

2 .目录 CONTENTS "# 需求分析 "! 适配迁移 "$ 特性增强 "% 未来规划 

3 ."# 背景 需求分析 调研 架构 

4 .需求分析 - 背景 Fordeal 数据平台调度系统开始是基于 Azkaban 进行二开的，支持了机器分组、SHELL 动态参数、依赖检测等后勉强可满足 使用，日常使用中主要有以下几个问题 • 缺乏可视化编辑、补数等必要功能 （用户层面） • 技术架构陈旧，二开繁琐度高（技术层面） • 不定时出现 flow 执行卡死问题（运维层面） 

5 .需求分析 – 调研 • 首选 JVM 系语言 • 分布式架构，支持 HA • 工作流支持 DSL 和可视化编辑 • 前后端分离，主流框架 • 社区活跃度 

6 .需求分析 – 架构 （带*标识有2开） Master x 2 Worker x 6 调度信息 Api x 1 日均工作流实例：3.5k+ （v1.2.0） 日均任务实例：15k+ 

7 ."! 内部系统对接 适配迁移 Azkaban兼容 功能优化汇总 

8 .适配迁移 – 内部系统对接 Fordeal 内部系统需要上线对用户提供访问，需要对接几个内部服务，降低用户上手成本和减少运维工作 • 单点登录系统：基于 JWT 实现的 SSO 系统，一次登录认证所有 • 工单系统：DS 对项目的授权接入工单，避免人肉运维（后续接入所有授权动作，实现自动化） • 告警平台：扩展 DS 告警模式，将告警信息全部发送到内部告警平台，用户可配置电话、企业微信等模式告警 

9 .适配迁移 – Azkaban兼容 Azkaban 的 Flow 管理是基于自定义的 DSL 配置，每个 Flow 配置包含的 Node 数量多则800+少则1个，更新方式如下 • 用户本地保存，每次修改后zip压缩上传 • 所有flow配置和资源都托管git，在azkaban项目设置中绑定git地址，git提交后在页面点击刷新按钮 • 所有flow配置托管在配置中心，对接azkaban的上传接口 需求列表 1. DS 上传接口支持flow配置文件的解析并生成工作流（支持嵌套flow） 2. DS 资源中心支持文件夹（托管azkaban项目下的所有资源） 3. DS 提供client包，提供基础的数据结构类和工具类，方便api用户迁移 4. DS 支持工作流并发控制（并行或跳过） 5. DS 时间参数需支持配置时区（例如：dt=$[ZID_CTT yyyy-MM-dd-1]） 6. DS 跑数和补数界面支持全局变量覆写 7. DS dag图支持task多选操作 8. DS task日志输出最终执行内容，方便用户检查调试 9. DS 支持运行中失败任务手动重试 10.数仓项目需支持一键迁移，保持用户的工作习惯（ jenkins 对接 DS） （数仓项目的flow配置文件） 

10 .适配迁移 – 功能优化汇总 在协助其他团队迁移的整个过程中，根据用户使用反馈，共提交了140+个优化 commit，以下是 commit 分类词云 

11 ."$ 前端重构 依赖调度 特性增强 任务扩展 监控告警 

12 .特性增强 – 前端重构 为什么需要重构？痛点是什么？ • 操作步骤繁琐（项目 -> 项目首页 -> 工作流列表 -> 定义） • 无法直接通过名字、分组等条件检索到工作流定义/实例 • 无法通过url分享工作流定义/实例详情 • 数据库表和api设计不合理，查询卡顿（经常出现长事务告警） • 界面很多地方写死布局，导致添加列不能很好适配电脑和手机 • 工作流定义/实例缺少批量操作 执行方案 • 基于AntDesign库开发新的一套前端界面 • 弱化项目的概念，项目只作为工作流定义或实例的标签 • 简化操作步骤，将工作流列表和执行列表放在第一入口 • 优化查询条件和索引、增加批量操作接口等 • 完全适配电脑和手机（除了编辑dag，其他功能都一致） （新版UI） 

13 .特性增强 – 依赖调度 什么是依赖调度？ 工作流实例或Task实例成功后主动触发下游的工作流或Task跑数（执行状态为：依赖执行） 为什么需要依赖调度？设想以下几种场景 • 下游工作流需要根据上游工作流的调度时间去设置自己的定时时间 • 上游跑数失败后，下游定时跑数时也会出现错误 • 上游补数，只能通知所有下游业务方补数 • 数仓上下游定时间隔调整难，计算集群资源利用率没有最大化（K8S） 依赖调度规则 1. 工作流支持时间、依赖、两者组合调度（且与 或） 2. 工作流内的Task支持依赖调度（不受定时限制） 3. 依赖调度需要设置一个依赖周期，只有当所有 依赖在这个周期内满足才会触发 4. 依赖调度最小的设置单位是Task，支持依赖多 个工作流或Task（只支持且关系） 5. 工作流仅仅只是一个执行树中的组概念 （构思图） 

14 .特性增强 – 任务扩展 扩展更多的Task类型，将常用的功能抽象并提供编辑界面，降低使用成本。我们主要扩展了以下几个 • 数据开放平台（DOP）：主要是提供数据导入导出功能（支持Hive、Hbase、Mysql、ES、Postgre、Redis、S3） • 数据质量：基于Deequ开发的数据校验 • SQL-Presto数据源：SQL模块支持Presto数据源 • 血缘数据采集：内置到所有Task中，Task暴露血缘需要的所有数据 SQL-Presto数据源 数据开放平台（DOP） 数据质量 

15 .特性增强 – 监控告警 架构为 Java+Spring 下的服务监控，平台是有一套通用的Grafana监控看板，监控数据存储在Prometheus，我们的原则是 服务内部不做监控，只需要把数据暴露出来即可，不重复造轮子。改造列表为 • API、Master和Worker服务需接入micrometer-registry-prometheus库，采集通用数据并暴露prometheus采集接口 • 采集Master和Worker执行线程池状态数据，用于后续的监控优化和告警 • Prometheus侧配置服务状态异常告警，比如一段时间内工作流实例运行数小于n（阻塞）、服务内存&CPU告警等 

16 ."% 跟进社区特性 未来规划 完善数据统计 连接其他系统 

17 .未来规划 – 跟进社区特性 目前 Fordeal 线上运行的版本是基于社区第一个Apache版本（1.2.0）进行二开的，通过监控也发现了几个问题 • 数据库压力大，网络IO费用高 • Zookeeper充当了队列角色，时不时会导致磁盘IOPS飙升，存在隐患 • Command消费和Task分发模型比较简单，导致机器负载不均匀 • 整个调度模型中使用了非常多的轮询逻辑（Thread.sleep），调度消费、分发、检测等效率不高 社区发展非常快，现在的架构更加合理易用，很多问题已经得到了解决，跟进社区的发展是趋势，近期比较关注的是 • Master直接对Worker分发任务，减轻Zookeeper的压力 • Task类型插件化，易于后续扩展 • Master配置或自定义分发逻辑，机器负载更加合理 • 更完美的容错机制和运维工具（优雅上下线） 

18 .未来规划 – 完善数据统计 目前只提供了工作流实例的执行统计，粒度比较粗，后续需要支持更细化的统计数据，譬如 • 可按照Task筛选进行统计分析、按照执行树进行统计分析、最耗时的执行路径分析 • 执行统计添加同比、环比阈值告警 

19 .未来规划 – 连接其他系统 当调度迭代稳定后，会逐步充当基础组件使用，提供更加便利的接口和可嵌入式窗口（iframe），让更多的上层数据应用 （如：BI系统、预警系统等）对接进来，提供基础的调度功能 

20 . &'()*+, Ending