【交易技术前沿】基于开源架构的任务调度系统在证券数据处理中的探索和实践

1、背景和挑战

随着证券交易市场的快速发展，交易业务种类和待处理数据量也随之不断增加，核心应用系统的批处理业务越来越复杂。不同的批处理业务不但内部批处理单元相互依赖，而且与上下游对接系统的交互也越来越繁杂，导致留给批处理业务的处理时间窗口和应急时间窗口越来越小，这些都对新的批处理架构的高效性、高可用性和易维护性等方面提出了更高的要求。针对上交所批处理业务目前的实际情况，面临着如下问题和挑战。

首先是上交所各系统业务类型和数据量的增多对批处理架构的调度性能和功能提出了更多的要求。目前，上交所的核心交易盘后批处理业务类型越来越多，比如A/B股、综合业务、期权、沪港通等，对任务类调度的性能都有严格的要求。

其次是核心交易系统批处理业务的上下游交互越来越频繁，应急时间窗口越来越短，这对批处理架构的操控鲁棒性和预警系统的及时性都有了近乎严苛的要求。在证券系统中，不同的系统都有不同的分级，比如上交所核心系统为四级系统，对故障恢复时间要求极为严苛。如何能及时发现问题和解决问题，这不仅需要及时的预警系统，稳定的系统架构，更需要完善的应急操控功能。

第三、目前上交所技术公司业务系统、大数据系统和核心交易等系统都有各自的批处理框架，不同的批处理框架技术栈，各方面要求迥异，这都对新批处理架构选型造成了较大挑战。因此选择一个不同系统通用的任务调度系统，可以大大避免人力和资源的浪费，为软件的持续维护打下坚实的基础。

最后，软件技术、语言、系统等日新月异，软件的生命周期也是不可忽视的方面。比如，目前交易系统核心批处理是基于OPENVMS自主研发的批处理框架，虽然极其稳定高效，但是受限于操作系统生命周期将尽，升级或者重构都困难重重。

综上，已有的批处理架构在应对目前面临的各种挑战时就显得捉襟见肘，如何选择和研发一套满足证券业务处理高效性、鲁棒性和监控友好性的批处理架构越来越迫在眉睫。

2、批处理调度系统的探究和选型

目前批任务的处理根据调度控制的不同，分为资源调度和任务调度，资源调度是指为单个批步骤分配各种资源，比如CPU、内存、磁盘甚至主机，目的是为了提高批步骤利用资源的效率。典型的资源调度系统有Cloud Foundry、Yarn、Mesos等；任务调度是指一系列的批步骤按照批编排的顺序及时准确的执行。典型的任务调度系统有Elastic-job、Spring Batch、TaskCtl、Airflow等。具体如何选择技术方向，还需要根据实际的需求确定。

批处理调度系统的选型主要有三个方向：自研架构、基于开源软件二次开发和采用商用软件。自研批处理调度架构对人力成本、时间成本都耗费巨大，从零开始，是否经得起大数据量的考验都是不得不考虑的风险；商业软件，成熟稳定，但是一方面不能完全自主掌控，一旦出现问题，难以应急；另一方面，上交所业务复杂，批处理特殊需求较多，难以及时满足各种需求。基于开源软件二次开发，不但可以保证项目进度，而且开源软件经过多年验证，具有一定的可靠性，同时能满足不同业务的独特需求。所以选择开源项目并进行消化改造不失为一种便捷可靠的方向。

由于目的不同，资源调度和任务调度并不冲突，一个调度系统中既可以支持批步骤的资源配置，也可以支持不同批步骤间的流程编排。目前上交所核心批处理调度系统由于历史和稳定性要求等原因，暂时不会采用资源调度的方式，仅将资源调度能力作为系统扩展能力的一部分。目前已知的开源任务调度架构较多，比较有代表性的有Elastic-job、Airflow、Spring Cloud Data flow（以下简称Dataflow）等。

Elastic-job是当当网开源的定时分片类任务调度系统，目前很多公司基于该开源项目二次开发了自己的任务调度系统，比较有名的有唯品会的Saturn、数人云的Octopus等。但是Elastic-job对任务间的依赖关系支持较弱，支持的任务类型比较单一，监控的范围和粒度都不能满足证券交易业务的需要。

Airflow是Airbnb开源的DAG（有向无环图）类优秀的任务调度工具。Airflow主要由PYTHON实现，job的定义无法通过XML或者界面定义，只能依靠PYTHON定义，所以无法做到调度架构和应用业务的解耦合；另外，Airflow开源时间较短，调度性能较低，比较适用于简单的ETL类的编排。所以从易用性，稳定性和性能等方面都无法满足当前和未来证券业务的发展。

