# Day 12: 量化研發基礎建設：持久化數據儲存結構評測與架構指南

在量化交易的高頻演算法與多因子模型回測中，I/O 延遲與記憶體佔用是決定研發迭代速度的核心瓶頸之一。

然而，數據存儲並沒有絕對完美的格式，而是取決於「資料規模大小」以及「使用場景」。

本報告整合了各大儲存格式的底層特性與實測數據，旨在為量化投研團隊提供標準化、客觀的數據工程架構指南。

## 執行摘要 (Executive Summary)

* **小型資料集 / 資料交換**：對於小型（如幾千筆）或需要跨平台交付的結構化數據，**CSV 依然是極度方便且效能足夠的選項**，尤其是配合 Pandas 的 `read_csv` 時，具備開箱即用的靈活性。
* **短期快取 (Feature Store / Cache)**：推薦使用 **Feather (Arrow IPC)**。其極致的零拷貝 (Zero-copy) 讀取速度最適合本機模型訓練的反覆讀取與大數據的臨時特徵暫存。
* **長期數據湖 (Data Lake / History DB)**：推薦使用 **Parquet** 搭配日期/標的的分區機制 (Partitioning)。面對數十萬至數千萬筆的海量歷史數據，它具備最高效的壓縮比與列級過濾能力，能完美銜接主流大數據運算引擎 (如 Polars, ClickHouse)。

---

## 一、 主流數據格式特性總覽

建構穩健的量化系統，首要任務是理解各格式在「結構、存取模式與生態相容性」上的本質差異。以下總表涵蓋了從傳統文書處理到分散式計算的主流存儲結構 [1]：

| 格式 (附檔名) | 底層結構化特性 | 主要適用場景 | 缺點 / 不適用場景 |
| :--- | :--- | :--- | :--- |
| **Excel (.xlsx)** | XML 封裝的電子表格，支援公式與圖表 | 業務人員報表產出、小規模靜態數據人工檢查 | 效能極差、體積臃腫，無法支援自動化大數據處理 |
| **CSV (.csv)** | 純明文逗號分隔，需逐字元解析與型別推斷 | 數據交換、小資料集、對外 API 匯出、日誌輸出 | 大數據(>百萬級別)、高維度矩陣、缺乏內建結構校驗 |
| **Pickle (.pkl)** | Python 專屬二進位物件序列化 | 保存神經網路權重、自訂 Class 狀態或複雜物件 | 具備跨語言/跨版本阻礙、安全風險，不適合長期存儲 |
| **HDF5 (.h5)** | 階層式數值儲存結構，支援大容量與追加寫入 | 儲存巨型 3D/4D 張量矩陣 (如 Order Book 深層特徵) | 針對簡單二維 DataFrame 而言過於笨重，分散式併發支援差 |
| **Parquet (.parquet)**| 具備字典壓縮與延遲載入之高階列式儲存 | 海量歷史 K 線與因子表歸檔、大數據分析 | 不支援頻繁的行級 (Row-level) 更新與尾部追加寫入 |
| **Feather (.feather)**| 基於 Arrow 記憶體佈局之直接映射存儲 | 記憶體間快速數據交換、高頻模型調參之臨時存儲 | 檔案體積龐大，不適用長期歸檔、缺乏依附條件合併生態 |

---

## 二、 核心效能基準測試：讀寫延遲與空間壓縮比

為了觀察不同數據量級對框架與存儲格式的影響，本測試生成了二維金融時間序列（包含 OHLCV + Ticker），並記錄了從 5 千筆到 500 萬筆數據在 Pandas (配合 PyArrow) 與 Polars 中的效能表現。

*(備註：表中 **粗體字** 代表在該資料筆量下，各項目的最小耗時或最小檔案大小)*

| 資料筆數 (Rows) | 儲存格式 | 檔案大小 (MB) | Pandas 寫入 (ms) | Pandas 讀取 (ms) | Polars 寫入 (ms) | Polars 讀取 (ms) |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **5,000** | **CSV** | 0.50 | 21.03 | **14.46** | 3.41 | 63.12 |
| | **PARQUET** | 0.25 | 24.93 | 19.00 | 2.32 | 8.74 |
| | **FEATHER** | **0.24** | 3.86 | 8.71 | **1.24** | **6.88** |
| | | | | | | |
| **50,000** | **CSV** | 4.98 | 189.45 | 57.14 | 7.12 | 13.41 |
| | **PARQUET** | 2.48 | 25.17 | 13.13 | 5.72 | 11.82 |
| | **FEATHER** | **2.35** | 6.41 | 11.98 | **3.30** | **6.68** |
| | | | | | | |
| **500,000** | **CSV** | 49.84 | 1953.43 | 483.04 | 35.99 | 39.40 |
| | **PARQUET** | **20.94** | 134.15 | 44.94 | 21.02 | 18.50 |
| | **FEATHER** | 23.48 | 37.91 | 33.79 | **19.45** | **9.53** |
| | | | | | | |
| **5,000,000** | **CSV** | 498.43 | 27880.40 | 5439.49 | 307.80 | 488.95 |
| | **PARQUET** | **202.48** | 1391.49 | 336.14 | 328.21 | 153.28 |
| | **FEATHER** | 234.76 | 534.82 | 322.14 | **315.65** | **23.60** |

