什么是元數據？元數據MetaData狹義的解釋是用來描述數據的數據，廣義的來看，除了業務邏輯直接讀寫處理的那些業務數據，所有其它用來維持整個系統運轉所需的信息／數據都可以叫作元數據。比如數據表格的Schema信息，任務的血緣關系，用戶和腳本／任務的權限映射關系信息等等。

管理這些附加MetaData信息的目的，一方面是為了讓用戶能夠更高效的挖掘和使用數據，另一方面是為了讓平臺管理人員能更加有效的做好系統的維護管理工作。

出發點很好，但通常這些元數據信息是散落在平臺的各個系統，各種流程之中的，而它們的管理也可能或多或少可以通過各種子系統自身的工具，方案或流程邏輯來實現。那么我們所說的元數據管理平臺又是用來做什么的？是不是所有的信息都應該或者有必要收集到一個系統中來進行統一管理呢，具體又有哪些數據應該被納入到元數據管理平臺的管理范圍之中呢？下面我們就來探討一下相關的內容。

元數據管理平臺管什么

數據治理的第一步，就是收集信息，很明顯，沒有數據就無從分析，也就無法有效的對平臺的數據鏈路進行管理和改進。所以元數據管理平臺很重要的一個功能就是信息的收集，至于收集哪些信息，取決于業務的需求和我們需要解決的目標問題。

信息收集再多，如果不能發揮作用，那也就只是浪費存儲空間而已。所以元數據管理平臺還需要考慮如何以恰當的形式對這些元數據信息進行展示，進一步的，如何將這些元數據信息通過服務的形式提供給周邊上下游系統使用，真正幫助大數據平臺完成質量管理的閉環工作。

應該收集那些信息，雖然沒有絕對的標準，但是對大數據開發平臺來說，常見的元數據信息包括：

• 數據的表結構Schema信息
• 數據的空間存儲，讀寫記錄，權限歸屬和其它各類統計信息
• 數據的血緣關系信息
• 數據的業務屬性信息

下面我們針對這四項內容再具體展開討論一下

數據的表結構Schema信息

數據的表結構信息，這個很容易理解了，狹義的元數據信息通常多半指的就是這部分內容了，它也的確屬于元數據信息管理系統中最重要的一塊內容。

不過，無論是SQL還是NoSQL的數據存儲組件，多半自身都有管理和查詢表格Schema的能力，這也很好理解如果沒有這些能力的話，這些系統自身就沒法良好的運轉下去了不是。比如，Hive自身的表結構信息本來就存儲在外部DB數據庫中，Hive也提供類似 show table，describe table之類的語法對這些信息進行查詢。那么我們為什么還要多此一舉，再開發一個元數據管理系統對這些信息進行管理呢？

這么做，可能的理由很多，需要集中管理可以是其中一個理由，但更重要的理由，是因為本質上，這些系統自身的元數據信息管理手段通常都是為了滿足系統自身的功能運轉而設計的。也就是說，它們并不是為了數據質量管理的目的而存在的，由于需求定位不同，所以無論從功能形態還是從交互手段的角度來說，它們通常也就無法直接滿足數據質量管理的需求。

舉個很簡單的例子，比如我想知道表結構的歷史變遷記錄，很顯然多數系統自身是不會設計這樣的功能的。而且一些功能就算有，周邊上下游的其它業務系統往往也不適合直接從該系統中獲取這類信息，因為如果那樣做的話，系統的安全性和相互直接的依賴耦合往往都會是個問題。

所以，收集表結構信息，不光是簡單的信息匯總，更重要的是從平臺管理和業務需求的角度出發來考慮，如何整理和歸納數據，方便系統集成，實現最終的業務價值。

數據的存儲空間，讀寫記錄，權限歸屬和其它各類統計信息

這類信息，可能包括但不限于：數據占據了多少底層存儲空間，最近是否有過修改，都有誰在什么時候使用過這些數據，誰有權限管理和查閱這些數據等等。此外，還可以包括類似昨天新增了多少個表格，刪除了多少表格，創建了多少分區之類的統計信息。

