前言

  《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++底层做同步调整，于是这些用户只能望而生畏了。鉴于这样的状况，笔者也重复斟酌了一下，打算在将来思考将行情接入模块、交易模块向应用层子框架开发。这样的益处就是，一些二次开发的门槛也同步升高了，能够丰盛WonderTrader的生态，给不同需要的人群提供更丰盛的抉择。

结束语

  本文对WonderTrader的策略引擎的介绍就到此结束了，心愿本文能给一些想要应用WonderTrader进行策略开发的敌人一些指引。笔者程度无限，不免有错漏之处，还请各位朋友多多包涵斧正。下一篇，笔者将针对不同的策略引擎，来具体介绍WonderTrader不同类型策略的回测的机制，望各位读者届时多多捧场。

  最初再安利一下WonderTrader
  WonderTrader旨在给各位量化从业人员提供更好的轮子，将技术相干的货色都封装在平台中，打造更高效的底层框架，力求给策略研发带来更好的策略开发和交易体验。

WonderTrader的github地址：https://github.com/wondertrad...

WonderTrader官网地址：https://wondertrader.github.io

wtpy的github地址：https://github.com/wondertrad...

市场有危险，投资需谨慎。以上陈说仅作为对于历史事件的回顾，不代表对将来的观点，同时不作为任何投资倡议。