|
|
一、什么是Tick Data
Tick Data本身并不神秘，就是交易所把每只股票（亦或是futures options）的active order book(就是你的委托还存在在交易所里面，但并且没有被撮合成交)里面的买、卖的单的情况发给你。
举例说明：
某天的市场一开始的时候苹果股票的order book（委托挂单）清空（这里不进行auction period的探讨）：
1. 接着来了第一个卖家：1000@100 :
这时候交易所会发给你一个message，告诉你是苹果股票有人想以100块钱卖出1000股，那么这个order就先挂在了order book上，成为卖一。
卖：1000@100
2. 第二个卖家来了，他想卖得更高： 1000@101:
这时候交易所会发给你另一个message，告诉你是苹果股票有人卖的价格比你差，于是排序在更上面，卖二。
卖：1000@101
1000@100
3. 刚才的第一个卖家后悔了，cancel了他的order：1000@100撤消了，那么交易所会有message告诉你，现在只剩一个1000@101（卖一）。但是你可能需要自己编程处理这种remove掉一个tick的情况。
卖：1000@101
4. 终于有买家来了... 500@90 , 这个价格是不会成交的，因为买家低于现在的最佳卖价：101，那么order book里面会继续存着这个order，同时会发送一个tick告诉市场上的其他人，有买单了：
卖：1000@101
买：500@90
5. 继续，接着有一位买家以101块钱买入1000股，等于要把目前的bestoffer 1000@101给match - 撮合了，那么你是不会收到这个最新的bid： 101@1000 的，因为它会进入matching engine的瞬间跟对面的best offer 撮合了，tick table的一个规则： bid offer 永远不会cross，否则要么是数据商的bug，要么是交易所的bug。现在，你只会收到一个告诉你delete the best offer的message，那么tick table长这样：
买：500@90
Tick数据就是这么简单，市场上会重复这个过程。
但是比较麻烦的是：
1. 很多时候tick的数据会以UDP发送，想象股市上如果交易非常活跃，那么数据量会非常大，UDP会存在丢包情况，如何处理。曾经遇到过很疯狂的tick update但是还要保持在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），上交所深交所是3秒，然后发送给你，兴许是国内交易系统已经非常古老，跟不上IT的发展了。那么这个tick数据并不是“real time”的，你只知道“哦！在前100 millisecond和现在的tick 变化是这样的”，可能中间已经成交了数千单。
二：什么是快照数据与交易所数据的一些细节
对于国外的高频tick数据，有完整的order数据的过程，因此你可以利用这些order数据来复原快照数据。国内的两大股票和四大期货理论上讲都是快照数据。比如说典型的数据字段包括开盘价 最高价 最低价 最新价 成交量 成交额这里的最高（低）价就从开盘到现在成交发生过的最高（低）价，假设你有详细的每笔成交的明细，其实这个数据是可以用max(min)推算的，所以国外的tick数据里面一般是没有这个字段的。
上交所和深交所提供的实时行情有三种，快照和逐笔成交和委托。
快照就是每3秒一次(深交所，上交所是5秒)对市场照相，然后把现价、最高、最低、成交量、成交金额等行情相片发过来。由于照相是3秒一次，所以这3秒期间市场发生了什么，我们是不知道的。每天连续竞价时间是上下午各两小时共4小时。所以快照的次数就是14400/3大概是3800次。仅就股票来说，每天的全市场快照数据量超过2G。
逐笔成交就是真实的原子每笔成交。不过这个数据也是3秒发一批，也并非实时。比如说第1.5秒发生的一笔交易，到了第3秒才发过来。
委托挂单数据，Level 2里面只有买一卖一的前50，并非全部挂单。
典型的有几类原因导致数据的差异
1. 数据记录方式
比如拿股票的Level1的数据为例，交易所发布一个dbf文件，记录着所有证券最新的状态数据，dbf文件是不断的自动刷新的。那么数据提供商或者记录数据的人需要做的时候就是每隔一段时间读取这个文件，然后把所有的数据放入数据库，但是因为交易所更新数据的频率不是一个唯一值，所以为了不错过数据，最好的办法就是你读取的频率高于他更新的频率。这样问题就来了，因为你读取很多如果每次都记录下来一来数据很大，二来很多重复数据。所以大家往往使用的办法就是当这条数据有变化的时候我才放入数据库。因为有这样一条规则，所以你看到的一些非活跃成交的证券数据量会少于活跃成交的证券，远期的期货数据少于近期的，时间戳不同步等问题。
2. 运维问题谁也不能保证不会断网。如果发生断网、机器错误、程序错误等原因，就会错过交易所数据播放。按照前面所述的数据机制，其实对于Level1数据T和T+1时刻是没有任何逻辑关联的，假设缺失了你不可能从数据本身发现，因此大量的缺失其实都是这些原因造成的，而且无法弥补！就好比早期的电视录像带很不清晰，但是过去已经过去你已经无法补救。
3. 程序导致的数据错误
一些比较异常的错误，比如说某些类型股票的价格出现异常，空等等，可能因为录数据的程序的错误造成的。为什么会出现？反正理由也很多，我们知道会出现就可以了。少部分是因为交易所的问题，比如说交易所曾经把Level2数据的开盘价发错了。
因此原则上很难有100%可信的数据，数据的检验和清洗是必要的，也是一个枯燥的事情，规则的设立也看个人的经验。
|
|
