Quant必备工具箱：量化交易的技术框架
由polll创建，最终由small_q 被浏览 244 用户
2019年，定下一个小目标：做一套Quant的工具箱，一边学，一边做，也一边分享。欢迎小伙伴们前来围观、拍砖。
（tips：文末罗列了所有量化核心技术框架）
工具箱将立足于三个领域
- 量化开发——以交易后台开发为主
- 研究——以机器学习研究框架为主
- 交易——以期货和电子货币实盘为主
万水千山总是情，相信总有一款适合投身于量化领域的你。
第一期先听我BB一下量化开发（Developer），先讲总框架，之后再细究各个部分的设计和实现。
向量化回测系统
网络上已经存在了不少的开源回测框架和在线研究平台，他们都提供了完整的回测系统、归因分析，那为什么还需要自建一个回测系统？
因为慢。是的，很简单的一个原因。
那么回测快，很重要吗？重要。
假设一个简单的双均线策略，使用2005年至2018年的数据进行回测。
- 日线级别，某在线量化平台：60s
- 分钟线级别，离线向量化回测：0.1s
若将前者换算成分钟级别，二者相差5个数量级(A股每天交易240分钟 * 600倍)。
还不止如此，
- 如果策略里包含了3000只股票，每只股票10个标签
- 策略里往往都有2-3个参数，若每个参数有10个可取值，那么至少要在样本内回测1000次才能得到一个最优参数组合
- 策略不是一试就能出结果，不合适时要调整模型结构和逻辑，那么这个过程反复调整20次并不夸张。
如此算下来，用一整天时间很可能才跑出一个最优参数组合，而且还不能保证样本外效果良好，sad。
反过来，想象一下，如果以上过程仅在20秒内就全部结束，还能轮动回测多个时期，还能输出一份样本外的报告，你可以快速又直观地得知某个因子、或某个策略逻辑的效果，是否体验感会瞬间上升N个数量级呢。
好比机器学习，机器学习为什么比人更强，为什么alphago成为了世界第一的围棋高手，快就是其中的重要原因之一。因为快，所以能不断试错；试错更多，那么就能从中积累更多经验，学到更多知识。
所以速度快，很重要。你的时间就是最珍贵的财富。
技术解决方案：coming soon
技术栈要求: python xarray, empyrical, talib, mongo, hdf5
事件驱动回测系统
通过向量化的回测框架，你得以快速尝试和挖掘，终于回测到了一条不错的策略资金曲线，那么恭喜你，你通过自己的努力和创新发现了潜在的金矿。
但是，这仅仅是迈向圣杯的第一步。
你有没有考虑过：
- 订单的撮合。订单并不是发出后就能成交，特别是中高频策略这种尤为看重订单成交率的策略，并不是仅靠添加滑点就能模拟的来的。
- 风险控制。总会几个策略失效或者黑天鹅的瞬间，在这个时刻，你能不能检测到浮盈后立刻退出这笔交易，而不是呆呆地等到某根bar跑完了再进行操作呢？
- 还有最重要的，如何把策略接入实盘跑起来？
如果没有，那么该向你介绍第二种回测框架了。
流行的回测框架大致分为两种：for-loop(轮询)和event-driven(事件驱动)，本质上是在回测速度与实盘模拟这两个特性进行抉择权衡。
刚刚介绍的【向量化回测系统】就属于轮询回测，它速度更快，但不符合实盘交易的流程。而事件驱动则采用逐个bar/tick读取数据，并产生signal/order/trade的方式，利于统一回测和实盘的代码。而这样的回测系统，也很容易改造成一个能进行真实量化交易的系统，这点很重要。
技术解决方案：coming soon
技术栈要求: python, OOP
实时交易系统
策略只有最终上了实盘才有意义。应该没有人会质疑这句话，毕竟只有上实盘产生了PnL，策略才能算是真正落地。
富有的你一定实盘交易过，知道大概的交易流程，而我们的交易系统，就是把整个下单、盯盘的流程自动化。
当然，过程也并没有那么简单。
以数据流为例，讲一下系统从交易所收到一个tick数据，到一个订单最终成交的整个流程：
- 程序的套接字捕捉到该tick数据
- 解析，并向其他模块进行推送
- 策略收到数据，进行信号计算，如触发信号，生成订单
- 检查订单风险、有效性等检验
- 检验通过后，向交易所发出下单请求
- 成功下单（可能因为网络、账户、访问过频等原因而失败），交易所返回订单状态【待成交】
- 根据市场情况，可能发出取消订单命令
- 订单成交，返回订单状态【成交】，订单取消，返回订单状态【取消】
- 策略处理订单状态，结束该笔交易
这个过程涉及的模块包括有：
- 策略引擎负责多策略管理
- 订单引擎负责管理订单，仓位，风控
- 算法引擎负责订单算法（TWAP、VWAP、BLP）
- 数据引擎负责持久化及查询
- 日志引擎负责记录系统运行状态信息
- 交易所连接引擎负责与交易所的信息交互
- 控制界面负责信息交互、手动交易调整
不过整个过程，也不完全需要你撸起袖子从细节的一点一点完善。推荐两个开源项目vn.py & backtrader，其中有不少的特性和功能都值得借鉴，感谢作者和社区小伙伴，开源的力量真是伟大。
技术解决方案：coming soon
技术栈要求: python, OOP, 多线程, 设计模式, MVC架构, 敏捷开发
分布式交易服务器
实时交易系统开发完之后，顺利地在生产中运行了几个月，没有宕过，很开心。
但是，随着公司不断地上策略，卡、慢现象开始频发。100个策略，亦或是2000个标的对象，都会让系统无法承载。
你发现了原因：
- GIL限制
- 动态语言开销大
- 单机性能有限
嗯，重构的时间到了。为了横向提高系统吞吐量，纵向提高系统的信息处理速度，该让微服务和集群进入你的视野了。
庆幸自己以往模块化的设计，你发现将模块服务化并不困难。你会：
- 用高IO速度的工具编写行情收发服务
- 用高吞吐的消息中间件负责系统内信息路由服务
- 用高性能的语言编写策略引擎、算法引擎、订单引擎等
技术解决方案：coming soon
技术栈要求: java, rabbitmq, protobuf, disruptor, docker
产品化
服务器成功地部署在云端，公司已经能用它跑起自营策略产生收益了，Congrats！！
那我们马到功成了？
不，还有更高的山等待着去攀爬，那就是产品化。
已知的量化系统产品化的方式：
- 自用：承载公司自身策略的运行
- 软件销售：部署整套软件供机构本地使用
- 云平台服务：开放接口给更多机构、客户使用户
- 策略服务：云端策略销售，将策略完全零售化
只有想不到，没有做不到。
\