面对业务应用的不断加深，异构系统越来越多，响应频率越来越快，管理水平要求越来越高。越来越大的压力作用到我们的数据基础平台上。除了运行核心业务的平台外，其它非核心业务应用系统在建设的时候，通常由多个项目单独立项的方式分批分期建设。有采用各种计算机编程语言实现，有的采用各种数据库脚本实现，还有采用各种系统批处理脚本来实现。面对各式各样的作业，与之配套的批量作业调度方式也不尽相同。有的项目为了控制成本，直接通过系统的计划任务或CronTab等方式实现定时启动执行。有的项目则采用了第三方ETL工具自带的调度功能来实现。从具体业务系统到作业系统，再到批量作业调度系统，数据平台建设者们不可避免面临着各种挑战。然而，在大数据时代背景下，我们又希望通过技术手段迅速地去响应市场业务需求。因此，各种业务系统越建越多，技术要求越来越多元化，对管理运维提出了挑战。响应需求越来越快，对数据平台性能要求越来越高，并进一步对平台稳定性提出了挑战。同时，对原有系统的升级越来越频繁，带来了额外的升级维护成本，对系统的维护越来越困难。另外一方面，由于项目的独立性，在项目建设的时候没有考虑或很少考虑到对其它项目的影响。导致部分平台，特别是批量调度平台重复建设，浪费资源，而且每个作业的运行质量完全由ETL开发人员个人能力决定，具有极大的不可控性。

 

统一批量调度平台的重要性

       通过科学的项目管理机制固然可以在一定程度上降低项目自身业务系统和作业系统的风险。但由于项目建设的独立性等因素，建设批量作业调度平台的风险却并没有得到明显改善。为什么会出现这种情况，其实是与批量作业调度系统的本质有关系。批量作业调度系统不像其它系统，如作业系统一样，其本身并不受制于具体业务运行系统。也就是说，它可以是一个与业务完全无关的、独立的技术运行平台。它应该满足如下特性：

1、支持跨平台调度批量作业：无论是Windows、linux、aix、hp-ux、saloris或者其它虚拟云环境。都采取相同的方式来统一调度管理。

2、具有企业级特性：支持企业级的网络技术环境，如多级代理，跨网段，跨域等复杂的分布式网络环境。还需要支持HA高可靠性以及负载均衡。

3、统一的作业定义：无论是何种作业类型，都可以采用统一的方式进行定义，调度和监控运维。并可支持作业类型的扩展应用。

4、完善的调度控制策略：除了支持一般的作业间的串并关系，依赖互斥外，还应支持时间计划、容错、循环、自定义条件等其它高级控制策略。

5、全方位监控运维管理：具备批量作业系统重要业务逻辑可视化展示功能。提供流程图实时监控，多维度统计监控，实时消息事件监控预警。让管理运维人员及时、清楚地了解到批量系统运行状况。

6、作业调度分析能力：具备作业及作业流历史运行日志、异常日志查看功能。并对作业为什么不运行作出准确分析。同时还应具备历史回放，运行预测等分析功能。

7、全面的人工干预：能够手动运行任意作业或作业流的任意分支。以及作业流断点调试，启用禁用作业，忽略、中止、重跑作业等。

8、多渠道应用能力：在现今云应用如此普遍的情况下，较好能支持多渠道的应用环境，如web应用端和手机APP应用端等。

       因此，批量调度系统不仅仅是一个统一的批量作业驱动中枢，它还是一个统一的批量作业应用管理平台。统一的驱动中枢能充分屏蔽各个作业，各个批量系统间的技术差异，并能从全局上释放更多的时间窗口，成倍提升批量系统的处理能力，保障各个批量系统的稳定性。统一的应用管理能降低系统升级以及整合的风险，提升技术团队的业务分析能力，进一步提高实施效率，节约更多的人力成本。

统一批量调度平台建设风险

       统一批量调度平台如此重要，但为什么企业建设该平台却举步维艰，面临种种风险呢？

