Data Governance (二) - 元資料治理

 

元資料到底是什麼?

其實元資料就是「資料的說明書」。
我自己這幾年在做元資料治理，最常碰到的三個基本問題：

  1. 資料定義（這個欄位到底代表什麼？是什麼單位？怎麼算的？）

  2. 資料在哪（Linkage，想找這個東西時，要去哪裡查？）

  3. 誰負責（Ownership，出問題要找誰，這欄位的老大是誰？）

但這邊有個重點，元資料不是只有一種，有分「業務元數據」跟「技術元數據」。

  • 業務元數據 比較像是讓業務、需求單位看的，舉例：這份資料是做什麼的、有什麼商業意義，屬於哪個領域、哪個業務對象，誰是Business Data Steward，誰是Data Owner。

  • 技術元數據 則是IT同仁的世界，像是：這筆資料存在哪個DB？哪張Table？哪個Column？IT Admin又是誰？這些才是「真的可以查得到、連得上的」底層資料資訊。

兩邊資料對得上，才不會業務說A、IT找不到A，永遠雞同鴨講。

為什麼元資料這麼重要？

說真的，資料治理大部分的進階玩法，都要靠前面這些東西站穩腳步。
你有沒有遇過這種狀況——想要盤點GDPR，結果根本沒人知道公司到底有哪些資料？或者想要強化某些資料品質、加速查詢效率，但資料定義模糊，越做越亂？

只要你有把元資料搞清楚，未來要加什麼敏感性標註、資料分級、資料品質註記、甚至資料分類，只要往那個表格加一欄，大家就會一目了然！
我自己碰過，像主資料治理，如果那時候早一點把元資料盤點到位，很多奇怪的遺留問題都不用再三討論。

元資料治理實務怎麼開始？

1. 準備元資料管理平台（推薦Open Source）

老實說現在開源選擇超多，大家只要挑一個有社群、功能夠用的就可以上手：

  • DataHub（我自己最推這個，血緣、API全都搞定，畫面也乾淨）

  • Amundsen（偏向資料探索、查詢）

  • Apache Atlas（如果你有大數據或Hive/ETL，這個很強）

  • CKAN（如果你有開放資料需求）

建議一開始可以小範圍PoC一下，不要一開始就全公司大規模導入，先找到自己流程最容易上手的切入點。

2. 元資料分層管理：業務元數據 & 技術元數據

最重要的一點是——元資料要「分層管理」！
我都會建議從「業務元數據」跟「技術元數據」兩條路線同步收斂，這樣最不容易漏掉東西。

- 業務元數據重點欄位（以主資料治理為例）：

  • 領域：像是業務、財務、生產…

  • 業務對象：比如客戶、供應商、產品…

  • 資料標準（L4）：例如「客戶主檔」

  • 屬性（L5）：例如「客戶ID」、「客戶名稱」

  • Business Data Steward：管業務邏輯的人

  • Data Owner：這份資料的真正負責人（通常業務單位主管）

  • IT Product Owner：系統負責人（IT窗口）

  • IT Admin：系統管理員

- 技術元數據重點欄位（專屬IT的）：

  • DB Name

  • Table Name

  • Column Name（只有屬性L5會有，L4通常不會有對應欄位）

3. 元資料治理範例Template（以客戶主檔為例）

下面這個Template就是我實際操作時，整理給各部門/同仁參考用的範本，一張表就能搞定所有資訊：

領域業務對象資料標準（L4）屬性（L5）定義/說明Business Data StewardData OwnerIT Product OwnerIT Admin敏感性GDPRDB NameTable NameColumn Name
業務客戶客戶主檔客戶ID客戶唯一識別碼王小明張主管陳工程師李管理員是是CRM_DBCUSTOMERCUSTOMER_ID
業務客戶客戶主檔客戶名稱客戶正式名稱王小明張主管陳工程師李管理員是否CRM_DBCUSTOMERCUSTOMER_NAME
業務客戶客戶主檔客戶主檔的業務說明王小明張主管陳工程師李管理員CRM_DBCUSTOMER

說明：如果是L4的「資料標準」，就不會有Column Name，只有到屬性（L5）才會對應到DB、Table、Column。

其他延伸欄位

這個表格很彈性，公司未來如果有新的盤點需求（像是是否為主資料、敏感等級、關聯表、存取頻率、是否需同步到雲…），都可以直接再加新欄位。例如：

  • 是否為主資料（是/否）

  • 資料品質負責人

  • 存取等級

  • …等

有什麼需求就往這張表格加，讓資料治理與時俱進，越來越好用。

總結

總之，元資料治理聽起來很玄，其實就是幫公司把「誰、在哪、負責什麼」搞清楚。有了這些底子，不管未來要玩資料分類、敏感資料控管、查血緣、做合規，都能快速起步，少繞彎路。
如果你現在還沒整理元資料，真的建議趕快啟動這一步，未來一定會感謝現在努力的自己！

留言

張貼留言

這個網誌中的熱門文章

Data Governance (一) - 從痛點開始

資料治理的範圍真的很大，從解決某個資料定義上的問題、撰寫定義、標準化、到Dashboard指標的管理，都在資料治理的輻射範圍內。 這時候就會有人問：不管是解決標準化的問題，還是Dashboard指標不準確，不都是一般專案可以處理的事情嗎？ 沒錯，一般專案確實能搞定這些事情，但資料治理注重的重點是在「個案之上」： 我要怎麼樣可以 快速 解決這個問題？ 我要怎麼樣可以 避免 這種問題再次發生？ 所以可以理解，資料治理就是將處理資料問題的手法，透過固化的流程、方法、組織、角色，把企業中常見的資料問題，系統性地加以解決，並從源頭預防問題再次出現。 這也是我第一個想跟大家分享的重點： 不要為了治理而治理 。資料治理的核心，還是在於「有事要解決」。只要能把這套解決框架固化下來，恭喜你，你已經在進行資料治理了！ 這邊也舉幾個常見痛點和對應解法，讓大家感受一下： 1. 有了資料倉儲，但資料本身的定義不清，無法讓業務人員自助查詢（Self Service） 透過資料中台規章，規範所有要進入資料中台的資料／產出的報表相關資料，都必須進行元資料治理，將定義與資料表格綁定。 這樣可以 讓業務人員清楚理解資料的意義與範疇，大幅提升自助查詢能力，降低對IT部門的依賴，同時也確保資料在各個環節被正確理解與應用 。 2. 重要資料每次更新都需專案內部進行上下游串接分析，導致進度緩慢，影響範圍不易盤點 透過制定系統開發規範，要求對外接口開放時必須明確定義資料標準，並於下游系統建立串接紀錄。 再搭配流程中綁定資料血緣（Lineage）維護規範， 可實現即時盤點上下游影響範圍，讓變更風險可視化，提升變更效率並降低專案溝通成本 。 3. 公司內大家常說的指標計算結果都不同，造成成果比較無法對齊 透過資料中台的導入，將計算公式於中台ETL層統一運算，由下游系統引用；同時要求所有報表專案在BA過程中確認指標定義，並與報表資料建立Linkage綁定， 可確保組織內所有指標「定義一致」、「公式一致」、「來源一致」，避免數字打架，也讓指標管理與溝通成本大幅下降 。
閱讀完整內容