### 基準測試解讀：規模決定選擇
1. **小數據的容忍區間 (5,000 - 50,000 筆)**：在小數據情況下，Pandas 讀取 CSV 的速度（14 ms）極具競爭力。這意味著對於諸如單日標的清單、策略配置檔、或是小量指標匯出，**繼續使用 CSV 配合 Pandas 是完全合理且高效的**。
2. **效能的轉捩點 (500,000 筆以上)**：當資料量來到百萬級數，CSV 的序列化成本呈現非線性爆炸（Pandas 讀取 CSV 需 5.4 秒，寫入更需驚人的 27.8 秒）。
3. **Feather 的極速領域**：在 500 萬筆級數，Polars 讀取 Feather 僅需 **23 毫秒**，這是任何其他格式無法企及的領域。
4. **Parquet 的空間魔法**：在 500 萬筆規模下，Parquet 將近 500 MB 的 CSV 數據壓縮至 **202 MB**。它雖然讀寫速度稍微慢於 Feather，卻提供了雲端存儲上最經濟的空間利用率。

---

## 三、 工程落地關鍵維度與架構設計

儘管基準測試顯示 Feather 在存取速度上具備絕對統治力，但在頂尖量化機構的生產環境 (Production Environment) 中，**Parquet 依然是巨量長期持久化儲存的首選標準**。以下為架構決策的核心工程維度：

### 1. 記憶體佔用與系統穩定性 (Memory Footprint)
* **Feather 的陷阱**：Feather 的極速源自於將硬碟資料直接映射進記憶體。當處理遠超 RAM 容量的數據集（如數百 GB 的底層 Tick 資料）時，Feather 極易觸發 OOM (Out Of Memory) 導致系統崩潰。
* **Parquet 的防線**：Parquet 具備強大的「投影下推 (Projection Pushdown)」與「統計元數據過濾 (Metadata Filtering)」。在讀取前，引擎能根據檔首的索引塊判斷該檔案是否包含所需數據，從而保證峰值記憶體佔用極低。

### 2. 數據尾部追加 (Data Appending & Up-Sert)
* 金融數據的本質是持續生成的。**CSV 與 HDF5 支援原生的追加寫入 (Append-mode)**，這也是 CSV 為什麼常作為簡易串流日誌收集的原因。
* 相反地，**Parquet 與 Feather 都不適合頻繁的尾部追加**，每次寫入皆需重構檔案結構。
* **產業標準解法：分區寫入 (Partitioning)**。針對 Parquet，業界標準是利用目錄進行分區（例如 `/data/parquet/year=2024/month=10/`）。後續透過架構（如 DuckDB）將碎片化的 Parquet 虛擬合併為單一表單。

### 3. 分佈式計算生態相容性 (Ecosystem Interoperability)
* **Parquet 是現代大數據的共同語言**。所有的主流大系統（如 ClickHouse, Spark, DuckDB）皆深度支援 Parquet，提供極致的最佳化。
* **Feather 受限於 Python 與 R 語言的資料互動**，若未來將交易系統與資料庫對接，缺乏生態系的 Feather 可能不再適用。

---

## 結論：平衡效能與架構複雜度 —— 邁向全局最優的設計

無論是 Feather 在極速載入上的亮眼表現，還是 CSV 在輕量級應用的便攜性，皆展示了不同格式在特定場景下的優勢。然而，若從**量化投研團隊架構師或 PM (Portfolio Manager)** 的視角出發，構建一個能穩定承載海量數據、且便於多位研究員協作的系統，「可維護性、架構簡潔性與生態通用標準」往往是首要考量。

在現代量化技術棧（如漸趨主流的 **Python + Rust** 開發環境）中，架構設計傾向於降低工程複雜度，並建立 **「單一真實數據源 (Single Source of Truth)」**。基於此原則，以下提供幾項實務上的架構建議：

1. **以 Parquet 作為架構的共通語言**：
Parquet 憑藉其優異的儲存壓縮比、成熟的生態系跨語言相容性（Rust/C++/Python/SQL），以及強大的統計元數據加速能力，成為業界整合歷史資料與特徵庫的首選。與其在系統中混用多種二進位格式以追求局部的 I/O 極限，將架構統一收斂至 Parquet（搭配目錄分區機制），能顯著降低基礎設施的維護與溝通成本。
2. **善用新世代運算引擎的紅利**：
隨著 Polars 等底層由 Rust 構建的工具逐漸普及，運算與 I/O 的瓶頸已大幅緩解。配合 Parquet 的投影下推 (Projection Pushdown) 能力，在多數分析場景中，系統已經能以極低的記憶體佔用達到極高的吞吐量。這使得團隊可以更少地依賴記憶體映射 (如 Feather) 即能取得類似的效能突破，進而提升整體的系統穩定性。
3. **適才適所的 CSV 應用**：
在追求極致效能的整體架構中，CSV 依然扮演著不可或缺的角色。面對設定檔 (Config)、人工確認的標的清單、或者向外部系統串接的小型結構化數據，CSV 的高可讀性與人工檢驗之便利性，仍是極為高效的除錯工具。

理想的數據架構並非在所有環節追求絕對的極速，而是找到效能與可維護性之間的最佳平衡。透過標準化導入 **Polars + Parquet (分區架構)**，不僅能有效管理海量時序資料，也能讓投研團隊將寶貴的資源專心投入於 Alpha 挖掘與策略研發的核心任務中。

---

## 參考文獻 / 參考資源

[1] 科大金工 (2024). *量化金融数据存储结构及性能对比*. Bilibili. 取得自：[https://www.bilibili.com/video/BV1TMzvBGEBb/](https://www.bilibili.com/video/BV1TMzvBGEBb/?spm_id_from=333.1387.homepage.video_card.click&vd_source=194f5e3166f0bc459b08f116d99e3b40)