首先一直以来，批量系统从业者们对于作业调度的理解，仍然还存在于ETL软件里一个小功能的看法上，很少从全局性，管理性等角度去思考批量系统的重要性：“我写一些sh脚本就可以把作业调起来，为什么还要大费周折的采用专门工具，浪费成本不说，学习也费事”；“ETL软件自带了调度功能，用起来不是挺好的嘛？而且自己维护起来也不错。我不觉得一定要采用专门的批量调度工具。”在整个批量系统项目生命周期中，大家通常最关心的是ETL作业的设计。但是ETL工程师是具有流动性的，这样就决定了每个工程师只能管理自己的调度任务，一旦出现人员流动，新的ETL工程师将会付出极大成本对已有的作业进行维护，同时由于每个ETL工程师精力有限，靠人力进行作业管理的话，每个工程师管理的作业作业将会受到极大限制。

       其次，目前市场上专业批量调度产品相对较少，可供选择面较窄，缺乏足够的产品横向比较指标。因此一些大型企业，如中国X行则高价采购了国际更为知名的企业级作业调度工具Control-M。然而X行在实施Control-M的过程中却发现该软件十分复杂，要求使用者除了必须具备较高的素质外还要付出高昂的培训费用，实际的使用效果也不太尽如人意。另外，国内一些所谓的批量调度软件有很多是以项目的形态发展起来的，其本质上是由多个项目经验堆积而成。 由于受制于项目自身特点和需求的局限性，使其很难朝着专业的产品方向发展。另外，国内还出现了号称与领军者Control-M可以PK的TASKCTL。虽然TASKCTL从产品形态上来看还算不错，但是其初入市场不久，缺乏足够的市场检验。目前国内最先进的调度系统莫过于淘宝的TBSchedule和当当网的elestic-job，TBSchedule功能强大，在大数据处理方面能够很好的实现并行和优化策略，满足了阿里所有的任务，但是，TBSchedule最大的缺点就是该产品是定时调度系统，为了保证所有任务能在计划时间内完成，阿里是采用堆服务器的策略，所以TBSchedule并不适合国内绝大多数中小企业，没有几家企业可以像阿里一样不计成本，无限制堆加机器。elestic-job也是一个分布式的定时调度系统，同样也不适合很多中小企业。

       其三，有些项目组织者们虽然已经注意到统一调度平台的重要性，但留给建设统一批量调度系统的资源并不多，缺乏驱动使然。建立统一批量调度平台涉及到各个项目，各个部门的协调工作，总体上却没有一个“领导者”来牵头建设。有的企业少则5,6个，多则几十个业务应用的批量系统整合，如果没有一个良好的沟通协调制度，就很难从全局上把控建设风险。据笔者所知，目前国内银行业已经有多家企业开始着手全行级统一批量调度平台的建设，但目前市场上还没有一个完全成熟的方案可供参考。因此，由谁来牵头，怎么选型企业级调度技术产品则是摆在建设者们不得不面临的全新问题。

       其四，数据仓库调度系统升级成本极高。之前公司使用的的某国外公司的任务调度系统，今年准备将系统升级，带领团队在耗费半年时间，终于实现支持定时调度和依赖调度的秒级任务调度系统，本以为大功告成，但是在老系统作业迁移方面遇到了更大的困难，老任务调度系统的作业作业类型多样，相互之间依赖关系复杂，牵扯部门众多，每个部门与部门之间的数据也有依赖关系。同时，由于测试环境有限，无法大规模测试。迁作业时即不允许作业失败，也不允许老系统重跑该作业，同时该作业也要承接老系统作业的依赖关系，一时间项目处于崩溃的边缘。在尝试多种方案无法迁移后，最后决定项目重构，添加了很多与老系统交互的模块，两系统同时运行，最后虽然迁移成功，但是严重影响新系统的效率和稳定性，应该说，新系统并没有达到预期的效果。

       就到这里，如果大家有更多关于数据仓库任务调度系统建设的想法，欢迎邮件沟通gis2015@126.com