跳至主要内容

資料平台架構 —— 總覽

內部工程文件

一張圖看形狀。詳細設計 —— 容量、階段、成本、風險與未決事項 —— 在平台工程部的建置計畫裡, 連結放在頁尾;本頁不重複那些內容,以免出現兩份會各自漂移的來源。

IDC 站點GCP 站點Trino + 物件儲存排程器 —— 控制面自助入口Kafka 鏡像 —— 流量 Kafka 鏡像 —— 非同步,站點之間一站一座排程器Airflow + dbt,各自驅動本站 TrinoIDCTrino + 物件儲存GCP TaiwanTrino + 物件儲存GCP USTrino + 物件儲存三個彼此獨立的站點 —— 每一站都是完整的倉儲自助入口儀表板 + 語意層,身分一路傳遞

這張圖在說什麼​

每一站都是完整的倉儲,不是同一套的分片。 三站各自以自己的 Trino 查詢自己的物件儲存, 以自己持有的資料回答查詢,因此 WAN 中斷或單站故障只影響該站(項目 27)。

資料靠鏡像收斂,不靠跨站查詢。 topic 在站點之間鏡像,各站各自落地;複製為非同步, 站點在查詢時保持獨立(項目 28)。

排程器要統一,因為血緣有上限。 DAG 就是依賴圖,「這張表壞了會影響誰」是從排程器推導 出來的。管線分散在兩套排程器上,血緣圖從結構上就是破的 —— 這正是排程器要統一、而不是各團隊 各自為政的原因(項目 27)。應用層的定時任務不在此範圍內,維持原狀。

存取以人決定,不以共用服務帳號決定。 使用者透過 SSO 登入自助入口,身分一路傳遞到 Trino,每次查詢都以提問者本人的身分執行,政策也針對該身分評估(項目 27)。

工作在哪裡​

項目里程碑
27 · 資料平台資料平台里程碑
28 · 事件匯流排(Kafka)事件匯流排架構

完整計畫​