跳至主要内容

10 · 資料平台

此主題 roadmap 項目的里程碑

截至 2026-10-22 · 今天

完成進行中規劃中等待前置逾期（目標日已過）等待今天

甘特圖​

2026 Q32026 Q42027 Q12027 Q22027 Q32027 Q42028 Q12028 Q22028 Q32028 Q42029 Q12029 Q22029 Q32029 Q42030 Q17891011121234567891011121234567891011121234567891011121227 · 資料平台27.3Phase 1 —— 地端資料平台就緒2026-11-1127.4Phase 2 —— US2028-02-25 · 規劃中 · 0/7等待 27.327.8Phase 3 —— asia-east1；三站聯邦完成2028-12-10 · 規劃中 · 0/3等待 27.427.9ETL 排程器上線，提供類似 BigQuery 排程查詢的入口2027-04-12 · 規劃中 · 0/4等待 27.327.10StarRocks 遷移至資料平台2028-12-10 · 規劃中 · 0/4等待 27.327.11既有作業以排程查詢形式遷入2028-02-25 · 規劃中 · 0/3等待 27.927.12已遷入作業的 DAG 重建2028-12-10 · 規劃中 · 0/3等待 27.1128 · 事件匯流排(Kafka)28.1事件匯流排端到端驗證 —— 從 HTTP 發布到查得到的資料表2026-08-2728.2控制面在 git —— schema、topic 與存取規則皆為程式碼，並有 CI2027-09-17 · 規劃中 · 0/328.3後端服務以已認證的 HTTP 發布，寫入前先驗證2028-03-17 · 規劃中 · 0/3等待 28.228.4US 站 Kafka 建置完成，作為唯讀副本站2028-07-19 · 規劃中 · 0/3等待 28.228.5地端匯流點上線 —— 事件與異動資料落在同一處2028-09-17 · 等待 28.328.6三站之間的鏡像建立，每一站各自落地一份2028-11-17 · 等待 28.4, 28.528.7複製延遲與健康可觀測、有告警 —— 在第一條邊開始載流量之前2028-09-17 · 規劃中 · 0/3等待 28.228.8演練單站中斷與其後的追補2029-02-22等待 28.6, 28.7今天

里程碑​

#里程碑開始日目標日狀態等待團隊Epic推導
27 · 資料平台
27.3Phase 1 —— 地端資料平台就緒2026-09-012026-11-11進行中—平台工程——
27.4Phase 2 —— US2026-11-122028-02-25規劃中27.3平台工程—等待 27.3
27.8Phase 3 —— asia-east1；三站聯邦完成2027-06-192028-12-10規劃中27.4平台工程—等待 27.4
27.9ETL 排程器上線，提供類似 BigQuery 排程查詢的入口2026-11-122027-04-12規劃中27.3平台工程—等待 27.3
27.10StarRocks 遷移至資料平台2026-11-122028-12-10規劃中27.3平台工程—等待 27.3
27.11既有作業以排程查詢形式遷入2027-01-122028-02-25規劃中27.9平台工程—等待 27.9
27.12已遷入作業的 DAG 重建2027-02-012028-12-10規劃中27.11平台工程—等待 27.11
28 · 事件匯流排(Kafka)
28.1事件匯流排端到端驗證 —— 從 HTTP 發布到查得到的資料表—2026-08-27完成—平台工程——
28.2控制面在 git —— schema、topic 與存取規則皆為程式碼，並有 CI—2027-09-17規劃中—平台工程——
28.3後端服務以已認證的 HTTP 發布，寫入前先驗證—2028-03-17規劃中28.2平台工程—等待 28.2
28.4US 站 Kafka 建置完成，作為唯讀副本站2027-01-042028-07-19規劃中28.2平台工程—等待 28.2
28.5地端匯流點上線 —— 事件與異動資料落在同一處—2028-09-17規劃中28.3平台工程—等待 28.3
28.6三站之間的鏡像建立，每一站各自落地一份—2028-11-17規劃中28.4, 28.5平台工程—等待 28.4, 28.5
28.7複製延遲與健康可觀測、有告警 —— 在第一條邊開始載流量之前2027-01-042028-09-17規劃中28.2平台工程—等待 28.2
28.8演練單站中斷與其後的追補—2029-02-22規劃中28.6, 28.7平台工程—等待 28.6, 28.7

