- 设计概述
1.1术语及缩略语
回测参数: 初始值,终止值,步长
回测实例参数:初始值+步长*N
回测任务: 策略+一组回测参数
回测子任务: 策略+一组回测实例参数
- 2 背景介绍
传统的策略研发的缺点:
- 主要是通过策略研发人员自己通过 Matlab等第三方工具,工具限制很多,使用不方便,研发效率低,不能转成实盘策略,或者需要大量修改代码,修改容易出错。
- 研发机器性能限制,不能很好的利用分布式高计算的优势,找出最优策略实例的参数配置,策略研发周期长。
- 第三方工具不能很好的与现有交易系统集成,很多重复工作要做。
策略研发人员希望:
- 新系统能快速进行策略回测,从大量的参数组合中,找出最优的一些参数配置的组合。
- 回测策略能平稳过渡到实盘策略中。
- 最好能与现有交易系统集成,减少很多重复工作。
1.3 主要设计目标
- 高性能计算
充分利用分布式系统高性能计算优势,以最快的回测速度,从大量策略参数组合中找出最优的参数组合的策略实例。
- 提高研发效率
辅助策略研发人员,快速开发出优质的实盘策略,提高策略研发效率。
- 减少实盘风险
2. 设计需求
2.1 功能需求
- 支持多客户端同时使用,每个用户平均分配计算资源
- 支持策略回测任务控制功能,包括任务启动,暂停等操作。
- 回测策略容器支持Python和C++编写策略。
- 支持策略参数断点回测。
系统重启时,已经回测的子任务不用重新计算,只需从未完成的任务开始进行。
- 查询策略参数回测运行结果。
- 回测进度更新及汇总分析推送
2.2 非功能需求
- 高性能
充分利用计算服务器CPU和内存资源,尽可能快的得到策略参数回测结果。
- 支持同时上万组策略参数进行回测。
- 系统根据计算负载大小,为用户平均分配计算资源,支持灵活调整(增加或减少)计算资源。
假设有两台回测服务器,每台服务器有10个计算资源,有两个回测任务,第一个回测任务有30套计算参数,第二个回测任务有40套计算参数。
系统刚开始只有一台回测服务器资源,客户A发起第一个回测任务。系统会分配10套回测子任务到回测服务器。接着系统又增加了一台回测服务器,每台机器上运行10套回测子任务。紧接着客户
B发起了第二个回测任务,系统会关闭每台回测服务器上运行时间最短的5个子任务A,重新运行5个回测子任务B。那么每
台 回测服务器上5个子任务A和5个子任务B.
- 回测策略与运行策略平稳过渡。
回测策略尽经过少量的修改就可以运行在策略交易平台。
3 系统功能设计
3.1任务调度管理服务器
接收客户端任务请求,进行任务的创建和子任务的分解,根据回测计算资源的状态,均衡分配回测任务给回测服务器,并将回测运行状态及分析汇总结果发送客户端。
3.2回测管理服务器
从任务调度服务器接收回测子任务请求,根据子任务类型,启动Python或C++策略回测进程,并将回测进度和回测分析汇总结果发送任务调度服务器。
3.3 Python策略回测运行容器
设计参考交易系统策略引擎,提供给策略人员开发接口应保持一致。
3.4 C++策略回测运行容器
设计参考交易系统策略引擎,提供策略人员开发接口应保持一致。
3.5行情数据管理模块
- 对历史行情数据进行管理
创建多级历史数据缓存和缓存数据管理,对本地行情文件进行管理。
- 各种历史行情查询访问
统一对外提供高速数据访问接口,为策略回测进程程序提供数据服务。
3.6业务处理流程
- 回测任务处理流程
4.总体架构