背景

據說，英語中元數據meta一詞最早出現于1968年，其是對希臘語前綴"meta-"的粗略翻譯，用于表明更抽象層次的事物。盡管元數據一詞只有幾十年的歷史，然而幾千年的圖書館管理員們一直在工作中使用著元數據，只不過我們先所謂的“元數據”是歷史上被稱為"圖書館目錄信息"。圖書目錄中的信息解決了一個十分關鍵的問題，就是如何幫助用戶在圖書館快速地、準確地找到想要的資料。

圖為愛爾蘭最古老的都柏林圣三一學院圖書館

圖書目錄中依然延續至今的信息片段：書名、作者或整理、主題、簡介和篇幅。但如今其含有更多的信息，如出版社、出版時間、定價、條形碼和上架建議等等。

如今的圖書目錄采用更多的信息片段。每本著作都有唯一的編碼號碼（圖書館的書一般帶有手寫或機打標簽），根據某種編碼方案（如杜威十進制分類法等）設計的純數字或字母數字混編字符串，來幫助圖書館用戶在書架上準確地快速地找到著作。

試想幾種場景，一個藏有幾千萬冊的圖書館沒有分類編碼存儲；著作沒有著作名稱、作者、簡介等；著作封面簡介與內容不符；著作沒有目錄等等。就會出現這樣的結果：

圖書館無法管理的自己圖書，很難統計館內多少圖書、每類圖書多少

圖書館無法根據大眾讀者喜好擺放某類圖書的位置

讀者無法找到自己想讀的圖書

讀者費時費力地找到了圖書，但內容與描述不符

讀者精疲力盡地找到了圖書，但無法快速定位到某些章節

讀者心平氣和地找到了圖書，但內容是錯誤的

讀者心滿意足地找到了圖書，但內容是下冊的，又必須從上冊讀起

讀者喜出望外地找到了圖書，但內容是用甲骨文寫的，用梵文作的注解（讀者看不懂）

讀者欲哭無淚地找到了圖書，但圖書館要下班關門了

......讀者崩潰了.....

同樣道理，若企業沒有做好元數據管理，那么數據消費者或數據分析師會面臨上述讀者的同類困境：找不到數據、找到沒有上下文無法理解數據、理解了數據因數據格式無法使用、內容有誤導致結果錯誤、查詢性能低、數據加工好已經錯過時效等等問題。解決上述困境或管好這些對事物的描述信息都屬于元數據管理的概念范疇。

如果沒有元數據管理，數據無法被有效地組織起來、被準確地理解、被合理地使用和產出預期的結果，那么數據價值無法發揮出來，于是數據變成了數據負債；如果沒有元數據，那么數據的內容和真實性就難以估量，繼而可能造成數據價值和可用性的降低。元數據是發揮數據價值的前提，是數據治理的基石。

何為元數據

“元數據是關于數據的數據”（準確地說這個定義不大實用，且不易被理解）。從數據、信息、知識和智慧人類認知領域的層次結構來講，數據是通過工具或機器搜集的原始資料。確切地說，數據是原始、未經處理的資料或潛在信息。信息就是經過某種處理并供人使用的數據。知識指的是你知道的事情，也就是經過內化的信息，而智慧則是指了解如何運用知識。元數據是對潛在信息的信息，是關于數據的更高層次抽象，是對數據的描述。

準確的元數據是必不可少的，也是迅速有效地對數據去粗取精的關鍵。沒有元數據，數據就毫無意義，只不過是一堆數字或文字而已。

元數據只是發揮數據價值的充分條件，“酒香也怕巷子深”如制定了合理并嚴格執行數據標準，通用的易用的模型設計數倉底座，極高的良性循環的數據質量，安全的順滑的數據訪問和數據共享機制和合理的高效的管理流程等，就亟須統一標準的、合理的、易用理解的、易用使用的元數據管理系統，不能把“好酒”（數據）埋沒掉，要把數據宣傳出去，讓更多用戶知曉、理解和高效使用，并使數據價值得最大發揮。

同時也應避免言過其實的“金玉其外，敗絮其中”即數據不標準、數據質量較差、數據存在異常和形散而神散、重復建設及計算的數倉等等，即使有個華麗的元數據可視化展示，只會換來業務用戶更多抱怨。

總之，名副其實是最好的，數據與元數據同步持續良性迭代優化。

元數據應用領域較廣，種類甚多，?按照不同應用領域或功能，元數據分類有很多種方法或種類，元數據一般大致可為三類：業務元數據、技術元數據和操作元數據。各自包含內容如下：

業務元數據：

指標名稱、計算口徑、業務術語解釋、衍生指標等

數據概念模型和邏輯模型

業務規則引擎的規則、數據質量檢測規則、數據挖掘算法等

