在企業建構數據基礎建設時，常因起步時追求完美架構而導致後期維護困難、越建越亂。本文探討如何借鑑 OLX Group 資料工程師 Alexey Grigorev 的務實經驗，以最小可行性產品（MVP）出發，逐步優化資料平台，解決過度工程化帶來的維護痛點。

本文重點快速看

  • 追求完美架構往往是資料平台走向混亂的開端。
  • 借鑑實作經驗，應以務實順序取代盲目引進高深技術。
  • 初期專注打通端到端最簡流程，後期再逐步引入複雜工具。

為什麼資料平台在初期容易越建越亂？

因為團隊常在需求未明時引入過多複雜工具，試圖一步到位，反而造成維護災難。

許多資料工程師在專案啟動時，急於使用最新、最複雜的微服務或分佈式架構。然而，在缺乏實際數據流和業務場景驗證下，這些超前部署的架構很快就會變成難以收拾的技術債。

借鑑 Alexey Grigorev 的務實建構順序

核心原則是先求有再求好，以最簡單的腳本打通流程，再依痛點逐步升級工具。

Alexey Grigorev 的經驗指出，與其一開始就搭建 K8s 或 Airflow，不如先用簡單的 Python 腳本與 SQL 資料庫完成第一版。當數據量與協作人數增加時，才引入對應的調度與監控。

完美主義架構與務實遞進架構的權衡比較

透過對比，可看出務實遞進策略在交付速度與資源消耗上具有明顯優勢。

比較維度 完美主義架構 務實遞進架構
核心焦點 架構的先進性與理論完美度 快速打通端到端數據流與業務價值
工具選擇 一開始導入複雜調度套件 優先使用簡單腳本與資料庫
技術債風險 極高，需求變更易報廢 較低，架構隨業務演進

常見問題 FAQ

Q1：什麼時候該從簡單腳本升級到專業排程工具？

當工作流依賴關係變得複雜，手動維護排程頻繁出錯時。初期一兩個任務用簡單排程即可。

Q2：務實開發會不會導致後期重構難度變大？

不會。只要初期做好模組化設計與介面定義，後期替換底層引擎時反而比修改複雜架構更容易。

Q3：如何說服主管接受不夠完美的第一版平台？

用數據交付速度來說話。快速展現能運作的端到端報表，比花三個月畫一張無法落地的架構圖更有說服力。

Q4：務實順序中，最先建立的關鍵指標是什麼？

數據的準確性與基本交付時效。先確保資料能準確落地，再來考慮高可用性等進階指標。

回顧這段學習歷程，資料平台建設是一場馬拉松。Alexey Grigorev 的務實哲學提醒我們，優秀的資料工程師不只是技術追求者，更是價值的交付者。在動手設計前，先問自己：這個設計是為了解決當下痛點，還是為了滿足完美的幻想？唯有務實，平台才能走得長遠。

延伸參考資料