• ### ティックデータとは何か?

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

　　市場では,このプロセスを繰り返します. しかし,もっと厄介なことは,

• 1. 多くの場合,tickのデータはUDPで送信されます. 株式市場で取引が非常に活発であれば,データ量は非常に大きく,UDPはパケットの喪失が発生します. どう対処するか. 非常におかしいtickの更新を経験しましたが,マイクロ秒の更新キャッシュに保存する必要があります.

1. リアルタイムの tick データを処理する方法を考えましょう. 遅延が起きれば,あなたのプログラムが停止するまで,リアルタイムの tick のペースに追いつけないでしょう.

特定の状況でバグが発生しないようにするにはどうすればいいですか? 一つのタックは正しくないので,次のタックテーブルはすべて間違っています.

** また,tickの理解の問題もあります:異なる市場のtickは,上記のように,先進国の株式市場で,リアルタイムで推し ((新しいオーダーがあり,tickの送付レベル内では,例えば,東京取引所が8つのtickレベルしか送付しないので,あなたは100以上のレベルがあり,多くの人が取引している場合,あなたは全 tickを見ることができない) ≫ 国内期取引所は何ミリ秒でスナップショットを撮り,上期取引所深期取引所3秒で,そしてあなたに送られて,国内取引システムが非常に古く,ITの発展を追いつけないかもしれない. じゃあこのtickデータは,リアルタイムに表示されない,あなたはただ,tickを知っている! 前100ミリ秒と現在のtickの変化は,このようなtickであり,その間に何千枚ものチケットが取引されているかもしれない.

(この記事は微信id:quantcityの定量トレーダーがまとめました。)

• ### 2 スナップショットデータと取引所データとは何か

　　 外国からの高周波の tick データには,完全な order データのプロセスがあり,これらの order データを用いて快照データを復元できます.

国内最大の2つの株式と最大の4つの期貨は理論的にはスナップショットデータである.例えば,典型的なデータフィールドは, オープン価格 最高価格 最低価格 最新価格 取引量 取引量 この値では,開盤から現在までの取引の最大値である.この値では,各取引の詳細を正確に把握しているとするが,これはmax (min) で計算できるので,海外のチケットではこの項目は含まれていない. 上取引所と深取引所から提供されるリアルタイム取引は,スナップショットと手書きの取引と委託である. スキャップは,3秒ごとに (深取引所では5秒,上取引所では5秒) 市場の写真を撮り,現価,最高,最低,取引量,取引金額などの状況写真を送信する.スキャップは3秒ごとに撮影されるので,この3秒間の間に市場がどうなっているのかはわからない.毎日の連続した競売時間は午前2時間毎に合計4時間である.スキャップの回数は14400/3で,おそらく3800回である.株式だけで言えば,毎日の市場全体のスキャップデータ量は2G以上である. 単位取引は,実際の原子毎の取引である。しかし,このデータは3秒のバッチでも,リアルタイムでもありません。例えば,1.5秒で起こった取引は,3秒後に発送される。 Level 2のデータでは,すべてのリストが表示されていないが,トップ50のリストのみが表示されている. (この記事は微信id:quantcityの定量トレーダーがまとめました。)

統計の差異には,典型的にいくつかの原因があります.

• 1. 記録方法 例えば,株式のレベル1のデータを例に取ると,取引所はdbfファイルを発行し,すべての証券の最新の状態データを記録し,dbfファイルは絶えず自動更新されます. データの提供者またはデータを記録する人は,このファイルを毎回読み,すべてのデータをデータベースに保存する必要があります. このルールにより,非アクティブ取引のデータ量がアクティブ取引のデータ量より少なくなり, 長期の期貨のデータ量が近期のものより少なくなり, タイムカプセルが同期しないという問題があります.

• 2. 運用問題 ネットワークが切断されないことを保証することはできません. ネットワークが切断されたり,機械のエラー,プログラムのエラーなどの原因で,取引所のデータ再生が逃されます. 上述したデータ機構によれば,Level1データTとT+1のタイミングは,実際には論理的な関連はありません. 欠陥があると仮定すると,データ自体から発見することは不可能です.

• 3. プログラムによるデータエラー 比較的に異常なエラー,例えば,特定の種類の株式の価格が異常,空等である,というエラーは,データを記録するプログラムのエラーによるものかもしれない。なぜ発生するのですか?とにかく,理由もたくさんあり,発生する事は分かっている。少なからず,取引所の問題である,例えば,取引所がLevel2データの開場価格を誤って送信したことがある。 だから,原則として100%信頼性の高いデータを持つことは難しいし,データの検査と浄化も必要であり,つまらないことであり,規則の制定は個人の経験にもかかっている.