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

在上篇的 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 也遇到了實務上的議題：

• 資料庫備份後會刪除日誌，來不及接收的變更紀錄被刪除，出現接收異常。
• 資料異動量大時，接收端來不及消化或發生異常未接收，可能讓資料庫主機硬碟爆滿，影響其他服務。
• 隨著接收範圍增加，需要啟用 CDC 與監控的主機變多，維運負擔會快速上升。

這些問題彼此關聯，也讓我們重新檢視 CDC 的邊界，啟用 CDC 的資料庫不應該再承載其他服務。因此，資料改成由地區專作 CDC 的資料庫進來，讓 Data Center 限縮面對的來源，也避免各地區來源系統跨區抄寫資料。在當時的條件下，這是風險與成本都相對可控的方案。

驗證初版架構帶來了什麼

初版技術架構 POC 的價值，在於資料接收可以沿著設計的架構一路串接。
這對於透過技術路徑逐步落地資料中心，帶來了不少信心。

同時，在實際資料應用的過程裡，也幫助我們看見需要調整與修正的地方。
在架構準備擴大應用前，我們也盡可能先辨識可預見的維運成本，並提前思考如何降低。

架構逐漸清晰之後，我也開始意識到，真正的挑戰或許不只是技術本身，而是這條路能不能被團隊長期承接。