调度系统是数据仓库的重要组成部分，也是每个银行或公司一个基础软件或服务，需要在全行或全公司层面进行规划，在全行层面统一调度工具和规范，由于数据类系统调度作业较多，交易类系统批量优先级高，为不互相影响可以和交易类系统独立分开，建立2套调度环境。

1.调度系统常见架构

上图是一种常见的调度架构，它分为两个部分：

（1）调度服务器集群作为调度中心，对调度批次和作业进行创建、管理、监控，它负责所有批量作业的调度和编排；

（2）代理（agent）: 在各需要调度的服务器上需要安装一个agent，agent主要从调度中心获得指令执行服务器上作业，并将结果返回给调度中心，调度系统需要支持多种操作系统，因此agent需要兼容多种操作系统，但如果服务器上作业可以远程调用的话可以不安装agent。

另外还有一种架构也比较常见，架构和上图一样，但是在调度集群中心建立作业后，所有的作业被分配到各agent，由agent来调度作业的执行，调度中心只负责管理和结果监控，作业的调度编排、执行由agent进行，这种架构的好处是避免了调度中心故障不会影响批量调度。但agent的资源消耗和维护工作量较大。这种架构在交易系统中使用较多，但随着目前集群和数据库的HA越来越稳定，这种架构也慢慢在减少。

2.数据类系统重点功能及批量设计

由于调度系统较多，开源的也比较多，但是对于数据类系统的调度有一些实用的功能可以在选型或开发中重点关注，一些常见的功能如依赖、触发、多批量等就不再赘述。

（1）防重复启动

这个主要是控制一个作业在执行市不能再次被执行，许多设计会设置互斥文件或变量来实现，但在作业各种异常（如网络中断）后，也需要有机制或功能清理互斥文件和变量，以免不能重做作业。

（2）批量重跑

许多调度工具可以支持单个作业重跑，但是数据类系统作业关联性较大，如果主数据区作业发现正常结束但是数据异常，修复后需要重新跑依赖该作业的中间层、集市的作业。因此在任一个作业节点可以批量重跑后续作业，避免手动单个作业按顺序重跑，这个功能会对问题处理带来很大的效率提升。比如下图的作业流图中，作业B1数据错误，批量重跑时会将后续依赖B1作业的C1、C2以及后续的D1、E1作业都进行重跑。

（3）对接预警系统和ETL系统

对接预警系统主要是指将作业异常发送的统一预警系统进行通知，对接ETL系统主要是做好加载、抽取、数据转换作业、数据质量检查作业的调度和日志监控，因为调度系统也是数据仓库一个重要组成部分。

（4）时间监控和预警

由于关键作业没有执行完成会影响后续所有的批量作业，可能导致数据应用系统无法按时提供服务，比如数据仓库替核心系统计算久悬账户，所以经常需要对关键作业进行时间点的监控，比如3:00前作业未启动或未完成就进行一级告警。

（5）用户权限管理

作为一个全行的基础系统，用户权限管理主要是为了各系统开法运维人员各自负责自己的批量调度，以免互相影响。

（6）配置化导入和更新

由于ETL等作业都是可以根据作业属性和数据库表信息自动生成调度作业，因此为了方便开发，可以将作业批量信息导入到调度系统，批量创建修改作业，避免手工增加修改作业。

（7）监控可视化

监控可视化主要是对批量作业流能清楚看到当前哪些作业已完成，执行中，待启动，也可以看到整个批量作业的依赖路径，更智能的话可以通过每天的作业执行情况，自动分析出关键路径。

3.批量作业流设计优化：

（1）作业优先级设置

通过合理设置作业优先级，提前完成批量作业路径中的关键作业，提高整体时效。对于为交易系统以及高时效的监管报送系统的数据批量作业，需要单独分批次并设立高优先级，以确保不受其它作业影响。

另外作业依赖必须细化到作业级别，而不是依赖整个作业流或批次完成，即精细化管理，虽然复杂些，但能很大提高整体批处理的时效。

（2）合理设置源系统作业的抽取时间

由于源系统有些表依赖源系统的日终批处理完成，如内部总账，而有些表不需要依赖如客户信息、交易流水，可以在日切后分批次抽取源系统数据，将作业启动时间提前；

（3）批量作业分析及优化

定期如每周、每月对整个数据仓库批量作业进行汇总分析，重点关注源系统提供数据时间、作业时长超过30分钟的作业、作业时长增加比例最高的作业等，通过分析来确定优化作业并启动优化，一般可以通过重建表、优化SQL、重新分布表数据、增加资源等方式来优化作业，减少执行时间；

（4）关键批量作业监控

数据仓库中对于交易系统的数据加工往往会影响到银行对客户的服务，因此对关键作业和节点需要进行及时处理，如源系统数据提供时间、重点表的加工作业完成时间、高时效应用的数据提供作业完成时间都需要设置预警，报警时由值班人员及时处理。

关于银行数据仓库系列，笔者还会不断更新，欢迎继续关注~