數據血緣和影響分析

數據的安全或敏感級別等

技術元數據：

物理數據庫表名稱、列名稱、列屬性、備注、約束信息等

數據存儲類型、位置、數據存儲文件格式或數據壓縮類型等

數據訪問權限、組和角色

字段級血緣關系、ETL抽取加載轉換信息

調度依賴關系、進度和數據更新頻率

操作元數據：

系統執行日志

訪問模式、訪問頻率和執行時間

程序名稱和描述

版本維護等

備份、歸檔時間、歸檔存儲信息

上述只是大致的分為三類，簡單地列舉常用的元數據信息，其實還包括結構性元數據、保存性和權限元數據等等這里就不一一列舉了。

元數據管理

元數據也是數據，同樣適用數據生命周期管理。元數據生命周期可分為采集、整合、存儲、分析、應用、價值和服務幾個階段。

元數據架構

元數據戰略是關于企業元數據管理目標的說明，也是開發團隊的參考框架。元數據戰略決定了企業元數據架構。元數據架構可分為三類：集中式元數據架構、分布式元數據架構和混合元數據架構。

集中式元數據架構：

集中式架構包括一個集中的元數據存儲，在這里保存了來自各個元數據來源的元數據最新副本。保證了其獨立于源系統的元數據高可用性；加強了元數據存儲的統一性和一致性；通過結構化、標準化元數據及其附件的元數據信息，提升了元數據數據質量。集中式元數據架構有利于元數據標準化統一管理與應用。

分布式元數據架構：

分布式架構包括一個完整的分布式系統架構只維護一個單一訪問點，元數據獲取引擎響應用戶的需求，從元數據來源系統實時獲取元數據，而不存在統一集中元數據存儲。雖然此架構保證了元數據始終是最新且有效的，但是源系統的元數據沒有經過標準化或附加元數據的整合，且查詢能力直接受限于相關元數據來源系統的可用性。

混合式元數據架構：

這是一種折中的架構方案，元數據依然從元數據來源系統進入存儲庫。但是存儲庫的設計只考慮用戶增加的元數據、高度標準化的元數據以及手工獲取的元數據。

這三類各有千秋，但為了更好發揮數據價值，就需要對元數據標準化、集中整合化、統一化管理。如果企業做功能較為完善的數據資產管理平臺可采用集中式元數據架構。

元數據生命周期

筆者這里以集中式元數據架構為例講解，通過對數據源系統的元數據信息采集，發送Kafka消息系統進行解耦合，再使用Antlr4開發各版SQL解析器，對元數據信息新增、修改和刪除操作進行標準化集中整合存儲。在元數據集中存儲的基礎上或過程中，可提供元數據服務與應用，如數據資產目錄、數據地圖、集成IDE、統一SQL多處理引擎、字段級血緣關系、影響度分析、下線分析、版本管理和數據價值分析等（這些元數據應用可根據產品經理設計理念進行優化組合，筆者這里拉平排列各功能應用，為了方便講解各元數據應用模塊）。這里就包括了元數據采集、整合、存儲、分析、應用等階段的生命周期。

元數據管理與常見元數據應用：

數據資產地圖

數據資產地圖包括數據資產目錄和血緣關系等。通過對元數據的標準化、加工整合形成數據資產地圖。數據資產地圖一般可支持全文搜索和模糊查詢表信息檢索、也支持按照關系查找或按主題域層級查找。一般采集Elasticsearch做元數據信息檢索和Neo4J做血緣關系的數據地圖。如圖：

檢索表的元數據信息包括分層信息、分層數據庫數量、每層功能描述、數據庫表數量、總計存儲大小、存儲類型、實際表存儲位置，表基本信息包括主題分類、所屬主題、主題描述、表名稱、表數據功能簡介、表類型、表創建人、表更新人、創建時間、更新時間、數據更新人、數據更新時間、表預估數據量、表文件大小、表文件個數、表文件存儲格式、表壓縮格式、數據質量評分、數據熱度、更新頻率、大致更新完成時間等等。

還包含指標業務元數據信息如下：

元數據信息也要包括歸檔和已銷毀的數據記錄的元數據信息。歸檔元數據信息便于數據分析師查找，快速恢復，重新使用挖掘出數據價值。已銷毀元數據信息便于數據安全管理。

還包括未采集數據資產管理平臺的元數據信息，實際數據還分布在各個源系統的數據，需要抽取、轉換、清洗和加載到數據平臺的相關流程和ETL工具，便于業務用戶元數據查找和數據使用。

版本管理

