如何构建一个量化策略或者从事较为微观市场的研究，扎实的交易、财务甚至舆情、大数据的理解是第一步，因此我也逐渐会发一些文章来说明这些数据的本质是什么，希望能有所帮助罢。
从交易所的数据发出到你的电脑上能看到发生了很多事，如何判断数据的好坏是一个复杂的事情。
作为曾经写过不少交易所的 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 变化是这样的”，可能中间已经成交了数千单。
最后的一个思考题， limit order-限价单提供了流动性，而 market order-市价单吞噬流动性，为什么？（这个论点也未必成立？）
如果你们也逛知乎，欢迎关注我们的专栏（Moneycode）：
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.