58大数据任务调度和智能运维实践

1. 58大数据任务调度和智能运维实践

2. 张梦龙 58同城资深开发工程师，负责数据开发平台、工作流调度系统等建设工作

3. 目录 1 调度系统的定位与挑战 2 架构设计与演进 3 智能运维最佳实践

4. 01 调度系统的定位与挑战

5. 星河-数据开发平台

6. 定位-数据中台的心脏 “工作流调度”解决了什么问题？ • • • 按照条件、顺序依次执行按执行周期定时运行最简配置业界解决方案：DolphinScheduler、Airflow、 Azkaban 工作流

7. 任务调度系统-挑战 01 稳定 • • • • 日均25W调度任务跨部门任务相互依赖统一调度集团所有任务故障恢复能力 02 性能 • • 上下游依赖链长，秒级依赖处理夜间高峰期高吞吐要求 03 扩展 • • 数据中台基础能力各类业务系统接入

8. 发展历程满足业务需求任务数：9w+ 接入平台：4个 2016-2019 解决性能、高可用问题支持百万级任务调度任务数：13w 接入平台：8个 2020 资源隔离，智能运维任务数：25w 接入平台：几十个 2021-至今

9. 星河调度系统-核心能力可视化易于使用，托拉拽实现任务依赖配置，无需编码也可进行ETL操作 02 丰富的任务类型 Hive、Shell、MR、SparkSQL、 Python等20多种支持用户开发自定义插件 03 高可用 04 依赖 05 智能监控 01 容错能力节点失败转移，失败重试时间依赖、事件依赖、自依赖实时查看任务运行日志，丰富的告警类型，基线监控

10. 02 架构设计与演进

11. 工作流定义方式静态显式动态隐式 DolphinScheduler、 Airflow流派 • • • • 调度最小单位flow 先定义flow，后创建job 需解决跨流依赖问题适合小规模、业务变更少的场景星河调度系统(dp- scheduler) • • • 调度最小单位job 无DAG概念，管理压力较小业务调整、依赖变更灵活，不需要关注工作流概念

12. 探索历程-最初架构背景 • • 每天9w+次任务调度(19年) 凌晨高峰期单任务调度延迟5分钟+ 存在的问题 1. 调度单点问题 2. 缺乏监控、运维能力差 3. 吞吐能力受限

13. 探索历程-当前架构整体架构 Master-Worker、消息队列 • 稳定性  去中心Master✖️ n，Worker✖️ n  Worker cgroup资源隔离  高可用 • 扩展性&运维  Master&Worker水平扩展  按类型、时段等条件自定义规则分发  执行组件插件化开发，热部署  Master灰度发布、Worker蓝绿部署滚动升级  Worker无DB依赖  多yarn集群扩展 • 性能  高效依赖检查、状态流转

14. 调度Master高可用 Master宕机场景下实例重新下发、幂等保证

15. 去中心化设计之Master分布式锁实现动态中心化设计，让管理者被动态选举出来，而不是预置基于zookeeper分布式锁，选举临时管理者（Master）来调度任务。保证集群中同一时刻只有一个Master在消费数据

16. 03 智能运维最佳实践

17. 任务运维管理面临的问题几十万任务，任务数量多任务上下游依赖复杂，最大可达60+层值班同学起夜频率高任务诊断困难，依赖人工经验

18. 分级保障 • • P0 • P1 • • P2 • 最核心任务，公司级数据，严控产出时间。例如影响收入的任务、依赖链顶层任务。任务异常立即响应，平台第一时间跟进并通知用户重要任务，业务核心数据、严控产出时间，非核心在线业务，如部门内核心业务系统相关任务、跨部门合作数据任务等。任务异常6点前响应，故障优先恢复次要任务，业务普通数据，天内产出，离线任务。当天跟进修复任务数，服务质量呈金字塔分布效果：核心任务优先保障，15分钟内响应 P2 P1 P0 重要性等级按指数递减

19. 任务运维——基线监控  上游依赖复杂，异常任务定位困难  任务告警太晚，发现时已无法补救基线：基于任务产出时间构建能力 • 任务延迟根因分析 • 精度可以达到1分钟内 • 关键路径

20. 基线核心逻辑：预期时间推算模型拉取基线任务全部上游，构建DAG，进行链路分析(逆拓扑排序) 任务预期运行时长：avg(7天平均运行时长) 任务最晚完成时间：min(下游最晚完成时间 - 下游平均时长)

21. 基线监控实践凌晨 00:30 凌晨 00:40 凌晨 01:20 值班同学收到基线预警，8:30基线余量不足，可能会破线值班同学上线，系统定位延迟任务，发现由于队列堆积，杀掉非核心任务，加大任务资源 8:30基线预警恢复安全，任务已追上。事故被扼杀在摇篮中

22. 基线关键路径实践目标：优化链路，保障数据 SLA 增加资源 12 优化逻辑基线上游核心任务优先保证资源提升资源利用率，缩短运行时长调整时间减少上游时间余量，提前运行

23. 值班组 • 多策略排班机制 • 报警升级、恢复 • 多通道报警

24. 补数据场景 1. 上游任务数据出错，任务依赖关系复杂，如何快速恢复？ 2. 下游任务有禁止重跑、已恢复无需重跑怎么处理？避免重跑导致二次问题，产出错误数据 3. 下游任务pending，恢复后大量任务提交如何保障核心任务争抢到资源？

25. 补数据 1. 定位问题源头任务，创建补数据 2. 展开全部下游任务，发起补数重跑(审批流)，设置高优先级: set mapreduce.job.priority=HIGH 3. 开始清理下游任务：正在运行的，根据调度优先级kill；已完成的，重置信号；未开始的，停止调度；设置禁止重跑的，跳过 4. 上游任务结束后，未开始的恢复调度

26. 未来规划 A B C 数据质量智能运维智能数仓

27. 欢迎加入交流群小秘书微信 58技术公众号

28. THANKS