架構思考

Data Platform 筆記#01：初版技術架構成形

Photo by Jakub Żerdzicki / Unsplash

在上篇的 POC 之後，我們整理了一份內部報告，將問題拆成資料蒐集、基礎資料定義、資料量與查詢效能、資料治理、技術架構等幾個面向。
這份整理的目的是先建立邊界，讓我們從發散與模糊，逐步走向具體且聚焦。

在這個基礎上，我開始把關注重點轉向資料流：
如何讓資料自動、穩定、乾淨地進到分析效能較好的資料庫？

同時，也剛好迎來一個契機：與技術能量較高的團隊合作發展數據中台。這讓 Data Center 的推進獲得更多資源與支援，讓我們能更系統化地思考架構問題。

思考階段

這個階段，我們主要思考幾個問題：

不同來源的資料，能不能用相對一致的方法接進來？
資料會持續累積，是否有合適的儲存與管理方案？
資料進來後，分層應該怎麼定義？
查詢分析時，是否有更適合的查詢引擎？

各資料源的特性不同，接收方式很難完全一致。但若每種來源都設計一套專屬流程，維運成本會快速上升。因此初步的想法是先用一種主要方式處理大多數的情境，讓資料流先跑起來，再逐步優化。

過去常見的分層方式，是將資料分成：

可追溯的原始資料（Stage）
清洗整理後的乾淨資料（Data）
面向特定分析需求的整合資料（Mart）

延續這個方向大致不會錯，但在技術解決方案持續演進下，這些分層該定義在哪裡才更合適，仍需要透過實驗與驗證。

另一方面，以預期資料量來看，單純使用傳統 RDB 進行分析查詢，效能提升空間有限。這也讓我們開始探索引入更適合 OLAP 場景的引擎。

在這段時間裡，我們投入了不少時間測試不同工具，評估的也不只是 License，而是包含：

建置與部署難易度
操作與學習門檻
擴充與彈性
未來維運能量是否足以支撐

我們不是在定義「最佳解」，而是透過反覆測試與討論，逐步找出一個「合適且可掌握」的組合

初版架構的輪廓

當時建構初版架構的核心目標，是找出一套能將「資料接收、資料分層、分析查詢」串起來的解決方案。
對應的資料流概念如下：

Source DB -> Data Collection (CDC or ETL) -> Data Lake -> OLAP DB -> Virtualization

在這個輪廓中，各階段的職責是：

Data Collection：接收來源資料的機制
Data Lake：保存接收進來的資料
OLAP DB：面向分析查詢與報表輸出的服務層

當時選擇的主要元件如下，也一併記錄背景理解與用途：

Debezium：常見的 CDC（Change Data Capture）工具，可以從資料庫變更日誌抓資料。
Kafka：事件串流平台，適合承接持續進來的資料變更事件，解耦來源系統與下游處理。
Iceberg：資料湖表格式，存放接收進來的原始資料 (Stage)，以及整理乾淨的資料 (Data)。
Spark：分散式資料處理引擎，負責執行將 Stage 的資料整理到 Data 層的轉換邏輯。
Doris：負責分析查詢的 OLAP 引擎，提供查詢與報表分析能力。

初版輪廓完成是一個關鍵的里程碑，因為資料可以一路走到分析端，而不再只是架構圖裡的一個個元件。

解題累積經驗

開始透過實際資料驗證架構後，陸續遇到了一些問題。這些問題反而成為架構調整的重要契機，幫助我們快速累積經驗。

首先發現的問題是接收進 Iceberg 的資料偶發重複存在的狀況，當下我的處理方式略粗暴，直接利用 Doris 的特性，透過 Doris Job 將資料抄進 Doris，先讓重複問題消失，暫時地先無視這個方案需要 Doris Admin 權限的問題。

在解題過程中，我也持續吸收 Data Lake 的相關概念。漸漸地，開始將資料層拆開來看，分開處理「完整事實資料」與「查詢效率」兩件事。前者重視完整可追溯，後者重視分析效率，這個轉向也影響了後面的流程設計：Iceberg (Data Lake) 保有完整事實資料，Doris 就算存資料，也應以查詢效率為目的，並可依保存年限刪除。

當分層責任逐漸清晰後，我開始投入資料整理段的設計與實作。這是我前期最卡的一段，版本依賴、程式驗測都花了很多時間，才完成第一版程式。做出通用可執行 Spark SQL 的排程，讓後續其他資料整理時可以專注在寫 MERGE SQL，直接部署掛載程式，只是，這一段還停留在 Data Lake 的資料整理，對於使用 Doris Job 抄寫到 Doris 需要 Admin 權限的問題，仍留在我心裡的待解決清單。

除此之外，在資料接收段 CDC 也遇到了實務上的議題：