web-dev-qa-db-ja.com

Python：リアルタイムストリーミングデータ

Pythonを介してリアルタイムストリーミングのフィナンシャルタイムズデータをキャプチャしようとしています。最初に情報をデータベースに保存し、後日、このデータに基づいて取引を分析して決定するプログラムをさらに開発したいと思います。その後、WebサイトまたはJupyterノートブックのいずれかに、上記のデータを何らかのグラフィック形式で表示できるようになると便利です。

出発点として、GDAXまたはGeminiのいずれかのビットコインデータを使用することにしました。可能であれば、ティックデータと潜在的に追加のオーダーブック情報もキャプチャしたかったのです。

いくつかの調査を行う際に、私はそこにあるオプションに少し圧倒され、プロジェクトを構成する方法とどのライブラリが最も適切であるかについていくつかのガイダンスを使用することができました。

各サービスのAPIのそれぞれのドキュメントと、いくつかのGithubプロジェクトを確認しましたが、どこから始めればよいのかまだわかりません。アドバイス、提案、推奨読書をいただければ幸いです。

pythondatabasereal-timebitcointrading
6
Sinan Reis

アドバイス、提案、または推奨読書​​はありますか？

正当なアーキテクチャと設計の推論に関する数十年の実践的な経験の後に数セントを追加する場合：

常に現実的であり、自分自身に正直であり続けます。

_           0.1 ns - NOP
           0.3 ns - XOR, ADD, SUB
           0.5 ns - CPU L1 dCACHE reference           (1st introduced in late 80-ies )
           0.9 ns - JMP SHORT
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance -- will stay, throughout any foreseeable future :o)
         3~4   ns - CPU L2  CACHE reference           (2020/Q1)
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          10   ns - DIV
          19   ns - CPU L3  CACHE reference           (2020/Q1 considered slow on 28c Skylake)
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1K bytes with Zippy PROCESS
      20,000   ns - Send 2K bytes over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|
_

  • 実際にどれだけの「リアルタイム」があなたの野心であるかを決定します。これが最大の違いを生みます-技術的に実装する必要がある場合プロセス制御ループ、その安定性基準のために以下のしきい値a say 1 kHz RTT-エンドツーエンド（イベント発生+トランスポート+ローカル取得+ローカル処理+フィードバックループ_<< 1 [ms]_）、- 10 kHz（_<< 100 [us]_）。これを知ること"意図"は、適切で実行可能なテクノロジーを決定するのに役立ちます。これは、前述の目標を達成できる（または主に達成できない）ものです。不適切なテクノロジーを選択することは、アマチュアによくある（そして高価な）間違いです（しかし、プロのソフトウェアハウスでもしばしば繰り返されます）。

  • rTT-E2Eしきい値の現実的な値を知った後、先に進む前に、APIプロバイダーが技術的および商業的意味の両方で非常に頻繁な更新を提供できるかどうかを確認してください。そうでない場合は、別のデータフィードプロバイダーを見つける必要があります。リアルタイムシステムが適切にサンプリングされた（高速の）供給元から供給できない場合、制御ループはその安定性の範囲内で機能しません-これは悪いです-あなたが見ようとするのと同じくらい悪いですHDビデオストリームから、37〜46番目の画像をすべてではなく、ほぼすべて表示するテレビ。これを見ることができないでしょう「サブサンプリングされた途切れ途切れの何か」（確かに、ローカルDVB-Tデコーダーが何も表示することを諦めないのであればまったく、DVB-Tストリームプロトコル違反のそのような残忍な規模のために、リード/ソロモン冗長エラー耐性トランスコーディングのほんの数ビットのCRCビットでさえ正しく通過できなかった場合、チェッカーアーティファクトは不快です）が、間違いなく何もありません安定したエラーのない1：1FullHDストリームと比較して優れています。

  • rTT-E2Eしきい値の現実的な値と対応するAPIベンダーの両方を利用できるようにして、技術的な手順（それらを実装するための技術ではない）の設計を開始します。実際の世界をマスクするのにどのように役立つ予定ですかリアルタイムlatencies --実際の時間コスト[us] APIプロバイダーからのトランスポート（+すべての関連する暗号化/復号化スキーム（SSLトンネルまたはVPNなど））アクセスポイントを処理エンジン入力まで参照します。これを知らないと、それ以降のすべての決定に欠陥が生じます。

  • その実際のISO/OSI-L9-ダウンストリームレイテンシーを測定した後、その時間を2倍にします_[us]_、アップストリームもカバーするために妥当な時間を予約しますレイテンシー（レイテンシーのソースがまったく同じである必要はありませんが、桁違いに近くなります）。

