说到vnpy我想大部分quanter都非常熟悉,从2015年至今短短6年时间,不论是社区,还是代码更新量都是无与伦比的庞大。我第一次接触量化使用的也是vnpy,后来辗转反侧入到了C++的坑。
1. 技术解析:
a、运行环境:Windows7以上版本、Ubuntu、Linux
b、开发语言:python3.7
c、依赖库:pyqt、talib、websocket等
d、系统层次:
量化研究QRI
e、人工配置:
通过 .json 文件配置相关账户参数
VNPY整体结构采用的微服务结构,设计思路是数据驱动,引擎牵引,应用挂靠。 从业务出发,所有的交易都是基于行情的反应,有了行情才有信号,才有委托,才有持仓和风控。 从技术角度看,数据来源于API(CTP,LTS,币圈接口)等,可以说数据驱动了一切。
VNPY的引擎包括:主引擎,事件引擎,数据引擎和应用引擎。 引擎的作用有点类似电脑的主板,所有的东西都往上插,这也是微服务设计的主要特点。如果需要资源,就向引擎要。 VNPY主引擎驱动Gateway(延伸到各行情交易CTP),使用了消息引擎(EventEngine)把所有Gateway发过来的数据分发到各个内部的外部的引用。
内部的应用包括数据引擎,主界面等,外部应用包括风控管理,CTA策略,算法交易等各应用。 在应用里面,VNPY又设计了应用引擎来带动各策略组,给策略组提供服务。 同时VNPY主引擎提供了,订阅,委托,撤单,数据库操作等接口给各个内部的,外部的APP。
数据服务作为多个独立应用程序,来实现数据的下载,整理,保存。 供策略回测使用。从性能的角度来说Python性能会极大的牵制了回测部分的功能。
量化研究QRI
量化研究QRI
软件启动流程:
量化研究QRI
数据以及行情订阅流程:
量化研究QRI
整体设计的核心在于中心化引擎模块,他就像个粘合剂,将上层应用和中间service和底层的数据做了粘合。基于事件驱动的框架,本身vnpy也定义了很多事件类型。
量化研究QRI
基本每一次数据交互都是一次事件响应的过程。
这里需要强调的是,vnpy的核心之一就是数据订阅。订阅的目的就是和交易所服务器建立通讯联系。时间驱动很多时候都是被动驱动的模式,有了数据交互和被动推送之后才会有对应的事件行为。比如交易所推了一个tick,驱动了ontick事件,触发对应的事件引擎,驱动事件发生。
2、使用难度
vnpy主打的就是开箱即用的思路,但是从测试来看,除了CTP的行情接入和交易最方便也最好用以外,数字货币交易可能需要花点事件来做调试。
这点其实和vnpy的整体设计关系并不大,数字货币交易所很多接口确实很难统一规整,除非下大功夫,做一个独立模块出来,不然为了匹配CTP模块确实很难做到高度统一。
很贴心的是,vnpy官方也提供了Windows开箱即用的安装包。
量化研究QRI
对于新手小白入门确实是一件非常非常简单的事儿。
你可以根据自己的策略类型,做出相应的选择,demo中都给出了相应的数据模块和策略模板。
量化研究QRI
对于初级使用者非常友好。
如果你不知道怎么去使用官方也给出了很多demo测试案例供你选择学习。
https://www.vnpy.com/demo
这可能就是开源所带来的好处,社区完善,资料齐全,案例丰富。基本上你能遇到问题,在相应的群里或者社区提问都能第一时间有人为你解答,这是我测试过程中最大的体会。
3、策略编写难度
策略方面,vnpy自身携带了很多案例策略。学习起来难度并不大,但是这里需要一定的code能力。
自带的CTA策略模板为策略编写提供了基础的框架。
量化研究QRI
在template.py模板文件中我们可以看到以下三个类。
CtaTemplate——>Cta策略模板
CtaSignal——>Cta信号模板,负责产生信号,不参与具体交易事务
TargetPosTemplate——>为允许直接通过修改目标持仓来实现交易的策略模板,该模板实现的是开发策略时,无需再调用buy/sell/cover/short这些具体的委托指令, 只需在策略逻辑运行完成后调用setTargetPos设置目标持仓,底层算法会自动完成相关交易,适合不擅长管理交易挂撤单细节的用户。
纵观以上几个类,主要分为以下几个方法:
1、策略管理类:初始化、启停,
2、k线管理类:ontick、onbar
3、指令管理类:委托类(sell、buy、short、cover),onOrder,Ontrader
4、历史数据管理类:insertTick、 insertBar、saveSyncData、getPriceTick
基本方法集合:
- 构造函数
- __init__函数:参数包括引擎对象(回测or实盘)和参数配置字典
- 回调函数
- onInit:策略初始化时被调用,通常在这里加载历史数据回放(调用onTick或者onBar)来初始化策略状态
- onStart:策略启动时被调用
- onStop:策略停止时被调用,通常会撤销掉全部活动委托
- onTick:收到Tick推送时调用,对于非Tick级策略会在这里合成K线后调用onBar
- onBar:回测收到新的K线时调用,实盘由onTick来调用,通常在这里写策略主逻辑
- onOrder:收到委托回报时调用,用户可以缓存委托状态数据便于后续使用
- onStopOrder:收到本地停止单状态变化时调用
- onTrade:收到成交时调用
- 交易函数
- buy:买入开仓,返回委托号vtOrderID,下同
- sell:卖出平仓
- short:卖出开仓
- cover:买入平仓
- cancelOrder:撤销委托,传入的参数是需撤的委托号vtOrderID
- 其他函数
- getEngineType:获取引擎类型,用于判断当前是回测还是实盘
- writeCtaLog:发出CTA日志事件,会显示在CTA策略模块的监控界面上
- putEvent:发出策略更新事件,通知CTA策略模块的监控界面更新策略的状态数据
- loadTick:从历史行情数据库中加载Tick数据
- loadBar:从历史行情数据库中加载K线数据
- insertTick:记录Tick数据到数据库中
- insertBar:记录K线数据到数据库中(通常只有在策略基于非标准K线时才用)
TargetPosTemplate基于CtaTemplate实现,增加了一个setTargetPos函数,用户只需在交易信号出现后指定目标仓位,具体的挂撤单操作会由策略自动执行。
根据策略模板函数,把相应的函数功能了解清楚,根据策略需求查看是否需要对应的函数功能,就很容易把策略的基础框架搭起来,剩下的就是按照自己的数据需求去建模,编写策略核心模块,上面说到这里需要一定的代码基础其实主要体现的就是这里,不同方法和自定义方法之间的调用和数据传输需要一定的代码能力。
4、风控难度
vnpy里面封装了独立的风控模块来帮助用户做好风控。
risk_manager:风险管理模块,提供包括交易流控、下单数量、活动委托、撤单总数等规则的统计和限制,有效实现前端风控功能
量化研究QRI
整个风控模块的代码非常简洁。
总结下来就是以下几个功能:
1、订单委托量的控制
2、单位之间内委托量的控制
3、活动委托数量的控制
4、撤单频率的控制
常规风控体系分类其实每个人的使用是不同的。主要还是看具体需求:
主要内容:
(1)五层体系:资金、交易、评估、策略、组合
(2)风险分散:多周期组合、多品种策略、降低单一市场内风险
(3)严谨执行:通过流量控制降低操作风险、通过资金回撤止损降低市场风险、通过交易端降低交易价格风险
(4)风控策略:单独执行风控策略,将市场风险进行评估,供交易策略进行调节。
应该掌握:
(1)5层风控体系
(2)弹性舱位控制
按照上面的基础功能,vnpy可以完整的实现具体细则。
5、代码完整度
代码完整度其实对于vnpy的主要问题就是改bug的过程。对于开箱即用的这个说法在国内传统市场上表现非常好,可是对于周边的数字货币市场其实开箱即用是比较难的。再加上python语言本身每个人的书写习惯和编程的泛型约束性比较弱,所以很难达到高度统一。需要花点时间去打磨一下整体的代码,才能说得上放心去使用,不然你可能会在实盘中遇到各种各样的问题。
不过基于vnpy庞大的社区,我想很多问题都可以得到快速解决。我们后期也会整理出完整的学习和改进教程供大家学习参考,希望大家可以持续关注我们,另外针对不同市场我们后期也会针对大家的需求,按照vnpy的设计思路,整合对应独立市场的交易系统,毕竟币圈和国内传统市场差别千万,为了让大家使用方便,我们也会做相应的调试和二次编写,并且开源出来供大家学习使用。
6、二次开发难易度
对于完全开放源码社区庞大的系统来说,只要你代码能力过得去,二次开发没什么问题,就算重构都没有任何问题。
7、系统性能测评
对于性能这块,我之前也是使用过vnpy的用户,再加上我是做的币圈的超高频交易,本身python的单线程特性如果用在低延迟频率不是那么高的交易上其实没有任何问题,但是如果你的频率的计算一旦上去了,那么你会觉得python的设计很鸡肋,你需要附加很多其他的第三方的东西来辅助自己的策略运行,这样无形中增加了策略编写的难度,所以我后来从python转向了c++,但并不代表python不好,只要你的频率不是那么高,就可以很好的完成你的策略,而且效率非常高。
如果要在vnpy中实现高频交易你需要做的就是继承CtaTemplate基类,在基类中实现你的策略逻辑。切记频率不要太快,控制在1M左右的事件比较好,太快可能会出现意想不到的问题。
系统资源消耗率测评
性能这块我们使用了一台Windows10系统。
量化研究QRI
系统参数如上,开了一整天跑的模拟交易,目前看来系统使用
量化研究QRI
应该不算是很占用系统资源的。