一文詳解後設資料管理與資料血緣

什麼是後設資料?後設資料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階段。

這麼做的優點是血緣的追蹤分析是基於真實執行任務的資訊進行分析的，如果外掛部署全面，也不太會有遺漏問題，但是這種方式也有很多不太好解決的問題，比如

• 如何更新一個歷史上有依賴後來不再依賴的血緣關係

• 對於一個還未執行的任務，不能提前獲取血緣資訊

• 臨時指令碼或者錯誤的指令碼邏輯對血緣關係資料的汙染

簡單總結一下，就是基於執行時的資訊來採集血緣關係，由於缺乏靜態的業務資訊輔助，如何甄別和更新血緣關係的生命週期和有效性會是一個棘手的問題，一定程度上也限制了應用的範圍。

我們的做法是，血緣資訊的採集不是在執行時動進行的，而是在指令碼儲存時進行的。由於開發平臺統一管理了所有使用者的任務指令碼，所以，我們可以對指令碼進行靜態的分析，加上指令碼本身業務資訊，執行情況和生命週期對開發平臺是可知的。所以一定程度上能解決上述提到的幾個問題。

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