量化必读：Tick数据到底是什么为么难找到可靠交易数据？
转 量化必读：Tick 数据到底是什么？为什么很难找到可靠的交易数据？
一、什么是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%可信的数据，数据的检验和清洗是必要的，也是一个枯燥的事情，规则的设立也看个人的经验。
来源：量化交易员
《算法导论 第三版英文版》_高清中文版
《深度学习入门：基于Python的理论与实现》_高清中文版
《深入浅出数据分析》_高清中文版
《Python编程：从入门到实践》_高清中文版
《Python科学计算》_高清中文版
《深度学习入门：基于Python的理论与实现》_高清中文版
《深入浅出数据分析》_高清中文版
《Python编程：从入门到实践》_高清中文版
量化必读：Tick数据到底是什么为么难找到可靠交易数据？相关推荐
- 大数据到底应该如何学？
写在前面:博主是一只经过实战开发历练后投身培训事业的"小山猪",昵称取自动画片<狮子王>中的"彭彭",总是以乐观.积极的心态对待周边的事物.本人的技 ...
- 另类因子：消费交易数据与股票截面收益
量化投资与机器学习微信公众号,是业内垂直于量化投资.对冲基金.Fintech.人工智能.大数据等领域的主流自媒体.公众号拥有来自公募.私募.券商.期货.银行.保险.高校等行业30W+关注者,荣获202 ...
- 大数据之父_“大数据之父”舍恩伯格最新演讲：大数据重塑制造业（含视频）...
2019年8月16日,在2019智博会"智造新动能·智联新产业"高峰论坛上,全球知名大数据专家,<大数据时代>作者维克托·迈尔·舍恩伯格先生进行了以"大数据重 ...
- 什么猫猫最受欢迎？Python采集猫咪交易数据
前言 在日常生活中,我们看到可爱的猫咪表情包,总是会忍不住收藏 认识的一些朋友也养了猫,比如橘猫.英短.加菲猫之类的 看他们发朋友圈撸猫,老羡慕了,猫咪真的太可爱啦. 你是不是也动过养猫猫的小心思呢~ ...
- python获取股指_用Python读取csv文件中的沪深300指数历史交易数据
保存路径:D:\python\用Python读取csv文件中的沪深300指数历史交易数据 程序名称:readcsvhs300.py: 数据名称:沪深300指数历史交易数据.csv: 开发环境:Win7 ...
- [转]量化必读：Tick 数据到底是什么？为什么很难找到可靠的交易数据？
一.什么是Tick Data Tick Data本身并不神秘,就是交易所把每只股票(亦或是futures options)的active order book(就是你的委托还存在在交易所里面,但并且没 ...
- 【python量化交易学习】从tushare获取股票交易数据，存入后再从mysql或excel读取数据，筛选股票，用pyecharts画出K线图。
选定日期,筛选涨幅达到10%的股票,并画出K线图.观察涨停后股票走势. 由于创业板涨停板为20%,科创板20%,北交所30%.因此筛选出的涨停股票不完全准确.考虑到目前市场打板主要集中在10%的主板股 ...
- Python 量化交易 数据分析学习之旅
列表 用法 List set tuple Dict #集合 不含重复对象 StockExchange1 ={'1','2','3'} StockExchange1.update (['4']) Sto ...
- @RequestBody注解失效？从前端传来的数据到底需不需要@RequestBody注解？前端传输数据解析的问题？
@RequestBody注解失效?从前端传来的数据到底需不需要@RequestBody注解? 又是在日常的从Mybatis升级Mybatis-Plus的过程中,我又发现了问题:怎么从前端传来的数据没有 ...
最新文章
- ASP.NET操作文件大全
- 性能翻倍 IBM借DS3500拓中低端存储市场
- 【Scratch】青少年蓝桥杯_每日一题_5.01_画三五七边型
- 《正规军的Python进阶之路｜Python技能树测评》
- 『软件测试3』八大典型的黑盒测试方法已来袭，快快接住！
- js原生后代选择器_CSS 后代选择器
- 使用 GDB 恢复堆栈信息
- 微信小程序底部弹框 showActionSheet
- 程序猿在等电梯时都在想什么？
- 随记：Ubuntu12.04下关闭图形界面的相关问题
- [SGU223]Little Kings（状压DP）
- Unity3D之Assetbundle
- 基于信息论的特征选择算法综述
- libyuv NV12裁剪
- EasyDarwin开源摄像机访问EasyCamera中海康摄像头语音对讲和云台控制转发实现
- BT文件分享服务器,bt是什么意思服务（bt资源库）
- go语言读取xls表格xls文件操作替代解决方案
- VFB组件：MonthCalendar控件（月日历）
- python编写自己的股票系统
- 性能测试专项：帧率测试 FPS