Dataflow是Pivotal公司开源的支持ETL、批量运算和持续运算的统一编程模型和托管服务。根据批任务的生命周期长短不同，Dataflow把应用处理分为流处理和任务处理，并且为基于微服务的分布式流处理和批处理提供了一系列的模型和最佳实践。

但是Dataflow也有一些不足：首先云调度性能不足，一个微服务的调度达到了分钟级；其次整体架构比较庞大，如何取其精华是必须面对的挑战。但是结合上交所盘后批处理的实际情况，还有如下几方面优点：

1、 Dataflow强大的编排能力可以支持关系复杂，数量庞大的交易业务。

2、 Spring/Spring Cloud技术栈在上交所技术公司内部使用越来越广泛，这都为后期的Spring系列功能维护升级提供了保障。

3、 Dataflow支持本地调度、云调度等部署方式，可以满足不同系统的等级要求，方便以后的系统升级和维护。核心交易系统为了安全性和稳定性的考虑，采用Dataflow本地版本可以规避Docker等新技术的稳定性风险，也方便了后续云调度功能的完善，核心系统的平滑升级。而大数据系统却可以采用云调度等部署方式，支持微服务，Docker等新技术满足自己弹性伸缩、灰度发布等方面的需求。

4、 Dataflow天然支持流处理业务和批处理业务。证券交易业务既有实时交易数据流的同步处理需求，也有报表、对账等盘后处理需求。

5、 Dataflow支持各种类型的批任务，比如EXE、SHELL、PERL、PYTHON、JAR等，可以实现调度架构和批应用开发完全解耦。

综上所述，选择以Dataflow开源框架为基石，开发出符合上交所数据处理实际需求的调度架构不失为一个可行、可控且符合安全运行需求的方案。

3、面向证券交易的任务调度系统的设计

虽然dataflow有诸多优点，但是其作为开源软件，也有开源软件的通病，比如：

1、 开源软件只实现了基本功能，且侧重通用性，但是一个完整的企业级软件需要满足各种定制化需求。

2、 开源软件一般性能不足，并且实战检验会有各种缺陷，需要不断优化。

3、 开源软件需要消化学习成本较高，需要深入学习，才能融会贯通。

所以，结合核心系统的实际情况，我们开发了新一代任务调度服务架构（简称EzTS），它是基于Dataflow深度开发，支持跨操作系统（Linux和Windows）运行，满足不同的部署场景（本地、分布式、云调度），具有框架和批应用低耦合，强操控，自动化运维等特点的批处理调度系统。

3.1 总体架构

3.2 极简的应用配置导入

3.3 灵活的三层调度模式

随着交易业务的多样性，同一业务类型内部处理单元错综复杂，这些都对调度层级提出了更高的要求。为了更好的支持不同业务类型，不同的批处理逻辑单元的关系，EzTS采用了三层调度架构的设计，根据层级的不同，分为流程、批组和批步骤，如图3所示。

目前，业界大多调度系统都支持基于UNIX的CRONTAB的定时任务，一方面CRONTAB为周期性的任务提供了极大的便利，但是却存在着明显的局限性。往往批步骤之间都有极大的耦合性，如果仅仅依靠定时的方式，所有的批步骤均和时间相关，一旦批步骤出现问题，未必能保证批步骤的执行顺序。

另外，目前部分较完善的批处理框架虽然也支持批步骤的串并行配置，但是却无法满足交易业务中天然具有分组概念的内部逻辑。所以为了区分不同业务批处理，不同处理组和不同批的处理先后关系，EzTS采用了三层的调度架构：

第一层：流程的定时调度或者手工触发运行。一个流程可以为一个业务的所有批的组合或者一类业务的组合。流程和流程之间完全解耦合。

第二层：批组的自动触发和依赖触发。当一个流程触发运行时会自动触发第一个批组，该批组完成，会触发依赖于该批组完成的批组。

第三层：批步骤的自动触发和依赖触发。批步骤作为最基本的处理单元，当批组触发运行，会自动触发第一个批步骤，该批步骤完成，会触发依赖于该批步骤完成的批步骤。

三层调度模式不但使不同的业务处理完全解耦合，而且能够清晰的划分同一业务内部的不同处理组的关系。极大地方便了批步骤的分类和管理。

3.4 多样的操控方式

随着交易业务越来越多，批处理业务的复杂度也越来越高，批步骤关联的上下游系统也越来越多，造成了批处理的应急窗口不断缩小，如何快速的解决批处理中遇到的问题，就显得愈加重要。

