プログラマティック取引の実際のコードに関する前の 3 つの記事からの続きです。
ハードコア乾物～定量取引システムの自動リアルタイム取引の詳細と考え方（１．問題点と困難さ）
定量取引システム - 自動ファームオファーの詳細と考え方 (2. ファームオファーの目的)
定量取引システム - 自動リアルオファーの詳細と考え方 (3. 処理スキル)
ここでは、マルチストラテジー取引システムと実際のオファーコードの全体構造におけるマーケットセンターについて引き続き説明します。
序文
取引業界、特に先物取引ではハイレバレッジ取引の達人が時々現れ、10万元の元本が軽く数千万元になることもあります。しかし、それらの人々のほとんどは、夜空を横切る流星のように、一瞬のまばゆいばかりの時間を経て、静かに消えていきました。
そして、長い間ビジネスを続けている別のベテラントレーダーのグループは、一日中従順で、未知の未来について話し、市場やブラックスワンがいつでもやってくるのではないかと恐れ、同時に非常に低いレバレッジを使用しています。ポジションをオープンし、試行錯誤を繰り返しますが、マスターのような決意と勇気がなければ、方向性は壁に生えた草のように左右に振れます。しかし、何らかの理由で、このグループはレバレッジが低いにもかかわらず、市場で活発に活動しています。そのポジションは小さくありません。
トレーディングの世界では人間の性質上、スターは簡単に入手できますが、誕生日のスターを見つけるのは困難です。
生き残ったクオンツトレーダーとして、トレーディングにおいてより重要なポイントの 1 つは、複数の戦略の必要性を認識することだと思います。人的資源は限られており（機関のように複数のトレーダーを雇わない限り）、市場は年中無休で稼働しており、エントリーポイントを見逃しやすいため、主観的な取引でマルチ戦略を実装することは依然として困難です。ただし、プログラム取引は比較的簡単に実装できます。プログラミングは人間の脳や目の価格傾向のパターンを識別する能力を失いますが、より強力な約定力と戦略をコピーしてポジションを分散する能力が強いため、長所と短所があります。
複数のターゲット、複数の戦略、複数のパラメータにより、資本ポジションは自然に分散されます。もはや、単一の利益または損失のエキサイティングな開始と終了ではなく、資本曲線を可能な限り滑らかにすることが追求されています。
概要
下の図は、実際のコードのセットの一般的なアーキテクチャ図です。
アーキテクチャ全体は 2 つの部分に分かれています。 1 つは独立した市場センターであり、もう 1 つは戦略ロジックの実装を担当する取引プログラムです。
通常、私は 1 つのアカウントでプログラムを開始し、そのポリシー パラメーターとアカウント キーは構成ファイルによって区別されるため、コードを完全に共有でき、コード バージョンの管理が容易になります。戦略の一部のパラメータは、主に特定の操作が突然同時に実行されないようにずらすために、わずかに異なる場合があります。
以前、戦略がほとんどなかったとき、各サブ戦略で Python プログラムを開始しましたが、後でサーバーのメモリが十分ではないことがわかりました。 Python プログラム自体は約 60M のメモリを占有するため、さらに多くのストラテジがあり、複数のアカウントにコピーされると、すぐに大量のメモリを占有します。より強力なサーバーを購入するには、より多くの費用を支払うこともできますが、管理とメンテナンスが面倒になります。最終的には、アカウントに基づいて、異なる通貨 (複数の通貨と複数のパラメータ) での同様の戦略がグループ化され、その戦略のグループが Python アプリに分割されるようになりました。実行してみて、この組み合わせモデルは複数のアカウントと複数の戦略のレイアウトに非常に適していると感じました。コード管理とリアルタイムの運用とメンテナンスに非常に便利です。
1 つの Python アプリに対して 1 つのサブ戦略を使用する利点は、コードがはるかに単純になることです。ただし、想像してみてください。トップ 40 の主要コインで戦略が実行され、各コインで 3 つの異なる戦略が実行される場合、さらに 3 つのアカウントを追加すると、120 のサブ戦略になります。このモデルは持続不可能です。
アプリの数が少ない場合は、まず tmux などのターミナルを使用してログ情報をリアルタイムに出力できるため、プログラム動作の初期段階での監視に非常に便利です。後段でコードが安定した後は、pm2などの運用保守ソフトウェアを利用して管理することになります。今後は定期的にログ ファイルを分析してください。
複数のターゲットと複数の戦略の場合、独立したマーケットセンターが標準でなければなりません。取得したさまざまな市場情報は、複数の取引プログラム、つまり上の図の左側にある戦略モジュール間で共有できます。
見積センター
下の図は、マーケット センター モジュールの詳細図です。
まず、構成ファイルを通じて取得する k ライン シンボルを設定できるため、将来タイプを簡単に変更できます。
複数期間の場合、公約数期間 k ラインを取得でき、各戦略は独自のニーズに応じてリサンプリングできます。
物事を徹底的に単純化したい場合は、15 分の K ラインを直接取得するのが最善です。これは、15 分未満のサイクルの中低頻度戦略、特にトレンドフォローは基本的に重要であるためです。長期的にお金を稼ぐのは難しい。
たとえば、15 分、1 時間、または 4 時間の戦略がある場合、マーケット センターは 15 分の K ラインを取得するだけで済みます。リサンプル後の大きな期間の k ラインの長さが十分でない場合は、起動時にさらに 15 分の k ラインをデータベースに保存する必要があります。
WebSocket は最新の更新された k ライン情報のみをプッシュするため、戦略が比較的大きな k ライン サイクルと長いルックバック時間を使用する場合 (ma150 の 4 時間など)、600 時間 (25 日) のデータになります。 1 分あたり 1 k 行が必要な場合、2,400 行が必要になります。これは、その後の継続的な更新の基礎として、マーケット センターの開始時に残りの API を介して 1 回限りの取得と保存に依存します。
マーケットセンター全体を 2 つのアプリに分割しました。実際には、1 つのアプリに統合することもできますが、分離した方が堅牢です。まず第 2 のプラン B について話しましょう。
プランB
以前のいくつかの記事で述べたように、これは主に PlanA の Web ソケットが切断されるのを防ぐためであり、特に戦略の終了時に、価格が一定の距離ですでに反転して終了することを避けるための一時的なバックアップとして使用されます。ポジションが解消されていないため、さらに予想外の損失が発生します。
PlanB は非常にシンプルで、主に public_get_ticker_price 関数を使用して、すべての永久契約の最新価格を一度に取得します。こちらもビーアン自身がまとめた最新価格情報です。
現在、B'an には 200 を超える永久契約があり、最新の価格を 1 つずつ取得すると、各商品の価格が 1 分間に 4,000 回以上呼び出されるようにする必要があります。可能な制限を超えなければなりません。ただし、前述の関数の API ウェイトはわずか 2 です。3 秒に 1 回使用された場合、1 分あたり 40 個の API クォータを消費するだけです。クォータを超えることを心配する必要はありません。
私のテスト後、Binance は基本的にすべての契約の価格を約 1 ～ 2 秒に 1 回集計するため、中頻度および低頻度戦略のバックアップ価格の場合、約 5 秒の遅延で完全に十分です。
要件が高くない場合は、これを使用して、WebSocket の使用を完全に回避して、すべてのコントラクトの大まかな K ラインを合成することもできます。この種の K ラインは取引には使用できませんが、市場情報全体をスキャンし、移動平均の発散や収束など、独自に設計された戦略アルゴリズムに基づいて主観的なトレーダーにエントリー ポイントを提供するためにも使用できます。単純なパターン認識などの信号。そうでなければ、どうしてそんなにたくさんのコインが見えるのでしょうか？優れたデイトレーダーがいる場合、このツールは取引を支援するのに役立つかもしれません。以前にも他の人のために同様のツールを書いたことがありますが、市場が好調なときは非常に良いのですが、最近の市場は良くありません。
もちろん、このソリューションは多くのコインを取引する場合にのみ実用的です。それ以外の場合は、各品種のハンディキャップ BBO 価格を直接取得する方が良いでしょう。
また、バックアップ価格情報は、ポジションに対応する法定通貨資金の量やおおよその損益率を計算するために使用されるため、それほど正確なデータを必要とせず、メインコードで頻繁に使用する必要があることにも注意してください。頻繁に使用されないコードスニペットや情報は、かなり前に壊れている可能性があり、使用されるまで気づかない可能性があるためです。多くのコードを書いたことがある人なら誰でも、この種の付録コードは気付かないうちに誤って変更されやすいことを知っています。
プランA
マーケットセンターのメインコード。このアプリには主に4つの機能があります。
過去の基準ローソク足を取得します。この記事の前半で述べたように、開始するたびに、すべての戦略で必要なすべての K ラインが存在することを確認する必要があります。
Webソケットの管理。このモジュールはもう少し複雑で、さまざまな切断状況や再接続などを処理する必要があります。取引所が新しい k ライン データをプッシュするたびに、データベース内の k ラインの最新バーのデータが更新されます。
Kラインデータに加えて、各品種の精度情報の最新情報もマーケットセンターに載せています。つまり、public_get_exchangeinfo 関数は、さまざまな注文価格と注文数量の最小精度を取得し、それらを便利な辞書型に変換します。このようにして、すべての戦略を共有できます。
最後のステップはチェックです。単純な健全性チェックで十分です。取得したKラインが連続しているか、漏れがないかを確認し、定期的にRest APIで取得したKラインと1つずつ比較し、PlanBで取得した価格との価格差が大きすぎないかなどを確認します。つまり、エラーを早期に発見できるように比較と検査を行うだけです。
これらはおそらく、私の中低周波戦略市場の中核となる構造です。必要に応じて、WebSocket を通じてアカウント更新情報を取得することもできます。しかし、これは少し面倒なので、ほとんどの場合は使用されません。