資料治理與資料品質

前言

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

資料治理的四個支柱

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

---

1. 資料品質的六個維度

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

Data Quality Checker

Click a dimension to inspect example data quality issues

📋

Completeness

🎯

Accuracy

🔗

Consistency

⏰

Timeliness

🔑

Uniqueness

✅

Validity

📋CompletenessWhether required values are missing

Problem data

User ID	Name	Email	Phone
001	Alice	alice@mail.com	138xxxx1234
002	Bob
003		carol@mail.com	139xxxx5678

After governance

User ID	Name	Email	Phone
001	Alice	alice@mail.com	138xxxx1234
002	Bob	bob@mail.com	137xxxx9012
003	Carol	carol@mail.com	139xxxx5678

Quality score

72%

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

資料品質的 1-10-100 法則

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

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

---

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

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

Data Governance Framework

Click each stage to inspect the details

1

Define standards

→

2

Collect and ingest

→

3

Manage storage

→

4

Use and consume

→

5

Archive and destroy

Define standards

Create data standards, naming rules, and data dictionaries

📖

Data dictionary

Define meaning, type, and allowed values for each field

📏

Naming rules

Unify field naming conventions such as snake_case, camelCase, and prefixes

🏷️

Classification

Classify data by sensitivity: public, internal, confidential, restricted

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

2. 資料治理框架

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

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

資料治理的成熟度模型

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

---

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

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

Data Lineage Tracing

Click any node to inspect upstream and downstream dependencies

Data sources

🗄️

MySQL user table

🗄️

MySQL order table

📝

Click log

ODS layer

📥

ODS users

📥

ODS orders

📥

ODS clicks

DWD layer

🔧

DWD user detail

🔧

DWD order detail

🔧

DWD click detail

DWS layer

📊

DWS user profile

📊

DWS GMV summary

ADS layer

📈

ADS business report

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

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

血緣採集的兩種方式

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

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

---

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

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

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

資料字典的重要性

資料字典是元資料管理最基礎的產出。一個好的資料字典應該包含：

• 欄位名：英文名和中文名
• 資料類型：VARCHAR(50)、INT、DATETIME 等
• 業務定義：這個欄位代表什麼？怎麼計算的？
• 取值範圍：有效值是什麼？空值是否允許？
• 負責人：誰維護這個欄位？有問題找誰？

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

---

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

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

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

為什麼要分層？

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

---

6. 治理工具與實踐

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

從零開始的治理路徑

如果你的團隊還沒有資料治理，建議按這個順序推進：

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

---

總結

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

回顧本章的關鍵要點：

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

延伸閱讀

• DAMA-DMBOK - 資料管理知識體系，資料治理的「聖經」
• DataHub - LinkedIn 開源的元資料管理平台
• Great Expectations - Python 資料品質框架
• dbt - 資料轉換工具，內建測試和文件
• Apache Atlas - Hadoop 生態的元資料治理框架
• The Data Warehouse Toolkit - Kimball 資料倉儲建模經典