資料中心筆記#01：初版技術架構成形
在上篇的 POC 之後，我們整理了一份內部報告，將問題拆成資料蒐集、基礎資料定義、資料量與查詢效能、權限治理、技術架構等幾個面向思考。
這份整理的目的，是先建立邊界，讓我們從發散與模糊，逐步走向具體且聚焦。
在這個基礎上，我開始把關注重點先轉向資料流：
如何讓資料自動、穩定、乾淨地進到分析效能較好的資料庫？
解題思考階段
這個階段，我主要在思考幾個問題：
- 不同來源的資料，能不能用相對一致的方法接進來？
- 雖然資料源不同，接收方式很難完全一致，但是否有機會收斂？初期是否可以先用一種主要方式處理（80/20 法則）？
- 資料會持續累積，是否有合適的儲存與管理方案？
- 資料進來後，分層應該怎麼定義？
前人的做法大多是將資料分成可追溯的原始資料（Stage）、清洗整理後的乾淨資料（Data）、整合不同維度需求的資料（Mart）。
延續這個方向大致不會錯，但在技術解決方案持續演進下，這些分層該定義在哪裡才更合適，仍需要驗證。
另外，查詢分析時是否有合適的查詢引擎，也是一個關鍵問題。
以可預見的資料量來看，依過去經驗，一般 RDB 在分析場景中能提供的效能提升有限。
整個過程投入了大量時間在不同工具間嘗試，但核心不走偏，仍是找出「合適、可掌握」的組合。
當下其實很難直接定義什麼是「合適」，因此我採取的是持續查找資料、反覆提問討論、參考他人的實務經驗，逐一建置並測試其可用性 (除了通常關注的 License，還包含了建置的難易、操作門檻、擴充彈性)，同時評估自己對工具的掌握程度，以及未來維運能量是否能支應。
初版架構的輪廓
當時建構初版架構的核心目標，是找出一套能將「資料接收、資料分層、分析查詢」串起來的解決方案。
對應的資料流如下：
Source (PostgreSQL) -> CDC -> Iceberg (Stage / Data) -> Doris
在這個輪廓中，各層的職責是：
CDC：持續接收來源資料的變更事件Stage：保存原始資料，確保可追溯Data：整理與轉換後的可用資料層Doris：面向分析查詢與報表輸出的服務層
當時選擇的主要元件如下，也一併記錄背景理解與用途：
Debezium
背景：常見的 CDC（Change Data Capture）工具，可以從資料庫變更日誌抓資料。
用途：讓資料跟著來源變更流動。
Kafka
背景：事件串流平台，適合承接持續進來的資料變更事件。
用途：作為資料流中間層，解耦來源系統與下游處理。
Iceberg
背景：資料湖表格式，支援大型資料管理與演進。
用途：分成 Stage/Data 兩層，讓原始資料與整理後資料分開管理。
Spark
背景：分散式資料處理引擎。
用途：負責將 Stage 的資料整理到 Data 層，執行轉換邏輯。
Doris
背景：負責分析查詢的 OLAP 引擎。
用途：承接整理後資料，提供查詢與報表分析能力。
部署上，除了 Doris 遵循工作環境規則建置在 VM，其餘元件與作業多基於 K8s 建置。
剛開始接觸 K8s 時，因不熟悉而遇到不少困難；但在持續 try and error 的實踐後，我也逐步建立理解，為後續部署與運行定義一致的環境與方法，打下了不錯的基礎。
POC 帶來了什麼
初版技術架構 POC 的價值，在於資料接收可以沿著設計的架構一路串接。
這對於透過技術路徑逐步落地資料中心，帶來了不少信心。
同時，在實際資料應用的過程裡，也幫助我們看見需要調整與修正的地方。
在架構準備擴大應用前，我們也盡可能先辨識可預見的維運成本，並提前思考如何降低。
