为了更加深入地了解用户需求，我们采访了几家有上述困扰的企业，并针对他们的日常批量作业管理工作和运维工作的问题进行了探讨：

某股份制银行运维部门的困扰
随着银行新的系统建设以及老系统的更新、扩展，目前运维部门接手运维的应用系统越来越多，每天凌晨有数十个系统需要跑批，近百万的批量作业需要执行。这些系统是以各自项目为单位开发和移交的，没有统一的管理口径和标准，每天需要把这些系统挨个检查一遍，工作量非常繁重。如果有任务出错，还需要我们查找对应系统的手册，按手册的步骤进行错误检查和重新运行，工作效率很低，我们运维团队的同事也很疲累。
在这种情况下，一旦系统运行不稳定，很难及时排除故障，也就会影响第二天的业务报表及时性。——运维部主任

某城市商业银行开发团队--头疼于批量任务的开发管理问题
系统开发项目的任务都压在我们开发部门的头上，目前光我手上负责的就有四五个项目。这些项目都有你提到的批处理， 有的系统批处理作业还很多，得有数万个吧。项目组完成批处理的开发后，很头疼的一个问题就是怎么把这些作业组织起来， 用 ETL 工具自带的调度不太现实，一个一个拖拽效率很低，而且也很容易出错。另外 ETL 工具也不够友好，操作不灵活， 且缺乏总体的管理界面，很难观察任务总体执行进度，测试时很不方便。
此外，多个项目间没有统一的标准，多系统间的数据流转梳理不清，系统越多越难管理。
一般来说，项目组完成功能性作业的开发后，还要花费大量的时间开发作业的调度任务，这也额外增加了很多工作量和人力投入。——开发部门项目经理

某制造企业--棘手于数据仓库建设过程中的调度问题
我司数仓建在大数据平台上，用了 hive、spark、hdfs、HBase 等多种组件，还用到 ETL 工具从业务系统中把数据抽取到大数据平台中。抽数和加工任务总共有数千个。现在我们的困扰是 Oozie 和 quartz 在大数据平台内可以做较好的调度管理，能做流程控制和触发控制，但是很难结合外部的 ETL 工具、数据库、shell 等对其任务做关联控制。在监控上也不太满足运维管理的要求，大数据的调度工具还是有很多缺陷。现在很头疼应该怎么处理这个情况。——信息中心业务经理

这些受采访的企业，大部分科技部门都有类似的，关于如何才能做好任务调度的困扰。有些企业通过使用 ETL 工具或者开源的调度工具来进一步解决调度的问题，但由于其采用的工具存在各种各样的缺陷，仍然会有批量作业的调度管控或者运行监控上的问题。

综合各企业的情况并进行总结归纳，筛选出了几个目前大部分企业面临的，在数据调度方面比较具有代表性的困境：

调度原始落后：时至今日仍然有一些系统使用人工调度或操作系统的 crontab 方式调度。在如今追求自动化甚至智能化的时代已显得非常原始和落后，耗费人力、容易出错、难以监控已成为这类系统的致命性问题。

使用开源软件：调度系统使用开源软件，学习成本较高并且没有服务保障，bug 修复不及时，生命周期不确定。

调度自主研发：调度系统伴随项目自主研发，投入产出比小并且影响项目周期，软件质量也难以保证，需求扩展性差。

系统间协调交互困难：各系统独立建设，没有统一的标准和规范，无法简单有效的实现系统间的交互。运维效率较低， 当一个系统出现问题，可能需要运维人员逐个联系上游系统确认问题根源。运维效率低下。

作业规模变大：随着 IT 系统的持续建设，批量处理作业规模越来越大，相对应的调度场景更加多样系统调度逻辑也会更加复杂，系统开发人员很大一部分精力花费在了调度逻辑的控制，而非业务处理本身。另外，随着作业规模的增长，对调度性能和稳定性、扩展性提出了更高要求，一些现有系统已经逐渐不能满足要求。

系统越来越多，导致管理和运维困难：企业需要运行和维护的系统越来越多，不同的系统，对于技术要求不同，导致批处理作业管理越来越复杂， 使得 IT 技术异构的风险变大。一个技术人员很难同时熟悉多个系统，所以需要大量的技术人员对这些系统分别进行管理和运维。夜间值班人员同时开着十几个甚至更多的监控屏幕也成为常态和痛点。这些问题很显然的造成了运维投入的不断增加。

综上可知，对于企业数据开发过程而言，一个完整且高效的工作流调度系统将起到至关重要的作用。