Tick 数据在技术上究竟是什么东西?

发现知乎上聚集了不少量化交易的专家,其中有提到Tick, "好的数据“这两个概念,一直对这两个概念感到不确定和困惑,所以提问这两个问题。特别是Tick,我好像了解,但又总觉得哪里不对,但又不知道具体哪里不对。。。 所以下面第一个问题先说我的理解,然后大家帮我看看。我从事的行业与金融毫不相关,也没有从事这行的意向,所以你答得越通俗对我的帮助越大。谢谢。 问题一(我的理解):Tick数据是不是指一个Order_Book上的数据…
关注者
1741
被浏览
107807
从交易所的数据发出到你的电脑上能看到发生了很多事,如何判断数据的好坏是一个复杂的事情。
作为曾经写过不少交易所的tick数据的处理程序的人,可以解释下为啥复杂:)

Tick Data本身并不神秘,就是交易所把每只股票(亦或是futures options)的active order book(就是你的order还存在在交易所里面,并且没有被撮合成交。)里面的买、卖的单的情况发给你,但是每个市场的规定都不同,举个栗子:

最真实的order book是这样的,一天的市场一开始的时候苹果股票的order book清空(这里不进行auction period的探讨):

1. 接着来了第一个卖家:1000@100 :


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

2. 第二个卖家来了,他想卖得更高: 1000@101:

这时候交易所会发给你另一个message,告诉你是苹果股票有人卖的价格比你差,于是排序在下面。

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

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

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长这样:

Tick数据就是这么简单,市场上会重复这个过程。
但是比较麻烦的是:
  1. 很多时候tick的数据会以UDP发送,想象股市上如果交易非常活跃,那么数据量会非常大,UDP会存在丢包情况,如何处理。曾经遇到过很疯狂的tick update但是还要保持在x micro second的更新cache,可能要排序(看交易所protocol),以及发送出去给前端。
  2. 如何更快的处理实时的tick数据,否则数据量如此大,一旦延迟,以后就再也跟不上“实时”的节奏了,直到你的程序挂掉。
  3. 如何避免一些特殊情况造成bug,一旦一个tick没有算对,那么后面的tick table全是错的:)
同样,还有对tick的理解问题:不同市场的tick还有不同点,上面所说的是发达国家的股票市场,以实时情况推送(有新的order并且在tick的发送level以内,比如东京交易所只发送8个tick level,那么你看不到整个full tick的,因为可能会有100多个level,如果很多人交易的话)。

但是国内是多少个milli second截取一个快照(snapshot),然后发送给你,兴许是国内交易系统已经非常古老,跟不上IT的发展了。那么这个tick数据并不是“real time”的,你只知道“哦!在前100 millisecond和现在的tick 变化是这样的”,可能中间已经成交了数千单。