細節​

27.3Phase 1 —— 地端資料平台就緒2026-11-11進行中 · 2/8
  • 既有儲存叢集的容錯現況實測並寫下負責人 · TBD
    既有叢集只有兩塊同位分片：掉一台節點、或做一次 rolling upgrade，就沒有任何容錯空間。
  • 儲存決策定案 —— 成本、交期、機櫃、供電與網路確認負責人 · TBD架構 →
  • 在 SIT 可查詢，同時看得到既有倉儲與 Iceberg負責人 · TBD
  • 認證、分組與授權引擎端到端實測負責人 · TBD
    身分由外部 IdP 簽進 JWT，每個請求自行驗簽，授權交由一旁的 policy-as-code 判定。
  • 權限 RFC 與基礎設施及資料倉儲團隊 review；確定承接單位負責人 · TBD
  • 欄位遮罩可端到端實測負責人 · TBD
    在這件事完成之前，RFC 明寫：不可宣稱敏感欄位已受遮罩保護。
  • 排程器範圍：既有排程器上的資料管線依 owner 列出，並與應用層定時任務分開負責人 · TBD
  • production 就緒簽署：容量基準、備援與回復演練、與資料倉儲團隊的交接負責人 · TBD
27.4Phase 2 —— US2028-02-25規劃中 · 0/7
  • US 站 GKE 以 IaC 建置；查詢叢集註冊至本站 gateway負責人 · TBD
    一站一個 gateway：各自只認識本站的叢集。
  • 跨洲流量稽核與告警負責人 · TBD
  • 依查詢歷史定出匯出範圍；選定的表以 Iceberg 落在 GCS-US 可讀負責人 · TBD
    匯出是選擇性的，不是全量搬遷。最小權限服務帳號：只給讀取與 read session。
  • 以搶佔式資源彈性擴縮，並設硬性預算上限負責人 · TBD
  • 匯出的雲端資料納入相同的授權與稽核；政策來源只有一份負責人 · TBD
  • 雲端管線在 27.9 的排程器上對 US 站執行負責人 · TBD
  • asia-east1 的定位與資料落地問題在本階段開頭提出負責人 · TBD
    若結論是「必須留在亞洲」，Phase 3 的優先序會高於本階段其餘項目。
27.8Phase 3 —— asia-east1；三站聯邦完成2028-12-10規劃中 · 0/3
  • 查詢叢集運行於既有 GKE 資源，以本站 gateway 為入口負責人 · TBD
  • GCS-asia-east1 的 Iceberg catalog 上線，作為新資料落地區負責人 · TBD架構 →
  • asia-east1 站排程器上線；三站皆為一站一座排程器負責人 · TBD
27.9ETL 排程器上線，提供類似 BigQuery 排程查詢的入口2027-04-12規劃中 · 0/4
  • 排程器與 dbt 部署完成負責人 · TBD
  • 排程查詢入口：使用者只給 SQL、排程與目標表，平台自動產生排程作業負責人 · TBD
    讓既有作業可以原樣搬過來，不必先改寫。
  • 作業以擁有它的團隊身分執行負責人 · TBD
  • 有一個團隊在無人協助下搬完一個作業負責人 · TBD
27.10StarRocks 遷移至資料平台2028-12-10規劃中 · 0/4
  • StarRocks 的表與讀取方依 owner 列出負責人 · TBD
  • 表改由資料平台以 Iceberg 提供負責人 · TBD
  • 報表與 SQL 改指資料平台（與資料倉儲團隊一起）負責人 · TBD
  • 最後一個讀取方遷走後 StarRocks 退場負責人 · TBD
27.11既有作業以排程查詢形式遷入2028-02-25規劃中 · 0/3
  • 資料作業依 owner 列出 —— BigQuery 排程查詢與既有排程器；應用層定時任務不在範圍負責人 · TBD
  • 原樣搬入，不先改寫負責人 · TBD
  • 每搬一個作業就關掉它原本的排程負責人 · TBD
