# 資料治理原理

::: tip 前言
**你有沒有遇過這種情況：報表上的數字和實際業務對不上，兩個系統裡同一個使用者的資訊不一樣，或者分析結果因為髒資料完全不可信？** 資料治理就是解決這些問題的系統性方法。在「資料驅動決策」的時代，資料品質直接決定了決策品質——垃圾進，垃圾出（Garbage In, Garbage Out）。
:::

**這篇文章會帶你學什麼？**

學完這章後，你將獲得：

- **資料品質維度**：理解完整性、準確性、一致性等六大品質維度
- **資料治理體系**：了解從組織、流程到技術的治理框架
- **資料血緣**：掌握資料從源頭到消費的全鏈路追蹤
- **元資料管理**：理解「描述資料的資料」的重要性
- **資料分層架構**：掌握 ODS → DWD → DWS → ADS 的資料倉儲分層模型
- **實戰能力**：知道如何在專案中落地資料治理

| 章節 | 內容 | 核心概念 |
|-----|------|---------|
| **第 1 章** | 資料品質維度 | 完整性、準確性、一致性、時效性 |
| **第 2 章** | 資料治理框架 | 組織、流程、技術、文化 |
| **第 3 章** | 資料血緣追蹤 | 影響分析、問題排查、合規稽核 |
| **第 4 章** | 元資料管理 | 技術元資料、業務元資料、操作元資料 |
| **第 5 章** | 資料分層架構 | ODS、DWD、DWS、ADS |
| **第 6 章** | 治理工具與實踐 | Great Expectations、dbt、DataHub |

---

## 0. 全景圖：需要資料治理的動機

資料治理不是一個技術問題，而是一個**管理問題**。它回答的核心問題是：**誰對資料負責？資料的標準是什麼？如何保證資料持續可信？**

想像一個公司有 100 個資料表，每個表由不同團隊維護，沒有統一的命名規範、沒有資料字典、沒有品質檢查。結果就是：同一個「月活使用者」指標，行銷部算出來 500 萬，產品部算出來 300 萬——因為定義不一樣。

::: tip 資料治理的四個支柱
1. **組織**：明確資料 Owner、資料管家（Data Steward）的角色和職責
2. **流程**：建立資料接入、變更、下線的標準流程
3. **技術**：部署資料品質監控、元資料管理、血緣追蹤等工具
4. **文化**：讓全公司認同「資料是資產」，而不是「資料是副產品」
:::

---

## 1. 資料品質的六個維度

資料品質不是一個模糊的概念，而是可以從六個具體維度來衡量的。每個維度都有明確的定義和檢測方法。

<DataQualityDemo />

| 維度 | 定義 | 檢測方法 | 常見問題 |
|------|------|---------|---------|
| 完整性 | 資料是否存在缺失 | 空值率檢查 | 必填欄位為空、關聯資料缺失 |
| 準確性 | 資料是否正確 | 規則校驗、抽樣核對 | 金額為負、日期不合法 |
| 一致性 | 多源資料是否一致 | 跨系統比對 | CRM 和訂單系統使用者名稱不同 |
| 時效性 | 資料是否及時更新 | 更新時間檢查 | 庫存資料滯後、價格未同步 |
| 唯一性 | 是否存在重複記錄 | 去重檢查 | 同一使用者註冊兩次 |
| 有效性 | 是否符合格式規則 | 正則/範圍校驗 | 信箱格式錯誤、年齡為負數 |

::: tip 資料品質的 1-10-100 法則
- **1 元**：在資料入口做校驗，預防髒資料進入
- **10 元**：在資料倉儲中清洗已有的髒資料
- **100 元**：因為髒資料導致錯誤決策的損失

越早發現和修復資料品質問題，成本越低。
:::

---

## 2. 資料治理框架：全生命週期管理

資料治理不是一次性專案，而是貫穿資料全生命週期的持續過程。從資料的產生到銷毀，每個階段都需要明確的規範和負責人。

<DataGovernanceFrameworkDemo />