在正常的工作流程中，多數人可能不需要也不會去關心這類信息。但是落到數據質量管理這個話題上時，這些信息對于系統和業務的優化，數據的安全管控，問題的排查等工作來說，又往往都是不可或缺的重要信息，所以通常這類信息也可以從Audit審計的角度來歸類看待。

與表結構信息類似，對于這類Audit審計類信息的采集和管理，通常具體的底層數據存儲管理組件自身的功能也無法直接滿足我們的需求，需要通過專門的元數據管理平臺中統一進行采集，加工和管理。

數據的血緣關系信息

血緣信息或者叫做Lineage的血統信息是什么，簡單的說就是數據之間的上下游來源去向關系，數據從哪里來到哪里去。知道這個信息有什么用呢？用途很廣，舉個最簡單的例子來說，如果一個數據有問題，你可以根據血緣關系往上游排查，看看到底在哪個環節出了問題。此外我們也可以通過數據的血緣關系，建立起生產這些數據的任務之間的依賴關系，進而輔助調度系統的工作調度，或者用來判斷一個失敗或錯誤的任務可能對哪些下游數據造成影響等等。

分析數據的血緣關系看起來簡單，但真的要做起來，并不容易，因為數據的來源多種多樣，加工數據的手段，所使用的計算框架可能也各不相同，此外也不是所有的系統天生都具備獲取相關信息的能力。而針對不同的系統，血緣關系具體能夠分析到的粒度可能也不一樣，有些能做到表級別，有些甚至可以做到字段級別。

以hive表為例，通過分析hive腳本的執行計劃，是可以做到相對精確的定位出字段級別的數據血緣關系的。而如果是一個MapReduce任務生成的數據，從外部來看，可能就只能通過分析MR任務輸出的Log日志信息來粗略判斷目錄級別的讀寫關系，從而間接推導數據的血緣依賴關系了。

數據的業務屬性信息

前面三類信息，一定程度上都可以通過技術手段從底層系統自身所擁有的信息中獲取得到，又或著可以通過一定的流程二次加工分析得到。與之相反，數據的業務屬性信息，通常與底層系統自身的運行邏輯無關，多半就需要通過其他手段從外部獲取了。

那么，業務屬性信息都有哪些呢？最常見的，比如，一張數據表的統計口徑信息，這張表干什么用的，各個字段的具體統計方式，業務描述，業務標簽，腳本邏輯的歷史變遷記錄，變遷原因等等，此外，你也可能會關心對應的數據表格是由誰負責開發的，具體數據的業務部門歸屬等等。

上述信息如果全部需要依靠數據開發者的自覺填寫，不是不行，但是顯然不太靠譜。畢竟對于多數同學來說，對于完成數據開發工作核心鏈路以外的工作量，很自然的反應就是能不做就不做，越省事越好。如果沒有流程體系的規范，如果沒有產生實際的價值，那么相關信息的填寫很容易就會成為一個負擔或者是流于形式。

所以，盡管這部分信息往往需要通過外部手段人工錄入，但是還是需要盡量考慮和流程進行整合，讓它們成為業務開發必不可少的環節。比如，一部分信息的采集，可以通過整體數據平臺的開發流程規范，嵌入到對應數據的開發過程中進行，例如歷史變遷記錄可以在修改任務腳本或者表格schema時強制要求填寫；業務負責人信息，可以通過當前開發人員的業務線和開發群組歸屬關系自動進行映射填充；字段統計方式信息，盡可能通過標準的維度指標管理體系進行規范定義。

總體來說，數據的業務屬性信息，必然首先是為業務服務的，因此它的采集和展示也就需要盡可能的和業務環境相融合，只有這樣才能真正發揮這部分元數據信息的作用。

元數據管理相關系統方案介紹

Apache Atlas

社區中開源的元數據管理系統方案，常見的比如Hortonworks主推的Apache Atlas，它的基本架構思想如下圖所示

Atlas的架構方案應該說相當典型，基本上這類系統大致都會由元數據的收集，存儲和查詢展示三部分核心組件組成。此外，還會有一個管理后臺對整體元數據的采集流程以及元數據格式定義和服務的部署等各項內容進行配置管理。

