聊聊數據中臺：元數據建設有哪些坑（二）

編輯導讀：在進行數據地圖的工作中，需要注意兩個核心功能，即元數據信息的展示和血緣關係。本文將圍繞這兩個點展開分析，希望對你有幫助。

元數據地圖

上期講到數據地圖，這一期重點來講，開始之前說點別的，類似元數據、ETL平臺類的產品、非常考驗開發的技術水平。

這裏有個問題，作爲產品需不需要參與每個技術方案的評審？這裏我建議在時間允許的情況下儘量都參與下，很多時候開發給的技術方案都是爲了實現而實現，而需求從來都不是一層不變的，在定一個技術方案的時候也要考慮萬一我的需求或者場景變了的情況下，是否都能夠滿足？

而且技術方案變化也是很正常的事情，除非你們有CTO專門幫你們訂好方案和評審。這裏我建議產品儘量參與下，很多問題都可以在初期就可以避免。

數據地圖最核心的功能有兩個：元數據信息的展示、血緣關係。

元數據信息的展示上期已經講過了，根據採集的信息+元模型進行展示，這裏需要考慮的問題就是要儘量全，要對展示的信息進行一個分類，不然會很亂。

我這裏分了幾種：技術信息、業務信息、權限信息。這裏我只說下權限信息，用戶在查詢元數據的時候我們要給出權限的信息，讀、寫還是無權限等，同時還要提供數據預覽的功能，當用戶無法通過技術屬性和業務屬性直觀的瞭解數據時，還是可以通過查看數據內容去理解數據（建議限制20條）。

關於血緣關係需求：

血緣是元數據最核心的功能了，關於如何提血緣的需求產品要多聽聽用戶和技術的聲音，血緣存在一個覆蓋率的問題，是100%還是90%以上即可？

用戶都希望可以實現100%，但現實是打臉的，每個公司的場景都不一樣很難有公司說我們cover你們公司所有場景，可以保證血緣100%解析。如果真有要麼這個公司技術水平非常高，要麼是忽悠你。

SQL作爲一門語言它可以有成千、上萬中寫法，還可能會引用各種函數、這裏還存在書寫不規範的情況誰敢保證能夠100%覆蓋？

PS：我這裏說的血緣是指要到字段級的。

關於血緣需求的第一個建議：

實現不了的，列出來，訂好規範儘量避免這種寫法出現，比如銀行會有類似10大鐵律，發現即懲罰，來避免出現解析不了的情況。
能實現的要100%覆蓋，出現就是bug。
長期、大量測試要有，覆蓋主要業務場景。

關於血緣需求的第二個建議：

按照行業TPC-DS的評測標準，100%覆蓋。
超出的按照新需求迭代開發，不算bug。

說明：TPC-DS算是比較通用的大數據領域SQL測試標準，還有TPC-BB, TPC-H。

TPC-DS提供99個SQL查詢（SQL99或2003），分析數據量大，測試數據與實際商業數據高度相似，同時具有各種業務模型（分析報告型，數據挖掘型等等）。

以下爲TPC-DS詳細信息：

https://cloud.tencent.com/developer/news/83351

血緣影響分析：

在規劃影響分析時，我也參考了其他廠商做的，比如普元、亞信、阿里雲，主要場景基本類似，主要分析字段或者表發生變更時對下游鏈路的影響。我們做的比較簡單，提供表、字段的血緣分析，可以通過查詢表或字段來分析整個血緣鏈路的影響，尤其是鏈路較多的時候會用到。

血緣從哪裏解析？存哪裏？

用過ETL的都知道，ETL也有血緣或者叫依賴關係，一般情況都是ETL先建設，元數據都是後建設，血緣本質是解析SQL輸出表與表之間的關係，而SQL基本都是來自於ETL的任務，所以大部分的做法都是ETL將實時傳給元數據，元數據進行解析，我們也是類似。

這裏就涉及一個存儲的問題了，傳統的數據庫肯定是沒有問題的，但傳統的數據庫存在打開慢的情況，尤其是血緣鏈路長的時候（幾百個表），這裏的建議就是使用圖數據庫在存儲血緣關係。

Neo4j、TigerGraph、Amazon Neptune、JanusGraph、ArangoDB，是市場上最爲知名的五大圖數據庫品牌，我們用的是Neo4j。

科普性的我儘量少講，讓大家更關注元數據本身，感興趣的看下這個連接：

https://www.zhihu.com/question/19916683

開源 NoSQL 數據庫，原生的圖數據庫，2003 年開始開發，使用 scala和java 語言，2007年開始發佈；
世界上最先進的圖數據庫之一，提供原生的圖數據存儲，檢索和處理；
採用屬性圖模型（Property graph model），極大的完善和豐富圖數據模型；
專屬查詢語言 Cypher，直觀，高效。

跟ETL如何對接？如何確保SQL100%覆蓋？

我總結產品問題：凡是跟其他系統對接的都是坑。

剛剛提到的血緣100%覆蓋，但是這中間還有個問題，如果ETL不能100%的把SQL傳給你，你就算實現了100%解析也沒用。

ETL的邏輯：保存-提交-次日運行。

我們的方案：任務提交時觸發通過kafka將SQL以及任務信息傳給元數據。後續再講這個方案到底哪裏有問題。

表的任務信息如何展示？

這裏就又有問題了，在元數據裏都是以表作爲緯度去查看它的其他信息，但是在ETL裏面都是以任務爲緯度去查看它的表信息，這裏就出現一個表可能會有多個任務的情況，但實際上我們只關心它的數據來源是哪個任務。

解決方案：ETL任務、目標表、源表對應關係，簡單來說就是提供我們要的表跟它的任務對應關係接口。

還是那句話凡是跟其他系統對接的都是坑。

表的使用信息怎麼拿到？

在查看錶的元數據過程中，用戶還會關係這個表是否有人使用過，尤其是類似倉庫的數據，你建好的主題域、集市表根本沒什麼人用，那是不是考慮後續不維護了或者自身找原因是不是不滿足用戶需求。需求很簡單，但是實現很麻煩。

類似的指標數據我們定了好幾個，這裏我拿出其中的1個展開講。

表的使用次數：

表的使用次數非常麻煩，因爲這裏有個準確性的問題，你要多準？100%準確麼？還是大概準確就可以？

數據中臺怎麼會沒有查詢平臺那，類似即系查詢、tableau等等都可以查看數據，如果要大概準確可以從即系查詢平臺拿到，如果要100%準確那就麻煩了。

解決方案：

最全的日誌都在底層，我們是從從hive拿到的metastore日誌，這個絕對是100%準確，我們是通過SFTP定時從hive拿到metastore日誌然後在做解析，這裏時效性就沒辦法保障了，如果要做到實時使用flume會影響即系查詢的查詢性能，這個是運維不允許的，所以我們只做到準確性，不保障時效性（T+1）。