爲何要在大數據中心實施元數據管理

在數據管理領域，咱們一直致力於讓數據爲咱們提供價值，爲此咱們付出大量的努力和投入。
在過去二十年，各大企業都在着手搭建數據倉庫。當咱們費盡艱辛搭建好數據倉庫併成功用於線上運行時，發現咱們將花費更多時間爲數據科學家、分析師作數據準備。分析他們的數據需求，提供閃閃發光的數據報表。這將佔用數據維護人員 80% 的時間投入，這個投入是偏高的，包含如溝通、反查、校訂等大量重複和沒必要要投入。

如何提高數據管理能力？
咱們須要回到這 80% 的投入，想盡一切辦法壓縮它們，這樣才能更快的提供數據服務。這時有種工具呈現出了優點，那就是「元數據」。
元數據，一般的定義爲「描述數據的數據」。更準確一點說：元數據是描述流程、信息和對象的數據。這些描述涉及技術屬性特徵（例如，結構和行爲）、業務定義（包括字典和分類法）以及操做特徵（如活動指標和使用歷史）。
咱們用「元數據」去***這「80%」。將元數據作集中式管理，梳理元數據樹，翻譯、標註、補充元數據內容。方便使用者查找數據、理解數據、追蹤溯源以及規範專業知識。下降數據準備期間溝通、反查、校訂等大量重複和沒必要要投入，這樣咱們就能夠留下更多的時間進行數據分析，不只節省大量資金投入，還賺取更多的利潤。

以電信運營商爲例，經過各個時期的 IT 建設，公司有計費系統、網絡系統、OA 系統、財會系統和客服系統等等。隨着公司數據倉庫項目建設完成，各系統核心業務數據都彙總到了大數據中心。本覺得會大幅提高 IT 系統的「智能性」，沒想到基層的反應是根本用不起來。不少問題都來源於：缺少針對數據的指導，業務邏輯把控不許確，各部門指標不統一，致使數據準備的成本較高。
繼續以電信運營商爲例，對於運營商的「當日用戶數」這個指標，各個部門給出的定義並不同：

在營業部每週例會上，各個部門對「當日用戶數」爭吵的面紅耳赤，擔負着業務壓力的業務人員極可能誰也說服不了對方來接受本身的數字，不得不要求數據維護人員額外投入工做量去解析差別根源，校準報表數據。
這個問題按照元數據技術的術語來說，就是在業務元數據上，你們對於業務的認識並不統一。這種問題會形成大量的時間成本浪費：

元數據管理平臺的建設就是爲了不出現這樣的問題。建設元數據管理平臺能夠：
實現對技術元數據抽取、聚集、梳理，註釋相關庫表、列信息。支持查看完整數據鏈路和關聯圖譜。
梳理業務元數據，將相關的指標、流程在平臺中創建起來，固化並傳播企業專業知識。
將業務元數據同技術元數據聯繫起來，聯通業務與技術，給業務管理人員和技術維護人員提供更詳盡的指導。
就上文的舉例來看，就能夠在元數據管理平臺上維護「當日用戶數」等易混淆指標，規範其數據來源，將其同技術庫表元數據關聯起來並做詳盡的註釋。報表建設以元數據管理平臺維護的業務知識爲基準，這樣報表數據有章可循、有理有據，消弭沒必要要的爭吵，各部門專心分析報表數據，充分利用數據價值。
顯而易見，元數據管理平臺梳理企業資產、規範專業知識。推進元數據管理能夠顯著下降數據準備成本：

元數據管理是基礎
元數據管理能夠梳理企業資產，規範專業知識，下降數據準備期間溝通、反查、校訂等大量重複和沒必要要投入，輔助提高數據分析效率，是數據管理的基礎。
若是你進行的數據處理越複雜，做爲支撐的數據就須要更好。若是你同時兼顧了這兩件事，才能讓更多的人直接使用數據併爲本身服務。不少時候咱們每每「本末倒置」，碰到問題僅僅關注要如何解決，而忽略基礎的準備，不只增長複雜度和重複工做量，還會花費大量的溝通、理解的成本。

元數據管理是基礎
額外的，元數據管理做爲底層基礎，能使咱們在後續進行集成操做，如處理雲；在混合環境中作數據集成；在重複環境中作大數據時，獲取巨大的優點。事實上，將數據更快的交付給企業纔是重點。
綜上，爲了更快的數據分析和支撐業務，IT 中心的能力相當重要，由於它就是「80%」投入的來源。那麼什麼使一個成功的IT中心變得更加卓越。
元數據管理
東軟 SaCa MetadataManagement 元數據管理平臺軟件，致力於集中式元數據管理解決方案。普遍適配主流數據庫、ETL 工具、BI 工具等。支持智能語義檢索，提供數據剖析、全方位關聯分析、度量可調的血緣/影響分析、元數據質量自動分析等功能。