在之前的文章，我们规划了数仓架构，制定了数仓规范，然后在架构和规范的指导下设计了存储模型、构建了 ETL 系统。

数仓模型解决了数据存储问题，ETL 解决了数据同步集成计算问题，而调度解决的是自动化问题。

我们通过配置调度去周期性定时触发执行各种任务或流程(同步、集成、计算、校验、测试等)并监控他们的运行情况，及时、保质、自动化的满足各种数据使用需求。

最后调度还有一个附加的用途，对于新接手的维护项目，我们想要快速了解其数据流转，线上运行的调度任务就是最好的切入点了。

方案一、借助操作系统或数据库

这种方式的优势在于不需要专门安装配置、非常稳定、使用方便。在一些规模较小的系统非常建议使用。

方案二、自主开发

调度这个事情使用场景特别广泛，但是每个场景或者每家公司使用的功能有多又少，比如有的只需要能稳定的定时调度即可，有的还需要实现跨服务器调度、监控告警、流程依赖控制、可视化配置等等。

可能是感觉市面上可选的工具都不足以满足个性化的需求，不少公司会选择自主研发，利用多线程和定时器，或者基于一些底层开源工具进行深度封装。我们之前做对账系统就是 java 封装的 quartz。

这里有篇介绍底层调度工具的文章。需要自主研发的朋友，可以看看 "JavaBoy" 怎么说：

分布式定时任务调度系统技术选型

方案三、选用调度工具

借助操作系统或数据库这种方式稳定性最高，但只适合单一计算场景并且调度任务不是很多的场景。

• 如果所有计算都在同一数据库内就可以使用数据库本身的调度。
• 如果所有计算调用都能够集中到同一台服务器内完成，我们就可以用操作系统自带的调度。

自主研发的方式适用于个性化程度很高、调度性能并发要求不太高、或者功能相对少且自身有研发能力的场景。

虽然调度本身不是一个特别难实现的事情，很多公司可能都有过这种经历。但是想把它做到极致，具备稳定、易用、功能完备、高性能、高并发、高适应性等各方面都不错的程度，还是很难的。能用和好用/通用之间要走的路还有很多。海豚调度这两年能够迅速得到市场认可，但可能大家不知道的是，易观将其开源之前内部研发迭代了至少五年了，照样其开源后仍有一部分人觉得不好用呢。

下边这篇是博哥总结的常见大数据调度系统的介绍，大家可以看一下：

基础功能：

参数传递：复杂的 ETL 任务，可能会有一级任务、二级任务、三级任务等等，必须设置一些参数来支持过期重跑、补数等场景。而且最好设置成外部的参数可以覆盖内部的(这跟程序开发的逻辑正好相反)，防止开发/测试人员设置的子任务参数上线时候忘记删除造成不必要的问题。

跨服务器调用：很多 ETL 工具也都具备定时调度和参数传递的功能，但跨服务器调用就是调度工具所特有的了。拥有跨服务器调用能力后，可以真正的将整个数据流转串联起来，比如我们的数据集成同步任务、数仓内的主体 ETL 任务、对外推送任务，三者经常是分开部署的。

任务编排：正常的任务编排应该在 ETL 系统里完成，但涉及到跨集群任务依赖的场景，就必须使用调度工具了。

推荐阅读：

https://www.51cto.com/article/687527.html