元數據版本管理功能，可對元數據進行發布、查看歷史版本、導出歷史版本和版本對比操作。在元數據未發布或未正式上線使用時，其他僅有使用權限的用戶無法查看此版本信息，這樣保證了元數據系統權威性和可靠性。這里同樣涉及影響度分析和下線分析元數據應用模塊，如表結構變更、刪除等下游系統都能做到動態感知提醒或告警功能，下線分析也是如此。

血緣關系

血緣關系包含了集群血緣關系、系統血緣關系、表級血緣關系和字段血緣關系，其指向數據的上游來源，向上游追根溯源。這里指的血緣關系一般是指表級和字段級，其能清晰展現數據加工處理邏輯脈絡，快速定位數據異常字段影響范圍，準確圈定最小范圍數據回溯，降低了理解數據和解決數據問題的成本。

在傳統的ETL工具如Informatica、DataStage和開源Kettle中都有相應血緣關系，以informatica ETL工具的表級血緣關系和字段級血緣舉例，如圖：

（上圖：表級血緣關系）

（上圖：字段級血緣關系，也稱mapping）

但只能展現使用這些傳統ETL工具的血緣關系，其他方式ETL卻無法生成血緣關系。其不靈活也不便于元數據統一集中管理。

大數據時代，大部分企業數據倉庫都使用Hive作為數倉存儲和ETL數據加工，如果是單一Hive處理引擎，可使用Hive Hook直接解析字段級血緣關系和表級別血緣關系。如果多種計算引擎就使用上述筆者給出技術架構圖，通過對不同存儲和計算引擎監聽動作，使用Antlr4開發各版本SQL解析工具，動態識別元數據信息變更、刪除和新增實時或準實時生成集群血緣關系、系統血緣關系、表級血緣關系和字段血緣關系。通過從語法樹遍歷解析后存儲Neo4j圖數據。

影響度分析

影響度分析，也是較為血緣關系應用的一部分，其用來分析數據的下游流向。當系統進行升級改造時，能動態數據結構變更、刪除及時告知下游系統。通過依賴數據的影響性分析，可以快速定位出元數據修改會影響到哪些下游系統，哪些表和哪些字段。從而減少系統升級改造帶來的風險。

下線分析

下線分析和影響度分析功能大致相同，只是應用的側重點不同，下線分析是根據數據熱度，對冷數據或冰數據歸檔下線時，是否對其他應用造成依賴影響，便于數據歸檔操作。

數據價值分析

數據價值分析主要是對數據表的被使用情況進行統計，價值密度、訪問頻次、使用方式、時效性等級等維度評估，從而評級出數據熱度，熱數據、溫數據、冷數據和冰數據。數據價值訪問評估一些常用的維度：表的訪問頻率分析、表分區數據訪問分析、跨表訪問分析、跨層訪問分析、跨庫訪問分析、字段訪問頻率分析、表訪問用戶量分析和分層表訪問總量分析等。數據熱度應隨著時間的推移，數據價值會變化，應動態更新數據熱度等級，推動數據從產生到銷毀數據生命周期管理。總之，在成本可控、可量化、可管理的前提下，從數據中挖掘出更多有效的數據價值。

集成IDE

為了方便數據提供者或數據分析師數據收集、清洗、加工數據的方式不同，集成IDE集成了不同數據開發語言或工具，如集成Python、R、Shell和各版本數據處理引擎的SQL。這是統一的數據開發加工入口。每個元數據應用模塊都不是獨立的，需要其他元數據應用模塊如數據資產地圖和數據目錄集成，便于快速定位分析師要查找的數據和準確地理解數據，從而提高了數據加工或數據分析的效率。

統一SQL路由引擎

集成IDE開發中提到統一SQL路由引擎，其統一使用HQL語言智能地路由多種執行引擎。這降低了用戶熟悉其他SQL的學習成本，其可屏蔽了多種引擎SQL差異，可基于SQL復雜度和成本估算、優先級和各引擎集群空閑程度，把用戶提交的SQL路由到合適的執行引擎，如果Hive轉換Presto、Spark或其他引擎執行失敗，則使用Hive引擎來補救執行，最終都會返回結果。

元數據應用還有很多，如數據探查、元數據對比分析是否存儲重復計算和重復存儲等等，限于篇幅，不一一列舉。

總結

如何從數據中探索信息、發現知識，尋找隱藏在數據中的趨勢、模式、相關性及隱含規律，都要我們用于更好的數據洞察力，而這種洞察力的基礎來自我們對元數據的理解。

元數據是用數據管理數據，是快速查找數據、精確定位數據、準確地理解數據和快速使用數據的關鍵。元數據管理還須符合數據標準、較高的數據質量、數據安全、數據共享、合理順滑管理流程。在存儲、計算和人力成本合理可控、可管理的前提下，使數據價值得最大發揮，是數據全生命周期管理重要組成部分。是提升數據價值發揮的前提，是數據治理的基石。

<END>