3. データの取得、保存、およびデータ型

3.1. 1. 数据层在整体中的位置

データ層は、戦略層とランタイム層に「タイプ別、ウィンドウ別」の履歴情報を提供します。ストラテジーは生データテーブルに直接アクセスしません。代わりに、どの DataType が必要か、window_length の長さはどれくらいであるべきかを宣言します。実行前に、エンジンは DataSource から対応するデータを取得し、それをデータウィンドウに編成して、戦略に挿入します。これにより、バックテストとライブ取引で同じデータビューが使用されることが保証され、また、戦略が設計上「将来のデータ」を使用することも防止されます。

3.2. 2.生データからローカルストレージへ

2.1 データの流れ

外部データソース (例: Tushare、Eastmoney など) → フェッチとクリーニング (形式の統合、重複排除、位置合わせ) → DataSource (ファイルまたはデータベース) → 統一された構造で複数の データテーブルに書き込まれます。

2.2 DataSourceの役割

統合ストレージ抽象化: 基礎となる層が CSV/HDF/Feather ファイルであるか、MySQL などのデータベースであるかに関係なく、上位層に対しては常に「テーブル名ごと、列ごと」に読み書きされます。
マルチエンジンのサポート: さまざまな導入ニーズに合わせて、ファイル (csv/hdf/fth) またはデータベース (MySQL など) として構成できます。
積極的にデータを取得しません: DataSource は、ローカルに既に存在するデータの読み取りと書き込みのみを担当します。ネットワークからの取得と更新は、ユーザーまたはスケジュールされたタスクによってデータインターフェイスを呼び出し、DataSource に書き込まれます。

したがって、データ層の設計では「フェッチ」と「ストレージ」が分離されています。フェッチから取得されたデータはクリーニング後に DataSource に書き込まれ、戦略とバックテストは DataSource にすでに存在するデータのみを消費します。

3.3. 3. 数据表

組み込みのテーブルパーティショニング: qteasy は、市場データ (日足、分足など)、財務データ (損益計算書、貸借対照表など)、マクロと指数などを含む複数のデータテーブルを事前定義します。各テーブルには、固定のテーブル名、主キー、列スキーマがあります。
テーブルスキーマと DataType 間のマッピング: 「戦略が参照できる情報」は、多くの場合、テーブル内の列 (または計算後の 1 つ以上の列) に対応します。 DataType の name (および頻度、asset_type) からデータテーブル/列へのマッピングはシステム内で維持されます。戦略では、特定のテーブル名や列名を気にすることなく、DataType または dtype_id を介して要件を宣言するだけで済みます。

3.4. 4. DataType：从“表里的数据”到“策略可引用的信息”

4.1 name、freq、asset_type、および dtype_id

name: 特定の種類の利用可能な情報に対応するデータ型名 (close、open、total_mv、pe など)。
freq: データテーブルの時間粒度またはリサンプリング方法に関連するデータ周波数 (例: d/w/m/q)。
asset_type: 株式、指数などを区別するために使用される、該当する資産タイプ (例: E、IDX、ANY)。
dtype_id: ルール name_assettype_freq を使用して、上記の 3 つの項目から生成されます (例: close_E_d、total_mv_E_q)。ストラテジーは、get_data(dtype_id) を呼び出すときにこの ID を使用します。

4.2 組み込みの DataType とデータテーブル/列間のマッピング

システムには、大規模な組み込み DataType セットが付属しており、それぞれが異なるデータテーブルの列または派生列にマップされます。特定のテーブル名、列名、およびそれらの取得方法については、財務履歴データのダウンロードと管理 および API ドキュメントの「データ型とデータテーブル」ドキュメントを参照してください。このシリーズでは、戦略は DataType (dtype_id) 経由でのみデータを参照し、テーブルスキーマに直接依存しない ことのみを強調します。こうすることで、スキーマが進化したときに、戦略コードを変更することなく、マッピングを調整するだけで済みます。

3.5. 5. 小结：为什么策略只接触 DataType 而不直接读表

一貫性: バックテストとライブ取引の両方が同じパス (「DataType を宣言 + ウィンドウごとにエンジン挿入」) を通じてデータをフェッチし、2 つの別個のロジックセットを回避します。
先読みバイアスなし: エンジンは現在のタイムステップと window_length に基づいて履歴データウィンドウを厳密に準備するため、ストラテジーは注入されていない将来のデータにアクセスできません。
統合インターフェイス: すべての戦略は、get_data(dtype_id) を介してデータを取得します。各 dtype_id は DataType と 1 対 1 に対応するため、メンテナンスと拡張が容易になります。

データ構成と API の使用方法の詳細については、財務履歴データのダウンロードと管理 および API リファレンスを参照してください。