Tick Data自体は神秘的なものではありません. 取引所は,すべての株式 (またはフューチャーオプション) のアクティブオーダーブック (つまり,あなたの委託が取引所で存在していますが,合成されていません) の購入・販売の状況を送信します.
**举例说明：**
某天的市场一开始的时候苹果股票的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.多くの場合,ティックのデータはUDPで送信されます. 株式市場で取引が非常に活発である場合,非常に大量のデータがあると想像してください. UDPはパケットが失われ,どのように処理するか.
2. リアルタイムのタックデータをより速く処理する方法,そうでなければ,データが非常に多く,遅滞すると,あなたのプログラムが吊るされるまで,リアルタイムのタックのペースを追いつくことはできません.
- 3. 特殊な状況でバグが発生しないようにするには,一つのタックが正しくない場合,その後のタックテーブルがすべて間違っています:)
**また,ティックの理解の問題もあります. 異なる市場のティックは異なる点もあります. 上記は先進国の株式市場についてです. リアルタイムで推し進めています. (新しいオーダーがあり,ティックの送信レベル内には,例えば東京取引所では8つのティックレベルしか送信されていません. スナップショットを切り取ると,国内取引システムが非常に古いので,ITの発展と追いつけない可能性が高い. そうすると,このティックのデータはリアルタイムに切り取られていません.
微信 id:quantcityによってまとめられた記事です.
海外の高周波ティックデータには,オーダーデータの完全なプロセスがありますので,これらのオーダーデータを利用してスナップショットのデータを復元できます.
国内で2つの主要株と4つの主要フューチャーが理論的にはスナップショットデータである.例えば,典型的なデータフィールドは以下のとおりである. ありがとうございました. 開始価格 最高価格 最低価格 最新価格 取引量 取引量 ありがとうございました. ここでの最高値は,開店から現在までの取引が起こった最高値である. 詳細な取引の詳細を仮定すると,実際にはこのデータはmaxで推測できるので,海外のティックデータには通常このフィールドがありません. ありがとうございました. 取引所や深交所によって提供されるリアルタイム取引は,快照,一筆取引,委託など3種類あります. ありがとうございました. スナップショットは,3秒ごとに市場を撮影し,現在の価格,最高,最低,取引量,取引金額などの市場をスナップして送信する. 写真が3秒ごとに撮影されるので,この3秒間に市場がどうなるかはわからない. 毎日連続競売時間は午前2時から午後4時間です. したがって,スナップショットの数は14,400/3で約3800回です. 株式について言えば,毎日全体の市場スナップショットのデータ量は2G以上です. ありがとうございました. 単行本取引は,実際の原子の各取引である.しかし,このデータは3秒間の大量送信でもあり,リアルタイムではない.例えば,1.5秒間に起こった取引は,3秒後に送信される. ありがとうございました. 委託上場データ,レベル2では,上場50件のうち1件を1件で購入し,1件を1件で販売するだけ,上場50件は全てではない. この記事のまとめは,微信ID:quantcityによるものです.
**典型的有几类原因导致数据的差异**
- **1. 数据记录方式**
例えば,株式のLevel1のデータを例に挙げると,取引所がすべての証券の最新状態データを記録するdbfファイルを公開し,dbfファイルは自動的に更新され続けます.データ提供者またはデータ記録者は,すべてのデータをデータベースに入力するために,毎回このファイルを読み込む必要があります. しかし,取引所がデータを更新する頻度は単一ではありませんので,データを逃さないようにするには,あなたが更新する頻度よりも頻繁に読むのが最善です. このルールがあるため,動いていない証券のデータ量が動いている証券よりも少なく,長期期間の先物データが近期期のものよりも少なく,タイミングが異なることが問題になります.
- **2. 运维问题**
ネットワーク断絶が起きないことを保証することはできない.ネットワーク断断,機械の誤り,手順の誤りなどがある場合,取引所のデータ再生を逃す.上記のデータメカニズムに従って,実際にはレベル1データTとT+1の瞬間には論理的な関連性がない.欠陥を仮定すると,データ自体から発見することは不可能です.したがって,多くの欠陥は,実際にはこれらの原因によって引き起こされ,補完できません.
- **3. 程序导致的数据错误**
比較的に異常なエラーは,例えば特定のタイプの株の価格が異常,空白などで,データ記録の手順の誤りによって引き起こされる可能性がある.なぜ起こるのか?理由もたくさんあるが,我々はそれを知っている.一部は取引所の問題である.例えば,取引所は一度レベル2データの開示価格を間違えた. 原則上,100%信頼可能なデータを得ることは困難であり,データの検証と清掃は必要であり,退屈なものであり,規則の設定は個人の経験にも依存する.