Data Governance (三) - 專案內的元資料治理

留言

張貼留言

這個網誌中的熱門文章

Data Governance (二) - 元資料治理

  元資料到底是什麼? 其實元資料就是「資料的說明書」。 我自己這幾年在做元資料治理，最常碰到的三個基本問題： 資料定義 （這個欄位到底代表什麼？是什麼單位？怎麼算的？） 資料在哪 （Linkage，想找這個東西時，要去哪裡查？） 誰負責 （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. 元資料分層管理：業務元數據 & 技術元數據 最重要的一點是——元資料要「分層管理」！ 我都會建議從「業務元數據」跟「技術元數據」兩條路線同步...
閱讀完整內容

Data Governance (一) - 從痛點開始

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