初期設計のRTT-E2Eターゲット数値に、前述の1kHzの制御ループしきい値があり、max( DownStream ) + max( UpStream )実験的に観測されたレイテンシの上限がある場合、少なくとも1つの24/7デューティサイクル中にプロバイダーの実際の本番APIゲートウェイ（_1kHz_制御ループしきい値と一致するかどうかがチェックされたゲートウェイ）に対してライブで測定された場合、ここでどのくらいの時間を計算しますかあらゆる種類のローカル処理を開始するために残されています-つまりローカル処理のために実際に残っている_[us]_の数 1kHzの制御ループが安定性のしきい値を満たさないようにする。

あなたの正味のローカル処理の時間予算がすでにここになっている場合負、あなたはあなたの仕事が何も良いものを生み出さないことを知っています。できない。プルストップ。

もしあなたのネットローカル処理時間予算はまだかなりの量の[私たち]を残しています-これはあなたの実際のプロセスです 'そのような設計を開始するための設計目標常に安全に収まるように計算手順と測定値。

この主要な設計限界を知らずにコーディングを開始する人は誰でも、素朴または無責任であり、「ただ教える」学者またはヘッドバン愛好家（失敗するのが大好きで、既知の壁に何度も何度も行くことを気にしない）です。 体系的なプロの設計者は、収集された確かな事実と証拠に裏付けられた設計目標に対して、すべての注意深い設計作業を開始することに集中するようになりました（そして、これらの主要な制約のセットを知らずにタスクに1秒も費やすことはありません、不思議の国のアリスだけが抽象化できます-どこに行きたいのかわからないので、どんな道でもそこにあなたを導きます-これは素敵なおとぎ話ですが、実際に実験する習慣ではありませんか？）

  • さて、あなたをチェックしてくださいしきい値、GILがリリースされる頻度（_[us]_）-もしそうならnot驚くべき回数に適合内部残りのネットローカル処理時間予算、Pythonの使用を忘れてしまうかもしれません、その単純な（そしてマルチスレッド処理に関する異議はPythonドメイン：

「... Pythonでは、GILは、計算で複数のスレッドが同時にチャギングしている場合でも、他のすべてのスレッドがブロックされて取得を待機するため、それらのスレッドの1つだけが実際に実行されることを意味しますグローバルインタプリタロック。つまり、マルチスレッドPythonプログラムは、一度に1つのスレッドしか実行されないため、実際にはシングルスレッドバージョンよりも遅くなります。すべてのスレッドに数ミリ秒ごとにGIL（ラウンドロビンスタイル）を待機、取得、および放棄することを強制することによって発生するアカウンティングオーバーヘッド...」

すべての志望の専門家が無限の量のa-無料を投稿したとしても-）adviceこれとそのパッケージはとても素晴らしいツールです。確かに、多くのパッケージは確かにare優れたツールですが、申し訳ありませんが、安定性のしきい値の特定の主要なレベルの下で、よりタイトなリアルタイムアプリケーションドメインにはほとんどありません。はい、私はpython/scikit-learnGLAN分散の高速AI/ML予測システムの設計と運用に非常に満足していましたが、_<< 1 [ms]_と_80 ~ 90 [us]_のしきい値を確実に満たすことができました。ローカルRTT-E2Eは、私の制御ループの安定境界のかなり内側にありました）

文字通り、ツールに愛のコーディングをいくらでも費やす可能性があります。これは、制御ループの安定性のしきい値に一致して満たすことができないことがわかっているため、専門家が正しく使用を開始する理由がないため、十分に注意してください。リアルタイムシステムアーキテクチャの実現可能性/レビューフェーズでは、これらのエラーや同様に単純な致命的な決定エラーの一部を繰り返さないようにします。

17
user3666197