| 階段 | 核心產出 | 關鍵角色 |
|------|---------|---------|
| 定義標準 | 資料字典、命名規範、分類分級標準 | 資料架構師 |
| 採集接入 | 接入規範、校驗規則、血緣記錄 | 資料工程師 |
| 儲存管理 | 分層模型、權限矩陣、生命週期策略 | DBA / 平台工程師 |
| 使用消費 | 資料目錄、脫敏規則、品質報告 | 資料分析師 / 業務方 |
| 歸檔銷毀 | 歸檔策略、刪除記錄、稽核日誌 | 安全合規團隊 |

## 2. 資料治理框架

資料治理不是買一個工具就能解決的，它需要一套完整的框架來支撐。業界最常用的參考框架是 DAMA-DMBOK（資料管理知識體系）。

| 治理領域 | 核心內容 | 關鍵產出 |
|---------|---------|---------|
| 資料架構 | 定義資料模型、資料流、儲存策略 | 資料架構圖、ER 圖 |
| 資料標準 | 統一命名規範、編碼規範、指標定義 | 資料字典、指標庫 |
| 資料品質 | 建立品質規則、監控告警、修復流程 | 品質報告、SLA 儀表板 |
| 資料安全 | 分級分類、存取控制、脫敏加密 | 安全策略、稽核日誌 |
| 主資料管理 | 統一客戶、商品等核心實體的「黃金記錄」 | 主資料中心 |
| 資料生命週期 | 管理資料從建立到歸檔到銷毀的全過程 | 保留策略、歸檔規則 |

::: tip 資料治理的成熟度模型
- **Level 1 - 初始級**：沒有統一標準，各團隊各自為政
- **Level 2 - 可重複級**：有基本的規範文件，但執行不一致
- **Level 3 - 已定義級**：有統一的治理流程和工具，大部分團隊遵守
- **Level 4 - 已管理級**：有量化的品質指標和自動化監控
- **Level 5 - 最佳化級**：持續改進，資料治理融入日常開發流程
:::

---

## 3. 資料血緣：從哪來，到哪去

資料血緣（Data Lineage）記錄了資料從源頭到最終消費的完整流轉路徑。它就像資料的「族譜」，讓你能追溯任何一個資料的來龍去脈。

<DataLineageDemo />

資料血緣在實際工作中有三個核心應用場景：

| 場景 | 問題 | 血緣如何幫助 |
|------|------|------------|
| 影響分析 | 要修改使用者表的欄位，會影響哪些下游報表？ | 沿血緣向下追蹤所有依賴 |
| 根因定位 | 今天的 GMV 報表資料異常，問題出在哪一步？ | 沿血緣向上回溯每個環節 |
| 合規稽核 | 使用者的手機號經過了哪些系統？是否都做了脫敏？ | 追蹤敏感欄位的全鏈路流轉 |

::: tip 血緣採集的兩種方式
- **主動採集**：解析 SQL 語句、ETL 設定，自動提取表級/欄位級血緣關係
- **被動採集**：透過 Hook 攔截查詢引擎（如 Hive、Spark）的執行計畫，即時記錄血緣

主流工具如 Apache Atlas、DataHub、OpenLineage 都支援自動化血緣採集。
:::

---

## 4. 元資料管理：「描述資料的資料」

元資料（Metadata）是關於資料的資料。如果資料是一本書的內容，元資料就是書的目錄、作者、出版日期、ISBN 號。沒有元資料，資料就是一堆無法理解的數字和字串。

| 元資料類型 | 描述 | 示例 |
|-----------|------|------|
| 技術元資料 | 資料的物理儲存資訊 | 表名、欄位類型、分區方式、儲存位置 |
| 業務元資料 | 資料的業務含義 | 欄位中文名、業務定義、計算口徑 |
| 操作元資料 | 資料的執行狀態 | ETL 執行時間、資料量、更新頻率 |

::: tip 資料字典的重要性
資料字典是元資料管理最基礎的產出。一個好的資料字典應該包含：
- **欄位名**：英文名和中文名
- **資料類型**：VARCHAR(50)、INT、DATETIME 等
- **業務定義**：這個欄位代表什麼？怎麼計算的？
- **取值範圍**：有效值是什麼？空值是否允許？
- **負責人**：誰維護這個欄位？有問題找誰？

