3. 數據獲取、存儲與數據類型

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

數據層爲策略層與運行層提供“按類型、按窗口”的歷史資訊。策略不直接訪問原始數據表，而是聲明自己需要哪些 DataType 以及多長的 window_length；運行前，引擎根據這些聲明從 DataSource 中取出對應數據、整理成數據窗口並注入策略。這樣既保證了回測與實盤使用同一套數據視圖，也從機制上避免了策略使用“未來數據”。

3.2. 2. 从原始数据到本地存储

2.1 數據流

外部數據源（如 Tushare、東方財富等）→ 拉取與清洗（格式統一、去重、對齊）→ DataSource（文件或數據庫）→ 以統一結構寫入多張數據表。

2.2 DataSource 的角色

統一存儲抽象：無論底層是 CSV/HDF/Feather 文件還是 MySQL 等數據庫，對上層而言都是“按表名、按列”讀寫。
多引擎支持：可配置爲 file（csv/hdf/fth）或 db（mysql 等），滿足不同部署需求。
不主動拉數：DataSource 只負責讀寫本地已存在的數據；從網絡拉取與更新由用戶或定時任務調用數據接口完成，再寫入 DataSource。

因此，數據層設計把“拉取”和“存儲”分開：拉取得到的數據經清洗後寫入 DataSource，策略與回測只消費 DataSource 中已有的數據。

3.3. 3. 数据表

內置表劃分：qteasy 預定義了多張數據表，大致包括行情類（如日線、分鐘線）、財務類（利潤表、資產負債表等）、宏觀與指數等。每張表有固定的表名、主鍵與列結構。
表結構與 DataType 的對應關係：一種“可被策略引用的資訊”往往對應某張表的某列（或若干列經計算得到）。DataType 的 name（及 freq、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，例如 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 + 引擎按窗口注入”的路徑取數，避免兩套邏輯。
防未來函數：引擎嚴格按當前時間步和 window_length 準備過去的數據窗口，策略無法訪問未注入的將來數據。
接口統一：所有策略都用 get_data(dtype_id) 取數，dtype_id 與 DataType 一一對應，便於維護與擴展。

更多數據配置與 API 用法見《下載並管理金融歷史數據》與 API 參考。