對應到Atlas的實現上，Atlas通過各種hook/bridge插件來采集幾種數據源的元數據信息，通過一套自定義的Type 體系來定義元數據信息的格式，通過搜索引擎對元數據進行全文索引和條件檢索，除了自帶的UI控制臺意外，Atlas還可以通過Rest API的形式對外提供服務。

Atlas的整體設計側重于數據血緣關系的采集以及表格維度的基本信息和業務屬性信息的管理。為了這個目的，Atlas設計了一套通用的Type體系來描述這些信息。主要的Type基礎類型包括DataSet和Process，前者用來描述各種數據源本身，后者用來描述一個數據處理的流程，比如一個ETL任務。

Atlas現有的Bridge實現，從數據源的角度來看，主要覆蓋了Hive，HBase，HDFS和Kafka，此外還有適配于Sqoop, Storm和Falcon的Bridge，不過這三者更多的是從Process的角度入手，最后落地的數據源還是上述四種數據源。

具體Bridge的實現多半是通過上述底層存儲，計算引擎各自流程中的Hook機制來實現的，比如Hive SQL的Post Execute Hook，HBase的Coprocessor等，而采集到的數據則通過Kafka消息隊列傳輸給Atlas Server或者其它訂閱者進行消費。

在業務信息管理方面，Atlas通過用戶自定義Type 屬性信息的方式，讓用戶可以實現數據的業務信息填寫或者對數據打標簽等操作，便于后續對數據進行定向過濾檢索。

最后，Atlas可以和Ranger配套使用，允許Ranger通過Atlas中用戶自定義的數據標簽的形式來對數據進行動態授權管理工作，相對于基于路徑或者表名/文件名的形式進行靜態授權的方式，這種基于標簽的方式，有時候可以更加靈活的處理一些特定場景下的權限管理工作。

總體而言，Atlas的實現，從結構原理的角度來說，還算是比較合理的，但從現階段來看，Atlas的具體實現還比較粗糙，很多功能也是處于可用但并不完善的狀態。此外Atlas在數據審計環節做的工作也不多，與整體數據業務流程的集成應用方面的能力也很有限。Atlas項目本身很長時間也都處于Incubator狀態，因此還需要大家一起多努力來幫助它的改進。

Cloudera Navigator Data Management

另外一個比較常見的解決方案是Cloudera CDH發行版中主推的Navigator，相比Atlas而言，Navigator的整體實現更加成熟一些，更像一個完整的解決方案，不過，Navigator并不是開源的，也難怪，畢竟要賣錢的的東西，也就更有動力去完善 ；）

Navigator的產品定位是Data Management數據管理，本質上也是通過管理元數據來管理數據，但周邊工具和配套設施相對完善，和Cloudera Manager管理后臺的產品集成工作也做得比較徹底。相比Atlas來說，Navigator的整體組件架構也更加復雜一些。Navigator的大致組件架構如下圖所示

Navigator定位為數據管理，所以對數據的審計管理方面的工作也會做得更多一些，除了采集和管理Hive/Impala等表格的血緣信息，Navigator也可以配置采集包括HDFS的讀寫操作記錄，Yarn/Spark/Pig等作業的運行統計數據在內的信息。Navigator同時還為用戶提供了各種統計分析視圖和查詢管理工具來分析這些數據。

從底層實現來看，Navigator同樣通過Hook或著Plugin插件的形式從各種底層系統的運行過程中獲取相關信息。但與Atlas不同的是，Navigator的元數據采集傳輸處理流程并沒有把這些信息寫入到消息隊列中，而是主要通過這些插件寫入到相關服務所在的本地Log文件中，然后由Cloudera Manager在每臺服務節點上部署的Agent來讀取，過濾，分析處理并傳輸這些信息給Audit Server。

此外Navigator還通過獨立的Metadata Server來收集和分析一些非Log來源的元數據信息，并統一對外提供元數據的配置管理服務。用戶還可以通過配置Policy策略，讓Metadata Server自動基于用戶定義的規則，替用戶完成數據的Tag標簽打標工作，進而提升數據自動化自治管理的能力。

