跳轉到

工具地圖

這份文件的目的，是把目前與未來可能用到的工具，放回整體架構裡看它們各自的責任邊界。

重點不是工具越多越好，而是每個工具只做它最該做的事。

整體位置圖

外部來源
  -> Connectors
  -> 資料接入與標準化
  -> Kafka Canonical Event Bus
      -> QuestDB 近即時查詢
      -> ClickHouse 分析查詢
      -> Strategy / Risk / Execution
  -> Parquet + Object Storage 歷史真相層

控制平面
  -> Supabase

治理與演進層
  -> Schema Registry
  -> Airflow / Prefect / Dagster
  -> DataHub / OpenMetadata
  -> Iceberg / Delta Lake

可觀測性
  -> Prometheus / Grafana / Logs / Alerts

核心運行層

Supabase

定位：

  • 控制面
  • 管理介面後端
  • 權限、設定、主資料

適合放：

  • instrument metadata
  • symbol mapping 管理資料
  • strategy config
  • risk params
  • broker/account config
  • users / roles / permissions

不適合放：

  • 海量 market events
  • replay archive
  • analytics 主查詢層

Kafka

定位：

  • canonical event bus
  • live data backbone

適合：

  • market data fan-out
  • strategy / risk / execution 解耦
  • replay 與 live 共用介面

不適合：

  • 當唯一歷史真相層
  • 當管理設定資料庫

Parquet + Object Storage

定位：

  • raw truth layer
  • historical truth layer

適合：

  • raw immutable log
  • normalized historical events
  • replay data source
  • large-scale backfill / recompute input

QuestDB

定位：

  • hot time-series query layer

適合：

  • recent trades / quotes / bars
  • 近即時行情查詢
  • data quality operational query
  • dashboard 最近資料查詢

ClickHouse

定位：

  • analytics warehouse

適合：

  • execution analytics
  • PnL attribution
  • factor / feature / signal analysis
  • 長時間範圍研究查詢
  • cross-strategy analytics

治理與演進層

Schema Registry

定位：

  • schema version 與相容性治理

作用：

  • producer / consumer contract 管理
  • canonical entity 的版本演進
  • 防止 schema 演進失控

Airflow / Prefect / Dagster

定位：

  • workflow orchestration

適合：

  • daily ingest
  • backfill
  • feature recompute
  • corp action update
  • analytics load
  • data quality jobs

簡單理解：

  • Airflow: 傳統且成熟
  • Prefect: Python 體驗較順
  • Dagster: data asset 思維較強

DataHub / OpenMetadata

定位：

  • metadata catalog / lineage

適合：

  • topic / table / dataset 文件化
  • owner 管理
  • lineage 關係
  • 資料資產檢索

Iceberg / Delta Lake

定位：

  • data lake table format

適合：

  • 讓 parquet 從檔案集合升級成正式資料表層
  • schema evolution
  • snapshot / table metadata 管理
  • 更正式的資料湖治理

可觀測性與營運層

Prometheus + Grafana

定位：

  • metrics、dashboard、alerts

關注重點：

  • connector health
  • Kafka lag
  • throughput
  • stale feed
  • replay progress
  • strategy heartbeat
  • fill latency

Logs / Alerts

定位：

  • incident response 與營運可見性

適合：

  • strategy errors
  • execution failures
  • schema mismatch
  • source disconnect
  • data quality anomalies

推薦採用順序

先做

  • Supabase
  • Kafka
  • Parquet + object storage
  • QuestDB
  • ClickHouse

第二波

  • Schema Registry
  • Prometheus + Grafana
  • Airflow / Prefect / Dagster

第三波

  • DataHub / OpenMetadata
  • Iceberg / Delta Lake

最後原則

選工具時，不要問「哪個最強」，而是問：

  • 這個工具在平台哪一層
  • 它是不是唯一真相來源
  • 如果未來替換它，上層是否仍可維持穩定