平台演進藍圖：Phase 1 到 Phase 5

這份文件的目的，不是列出一堆工具名稱，而是定義 Bull Investing 應如何從可用的交易系統，逐步演進成可治理、可重播、可擴充的量化平台。

核心原則：

不追求一步到位
每一階段都要有明確邊界
每一階段都要能留下可延續資產
優先建立穩定語言與穩定流程，而不是堆更多工具

全階段共同原則

在所有階段都應維持以下原則：

策略不得直接依賴 vendor 或 broker 原生 API
historical、replay、live 必須逐步收斂到同一套資料介面
raw data 與 normalized data 必須分開
internal schema 必須比外部來源更穩定
query layer 不應被視為唯一真相來源
instrument identity 必須由內部主檔管理

Phase 1：建立平台地基

目標

把現有交易系統整理成最小可用的平台骨架，先停止「策略直接碰外部 API」的模式。

核心能力

instrument master 初版
canonical trade / quote / bar schema
source connector 與 ingestion 邊界
raw archive 與 normalized event stream 雙軌
strategy runtime 初版
risk check 與 execution gateway 初版

建議技術角色

Supabase: 控制面、設定、權限、基本主資料
Kafka: live canonical event bus
Parquet + object storage: raw archive 與 historical archive
QuestDB: 近即時查詢
ClickHouse: 可先保留規劃，或先不上

交付重點

instrument_id、symbol mapping、session template 明確定義
md.trade.v1、md.quote.v1、md.bar.1s.v1、md.bar.1m.v1
至少一條 live data source 接入
至少一條 historical source 可輸出同格式事件
strategy 不再直接碰 vendor schema

驗收標準

同一個策略可以吃 canonical events
任一筆市場事件都能追到 raw source
vendor 替換不需重寫 strategy 核心
broker 回報可回流到平台事件流

Phase 2：統一回放與研究流程

目標

把研究、回測、重播、即時交易慢慢收斂成同一條資料語言，降低「每個場景一套系統」的風險。

核心能力

historical -> replay -> live consumer 介面統一
bar aggregation 正式化
indicator / feature pipeline 初版
回放工具與事故重現能力
data quality checks 初版

這一階段的關鍵問題

strategy 是否知道自己正在吃 replay 還是 live
bar 是否依照固定 session 與 event time 聚合
late event、duplicate event、stale feed 是否有規則

建議新增能力

replay service
bar aggregator
indicator / feature service
基本 data quality monitor

驗收標準

同一份 historical data 可 replay 到 live consumer
可以重現某一天某段行情與策略行為
研究與 live 使用同一套 trade / quote / bar 定義
基本資料品質問題可被偵測與告警

Phase 3：治理層正式成形

目標

讓平台不只是能跑，而是開始具備 schema 治理、資料工作流、品質控管與正式資料分層能力。

核心能力

schema version 規範
schema registry 或等價治理方式
topic naming / data contract 正式化
workflow orchestration
object storage 佈局規範
ClickHouse analytics layer 正式上線

建議新增工具或能力

Schema Registry
Airflow、Prefect 或 Dagster 擇一
Prometheus + Grafana 觀測能力初版
ClickHouse 匯入與研究查詢流程

這一階段要解決的問題

producer 改 schema 時如何不炸下游
backfill、daily ingest、feature recompute 如何可管理
各 table、topic、dataset 的 owner 與用途是否清楚

驗收標準

canonical entity 都有 version 概念
batch / backfill / reload 不再依賴一堆散落 script
analytics query 與 operational query 明確分層
topic、table、dataset 命名開始收斂一致

Phase 4：資料平台與交易平台成熟化

目標

把平台從「資料可用」提升到「交易可治理、風控可追蹤、營運可操作」。

核心能力

execution abstraction 成熟化
order / fill / position reconciliation
portfolio 與 account snapshot 正式化
cross-source validation
advanced data quality 與 health monitoring
operational controls

建議新增能力

fill reconciler
broker/account reconciliation jobs
stale data guard
kill switch
strategy on/off controls
vendor divergence monitor

這一階段的重點

不只看 market data，也要看 execution truth
不只看 strategy signal，也要看 broker 實際回報
不只做資料平台，也要做可營運的 production trading platform

驗收標準

broker position 與 internal position 可定期對帳
order lifecycle 可完整回溯
major incident 可用 replay + logs + metrics 還原
production 有基本 operational controls 與風控開關

Phase 5：正式平台化與資產治理

目標

讓整個系統從工程專案，演進為正式的研究與交易平台資產。

核心能力

metadata catalog / lineage
feature datasets / research datasets 正式管理
data lake table format 升級評估
團隊協作流程、ownership、可維護性成熟化

可評估方向

DataHub、OpenMetadata、Amundsen
Iceberg 或 Delta Lake
更正式的 data lineage 與 ownership 管理
reproducible research dataset 標準化

這一階段解決的問題

哪份資料由誰負責
哪個 topic / table 會影響哪些系統
因子、特徵、標註資料如何可重現
歷史資料層如何從 parquet 檔案集合進化成正式 data lake

驗收標準

主要資料資產都有 owner、說明、上下游關係
feature / factor / replay datasets 可版本化
資料湖與分析層有更正式的治理能力
新市場、新 broker、新策略的接入成本顯著下降

各階段重點總結

Phase 1

先建立地基與邊界，停止直接依賴外部 API。

Phase 2

把 replay、研究、即時交易收斂成同一條資料語言。

Phase 3

補上 schema、workflow、analytics 與基礎治理能力。

Phase 4

讓交易、風控、對帳、營運進入正式 production 等級。

Phase 5

把整個平台升級成可治理、可協作、可長期累積的公司資產。

最後一句話

平台真正的成熟，不是工具越來越多，而是每加一個市場、broker、策略、資料源時，都不需要再砍掉重練。