为什么要构建自己的量化系统
在使用了一段时间聚宽
平台的在线策略编辑模块之后,发现了几个让我自己用起来不太舒服的地方:
-
运行启动时间偏慢
因其环境隔离的特性,编译运行或者回测,都会启动一个Docker容器,在容器中进行。
-
回测时间偏慢且受限制
这方面应该属于是策略的问题。当回测的策略是每天进行选股交易时,需要频繁的多次访问数据库。并在内存中通过DataFrame进行计算。
在通常意义的工程看来,其实可以在数据库层面进行特定的优化。但特定的优化适合我的同时,未必适合其他平台用户。这也是平台类型的回测工具的受限的地方。
也是因为平台其不可能做善事,总要谋求收益去支付基础设施费用,甚至产生盈利。所以对于回测时间受限制是理解的。
-
需要熟悉其特定的API,换个平台需要重新熟悉,虽然平移成本相对较低
每个平台对于金融产品以及其衍生品的存储方式不一致,也会导致不同平台之间的API是特定的。然而其本质上还是这些金融产品以及其属性。因此如果在本地建立数据模型,对我而言会方便很多。
-
无法编组进行重复回测
因为我没有金融行业的从业经验,没有积累去看比如PE,换手率,价值面等理论之城。对于选股其实没有好的经验之城。那么我自己更适合的是依靠数据本身的变化来选择策略。因此,适合我的是,每个交易周期对于我已经编写的策略分数据范围的重复进行回测。记录其收益率等关键指标信息。然后选择一个最高的,按这个策略执行。
这就要求我的回测速度要非常快,否则等回测完,也就闭市了,就没有意义了。
因此,更适合我自己的策略运行方式,其实是搭建一个本地的数据集,以及寻找能够支撑本地数据的量化交易框架,在本地运行。初步的理想结构如下图所示:
设计详述
截止目前为止,我理解的量化交易系统分为三个部分,包含了金融产品数据的获取,策略的回测执行,以及策略的执行结果报告。(暂时不涉及到模拟盘交易以及实盘交易部分)。
对于三个部分,初步的设想理念如下:
Data Fetcher
在Data Fetcher
模块中,包含了几块内容:
-
SDK
目前市面上有非常多的金融产品数据获取的SDK,如:
Tushare
,Baostock
等。虽然是使用python语言编写,对于目前的我而言,只需要获取日级别的历史交易数据,以及金融产品的基本面数据即可。如果采用爬虫或者调用Http接口的方式去做,反而显得有点浪费。因此,在这里决定采用
python
的已有的SDK
作为初期数据的获取方式。在后期酌情考虑自研扩充SDK。 -
Scheduler
对于数据的获取,并不需要实时。对于日级别的行情数据完全可以在收盘之后进行获取,依据SDK提供方的数据处理时间进行。因此,需要一个调度器定时的执行数据获取逻辑。根据不同的任务设定不同的执行周期和触发时间点。因此,
Scheduler
通过读取配置信息方便后期进行随时调整 -
Data Writer
通过
SDK
获取的数据通过Data Writer
进行写入,在此做一层封装可以兼容更多的存储系统。比如,前期为了方便写入MySQL
,后期为了查询性能的提升,更改为Click House
等等. -
Config
封装了一层配置的存储方式。前期为了方便可以是文件类型的存储,后期可以更改为数据库系统,如
MySQL
等。
Strategy Tester
Strategy Tester
模块针对策略的回测进行工作,按照我的情况,需要在交易周期跑完所有的策略,并选中一个最符合期望的策略执行。因此其依赖调度器完成回测的调度。在初期为了实现简便,会采用轮询的方式进行调度,而在后期会根据自身对于策略的理解,采用更好的调度方式(诸如k8s 多pod并行调度等等)
另外Strategy Tester
需要提供一个实现策略的SDK,能够支持模拟买入,持仓信息查询等等。这块在研究了vnpy
之后再进行决定是否自研。
因此Strategy Tester
的核心部分由如下几块构成:
-
Strategy Collection(Strategy Pool)
策略池。这里存放的都是编写好的策略,策略本身根据SDK制定初始化,周期运行等核心代码。对于调度器而言,调度的就是这些策略。
-
Scheduler
调度器。调度器本身有自己的调度周期,可通过配置信息配置。另外,所调度的策略也存在一个周期策略,因此是由双重调度策略控制。
-
Parameter Controller
对于策略而言,其可对外暴露需要不断调试的参数信息。如:初始资金、交易时间范围、持仓时间等等。
-
MySQL
因为
Click House
更适合存储写入后修改频次低的数据,并提供稳定高性能的查询能力。因此对于参数、策略的调度等需要频繁变化的信息,更适合存储在MySQL
中
Result Reporter
Result Reporter
模块用于将策略的回测结果通过钉钉
或邮件
的方式通知给我。在初期用于监控策略的执行情况以及耗时,在后期用于监控根据我的期望选择策略是否准确。以及模拟盘、实盘的实际交易情况等等。
在后期更改为一个在线的网页,用于实施查看。
其包含如下核心模块:
-
Result Collector
策略执行的结果收集器,用于分析和筛选策略。
-
Trade Log
回测、模拟盘或实盘的交易行为日志。
-
System Log
系统运行的日志。包含调度执行,调度进度,执行的策略个数。以及运行中出错的信息。
-
Notifier
通知模块。封装钉钉或邮件通知的接口
问题与延伸
在上面的初步设想架构中,存在了一些问题:
- 缺少交易系统
- 缺少细化的数据流转示意
- 对于每个模块的开发语言并没有确认
- 对于回测框架的技术选型没有完成
针对上述问题,逐步的来解决。首先解决的是本地数据的问题:
思路为以A股为例,获取交易日历
,股票信息
,日行情数据
,并分开存储。其中交易日历和日行情数据不存在变更(或极低概率存在变更的场景,哪怕出现变更也可以删除原有数据重新建立),因此存储于Click House
更为合适。而股票信息
存在ST变更
,停牌
等情况。而且针对策略,也会实时更新是否涨停,是否跌停等信息。避免在每个交易周期的头部进行计算。因此,该信息存储于MySQL
更为合适。
另外,调度器的执行从数据库中读取其执行频率,为方便更改,存储于MySQL
更为合适。
接下来,就是尝试建立自己的本地数据...
标签:从零开始,存储,策略,调度,回测,构建,量化,数据,SDK From: https://www.cnblogs.com/budaomudesanye/p/17371591.html