【資料治理實戰回憶錄】02. 拆解元數據 (上)：讓資料「說人話」的三大核心要素

data governance data platform

as93717913g 2025-12-31 00:03:47 ‧ 89 瀏覽

分享至

如同前文所述，我堅信元數據 (Metadata) 是資料治理的基石。如果說資料中台是強大的引擎，那元數據就是導航系統，它讓我們在茫茫數據海中知道：我們到底有什麼？它們在哪裡？

什麼是元數據？從一封 Email 說起
元數據究竟是什麼？用我們每天都在用的 Email 來打個比方：
資料 (Data)：就是郵件的「內文」本身，那是實際的訊息內容。
元數據 (Metadata)：就是郵件的「標頭資訊 (Header)」。它告訴你這封信是誰寄的 (Sender)、寄給誰 (Receiver)、什麼時候寄出的 (Timestamp)、以及主旨是什麼 (Subject)。
如果沒有這些標頭資訊，你收到的就只是一段沒頭沒尾的文字，要花很多時間才會知道上下文。同樣的，在企業中，如果沒有元數據，我們就需要額外花時間去詢問，去猜資料本身的含意。
元數據的核心任務，就是幫我們回答關於資料的 3W 1H：

What：我的資料代表什麼業務含義？
Where：我的資料存放在哪個系統、哪張表？
Who：誰負責管理這份資料？（Owner）
How：我該如何申請與存取這份資料？（Access）

為了實現這 3W 1H，我們必須深入了解元數據架構中的七大關鍵實體 (Entities)。

業務術語 (Business Glossary Term)
技術資料目錄 (Data Catalog)
業務與技術端連結 (Linkage)
技術目錄血緣 (Lineage)
資料產品 (Data Product)
領域 (Domain)
權責 (Ownership)

本篇將優先介紹最基礎、也最重要的前三項

1. 業務術語 (Business Glossary Term) —— 讓資料說「人話」

這是元數據的「靈魂」。業務術語是用來記錄在企業的商業流程中，我們是如何稱呼並定義這些資料的。它的目的是解決語言不通與定義歧義的問題。
舉例來說，IT 的資料庫裡有一張表叫 employee_info，大家口語都叫它「員工表」。但魔鬼藏在細節裡：
定義範圍：「員工」包含實習生嗎？包含外包廠商嗎？包含昨天剛離職的人嗎？
欄位邏輯：Employee Name 是指中文名還是英文名？Join Date 是指報到日還是試用期滿日？
如果沒有明確定義，報表做出來就會這錯那錯。因此，一個標準的業務術語定義應該包含業務定義、業務規則以及變更流程 。
以下是一個標準化的範例：

術語名稱：Employee (員工)
    - 業務定義：指公司內部簽署正式勞動契約的人員。包含正職、試用期員工；不包含實習生、約聘人員及委外廠商。
    - 生命週期管理 (Lifecycle)：
       - 新增：由人資發出聘書並收到回函後，經部門主管簽核生效。
       - 變更：由員工填寫申請單，經部門主管核可後生效。
       - 刪除 (停用)：員工離職程序完成後，由系統標記為「無效」(Inactive)，資料保留但不列入在職計算。

術語名稱：Employee Name (員工姓名)
    - 業務定義：員工身分證上的中文全名。
    - 業務規則：
        - 長度限制：最長 10 個中文字。
        - 特殊限制：不得包含數字或特殊符號。

術語名稱：Employee Code (工號)
    - 業務定義：員工在組織內的唯一識別碼。
    - 編碼原則：共 11 碼。第一碼代表類型（1=正職, 2=約聘...）

2. 資料目錄 (Data Catalog) —— 技術端的資料結構

如果說業務術語是「字典」，那麼資料目錄就是「倉庫清單」。它描述的是 IT 技術端的資料結構 (Schema)。
現代的元數據管理平台（如我們公司使用的開源工具 DataHub），通常具備強大的自動攝取 (Ingestion) 功能。它能直接連線到各種資料源（SQL Server, Oracle, Hive, S3 等），自動把技術資訊抓取回來，形成統一的查詢介面。
alt text
在資料目錄中，我們會看到這些資訊：
物理位置：hostname.dbname.schema.table.column
資料格式：Varchar(32), Int, Date
鍵值關係：Primary Key (PK), Foreign Key (FK)
這讓使用者不用登入資料庫，就能知道：「哦！原來 employee_info 這張表是在 HR_DB 這個資料庫裡。」

3. 業務與技術連結 (Linkage)

這是最關鍵的一步。單有「業務術語」（只有定義沒有資料）或是單有「資料目錄」（只有資料沒有定義）都是不夠的。Linkage 就是將兩者綁定的過程，將「概念」映射到「實體」。

[業務術語: Employee] --Linkage--> (技術表: hrsysdb.dbo.employee_master)
[業務術語: Employee Name] --Linkage--> (欄位: hrsysdb.dbo.employee_master.name)
[業務術語: Employee Code] --Linkage--> (欄位: hrsysdb.dbo.employee_master.Code)

有了這層連結，我們才能實現真正的治理價值：當業務人員想找「員工工號」時，他在平台上搜尋 Employee Code，系統就能直接告訴他：「請去 Query hrsysdb.dbo.employee_master 這張表的 Code 欄位。」

實戰小故事：別犯我們當年的錯

在我們剛開始做元數據治理時，犯了一個嚴重的誤區：我們只做到了「表格 (Table) 等級」的定義，卻忽略了「欄位 (Column) 等級」。
當時我們開心地把 Employee 連結到了 employee_master 表，覺得大功告成。結果使用者一進去，發現裡面有 50 個欄位，c1, c2, name_1, name_2......他們完全傻眼，根本不知道哪個才是他們要的「中文姓名」。
這就像給你一個 Excel 檔，檔名寫得很清楚叫「年度財報」，但打開來裡面完全沒有標頭 (Header)，只有一堆數字。這種檔案給誰都沒用。
這個教訓告訴我們：魔鬼都在細節裡。元數據治理必須下鑽到欄位級別 Column Level，否則就只是做半套的表面工夫。

以上是元數據管理的第一部分。掌握了這三個基礎要素，我們就算搭建起了資料的骨架。在下一篇，我們將探討更進階的概念：如何透過血緣 (Lineage) 追蹤資料的來龍去脈，以及如何定義資料產品 (Data Product) 與權責 (Ownership)。