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

发现知乎上聚集了不少量化交易的专家,其中有提到Tick, "好的数据“这两个概念,一直对这两个概念感到不确定和困惑,所以提问这两个问题。特别是Tick,我好像了解,但又总觉得哪里不对,但又不知道具体哪里不对。。。 所以下面第一个问题先说我的理解,然后大家帮我看看。我从事的行业与金融毫不相关,也没有从事这行的意向,所以你答得越通俗对我的帮助越大。谢谢。 问题一(我的理解):Tick数据是不是指一个Order_Book上的数据…
关注者
1741
被浏览
107776

18 个回答

Tick 一般是指 Best Bid/Offer 的变化,就是 Order Book 上最优的买单和卖单发生的变化。题目中的例子,Tick 2 和 Tick 1 的不同就在于 Best Offer 的 size 变了(少了 25),所以产生了这一个 tick。

当然这个不等于说 Tick 1 和 Tick 2 之间没有别的 Order Book 的变化,它可以在除了 Best Bid/Offer 之外的地方变化,只不过这些事情在 Tick Data 上被滤掉了而已。

这种所谓的 Tick Data 其实就是一种对 Order Book Events 的 Down Sample 而已,它的前提假设是 Best Bid/Offer 是最重要的信息,以丢弃其它相对不如这个重要的信息为代价,缩减数据规模,让数据处理变的更容易。

而实际上,真正的 Limit Order Book Market 里,交易所发的原始数据是所有对 Order Book 的增、删、改+成交这四样,特别是改单一般都是占整体数据流的大部分。只不过要处理这种级别的数据,需要你懂一些数据结构的操作,能自己维护重建 Order Book。这个手艺一般做 Quant 的人都不会,要么就是写出来的代码实在太慢根本处理不了原始数据的规模,所以往往是为了简化起见就给他们 Tick Data,一般人就都能凑合着用了。

因为这种二手数据的本质,Tick Data 做的好不好当然是会有区别的。虽然说是需要记录每一个 Best Bid/Offer 的变化,但实际上这种数据反正也不用维护 Order Book 的一致性,因为各种技术问题少记了几个也不会有人说什么。甚至可能某家的数据处理程序还有 bug ,其中一些数据偷摸的错了一些,一般人也很难发现。这些都是可以用来比较数据质量的。

建议大家做 Quant 工作的,还是要注意编程基本功,有条件就自己直接处理原始数据。少一层二手过滤,就少一次出错的机会,离你发现新策略也就更近一步。
从交易所的数据发出到你的电脑上能看到发生了很多事,如何判断数据的好坏是一个复杂的事情。
作为曾经写过不少交易所的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 变化是这样的”,可能中间已经成交了数千单。