27.12已遷入作業的 DAG 重建2028-12-10規劃中 · 0/3
  • 依相依程度排序，被依賴最多者優先負責人 · TBD
  • 宣告相依關係，讓血緣直接來自 DAG負責人 · TBD
    DAG 就是依賴圖：「這張表壞了會影響誰」在這裡得到回答。
  • 重建完成的作業取代它的排程查詢形式負責人 · TBD
28.1事件匯流排端到端驗證 —— 從 HTTP 發布到查得到的資料表2026-08-27完成 · 3/3
  • 以 HTTP 發布，通過 schema 驗證，並以已驗證的身分寫入負責人 · TBD
  • 落地為 Iceberg，不重複也不遺漏負責人 · TBD
  • 可從 Trino 查得到；147 項測試全綠負責人 · TBD
    政策單元測試 52/52，另有 fail-closed、刪除保護、決策日誌三項專項驗證。最後查證 2026-08-27。
28.2控制面在 git —— schema、topic 與存取規則皆為程式碼，並有 CI2027-09-17規劃中 · 0/3
  • 一個 topic 一份檔案，作為唯一事實來源負責人 · TBD
    schema、授權資料與落地資料表都由它產生；三者都不手改。
  • CI 擋下違反 schema 規則的變更負責人 · TBD
  • 註冊中心拓樸定案 —— 一站可寫，其餘唯讀負責人 · TBD
28.3後端服務以已認證的 HTTP 發布，寫入前先驗證2028-03-17規劃中 · 0/3
  • HTTP 端點具備認證與政策式授權負責人 · TBD
  • broker 直接驗簽；存取規則由 topic 檔案產生負責人 · TBD
  • 呼叫者身分原封不動傳遞到 broker負責人 · TBD
    身分不換手，授權只有一個執行點。
28.4US 站 Kafka 建置完成，作為唯讀副本站2028-07-19規劃中 · 0/3
  • broker 與 controller 建置，規格比照既有站台負責人 · TBD
    計畫的規格是 broker ×4 ＋ controller ×3 ＋ 28 TB 資料碟，是該階段最大的硬體項目。
  • 本站在 topic 控制面註冊為唯讀負責人 · TBD
  • 保留期與容量依實測事件量決定負責人 · TBD
28.5地端匯流點上線 —— 事件與異動資料落在同一處2028-09-17規劃中 · 0/3
  • 地端 Kafka 建立為共同落點負責人 · TBD
  • 不依賴 broker healthcheck 的監控負責人 · TBD
    healthcheck 走內部 listener、以 super user 身分在授權被呼叫之前就短路：實測授權全壞、全站拒絕時，broker 仍回報健康。
  • 自由格式內容的防線不只控制面的一條 lint 規則負責人 · TBD
    格式定義寫得太鬆時,內容會在落地時消失:沒有錯誤、不進死信佇列、對帳數字還是對的。防線只有一條可豁免的 lint 規則,而豁免不是叢集上的性質。
28.6三站之間的鏡像建立，每一站各自落地一份2028-11-17規劃中 · 0/3
  • 三站之間的有向複製邊設定完成負責人 · TBD
    雙向邊必須用預設命名政策，否則鏡像回原站的 topic 會與自己撞名。
  • schema registry 由可寫站單向複製出去負責人 · TBD
  • 每一站各自落地到自己的物件儲存負責人 · TBD架構 →
28.7複製延遲與健康可觀測、有告警 —— 在第一條邊開始載流量之前2028-09-17規劃中 · 0/3
  • 每一條複製邊都收集延遲與健康指標負責人 · TBD
    複製本來就是非同步的，目標是延遲看得見、會告警，不是延遲為零。
  • 告警門檻議定、接上，並指定負責人負責人 · TBD
  • 跨站流量計量並告警負責人 · TBD架構 →
28.8演練單站中斷與其後的追補2029-02-22規劃中 · 0/3
  • 端到端演練單站中斷負責人 · TBD
  • 回復時間與積壓消化實測，不用估的負責人 · TBD
  • 依演練結果寫成 runbook負責人 · TBD

回到 平台路線圖總覽 · 這些里程碑背後的方向見平台路線圖。