从零开始量化交易 - 尝试构建自己的量化系统

为什么要构建自己的量化系统

在使用了一段时间聚宽平台的在线策略编辑模块之后，发现了几个让我自己用起来不太舒服的地方：

运行启动时间偏慢

因其环境隔离的特性，编译运行或者回测，都会启动一个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更为合适。

接下来，就是尝试建立自己的本地数据...