沒有資料字典的團隊，新人入職後理解一張表的含義可能需要一週；有資料字典的團隊，10 分鐘就夠了。
:::

---

## 5. 資料分層架構：ODS → DWD → DWS → ADS

資料倉儲不是把所有資料堆在一起，而是按照**加工程度**分層儲存。每一層有明確的職責，上層依賴下層，逐步從原始資料提煉為業務可用的資料。

| 層級 | 全稱 | 職責 | 資料特點 |
|------|------|------|---------|
| ODS | 操作資料層 | 原樣同步業務資料庫 | 最原始，未經處理 |
| DWD | 明細資料層 | 清洗、標準化、去重 | 乾淨的明細記錄 |
| DWS | 彙總資料層 | 按主題聚合（日/週/月） | 預計算的聚合指標 |
| ADS | 應用資料層 | 面向具體報表/介面 | 直接可用的結果資料 |

::: tip 為什麼要分層？
- **複用**：DWD 層清洗一次，所有上層共享，避免重複清洗
- **解耦**：業務庫表結構變更只影響 ODS 層，不會波及報表
- **效能**：DWS 層預聚合，報表查詢直接讀取，不需要即時計算
- **可追溯**：每一層都保留，出問題時可以逐層排查
:::

---

## 6. 治理工具與實踐

| 工具 | 定位 | 核心能力 | 適用場景 |
|------|------|---------|---------|
| Great Expectations | 資料品質 | 宣告式資料校驗規則，自動產生品質報告 | Python 資料管道 |
| dbt | 資料轉換 | SQL 模型化開發，內建測試和文件生成 | 資料倉儲建模 |
| DataHub | 元資料管理 | 資料目錄、血緣追蹤、資料發現 | 企業級資料治理 |
| Apache Atlas | 元資料管理 | Hadoop 生態血緣追蹤 | 大資料平台 |
| OpenMetadata | 元資料管理 | 開源資料目錄，支援多種資料來源 | 中小團隊 |
| Amundsen | 資料發現 | 搜尋式資料發現平台 | 資料民主化 |

::: tip 從零開始的治理路徑
如果你的團隊還沒有資料治理，建議按這個順序推進：
1. **先建資料字典**：把現有的表和欄位含義記錄下來（哪怕用 Excel）
2. **加品質檢查**：在關鍵資料管道中加入基本的空值、範圍校驗
3. **統一指標定義**：把「日活」「月活」「GMV」等核心指標的計算口徑統一
4. **引入工具**：當手動管理成本太高時，引入 DataHub 或 dbt 等工具
5. **建立流程**：資料變更需要審查，品質問題有 SLA 和告警
:::

---

## 總結

資料治理是讓資料從「能用」變成「好用、可信、可追溯」的系統性工程。它不是一次性專案，而是持續營運的過程。

回顧本章的關鍵要點：

1. **六大品質維度**：完整性、準確性、一致性、時效性、唯一性、有效性
2. **治理四支柱**：組織、流程、技術、文化缺一不可
3. **資料血緣**：追蹤資料的來龍去脈，支撐影響分析和問題排查
4. **元資料管理**：資料字典是最基礎也最重要的治理產出
5. **分層架構**：ODS → DWD → DWS → ADS，逐層提煉資料價值
6. **漸進式落地**：從資料字典開始，逐步引入工具和流程

## 延伸閱讀

- [DAMA-DMBOK](https://www.dama.org/cpages/body-of-knowledge) - 資料管理知識體系，資料治理的「聖經」
- [DataHub](https://datahubproject.io/) - LinkedIn 開源的元資料管理平台
- [Great Expectations](https://greatexpectations.io/) - Python 資料品質框架
- [dbt](https://www.getdbt.com/) - 資料轉換工具，內建測試和文件
- [Apache Atlas](https://atlas.apache.org/) - Hadoop 生態的元資料治理框架
- [The Data Warehouse Toolkit](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/) - Kimball 資料倉儲建模經典