Cross Validation for Time Series 时间序列数据的交叉验证

Methods for choosing training, testing and validation sets for time-series data work a little differently than the methods described so far. The main reasons we cannot use the previously described methods exactly as described are,选择时间序列数据的训练,测试和验证集的方法与到目前为止描述的方法稍有不同。我们无法完全按照上述说明使用前述方法的主要原因是: We want our validation and testing procedure to mimic the way our model would work in production. In production, it’s…

期权高频交易系统 简单揭秘

温故而知新。 框架 上图是我眼中的最简交易系统,它分为几个部分: 网关(Gateway): 负责和交易所/经纪人(远端)打交道。一方面接收行情数据(报价更新,订单更新等),另一方面把交易指令传给远端. 定价引擎(Pricing Engine): 接入的行情数据需要转换成策略需要的报价。对于衍生品来说,它的输出应当至少包含衍生品的理论价格。定价引擎可能还有额外的输入,比如对于期权定价而言,,一般会使用类Black-Scholes模型定价,有了标的物(underlying)的市场数据之后,它还需要波动率(volatility)、利率等参数的输入以及一些合规、风控相关的参数。 策略(Strategy): 交易策略接收定价引擎的信息,同时他也接受策略目标instrument的实时行情。不同的策略给出不同的执行建议,然后把这些执行建议传给后续模块。 风控&执行复用(Compliance & Execution Mux): 一个交易系统(很)可能同时执行多个策略。不同策略发出的执行建议可能互相重合、冲突或者产生执行时的合规风险。这个模块负责处理所有的执行请求,把合格的请求发给Gateway执行。这边用Mux相对形象一些,暂时还没想到更好的词。 需要说明的是,上面这些仅仅是极其基础的组件。如果把交易系统作为一个模块看待,它其实会有许多附加组件,例如高频交易员往往会根据经验值调整一些参数,这些参数会反映在策略执行、风控、定价模块中,于此就会产生一些和人交互的UI组件。 优化: 软件、硬件、程序语言… 不同于一众互联网公司的系统,高频交易系统对于低延迟的渴求相当急切,对它来说高并发往往是可以忽略的。重要的是一个报价更新如何最快到达系统,一个订单(order)如何在最快的时间内到达交易所。目前能见到的国外交易公司,主要用C++编写交易系统,当然也有很厉害的公司用自己定制的JVM跑Java交易。对于延迟不是非常敏感的市场,也有使用Python作为开发语言的。当然这些仅限于软件层面,事实上很多交易公司已经用上了FPGA用来进一步加速执行速度,甚至使用FPGA来执行一些简单但是对延迟极其敏感的交易策略。以C++为例,代码编写上将会大量使用模板(template)替代虚函数。一般应用场景上虚函数调用的开销可能是不值一提的,但是如果算到了纳秒(或CPU tick)级别,虚函数的开销也会令人头疼。也许有人会问,那接口继承怎么不用虚函数弄呢?有兴趣的可以去看一下CRTP设计模式。 Gateway 网关系统的职责是负责对外联系,一般分为行情数据(Market Data)和订单执行(Order Execution)两个部分。交易所一般会提供机房租赁,衍生品交易公司会采用co-location策略把交易主机放在租的机房里,确保和交易所的Matching Engine距离最近。所谓Matching Engine就是交易所自己用来匹配订单(order)的中央机器(其实有很多个机器)。就行情数据而言,绝大多数交易所是用UDP组播的方式下发数据的。收到组播数据后,需要把订单报价更新的信息尽快处理并上发。就程序逻辑优化而言,第一是要尽最大可能减少内存拷贝(memory copy)。第二是要钻研(并且实验!)交易所给的数据格式,避免去读取不需要的字段。其次某些交易所的市场数据可能还是通过ASCII字符下放的,这边就要尽量优化string to int的延迟。 Market Data 对于某些交易Gateway实现,也会包含price book/order book的更新。行情数据可以细分为不同的频道(channel),一些会播放price book update, 另一些则是order book update. 后者往往包含更多的交易信息,这些交易信息与trade update合并关联之后,就能给pricing module提供实时更新。对于price book/ order book,写代码的小哥往往会对他们各自抽象各自的数据结构,这些数据结构需要保证book update的响应尽量快。在book得到更新后,上层系统(strategy, pricing module)对它的需求是不同的,有些需要full depth of book,有些可能只需要几个book level或是只要TOB(top of book),针对这些不同的需求,系统也会给出不同的优化。也有系统把book update的具体操作另外归类为几个特殊事件直接传给系统上层、以便做出最快响应。这些事件可能包括巨大的价格变动(此时很可能需要撤单)。另一部分个重要部分是重启、恢复机制。由于UDP传输的不稳定性(尽管已经是co-location了),交易所一般提供通信恢复的专门channel播放恢复数据。在网络中断或者系统故障后,需要通过数据恢复机制重建各种交易工具(instrument)的最新信息。…