问题一（我的理解）：Tick数据是不是指一个Order_Book上的数据只要有任何变化，即对其变化后生成的新Order_Book进行Copy,这份Copy就叫做Tick？
而Order_Book上的变化是不连续的，比如客户端连续收到下面3个Tick, Tick1到Tick2之间的时间段Order_Book应该是没有发生任何变化的。因为如果有变化的话，则会被完全分解，在Tick1和Tick2之间出现一个或更多的Tick才对。
问题二：哪些原因造成了A家的数据好，B家的数据不好这种现象？
AB软件商的数据不都是交易所提供的么。看到有人骂哪家的数据怎么怎么样骂的十分凶狠，想必他家的数据一定是非常糟糕了吧。你可以想像我一个外行人看来会觉得困惑......这就好像我朋友对我说街上有两家店在卖苹果手机，街头那家店的手机质量比街尾那家的质量好太多了。
董可人回答：
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 工作的，还是要注意编程基本功，有条件就自己直接处理原始数据。少一层二手过滤，就少一次出错的机会，离你发现新策略也就更近一步。
LIKE回答：
从交易所的数据发出到你的电脑上能看到发生了很多事，如何判断数据的好坏是一个复杂的事情。
作为曾经写过不少交易所的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数据就是这么简单，市场上会重复这个过程。
但是比较麻烦的是：
- 很多时候tick的数据会以UDP发送，想象股市上如果交易非常活跃，那么数据量会非常大，UDP会存在丢包情况，如何处理。曾经遇到过很疯狂的tick update但是还要保持在x micro second的更新cache，可能要排序（看交易所protocol），以及发送出去给前端。
- 如何更快的处理实时的tick数据，否则数据量如此大，一旦延迟，以后就再也跟不上“实时”的节奏了，直到你的程序挂掉。
- 如何避免一些特殊情况造成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 变化是这样的”，可能中间已经成交了数千单。
Keyword回答：
LIKE很详细的解释了国外的TickData和处理方法,而因为国内的交易所都只发送切片信息,而不是真实的Tick信息,所以还是有一定差别的,我来补充说下国内交易所一般所说的Tick数据。
国内交易所的order book的数据维护都是实时进行的，但是和国外交易所不同，并不是每个动作都会实时推送到市场上来，而是根据指定的时间间隔进行一次检查，如果该时间段内有动作，则生成一次快照并且推送出来，数据的推送充其量只能算做OnTime，而不能叫做OnTick（被动触发还是主动检测对用户没有区别，此处为了方便说明而取前一种方式）
以切片间隔时间为500ms的五档行情举例，上图来说明：
在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，丢失了不少信息。
此机制会产生一些值得注意的现象
1、信息的丢失
按上图流程所示，如果4500是当日的最低价，则可能会出现因为信息丢失而导致无法根据tick获取到当日最低成交价的情况,所以国内交易所都会单独推送一份当日最高最低价以弥补。
2、信息的延迟
如果是做时间间隔小于500ms的高频交易的话，因为无法及时获取市场信息，在这500ms内基本等于是在摸黑前进，增加了不少交易风险
来源：知乎
拓展阅读：
扫一扫
7705
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
