| 编辑推荐: |
| 本文来自于51cto，本文主要介绍了几种开源解决方案、饿了么调度系统特性以及调度系统整体架构等。 |
|
随着饿了么在大数据应用的不断深入，需要解决任务数量增长快、任务多样化、任务关系复杂、任务执行效率低及任务失败不可控等问题。
饿了么大数据平台现状：每天完成大数据任务计算 54000+;节点集群 85 台。
开源解决方案
Ooize
Ooize 基于工作流调度引擎，是雅虎的开源项目，属于 Java Web 应用程序。由 Oozie
Client 和 Oozie Server 两个组件构成。
Oozie Server 运行于 Java Servlet 容器(Tomcat)中的 Web 程序。工作流必须是一个有向无环图，实际上
Oozie 就相当于 Hadoop 的一个客户端。
当用户需要执行多个关联的 MR 任务时，只需要将 MR 执行顺序写入 workflow.xml，然后使用
Oozie 提交本次任务，Oozie 会托管此任务流。
AzKaban
AzKaban 是一套简单的任务调度服务，是 Linkedin 的开源项目，开发语言为 Java，包括
Web Server、DB Server、Executor Server。
它用于在一个工作流内以一个特定的顺序运行一组工作和流程，定义了一种 KV 文件格式来建立任务之间的依赖关系，并提供一个易于使用的
Web 用户界面维护和跟踪你的工作流。
AirFlow
AirFlow 是一个编排、调度和监控 Workflow 的平台，由 Airbnb 开源，现在在
Apache Software Foundation 孵化。
AirFlow 将 Workflow 编排为 tasks 组成的 DAGs，调度器在一组 Workers
上按照指定的依赖关系执行 tasks。
同时，AirFlow 提供了丰富的命令行工具和简单易用的用户界面以便用户查看和操作，并且 AirFlow
提供了监控和报警系统。
饿了么调度系统特性
饿了么调度系统特性如下：
任务创建简单，执行频率支持 cron 表达式。
任务拆分为多种任务类型，支持 19 种任务类型(计算、推送、抽取、检测)。
任务依赖配置简单，支持不同周期匹配，提供推荐依赖，DAG VIEW 功能。
调度与执行支持 HA，平滑发布，宕机恢复，负载均衡，监控告警，故障排查，快速扩容，资源隔离。
支持任务类型：
计算：Hive、Spark、PySpark、MR、Kylin。
推送：MySQL 推送、HBase 推送、Redis 推送、Cassandra 推送、HiveToX
推送、MySQL 多推。
抽取：数据抽取。
检测：Dal-slave 检测、数据质量检测、Edsink 检测、抽取数据检测、数据有效期、导入导出校验。
其他：邮件定时任务。
饿了么调度系统整体架构
饿了么调度系统整体架构包括如下 5 个部分：
Web 服务：主要提供任务创建、实例管理、任务依赖管理、Worker 控制、任务监控告警等。
调度执行：主要由主备 Scheduler 和多个 Worker 节点组成，负责任务的调度与执行。
基础服务：提供了 Eless 自助发布，ELK 故障排查，Huskar 配置中心，Etrace 埋点监控，DOG
告警等功能。
底层服务：提供 Hive、Spark、Presto、Kylin、Hadoop 支持。
公共设施：包括 MySQL、Redis、Zookeeper。
任务运行过程如上图：
Web Service 提供的 API 创建任务和依赖关系，将任务信息存入 MySQL。
Scheduler 定时生成第二天所有任务实例，并定时轮询检查并改变任务状态为 Ready(是否到了执行时间，是否依赖已完成)。
Worker 启动时注册信息至 Zookeeper，并定时上报机器状态给 Scheduler。
Scheduler 的 ZkWorkerManager 监听 Zookeeper，获取 Worker
的注册信息。
获取 Ready 的任务，TaskPacketFactory 将任务构造成 TaskPacket，使用对应的
SubmitPolicy 投递任务给 Worker。
Worker 通过 Thrift 接收任务，将任务解析成 InterpreterContext，交给对应的
Interpreter 执行，最终由 Docker 运行任务。
Docker 执行情况返回给 Worker，Worker 回调给 Scheduler 将状态写入 MySQL。
饿了么调度系统功能
任务依赖
任务依赖通过如下两种方式配置：
推荐依赖：是通过任务执行完将表和列的信息存入 MySQL，由饿了么血缘系统根据表的关联进行推荐。
手动依赖：则是人为通过界面设置表的依赖关系。依赖关系支持不同周期的任务依赖，偏移量支持表达式【，】【~】。
失败快速自动重试
当任务执行失败时，系统自动重新调起，默认重试 3 次;当任务投递过程中，节点因资源紧张拒绝投递，调度会根据负载均衡策略尝试投递另一台机器。
自助故障排查
任务执行错误故障排查：节点提供 HTTP 服务，将任务执行的日志通过 HTTP 返回给 Web Service
并展示到界面上，提供用户自助排查。或者通过页面上的连接访问饿了么错误分析平台(Grace)自动分析。
任务非执行错误排查：任务调度和执行通过 Flume 将任务日志进行收集，通过在 ELK 上搜索全局
ID 即可查看调度和执行情况。
监控告警
任务监控告警：根据用户设置的告警规则和告警频率，对任务执行超过完成时间和失败的进行手机、邮件、钉钉告警。
故障监控和告警：调度和执行节点进行 Etrace 埋点，通过对接收、执行、回调等关键点进行监测，当指标低于其他节点时间窗口平均值时，进行告警。
调度&执行
调度主备自动切换
调度器通过向 Zookeeper 注册，并随机选举出 Leader 提供调度服务。非 Leader
服务监听 Leader 状态并 Wait，当 Leader 出现故障，立即切换为 Leader 角色提供服务。
宕机恢复、自我修复
当所有调度都宕机时，调度服务未恢复期间，Worker 执行节点回调会出现异常。
此时任务状态会存入本地文件数据库，并定时重试回调。当调度服务恢复时，任务状态恢复正常。
当 Worker 执行节点宕机时，节点上的任务会处于运行中。当节点重启时，Worker 会自我修复运行中的任务，将节点上未调起的任务重新调起，已经运行中的任务通过读取
Docker 执行完写入本地的状态文件进行恢复。
平滑发布
当 Worker 节点进行版本升级时，运行中的任务进行自我修复，同上。
资源隔离和快速扩容
通过 Docker 限制每个任务的 Memory 和 CPU 资源使用;将依赖的底层服务打包成镜像，扩容时便可以很方便的构建需要的环境。
节点故障维护
当节点发生故障或需要维护时，Worker 执行节点通过 Web 界面即可进行上线下线服务，下线后认为不再接收任务，但不影响节点上运行中的任务运行。 |
