共计 5684 个字符，预计需要花费 15 分钟才能阅读完成。
前言
《WonderTrader架构详解》系列文章，上一篇介绍了 WonderTrader 的信号执行的解决机制 。平台的数据和信号执行机制曾经实现当前，接下来就是要思考如何生成信号了，也就是说策略如何编写。在解决策略编写的问题之前，首先要解决的就是平台要反对哪些策略。本文作为系列文章的第四篇，将针对WonderTrader 对不同策略的反对 展开讨论。
往期文章列表：
- WonderTrader 架构详解之一——整体架构
- WonderTrader 架构详解之二——从数据说起
- WonderTrader 架构详解之三——信号与执行
策略的分类
如何对策略进行分类，这个问题自身就很简单。很多介绍策略的书都会对策略进行一个分类，而后再开展介绍，然而每位作者都有本人的分类规范，所以每本书里介绍的策略分类也不尽相同。笔者已经拜读过几本，比拟有代表性的就是丁鹏的《量化投资——策略与技术》。这本书里大抵分为以下几个大类策略：
量化选股策略
- 多因子选股
- 格调轮动选股
- 行业轮动选股
- 资金流选股
- 动量反转选股
- ……
量化择时策略
- 趋势追踪择时
- 市场情绪择时
- 无效资金择时
- 牛熊线择时
- Hurst 指数择时
- …
股指期货套利
- 期现套
- 跨期套
商品期货套利
- 期现套
- 跨期套
- 跨种类套利
- 跨市场套利
统计套利
- 配对交易
- 股指套利
- 融券套利
- 外汇套利
- ……
然而对于量化平台来说，以上的分类都没有理论的意义。为什么呢？因为平台须要思考的是 从技术角度如何对策略进行分类，而下面展现的策略分类都是从策略实现的逻辑和指标交易种类来进行分类的。
那么从技术实现的角度角度对策略进行分类要思考哪些问题呢？
行情数据的需要
从技术实现的角度来说，策略对数据的需要会引起很大的架构变动。比如说有些策略须要 K 线数据进行信号的计算，有些策略须要
tick数据进行信号的计算，而有些策略同时须要K 线数据和tick数据进行计算。平台在对策略凋谢接口的时候，就必须要思考到不同策略的数据需要 。
以趋势追踪策略为例，趋势追踪策略个别应用K 线数据进行信号计算，然而在理论经营的过程中可能也须要利用实时的tick数据进行一个止盈止损逻辑的触发。
平台在思考策略对数据的需要的同时，还须要思考 在实盘过程中对策略所须要的数据如何进行缓存、如何进行实时的更新、以及如何传递给策略。信号执行的需要
策略对信号执行的需要，次要是 执行响应速度 和执行办法 两个方面。对于很多 日频调仓的策略 来说，如多因子选股，个别状况下须要执行较大数量的调仓，对于执行的要求绝对较低，次要依据执行当天的均匀成交价作为一个参考基准，在一天内执行实现即可。而对于 高频策略 来说，单次执行的数量个别较少，须要立刻响应信号，在微秒级的提早下收回下单指令。而对于 日内调仓的策略 来说，单次执行的数量介于多因子和高频之间，对执行的要求也介于二者之间：一方面不心愿太大的提早，造成太大的滑点；另一方面须要也不可能以一天的成交均价作为基准，反而以下一个周期的开盘价作为成交价的参考基准。
重算调度的需要
不论是何种策略，都须要一个机制驱动策略进行外围逻辑的计算 。个别策略采纳的驱动形式次要是 事件驱动 和工夫驱动 。 工夫驱动 ，就是到了某个规定确定的工夫节点，驱动策略的外围逻辑进行重算。而 事件驱动 ，咱们这里次要指的是
K 线闭合、K 线开始、tick进入等事件。对于基于K 线的日内趋势策略，个别须要在K 线闭合的时候进行重算；而基于日 K 线的跨日趋势策略，则能够在开盘后到第二天收盘前进行重算；对于高频策略，则须要在每一笔tick到来的时候进行重算。跟踪标的的需要
跟踪标的的需要，次要思考的是 跟踪的标的数量。如果你是做国内商品期货的，个别状况下，即便沉闷种类的主力合约全副跟踪，也只有 40 多个。而如果要跟踪沪深 300 的成分股、或者中证 1000 的成分股，那么如何设计才可能满足这样的利用场景，就是一个十分重要的问题。
综合下面几点，WonderTrader最终从技术实现的角度将策略分类成三个大类：
日内趋势类策略
日内趋势类策略，不是说策略只做日内交易，而是指策略会 在日内触发信号，即在交易工夫内的某个工夫点触发信号 。这类策略个别策略逻辑都是基于
分钟 K 线数据进行外围逻辑的重算，利用tick数据进行止盈止损逻辑的计算。这类策略信号强度个别较高，不须要在执行的过程中依据订单的成交状况动静调整执行策略 ， 可能容忍肯定水平的滑点 ，属于笔者在上一篇《 信号与执行 》中提到的“ 重逻辑轻执行”的策略。高频类策略
高频类策略，次要利用
tick数据触发外围逻辑重算，对于信号响应的 提早特地敏感 ，而且呈现信号当前，还 须要依据订单的执行状况实时调整信号 。这类策略的 盈利空间很小 所以 对滑点的容忍度非常低 ，因而须要平台解决信号要尽可能地快，属于笔者在上一篇《 信号与执行 》中提到的“ 轻逻辑重执行”的策略。选股类策略
选股类策略，次要指的是 日频以上周期调仓的策略 ，以 多因子选股策略 为代表，所以称为选股类策略。选股类策略，计算量大 、 计算工夫长 ， 资金容量大 ，信号的特点是 数量大 ， 对滑点也不敏感 。因而这类策略对于信号执行的成果容忍度也比拟高。不过正是因为这些特点， 选股类策略如果搭配更适合的执行算法的话，对绩效能够晋升好几个点。对于大规模的资金容量来说，几个点的晋升也是一个十分可观的数字了。因而选股类策略，对执行算法的需要，就体现须要在更长的时间跨度上，找到更适合的交易点。
WonderTrader 的策略引擎
针对下面的策略技术分类，WonderTrader提供了三种策略引擎，以满足不同类型策略的需要。
CTA 引擎
CTA 引擎 （类名WtCtaEngine），是WonderTrader 针对 日内趋势类策略 设计的策略引擎，因为最早次要是针对 CTA 策略的，所以引擎名字就依照 CTAEngine 沿用下来了。
CTA策略在初始化的时候，会向 CTA 引擎 订阅一个 主 K 线 ，也能够同时订阅其余周期或者其余种类的 K 线。CTATicker 收到行情当前，会依据工夫戳判断是否有 K 线 闭合，如果有 K 线 闭合，则触发策略的 on_bar 回调；如果闭合的是 主 K 线 ，则查看是否所有的 K 线 都曾经闭合；如果所有 K 线 都曾经闭合，则触发策略的 on_schedule 回调进行策略 外围逻辑的重算 。如果呈现新的信号，则由CTAEngine 汇总当前失去一个指标组合，再丢给执行管理器。执行管理器则将指标组合散发到各个执行通道，并由执行通道转成交易指令下达交易所。如果没有 K 线 闭合或者 K 线 闭合事件曾经解决实现，再触发策略的 on_tick 回调进行风控运算。
下图展现了 CTA 引擎 中策略 信号产生和执行的根本流程：
HFT 引擎
HFT 引擎 （类名WtHftEngine），是WonderTrader 针对 高频类策略 设计的策略引擎。
HFT策略在初始化的时候，会向 HFT 引擎 订阅一些合约的 tick 数据（如果通道反对的话，还能够订阅股票 Level2 数据），也能够订阅 K 线 数据（不分主次）。HFTTicker收到行情当前，和 CTA 引擎不同的是，不会查看是否有 K 线 闭合，而是间接触发策略的 on_tick 回调进行外围逻辑的重算。如果呈现新的信号，则间接通过交易通道收回交易指令。交易通道收到 订单回报 当前，会触发策略的 on_order 回调，如果策略有调整，则再收回新的交易指令。交易通道收到 成交回报 当前，会触发策略的 on_trade 回调，如果有相应的调整，又会收回新的交易指令。
下图展现了 HFT 引擎 中策略 信号产生和执行的根本流程：
SEL 引擎
SEL 引擎 （类名WtSelEngine），是WonderTrader 针对 选股类策略 设计的策略引擎。因为选股类策略具备 计算工夫长 和计算量大 的特点，并且通常是 非交易工夫重算 ，所以SEL 引擎实质上是一个 工夫驱动 的引擎。SEL引擎在设计的时候，要兼顾 盘后计算 和盘中计算 两种需要，所以整个策略的重算是 异步 的。
SEL策略在初始化的时候，会向 SEL 引擎 注册一个工夫驱动的策略。例如每天、每周、每月、每年指定的工夫触发重算，或者在交易工夫内每 N 分钟触发重算。在非交易工夫，因为没有行情接入，所以 SEL 引擎会依据本地工夫进行比拟，如果满足工夫条件，则触发策略的 on_schedule 回调进行外围逻辑的重算。如果注册的是交易工夫内的分钟线驱动，则通过 SELTicker 依据最新接管到的 tick 数据的工夫戳进行行情工夫同步，再触发策略的 on_schedule 回调进行外围逻辑的重算。如果有新的信号产生，则将指标组合丢给执行管理器。执行管理器则将指标组合散发到各个执行通道，执行通道会依据预设的算法交易进行拆单，并依据算法交易的逻辑在适合的实机会由执行通道转成交易指令下达交易所。
策略引擎现状的思考
后面介绍的 WonderTrader 不同的策略引擎的外围逻辑，曾经基本上能够笼罩市面上绝大部分策略调度的需要了。不过对于 WonderTrader 的策略引擎，笔者目前也存在一些疑虑。
HFT 引擎对做市策略的反对
WonderTrader为了简化策略的逻辑，将策略的信号全副简化为 买和 卖。这样的简化，省掉了策略研发人员很多事件，比方：到底是买开还是买平？可平今仓残余多少、可平昨仓残余多少？当初买进的信号要拆成几个单子下进来？单笔下单的最大数量是多少？WonderTrader会把这些问题全副主动解决掉。比方：主动依据持仓确定是开仓还是平仓；主动依据预设的开平计划管制是平仓还是锁仓；主动依据可平数量拆分信号为多个订单。笔者置信绝大部分策略研发都会喜爱这样的简化，然而有一种策略可能会例外：做市策略。
做市策略个别的交易逻辑是在 高位挂一个卖单，同时在低位挂一个买单 ，通过赚取两个单子之间的价差获取收益。问题在于，如果依照后面提到的一些主动解决计划，开始的时候是没有持仓的，同时挂的两个订单成交当前，持仓呈 一多一空 的状态，净头寸依然为0。如果这个时候呈现第二轮信号，就可能会呈现一些问题：买入订单会平掉空头的头寸，卖出订单会平掉多头的头寸。持仓的状况会如此重复，对于有些策略来说可能就不大适应了。
SEL 引擎回测的难点
SEL引擎回测的难点起源于实盘中的策略的 外围逻辑是异步执行 的。比如说，t0时刻触发了策略的重算，重算工夫较长，始终继续到 t1 时刻。如果在生产环境下，间接在 t1 时刻执行新的信号即可。然而对于回测环境下，如果采纳同步回测的形式，回测时执行的价格为 t0 时刻的 p0；如果采纳异步形式回测的话，回测行情回放的工夫又比生产环境快很多，到了t1 时刻行情早已回放超过 t1 了，这时的执行价格变成了 t2 时刻的 p2 了，而不是 t1 时刻的 p1。综合来说，SEL 引擎回测后果的参考价值要比 CTA 引擎小很多。笔者也已经思考过，依据重算工夫 t，计算t0+t 时刻，找到该时刻的 pt 作为执行价格。这样的解决形式看起来比拟可行，然而也会引入更多的复杂度。
WonderTrader 的布局
后面大抵介绍了 WonderTrader 各个策略引擎的一些根本状况。通过多方调研，笔者认为从底层来说 WonderTrader 反对的利用场景曾经足够丰盛了。然而在 WonderTrader 使用和推广的过程中，笔者也发现了一些预计之外的需要，这些也是前面 WonderTrader 欠缺的方向。
欠缺交易接口
目前来说，WonderTrader只反对一般的交易接口，能够抽象地概括为 现金业务 的交易接口。实际上还有其余业务类型，例如 ETF 申赎、 期权询价报价 、 期权行权 、 两融业务 等等。笔者前面会依据理论的须要逐渐的欠缺这些接口，让 WonderTrader 反对更多的业务类型。
适配更多种类
从 WonderTrader 目前的推广的反馈来看，不少用户心愿利用 WonderTrader 进行数字货币的交易。而后因为数字货币 7×24 小时交易的特点，目前 WonderTrader 还不能很好的反对。抛开技术细节不谈，本源还是在于 WonderTrader 原本设计的指标就是针对惯例的交易市场的，即便是 NYMEX 这样的交易所，每天也有 1 个小时的休市工夫。当然，这不能成为 WonderTrader 固步自封的理由，所以将来 WonderTrader 也会逐笔欠缺对不同市场和不同种类的适配。
为应用层凋谢性能扩大接口
WonderTrader在设计的时候，为了保障底层的执行效率，所有的性能组件都是用 C++ 开发的。功夫不负有心人，WonderTrader零碎外部提早，在个别台式机上也能达到 10 微秒以内。然而在推广的过程中，笔者发现局部用户实际上是基于wtpy 做开发的，并没有 C++ 的开发能力。然而这样的用户想要做一些二次开发的话，都须要 C++ 底层做同步调整，于是这些用户只能望而生畏了。鉴于这样的状况，笔者也重复斟酌了一下，打算在将来思考将 行情接入模块 、 交易模块 向应用层子框架开发。这样的益处就是，一些 二次开发的门槛也同步升高 了，能够丰盛 W onderTrader的生态，给不同需要的人群提供更丰盛的抉择。
结束语
本文对 WonderTrader 的策略引擎的介绍就到此结束了，心愿本文能给一些想要应用 WonderTrader 进行策略开发的敌人一些指引。笔者程度无限，不免有错漏之处，还请各位朋友多多包涵斧正。下一篇，笔者将针对不同的策略引擎，来具体介绍 WonderTrader 不同类型策略的回测的机制，望各位读者届时多多捧场。
最初再安利一下 WonderTrader
WonderTrader 旨在给各位量化从业人员提供更好的轮子，将技术相干的货色都封装在平台中，打造更高效的底层框架，力求给策略研发带来更好的策略开发和交易体验。
WonderTrader的 github 地址：https://github.com/wondertrad…
WonderTrader官网地址：https://wondertrader.github.io
wtpy的 github 地址：https://github.com/wondertrad…
市场有危险，投资需谨慎。以上陈说仅作为对于历史事件的回顾，不代表对将来的观点，同时不作为任何投资倡议。
