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

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

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

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

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

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

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

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

關(guān)于血緣關(guān)系需求：

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

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

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

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

關(guān)于血緣需求的第一個(gè)建議：

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

關(guān)于血緣需求的第二個(gè)建議：

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

說明：TPC-DS算是比較通用的大數(shù)據(jù)領(lǐng)域SQL測試標(biāo)準(zhǔn)，還有TPC-BB, TPC-H。

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

以下為TPC-DS詳細(xì)信息：

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

血緣影響分析：

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

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

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

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

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

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

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

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

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

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

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

ETL的邏輯：保存-提交-次日運(yùn)行。

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

表的任務(wù)信息如何展示？

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

解決方案：ETL任務(wù)、目標(biāo)表、源表對應(yīng)關(guān)系，簡單來說就是提供我們要的表跟它的任務(wù)對應(yīng)關(guān)系接口。

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

表的使用信息怎么拿到？

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

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

表的使用次數(shù)：

表的使用次數(shù)非常麻煩，因?yàn)檫@里有個(gè)準(zhǔn)確性的問題，你要多準(zhǔn)？100%準(zhǔn)確么？還是大概準(zhǔn)確就可以？

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

解決方案：

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

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

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

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

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

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

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

今天先介紹到這里~

作者：hackmonster，知乎號(hào)：hackmonster

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

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

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