在实际的盘后批处理运行过程中，批步骤需要人为干涉的原因各种各样，比如上游数据迟到、错误或者数据处理出错等，这些不同的问题对任务调度服务的操控提出了更高的要求。根据批步骤操控方式的不同，可以简单归为两类：重跑操控和置状态操控。

下表列出了目前支持的操控方式如表1所示。

在批应用的生命周期中，往往不是一个人在开发和运维，随着时间的推移，一个批步骤的前后依赖关系逐渐变得模糊。一旦一个批步骤出错，哪些相关联的批步骤需要重跑，除非对该应用十分熟悉，否则很难抉择，这大大增加了应急的难度、时间和风险。所以针对这一类情况，特别加入了相关批重跑的操控类型。当批应用开发的过程中，配置相关批步骤的信息，这样再碰到这样的应急场景时，可以通过相关批重跑功能快速解决问题，这样可以大大减少应急的时间和风险。

多样的操控方式不仅增加了问题处理的灵活性，而且大大缩短了批处理系统恢复处理的时间。

3.5 完善的依赖方式

所有的批步骤都必须依赖满足才能被调起运行，否则，一方面会造成有限资源的浪费，另一方面造成程序进度的不可预知。根据上交所批处理业务的实际，将批步骤的依赖分为三大类：时间依赖、文件依赖和状态依赖。

在交易系统的批处理应用中，时间依赖的应用场景主要有两类，一类是某一批步骤不能早于某一时间点运行，比如期权结算价计算不能早于实时收盘时间。另外一类是某一类批步骤只能一周或者一个月运行一次。

目前，不同的证券系统之间盘后处理主要依靠文件来交互数据，这就造成了批处理的文件等待处理越来越重要。一方面，文件就绪后，调度服务立即调起批步骤应用程序可以大大缩小批步骤运行的时间，另一方面，批应用运行结束后，文件是否正确生成也可以通过批配置文件依赖反馈到批的运行状态。

另外，随着证券业务类型越来越多，批步骤之间的逻辑划分在实际开发的过程中越来越不清晰，导致不同批步骤之间的关系越来越错综复杂。出于配置和展示的需要，流程图的节点依赖逻辑不能太过复杂，这样完善的批状态依赖设计就显得特别重要。在流程图上能够表示出来不同批步骤间依赖关系称为显式状态依赖，否则称为隐式状态依赖。显式状态依赖可以快速的定位批步骤在流程中的位置。隐式批状态依赖可以灵活的配置任意批/批组和流程的等待关系，最大程度的节省批程序的整体处理时间。

3.6 监控的可视化

4、总结与展望

虽然在新一代任务调度系统的实际开发的过程中碰到了各种各样的问题，比如开源软件底层架构的缺陷，高并发度时数据库死锁，线程和内存资源占用过多等问题，但是经过上交所批处理中心的不懈努力，这些问题都得到了优化和解决，完全达到了核心系统上线的要求。EzTS系统1.0版本于今年5月份在核心系统生产环境上线运行以来，经历了多种业务，多种场景的检验，整体运行平稳。新一代调度系统在核心系统生产环境上线，不但开了上交所核心系统使用开源软件的先河，而且也说明了核心系统采用基于开源软件二次开发的方式具有可行性。EzTS系统上线半年来的经验教训不但为批处理调度系统的进一步优化提供了方向，而且为EzTS系统在其他系统中的使用打下了坚实的基础。

未来，EzTS批处理调度框架一方面将在使用过程中不断完善，不断提高可靠性和调度性能，另一方面，要不断的打磨新功能，比如使用流处理、资源调度、微服务、Docker等，最终打磨出一款适用于上交所技术系统通用的调度服务框架，进一步地结合上交所金融云，推出云调度服务产品。

自动化运维、微服务、云调度一直是互联网技术研究的热点，上交所技术将会充分利用积累的运维经验，以开放的心态，拥抱、研究、落地新技术，不断打磨证券数据的处理能力，进一步提升自己对证券业务的研发、安全保障和运维的能力。

免责声明

本公众号内容仅供参考。对任何因直接或间接使用本公众号内容而造成的损失，包括但不限于因有关内容不准确、不完整而导致的损失，本公众号不承担任何法律责任。如有问题请反馈至tech_support@sse.com.cn。

-------------------------- 上海证券交易所为证券公司、基金管理公司等市场参与者及相关行业机构提供交易技术支持与服务，包括日常交易技术支持、技术交流研讨、市场调查反馈、证券信息技术知识库、测试等服务。

点击"阅读全文"了解详情