《WonderTrader架构详解》系列文章,上周介绍了WonderTrader的数据处理机制。当平台解决了策略的数据问题之后,就须要向策略提供稳定可靠的信号执行机制,保证策略的信号被正确的执行,是每个平台最基本的功能。所以,本文做为系列文章的第三篇,将主要介绍WonderTrader信号执行的处理机制。git
往期文章列表:github
WonderTrader设计了一种执行架构,该执行架构能够将一个策略组合的信号,分发到若干个执行通道执行,咱们称之为1+N执行架构。为何会把信号执行设计成这样呢?算法
对于策略来讲,最核心的任务是抓住赚钱的因子。可是交易的过程当中,会涉及到行情的接入和订单回报的处理。市面上有很多平台,选择直接将这样的回报暴露给策略。在这类平台上,策略除了核心逻辑之外,还须要写不少重复的订单管理逻辑。有些平台甚至将底层接口的数据结构直接暴露给策略,这样作的结果是给策略引入了更多的复杂度,除了管理回报,还须要对不一样的接口作数据的兼容处理。
WonderTrader的一个设计目标就是是要给策略研发人员作减法,让他们将更多的精力放到策略自己,而不是如何和接口打交道。 1+N执行架构,也正是基于这条基本原则。由于 信号和执行完全剥离,因此策略不须要关注任何回报,由于底层会将执行这块处理得很好,策略只须要关注本身的目标头寸和进出场的价格便可。这样就 大大简化了策略的编写,只须要 将信号计算的核心逻辑实现好就能够了。
当咱们只有一个策略时,最简单的方式,就是把策略写成一个小型的平台,本身处理行情回报和交易回报,再针对特定的需求作一些功能扩展便可。而这种作法,容易把平台作成一个“玩具”,不具有管理大规模产品的基础,有不少量化交易框架都相似这种。
对于大规模的产品管理,最基本的需求就是 多个策略造成一个组合共同交易,而一个策略组合又同时在多个产品进行交易。而不一样资金规模的产品,在发出交易指令的时候,所须要的执行算法也是不同的。好比 买入100手和买入1手某期货合约,显然就不能用彻底同样的方式下单。
1+N执行架构很重要的一方面就是 针对大规模产品管理的需求。相同的策略组合,在 不一样的交易通道下,会根据产品的资金规模和风险偏好 配置不一样的交易数量放大倍数。而交易数量的不一样,有须要针对不一样的交易通道 配置不一样的执行算法,这样才能让各个产品都能 得到更好的执行价格。
1+N执行架构下,须要把策略分为两类策略: 重逻辑轻操做的策略和 轻逻辑重操做的策略。 大多数趋势类策略都属于前者,而几乎全部的高频策略都属于后者。
重逻辑轻操做的策略,最显著的特色就是 信号出现时必需要执行到位。这类策略,还表现出频率较低(相对高频而言), 对滑点敏感度低等特色。而这类策略就是 1+N执行架构主要服务的策略,这类策略也很容易经过 1+N执行架构扩展到更多的交易通道。
相对的, 轻逻辑重操做的策略,最显著的特色就是 信号出现时,要看执行的状况,才能决定下一步如何应对。这类策略最多见的就是 套利策略和 高频策略,它们须要 不停地挂单试探盘口的状况,才能作出更有利的决策。显然 1+N执行架构没法知足这类策略,因此 WonderTrader专门针对这类策略提供了 HFT引擎,该引擎将交易接口和交易 回报直接暴露给策略,这样策略就能根据回报执行管理订单。
在量化领域中,对从业人员的成分划分,有一个颇有趣的分类方法: P-Quant和 Q-Quant。 P-Quant的共同属性是这些从业人员基本都有软件开发的 技术背景,拥有相对 较好的编码能力。而 Q-Quant则相反,通常 没有技术背景,编码能力相对较弱,可是在 策略建模、金融工程方面相对较强。
由于两类从业人员的背景和能力树的不一样,因此他们对于平台的需求也不大同样。 P-Quant编码能力相对较强,倾向于 平台提供核心的基础功能便可,他们能够 自行开发本身须要的各类功能,同时但愿 平台可以尽量低延时(P-Quant从事高频策略开发的比例更高); Q-quant编码能力相对较弱,则倾向于 平台提供更完善的基础设施和策略开发API,相对的,他们 对延时不那么敏感(固然若是平台可以作到更低延时,对他们一样有利),可是但愿 平台支持的应用场景更丰富一些(要知足不一样类型的策略的回测、实盘等需求)。
鉴于以上提到的几个方面,WonderTrader最终决定针对CTA策略,基于信号和执行的剥离,采用1+N执行架构进行实盘交易。而针对HFT策略,则选择将交易接口直接暴露给策略(不一样交易接口的差别被封装到交易模块中,策略处理的交易接口是无差异的),让策略自行管理订单,转而在数据需求上提供支持。这样就能兼顾不一样类型的策略的不一样的应用场景,让不一样类型的策略都能在WonderTrader中能够更高效的管理起来。segmentfault
对于CTA引擎,既然采用1+N执行架构,就意味着平台须要管理两套头寸,一套是策略的理论头寸,一套是交易通道的实际头寸。在实盘运行中,咱们须要对两套头寸分别进行管理。服务器
理论头寸的管理,也分为两个层面。第一个是 策略层面,即 每一个策略有本身的理论头寸,包括进出场的时间、价格、方向、数量等。策略能够管理的也只能是本身的理论部位, 每一个策略都是互相隔离的。持有的头寸,再实时计算浮动盈亏,并核算最大潜在浮盈和最大潜在浮亏等数据。 回测的时候,数据都在内存中, 不须要实时保存。而 实盘环境下,要考虑策略重启等各类状况,因此数据须要 实时保存到文件中。
第二个是 组合层面,即策略的目标头寸整合到一块儿之后,造成一个 净头寸。这个净头寸本质上和策略的理论头寸是一致的,只不过是轧平过相反的头寸之后, 归属于策略组合管理。策略组合也要实时计算浮动盈亏,同时根据预设的资金规模,计算资金风险指标,进行实时风控。 实盘环境下,数据也要实时保存到文件中(回测引擎针对单策略,因此不存在策略组合的概念)。
策略组合的头寸是最终分发到各个交易通道的 基础目标头寸。每一个交易通道,会根据所对应产品的资金规模和风险需求分别配置本身的放大倍数,基础为1倍,支持小数倍数,会自动作四舍五入的处理。
每一个执行通道肯定了本身的 实际目标头寸之后,跟本身当前 实际持有的头寸进行比较,将有 差异的头寸,根据预设的 执行算法( WonderTrader内置的是以最新价、最优价和对手价三个价格做为 基础价格,再加上一个滑价跳数做为限价,基本上知足了绝大部分资金规模有限的策略需求)发出下单指令。并根据 订单回报和 成交回报实时更新 持仓状态和 订单状态。
正如前面所说, 不一样资金规模的策略,最终成交的价格是不一样的,更况且不一样的交易通道仍是依赖相同的信号进行交易的,并发执行的前提下,不一样交易通道的订单最终也会在交易所进行竞争。这就形成一个客观的事实: 相同策略在不一样产品中的实盘表现必定是有差别的,而差别的来源就是滑点。
回测的时候,咱们通常用小手数进行回测,因此通常状况下都 不考虑滑点。可是 实盘环境下,滑点问题就不可避免。这也是咱们内置的执行算法,都是以限价单下单的根本缘由。通常状况下,笔者建议 放大倍数大的交易通道,执行算法中 预设的滑价能够相对放大倍数小的交易通道 设置得更大一些(最终要根据流动性判断)。这样即便产生滑点,也在能够接受的范围以内。若是使用市价单发出下单指令,极端行情下,最终产生的滑点可能会压缩掉所有的利润。
前面基本介绍了1+N执行架构基本原理。从WonderTrader的角度来讲,所谓的1+N其实也有两层意思:N个策略在1个组合中共同运行,而1个组合又同时在N个交易通道进行交易。因此一开始的时候笔者有意称之为N+1+N执行架构。显然,无论从哪方面来讲,1+N执行架构的意义是非凡的:数据结构
投研人员的技术栈实际上是策略coding
的核心问题,咱们选择一个平台的时候,应该 尽可能的减小技术栈的引入。而通常交易接口都是异步回调的,若是强行要策略投研人员深刻了解这类纯技术技能,从团队管理的角度来讲,是低效的。同时对于投研人员来讲,花太多的精力到自身技能树的分支上,也不是一个聪明的选择,更况且技术自己也并不那么容易。
因此 策略和执行的剥离,对大部分投研人员,尤为是 Q-Quants来讲,是一种很是友好的设计。这样的设计固然也不是 WonderTrader独创的,笔者也从同事的实际需求中和其余的量化平台吸取了一些经验。
对于策略来讲, 风控是必不可少的,一样策略组合的风控也是平台的重点之一。风控中,除了 资金风控之外,还有一个 合规风控。绩效回撤了,能够再赚,可是若是合规风控过线了,可能会引发很是大的麻烦。其中最重要的合规风控点就是自成交。 自成交次数过多,手数过大,很容易被认定为对敲操控市场,相应的处罚也是很是严厉的。
WonderTrader须要解决多策略在多产品运营的问题, 首要考虑的就是合规性的问题。若是两个策略同时发出相反的交易信号,而且分发到多个产品同时下单,自成交的风险就会被放大。因此 WonderTrader经过在策略组合中 轧平相反头寸,最终以 净头寸的方式发出下单指令。除了自然避免自成交的问题,同时还能 节省佣金、 减小保证金的占用。策略组合内部,策略有本身的理论头寸,不受组合头寸的影响。
笔者此前,常常会被投资人问:大家怎么保证各个产品绩效的一致性的?笔者没有太多去研究别家是怎么处理的,可是对于 WonderTrader的 1+N执行架构来讲,这样的问题就显得太简单了。
即便两个规模同样的产品,用同一套策略交易,绩效也不可能彻底同样。由于即便同时下单,也受到交易通道速度的影响。可是不能保证绩效的彻底一致性,保证信号的彻底一致性倒是没有问题的。
专业投资机构对于交易平台的需求,和我的投资者仍是有很大差异的。最核心的一点就是 大规模的产品如何管理的问题。例如某些头部私募,发了数百只产品,假设只有一百只产品须要实际操做,而每只产品都须要交易股票、期货、期权等标的。
若是不从架构上解决这样的需求,对于这些机构的IT
来讲,这基本上是一个灾难:在不一样的服务器上部署策略运行环境,天天还要监控各台服务器在开盘前是否正常运行。甚至有些柜台要到开盘前才会启动,这就使得运维人员的检查时间窗口只能限定在半个小时甚至更短的时间范围内。
WonderTrader的需求就从大规模产品管理中来,一开始的设计目标也是要知足大规模产品管理的需求。而 1+N执行架构正是针对这样的需求的核心机制。
本文对WonderTrader的信号执行机制的介绍就到此结束了,相信经过本文,各位读者可以对WonderTrader的1+N执行架构有一个更深刻的了解,也但愿本文可以在各位读者在遇到相似问题的的时候,对你们有所启发。笔者水平有限,不免有错漏之处,还请各位朋友多多包涵指正。下一篇,笔者将围绕平台如何兼容不一样的策略,来介绍WonderTrader不一样的策略引擎的底层逻辑,望各位读者届时多多捧场。架构
最后再安利一下WonderTrader
WonderTrader旨在给各位量化从业人员提供更好的轮子,将技术相关的东西都封装在平台中,力求给策略研发带来更好的策略开发体验。并发
WonderTrader的github
地址:https://github.com/wondertrad...框架
WonderTrader官网地址:https://wondertrader.github.io运维
wtpy的github
地址:https://github.com/wondertrad...
市场有风险,投资需谨慎。以上陈述仅做为对于历史事件的回顾,不表明对将来的观点,同时不做为任何投资建议。