工具-資料民主化

🎯 什麼情境該想到我

當「所有人都在等中央資料團隊／整合團隊」、拿一份資料要開單等好幾個月、
或資料明明存在卻沒人說得準它是什麼意思時。

⚙️ 怎麼用

1. 先把等待清單攤出來當證據。書中 Promotions 團隊的實況：整合團隊說要 6–9 個月、還在等資料倉儲修正錯誤、還在等一個新的資料庫實例——痛點列清楚了，才推得動架構改變。

2. 把資料的所有權推回最懂它的人。核心主張：

   「清理、匯入、分析、把正確資料發布給組織其他部門的責任，應該推進每一個業務與應用團隊，因為他們最清楚這些資料實際上是什麼意思。」

   中央團隊當了幾十年資料的保管人；現在要做的是解放它，讓任何想要的人隨時取用，不必開單。

3. 但安全性不能各團隊各自為政。平台團隊保留這幾件事的統一責任：資料安全、不該存的 PII 就不要存、靜態加密，以及評估資料外洩對公司的風險。這是刻意的集中，不是漏掉的。

4. 把資料轉換當程式碼管：轉換納入版本控制、建自動化測試，在資料入庫之前先確認它的形狀與大小是對的。這是防「資料意外」最有效的一招。

5. 先做最小切片，用託管服務降低營運風險。書中的取捨：從最關鍵的能力開始、沿用既有的 ETL 成果、採用雲端上成熟的託管資料平台服務、把最重的事件串流平台先延後。

6. 預先處理政治。原本的資料保管團隊會覺得被威脅，而且那不是無理取鬧——要在動手前就去談，別讓它變成事後的政治戰。

★ 核心主張：把「資料的所有權」推回最懂它的團隊

❌ 中央資料團隊模式
   各業務團隊 ──開單──▶ 中央資料團隊 ──▶ 資料倉儲
   ★ 問題：中央團隊「不懂」那些資料的業務含意
   ★ 結果：變成瓶頸（6–9 個月的等待清單），而且做出來的東西還常常不對

✅ 資料民主化 / data mesh
   各業務團隊「自己」負責自己資料的清理、發布、品質
   平台團隊提供「自助的」基礎設施與統一的治理

★ 關鍵洞察：瓶頸不是「資源不夠」，是「知識在錯的地方」。
加人給中央團隊不會解決問題——他們還是不知道那個欄位在業務上代表什麼。

★ 哪些該下放、哪些該集中（這條線是成敗關鍵）

★ 下放給業務團隊	★ 集中在平台團隊
資料的定義與語義	資料安全與存取控制
清理與轉換邏輯	★ PII 政策（不該存的就不要存）
品質保證與測試	★ 靜態加密與金鑰管理
對外發布（當成產品）	稽核與合規
SLA 與文件	★ 自助的工具與平台
	資料外洩的風險評估

★★ 「安全性不能各團隊各自為政」是刻意的集中，不是漏掉的。
民主化的是所有權與知識，不是治理與安全。
這兩件事被混為一談，就會變成「大家各自亂搞」。

★ 把資料當產品（data as a product）

這是 data mesh 最實用的一個概念：每個資料集要像對外 API 一樣被對待。

產品該有的	資料產品的版本
明確的擁有者	★ 有人負責、找得到人
文件	欄位定義、更新頻率、資料來源
SLA	★ 新鮮度、完整性、可用性的承諾
版本與相容性	★ schema 演進要相容（見 工具-資料編碼與演進）
品質保證	★ 自動化測試（見下）
可發現	資料目錄

★ 把資料轉換當程式碼管（最有效的一招）

□ ★ 轉換邏輯進版控（SQL / dbt model / Spark job）
□ ★ 有 code review
□ ★ 自動化測試：★ 在資料「入庫之前」先驗證形狀與大小
     - 列數在預期範圍內嗎？（突然變 0 或變 10 倍 = 上游出事了）
     - 主鍵唯一嗎？該非空的欄位有空值嗎？
     - 列舉值在預期集合內嗎？
     - ★ 和昨天比，分布有沒有異常跳動？
□ CI/CD 部署

★ 「入庫前驗證」是防止「資料意外」最有效的一招——
壞資料一旦進了倉儲，下游所有報表與模型都被污染，而且很難回溯清理。
這和 工具-讓LLM產出可驗證的產物 是同一條原則：在邊界上驗證，不要在事後補救。

★ 落地的順序（不要一次到位）

① ★ 把等待清單攤出來當證據 —— 沒有證據推不動組織改變
② 從「最關鍵的一兩個資料產品」開始，不要全面改造
③ ★ 沿用既有的 ETL 成果，不要重寫
④ 用雲端託管服務降低營運風險（★ 不要同時挑戰「新架構」和「自建平台」兩件事）
⑤ 把最重的部分（如事件串流平台）延後
⑥ ★ 預先處理政治

★ 政治面（技術解不了的部分）

★ 原本的中央資料團隊會覺得被威脅，而且那不是無理取鬧——他們的工作內容確實被改變了。

要在動手前就談，而且要給他們一個更好的位置：

• 從「代工者」變成 平台提供者（見 自助服務平台）
• 從「所有資料的保管人」變成 治理與標準的守護者
• 他們的專業（資料建模、效能、治理）仍然稀缺且有價值，只是用在不同的地方

★ 這是 工具-康威定律 的實例：架構改變必然伴隨組織改變，而組織改變是有人的成本的。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• ★★ 小組織不需要。十幾個人、一個資料庫 → 中央管理反而更有效率。
  民主化解決的是「中央團隊成為瓶頸」的問題——沒有這個瓶頸就不需要。
• ★ 「民主化」不等於「沒有治理」。安全、PII、加密、稽核必須集中（見上）。
  這一點做錯就會變成合規災難。
• ★ 平台必須是「自助」的。如果各團隊還是要開單請平台團隊幫忙，
  你只是換了一個瓶頸的名字（見 自助服務平台）。
• ★ 會出現重複與不一致。三個團隊各自定義「活躍使用者」→ 三個不同的數字。
  → 需要一層「共用的核心指標定義」（語義層 / metrics layer），這是要刻意維護的。
• 各團隊的資料能力不均。有的團隊沒人會寫 SQL → 平台要提供足夠低的門檻，否則民主化只是推卸責任。
• 成本會分散但不會消失。每個團隊都要花時間維護自己的資料產品——要在規劃時認列這個成本。

🔗 相關工具

• 自助服務平台 —— ★ 平台必須自助，否則只是新瓶頸
• 工具-康威定律 —— 架構改變伴隨組織改變
• 工具-資料加密與密鑰管理 —— 集中治理的部分
• 工具-資料編碼與演進 —— 資料產品的 schema 相容性
• 工具-限界上下文 —— 資料的所有權邊界
• 工具-讓LLM產出可驗證的產物 —— 「在邊界上驗證」的同一條原則
• PII、紅隊與公平性稽核 —— PII 政策
• 獨角獸專案