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

元數(shù)據(jù)地圖

上期講到數(shù)據(jù)地圖，這一期重點來講，開始之前說點別的，類似元數(shù)據(jù)、ETL平臺類的產(chǎn)品、非?？简為_發(fā)的技術水平。

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

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

數(shù)據(jù)地圖最核心的功能有兩個：元數(shù)據(jù)信息的展示、血緣關系。

元數(shù)據(jù)信息的展示上期已經(jīng)講過了，根據(jù)采集的信息+元模型進行展示，這里需要考慮的問題就是要盡量全，要對展示的信息進行一個分類，不然會很亂。

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

關于血緣關系需求：

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

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

SQL作為一門語言它可以有成千、上萬中寫法，還可能會引用各種函數(shù)、這里還存在書寫不規(guī)范的情況誰敢保證能夠100%覆蓋？

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

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

1. 實現(xiàn)不了的，列出來，訂好規(guī)范盡量避免這種寫法出現(xiàn)，比如銀行會有類似10大鐵律，發(fā)現(xiàn)即懲罰，來避免出現(xiàn)解析不了的情況。
2. 能實現(xiàn)的要100%覆蓋，出現(xiàn)就是bug。
3. 長期、大量測試要有，覆蓋主要業(yè)務場景。

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

1. 按照行業(yè)TPC-DS的評測標準，100%覆蓋。
2. 超出的按照新需求迭代開發(fā)，不算bug。

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

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

以下為TPC-DS詳細信息：

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

血緣影響分析：

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

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

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

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

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

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

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

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

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

我總結產(chǎn)品問題：凡是跟其他系統(tǒng)對接的都是坑。

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

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

我們的方案：任務提交時觸發(fā)通過kafka將SQL以及任務信息傳給元數(shù)據(jù)。后續(xù)再講這個方案到底哪里有問題。

表的任務信息如何展示？

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

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

還是那句話凡是跟其他系統(tǒng)對接的都是坑。

表的使用信息怎么拿到？

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

類似的指標數(shù)據(jù)我們定了好幾個，這里我拿出其中的1個展開講。

表的使用次數(shù)：

表的使用次數(shù)非常麻煩，因為這里有個準確性的問題，你要多準？100%準確么？還是大概準確就可以？

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

解決方案：

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

表發(fā)生表更了如何捕獲？

生產(chǎn)表發(fā)生變更了如何捕獲？

我們的做法時每次全量同步做merge，將變更內(nèi)容做記錄。

最麻煩就是Hive元數(shù)據(jù)變更的捕獲了？

我的了解應該還是有很多方案，我們的方案是：通過hive hook+kafka來實現(xiàn)，hook是hive的一個插件可以實現(xiàn)很多功能，我們這里用它來捕獲DDL事件，并將結果通過kafka傳給元數(shù)據(jù)做解析。

我了解大廠在血緣的解析這塊用的就是hook，感興趣的可以去研究研究。

今天先介紹到這里~

作者：hackmonster，知乎號：hackmonster

原文鏈接：https://www.zhihu.com/question/19916683/answer/459757696

本文由 @逆襲的騎士 授權發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。