如何看懂交易所tick数据


从交易所的数据发出到你的电脑上能看到发生了很多事,如何判断数据的好坏是一个复杂的事情。Tick 一般是指 Best Bid/Offer 的变化,就是 Order Book 上最优的买单和卖单发生的变化。所谓的 Tick Data 其实就是一种对 Order Book Events 的 Down Sample 而已,它的前提假设是 Best Bid/Offer 是最重要的信息,以丢弃其它相对不如这个重要的信息为代价,缩减数据规模,让数据处理变的更容易。


Tick Data本身并不神秘,就是交易所把每只股票(或期货)的active order book(就是你的order还存在在交易所里面,并且没有被撮合成交。)里面的买、卖的单的情况发给你,但是每个市场的规定都不同,举个例子:最真实的order book是这样的,一天的市场一开始的时候苹果股票的order book清空(这里不进行auction period的探讨)。

1. 接着来了第一个卖家:1000@100 。这时候交易所会发给你一个message,告诉你是苹果股票有人想以100块钱买1000股,那么这个order就先挂在了order book上。

Bid PriceBid QuantityOffer PriceOffer Quantity
1001000

2. 第二个卖家来了,他想卖得更高: 1000@101。这时候交易所会发给你另一个message,告诉你是苹果股票有人卖的价格比你差,于是排序在下面。

Bid PriceBid QuantityOffer PriceOffer Quantity
1001000
1011000

3. 刚才的第一个卖家后悔了,cancel了他的order:1000@100 撤消了,那么交易所会有message告诉你,但是你需要自己编程处理这种remove掉一个tick的情况:

Bid PriceBid QuantityOffer PriceOffer Quantity
1011000

4. 终于有买家来了... 500@90 , 这个价格是不会成交的,因为买家低于现在的最佳卖价:101,那么order book里面会继续存着这个order,同时会发送一个tick告诉市场上的其他人:“有买单了”。

Bid PriceBid QuantityOffer PriceOffer Quantity
90501011000

5. 继续,接着有一位买家以101块钱买入1000股,等于要把目前的best offer 1000@101给match - 撮合了,那么你是不会收到这个最新的bid: 101@1000 的,因为它会进入matching engine的瞬间跟对面的best offer 撮合了,tick table的一个规则: bid offer 永远不会cross,否则要么是数据商的bug,要么是交易所的bug。现在,你只会收到一个告诉你delete the best offer的message,那么tick table长这样。

Bid PriceBid QuantityOffer PriceOffer Quantity
9050

Tick数据就是这么简单,市场上会重复这个过程。

以上详细的解释了国外的TickData和处理方法,而因为国内的交易所都只发送切片信息,而不是真实的Tick信息,所以还是有一定差别的,来补充说下国内交易所一般所说的Tick数据。

国内交易所的order book的数据维护是实时进行的,但是和国外交易所不同,并不是每个动作都会实时推送到市场上来,而是根据指定的时间间隔进行一次检查,如果该时间段内有 动作,则生成一次快照并且推送出来,数据的推送充其量只能算做OnTime,而不能叫做OnTick(被动触发还是主动检测对用户没有区别,此处为了方便 说明而取前一种方式)。这个tick数据并不是“real time”的,你只知道“哦!在前100 millisecond和现在的tick 变化是这样的”,可能中间已经成交了数千单。以切片时间为500ms的五档行情举例,如下图:

交易所tick数据

在11时05分03秒200毫秒的时候,有人以4500的价格卖出3手,系统将其价格与买一价进行匹配,发现符合撮合条件,则撮合之,以价格4500成交3手,最新成交价为4500,总成交量为3手,而此时因为未到切片时间,所以不会推送数据出来。在11时05分03秒300毫秒,又有人以价格5000买入5手并成交,最新成交价变为5000,总成交量为8手,此时仍未到切片时间,仍不会推送数据。一 直等到11时05分03秒500毫秒,系统判断在11:05:03.000-10:05:03.500这个时间段内有数据变化,则将盘口的买卖信息以及汇 总的成交信息——最新成交价5000,总成交量8手——生成一份快照,并推送出来,这就是我们能够接收到的Tick Data。

我们可以发现,因为是一段时间内的交易信息汇总,所以我们只能得到最新的成交价和总的成交量,相比每次变化都会及时推送的Tick Data,丢失了不少信息。 此机制会产生一些值得注意的现象:

一、信息的丢失按上图流程所示,如果4500是当日的最低价,则可能会出现因为信息丢失而导致无法根据tick获取到当日最低成交价的情况,所以国内交易所都会单独推送一份当日最高最低价以弥补。

二、信息的延迟如果是做时间间隔小于500ms的高频交易的话,因为无法及时获取市场信息,在这500ms内基本等于是在摸黑前进,增加了不少交易风险。

(一)、常见问题解疑

什么是快照数据与交易所数据细节?打一个比喻,交易数据可以想象为河流,快照就是这个河流在某个横截面的数据。对于国外的高频tick数据,有完整的order数据的过程,因此你可以利用这些order数据来复原快照数据。

国内的交易所理论上讲都是快照数据(像期货是1秒2tick)。典型的数据字段包括开盘价、最高价、最低价、最新价、成交量,成交额这里的最高(低)价就从开始到现在成交发生过的最高(低)价,假设你有详细的每笔成交的明细,其实这个数据是可以用max(min)推算的,所以国外的tick数据里面一般是没有这个字段的。同样的成交量和成交额代表的意思不是这个时刻的成交量和成交额而是这个时刻开始到现在的累计成交额和成交量。从理论上讲:T时刻的累计成交量减去T-1时刻的累计成交量就是T时刻的成交量,但是这里的"成交量"其实是T-1到T时刻的汇总成交量,其实是有很多笔组成的。

期货的level2相比level1只是频率和报价深度上有些许区别。更有意义的是股票level2数据。 从表结构来看股票level2主要有三块内容:快照、逐笔成交和挂单快照类似前述的level1的快照 不过是把5档换成了10档另外还有一些比如所有挂单和数量等字段,深交所和上交所有略微差异。

逐笔成交就类似国外的tick数据,确实是发生过的真正的每笔成交情况,时间戳精细到10ms。但是问题在于这个数据也是3s一次发出来,发给你0-3s这期间的tick数据而不是实时发送给你,因此这里并不能把他定义为真正的tick数据。

Level2 里面的挂单只有买卖一档的Top50并不是全部挂单,另外理论上数据是纪录这些挂单的增删(挂单没有改一说),但是从实际数据来看,交易所的数据并不是增 量增量增量这种方式发送,而是夹杂着全量挂单和增量数据的方式,所以也不是完整的挂单动作。可以用这系列推算挂单情况但是挂单变化情况只是 sometiems能推算出来。

什么是好的数据和为啥数据有差异?既然都是交易所发送出来的,为什么会有数据的差异?交易所比喻成一个电视台,他不断的给客户发送信号。绝大多数客户只装了电视机,收看电视。而数据提供商装的是录像机需要录数据,然后把录像带卖给客户。

(二)、典型的有几类原因导致数据的差异

1、数据记录方式比如拿股票的Level1的数据为例,交易所发布一个dbf文件,记录着所有证券最新的状态数据,dbf文件是不断的自动刷新的。那么数据提供商或者记录数据的人需要做的时候就是每隔一段时间读取这个文件,然后把所有的数据放入数据库,但是因为交易所更新数据的频率不是一个唯一值,所以为了不错过数据,最好的办法就是你读取的频率高于他更新的频率。这样问题就来了,因为你读取很多如果每次都记录下来一来数据很大,二来很多重复数据。所以大家往往使用的办法就是当这条数据有变化的时候我才放入数据库。因为有这样一条规则,所以你看到的一些非活跃成交的证券数据量会少于活跃成交的证券,远期的期货数据少于近期的,时间戳不同步等等,你以为是数据问题,其实不然。

2、运维问题这个是真正的数据提供商或者记录数据的问题,比如某些原因如断网或者程序错误等造成了一大段的数据丢失。按照前面所述的数据机制,其实对于Level1数据T和T+1时刻是没有任何逻辑关联的,假设缺失了你不可能从数据本身发现,因此大量的缺失其实都是这些原因造成的,而且无法弥补!就好比早期的电视录像带很不清晰,但是过去已经过去你已经无法补救。

3、程序导致的数据错误我遇到过一些比较异常的错误,比如说某些类型股票的价格出现异常,空等等,绝大部分是因为录数据的程序的错误造成的,为什么会出现?反 正理由也很多,你记住会出现就可以了。少部分是因为交易所的问题,比如说交易所曾经把Level2数据的开盘价发错了.......