Data Platform 筆記#02：從可行到可承接

在初版架構逐漸成形後，時間也差不多過了一年。

架構可以跑、資料可以流動，但我仍然不確定它能不能真正落地。這條路必須要團隊可以承接、可以擴展，數據才有機會真正發揮價值。

很慶幸的是，我的主管願意投資時間，讓這個方向能繼續推進。也正是在那段時間，我的思考開始出現轉變...

前一篇的重點，是讓流程從「能跑」走向「能持續」。
而接下來我開始思考：如果這件事要由團隊一起做下去，現在的做法夠不夠讓人接手？

轉變的核心

回頭看那一年，大多數時間其實是在解問題。
但接下來，我該解的是另一個問題：怎麼讓別人不用再解一次同樣的問題？

於是投入了約莫三個月、壓力值很高的一段時間，開始把原本依賴個人經驗與記憶的做法，收斂成可以被團隊理解與複製的形式。

這個收斂，後來具體落在幾個方向上：

• 把 Data Center 的部署方式收斂成一致做法，降低環境轉換成本
• 把資料整理作業轉變為配置驅動，讓流程與部署有規則可循
• 整理 DDL 轉換規則與範本，讓團隊能共用同一套方法
• 把知識系統化交付出去

這些事情的唯一核心是 讓方法大於個人。

從個人經驗，到規則明確

第一個改變：把經驗顯性化。

例如 Iceberg 與 Doris 之間的 DDL 轉換，原本每張表都需要人工核對、手動調整。雖然做得出來，但效率低、風險高，也難以讓團隊承接。

為此，我準備了一個小專案，把轉換規則整理出來，並結合 AI 工具設計範本 prompt，讓團隊夥伴可以直接使用，夥伴們的角色，也從「執行者」轉為「審查與確認」。

經過幾次實際資料的驗證後，可以明顯感受到 DDL 轉換所花費的時間與心力下降。這是一個小改變，但它讓「經驗」開始變成「方法」。

從臨場調整，到配置驅動

第二個調整：讓流程變成可重複使用。

原本開發通用的資料整理排程，只是為了降低維運負擔。但當資料量逐漸成長後，我發現仍然會有不少人工調整與錯漏的可能。再加上當時依賴的社群版本早已停止維護，長遠來看並不穩定。

因此進行了一次重構，將原本的通用排程與部署 SOP，進化成配置驅動的形式。從程式引用到部署方式，定義出一套一致的配置規則，只要依循規則設定，就能正常部署與執行。 (順帶地把使用 Doris Job 的議題也一併解決了，不再需要 Doris Admin 權限)

這個過程讓我更清楚地體會到：規則讓事情可理解，流程讓事情可複製。
當兩者結合，事情才有可能被穩定地延續。

從個人理解，到知識交付

第三個改變：把知識交付出去。
我整理了 KM 文件，也在 AI 的輔助下補齊缺漏，並安排教育訓練，讓團隊理解：

• 資料怎麼接
• 資料怎麼整理
• Mart 怎麼建立

當夥伴開始能承接資料接收與整理工作時，我才真正感受到這件事開始有團隊支持。不再只是某幾個人熟悉的技術，而是團隊可以共同推進的方向。

回顧這段改變

最大的改變是重心的轉移：
從「我能不能做出來」，變成「團隊能不能一起持續做下去」。

技術本身重要，但它只是基礎。
真正讓專案走得遠的，是把方法沉澱下來，讓團隊承接。

至此，一版可以落地、也可以被承接的Data Platform，才算真正成形。
後面當然還有優化空間，但至少，我們可以開始往前走，不再停在「架構實作」。