總體而言，Navigator和Cloudera Manger的產品集成工作做得相對完善，如果你使用CDH發行版全家福套件來管理你的集群的話，使用Navigator應該是一個不錯的選擇。不過，如果是自主管理的集群或者自建的大數據開發平臺，深度集成定制的Navigator就很難為你所用了，但無論如何，對于自主開發的元數據管理系統來說，Navigator的整體設計思想也還是值得借鑒的。

蘑菇街元數據管理系統實踐

蘑菇街大數據平臺的元數據管理系統，大體的體系架構思想和上述系統也比較類似，不過，客觀的說我們的系統的開發是一個伴隨著整體開發平臺的需求演進而漸進拓展的過程，所以從數據管理的角度來說，沒有上述兩個系統那么關注數據格式類型系統的普遍適用性。比如Schema這部分信息的管理，就主要側重于表格類信息的管理，比如Hive，HBase等，而非完全通用的類型系統。但相對的，在對外服務方面，我們也會更加注重元數據管理系統和業務系統應用需求的關聯，架構大同小異，下面主要簡單介紹一下產品交互形態和一些特殊的功能特效設定等。

如圖所示，是我們的元數據管理系統的產品后臺針對Hive表格元數據信息的部分查詢界面，主要為用戶提供表格的各種基礎schema信息，業務標簽信息，血緣關系信息，樣本數據，以及底層存儲容量星系，權限和讀寫修改記錄等審計信息。

除了表格元數據信息管理以外，我們的元數據管理系統主要的功能之一是“業務組”的管理，業務組的設計目標是貫穿整個大數據開發平臺的，做為大數據開發平臺上開發人員的自主管理單元組織形式。將所有的數據和任務的管理工作都下放到業務組內部由業務組管理員管理。

從元數據管理系統的角度來說，業務組的管理，包括數據和任務與業務組的歸屬關系映射，業務組內角色的權限映射關系等，此外，為了適應業務的快速變化，也給用戶提供的數據資產的歸屬關系轉移等功能。

總體來說，業務組的管理功能，更多的是需要和大數據開發平臺的其它組件相結合，比如和集成開發平臺IDE相結合，在開發平臺中提供基于業務組的多租戶開發環境管理功能，再比如與調度系統相結合，根據任務和數據的業務組歸屬信息，在任務調度時實施計算資源的配額管理等。

最后，關于數據的血緣關系跟蹤，再多說兩句。在Atlas和navigator中，主要通過計算框架自身支持的運行時hook來獲得數據相關元數據和血緣相關信息，比如hive的hook是在語法解析階段，storm的hook是在topology submit階段。

這么做的優點是血緣的追蹤分析是基于真實運行任務的信息進行分析的，如果插件部署全面，也不太會有遺漏問題，但是這種方式也有很多不太好解決的問題，比如

• 如何更新一個歷史上有依賴后來不再依賴的血緣關系
• 對于一個還未運行的任務，不能提前獲取血緣信息
• 臨時腳本或者錯誤的腳本邏輯對血緣關系數據的污染

簡單總結一下，就是基于運行時的信息來采集血緣關系，由于缺乏靜態的業務信息輔助，如何甄別和更新血緣關系的生命周期和有效性會是一個棘手的問題，一定程度上也限制了應用的范圍。

我們的做法是，血緣信息的采集不是在運行時動進行的，而是在腳本保存時進行的。由于開發平臺統一管理了所有用戶的任務腳本，所以，我們可以對腳本進行靜態的分析，加上腳本本身業務信息，執行情況和生命周期對開發平臺是可知的。所以一定程度上能解決上述提到的幾個問題。

當然，這種方案也有自己的短板需要克服，比如：如果腳本管控不到位，血緣關系分析可能覆蓋不全；血緣關系是基于最新的腳本的靜態的邏輯關系，無法做到基于某一次真實的運行實例進行分析。不過，這些短板對我們來說從需求的角度來說都不是很核心的問題，又或者通過周邊系統的配套建設可以在一定程度上加以解決克服的。