基于开源架构的任务调度系统在证券数据处理中的探索和实践

摘要：为了应对证券行业盘后批处理业务复杂度上升带来的批处理时间窗口逐步缩小和运维越来越困难的挑战，上交所技术积极拥抱开源技术，结合上交所批处理的生产经验教训，以零人工介入、自动化运维为目标，开发了一种跨平台、支持多种部署模式的任务调度系统。本文从上交所批处理系统面临的实际挑战出发，通过调研几类典型的批处理架构，选择以开源软件Spring cloud dataflow为基础，设计并研发了上交所批处理任务调度系统。目前，该系统已经在交易系统生产环境上平稳试运行半年有余，为该系统在上交所各技术系统的推广打下了坚实的基础。

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 总体架构

　　EzTS主要由三部分组成：监控网关、调度服务和执行器。核心交易系统批处理采用多活的部署方式保证系统的可靠性。监控网关负责监测数据的汇聚和操控指令的转发。调度服务主要负责批配置的管理，流程的触发、调用和监控等功能。调度服务可以根据服务提供接口（SPI）的不同，支持不同的部署方式，比如local版和cloud版。执行器可以根据逻辑的不同分为流程和批组，通过流程和批组的配置编排运行批步骤。所有执行器和批步骤的状态都会存储在状态数据库（核心系统以MYSQL作为状态数据库）中，其总体架构如图1所示。

　　虽然dataflow提供了非常强大的任务编排功能，但是还远远达不到企业级调度服务的要求，必须深入的改造才能适合上交所不同业务盘后批处理的需求。下面就从批应用配置、调服模式、操控方式、依赖处理和监控可视化五个方面介绍新一代任务调度服务的优化设计。

3.2 极简的应用配置导入

　　目前任务调度领域应用配置导入方式主要有三大类：XML/JSON配置式、程序配置式和拖拽配置式。XML/JSON格式的应用配置方式比较复杂，比较适合业务数量较少，关系简单的系统；应用通过程序配置的方式，对框架侵入性太大，变更难度大，不够灵活，同样难以适合大规模的批处理应用系统；拖拽式的应用配置方式是最近比较流行的配置方式，虽然上手简单，但是实用性不足，难以满足大规模的应用配置。

　　为了将应用批步骤配置简单化、应用和架构完全解耦合，EzTS采用了EXCEL文件作为应用的配置文件，应用的配置流程如图2所示。

　　应用的配置升级，只需要如下三步骤：

　　1、 应用开发者从任务调度服务web操控端下载配置模板。
　　2、 应用开发者填写应用配置。
　　3、 应用配置升级。目前应用配置升级支持两种升级方式：方式一是通过任务调度服务的web操控端一键导入，提前检测配置的正确性；另一种升级方式需要把excel配置文件放置于公共目录，调度服务启动时会自动加载应用配置。

　　这种应用配置的方式一方面大大的简化了应用配置的复杂度，应用开发者更容易上手。另一方面，调度架构和批应用测试升级完全解耦，增加了批应用开发的灵活性。

3.3 灵活的三层调度模式

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

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

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

　　第一层：流程的定时调度或者手工触发运行。一个流程可以为一个业务的所有批的组合或者一类业务的组合。流程和流程之间完全解耦合。
　　第二层：批组的自动触发和依赖触发。当一个流程触发运行时会自动触发第一个批组，该批组完成，会触发依赖于该批组完成的批组。
　　第三层：批步骤的自动触发和依赖触发。批步骤作为最基本的处理单元，当批组触发运行，会自动触发第一个批步骤，该批步骤完成，会触发依赖于该批步骤完成的批步骤。

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

3.4 多样的操控方式

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

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

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

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

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

3.5 完善的依赖方式

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

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

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

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

3.6 监控的可视化

　　随着证券业务的发展，批步骤越来越多，批处理的运行时间也越来越长，批处理的运维变得更加困难，这都给批处理的监控提出了更高的要求。

　　批处理的监控由两部分组成：批处理的展示和操控。批处理的展示的难点在批步骤之间的关系和预警；批处理操控的难点在安全可靠。目前批处理的展示主要有两种：流程图展示和列表展示。两种展示方式各有优缺点，例如：流程图可以直观看到批步骤的关系，但是很难查找某一个批步骤，并且展示信息有限，列表反之。

　　EzTS采用了流程图和列表相结合的方式，扩展了流程图的功能，也发挥了列表的优点。流程图和列表展示示例如图4和图5所示。

图 4 流程示意图

图 5 列表示意图

　　在流程图页面可以快速的定位有问题的流程、批组和批步骤。不同的节点不但可以展示批名、批描述等信息，还可以点击批步骤直接操控，快速修复批处理中遇到的问题。

　　在列表页，则可以快速的搜索流程、批组和批步骤，直接定位操控。同时还支持根据不同维度快速分组批步骤，比如可以快速搜索出哪些批步骤为跳过状态。

　　在流程图的绘制过程中，如何合理的展示批步骤的节点成为了必须要面对的问题。

　　在流程图展示方面，目前只有商用软件TASKCTL宣称支持无流程图交叉，但是也有不足，比如所有批步骤必须完全属于某一串行或者并行组中，但是实际批步骤的关系很复杂，不一定满足这一设定。针对上交所批步骤实际的耦合关系，特别设计了流程图的坐标算法，计算流程如图6所示。

　　第一步：批处理调度服务通过读取数据库的流程图配置，获取流程图的串并行信息，例如A&&<B||C&&D>&&E
　　第二步：根据流程图中的串并行配置信息（备注：配置为DSL语言，例如A串行B用A&&B表示，A并行B用<A||B>表示）转换为有向无环图。
　　第三步：为了使流程图从开始到结束只有一个运行方向（例如从上到下，或者从左到右），对有向无环图进行拓扑排序，这样使不同批步骤的层次更加明显。
　　第四步：通过第三步的拓扑排序，节点分布在不同的层级上，但是却无法保证批步骤依赖关系连线和批步骤节点不重合，所以加入虚拟节点，实现流程图无点线交叉。

　　这种流程图显示坐标算法一方面通过简单的串并行配置规则实现了流程图的描述，另一方面实现了任意有向无环图的分层无点线交叉显示。

4、总结与展望

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

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

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

本文选自《交易技术前沿》总第三十三期文章（2018年12月）
上交所技术有限责任公司 技术开发总部：蔡丰令，樊玮，张培乐, 田肖, 杜小静