數(shù)據(jù)血緣圖譜升級(jí)方案設(shè)計(jì)與實(shí)現(xiàn)

　　數(shù)據(jù)地圖平臺(tái)是字節(jié)跳動(dòng)內(nèi)部的大數(shù)據(jù)檢索平臺(tái)，每天近萬的字節(jié)員工在此查找所需數(shù)據(jù)。數(shù)據(jù)地圖通過提供便捷的找數(shù)，理解數(shù)服務(wù)，大大節(jié)省了內(nèi)部數(shù)據(jù)的溝通和建設(shè)成本。

　　數(shù)據(jù)血緣圖譜介紹

　　字節(jié)的數(shù)據(jù)可分為端數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，這些記錄往往需要通過加工處理才能產(chǎn)生業(yè)務(wù)價(jià)值。數(shù)據(jù)加工處理的流程一般是讀取原始數(shù)據(jù)，進(jìn)行數(shù)據(jù)清洗，再經(jīng)過多種計(jì)算和存儲(chǔ)，最終匯入指標(biāo)、報(bào)表和數(shù)據(jù)服務(wù)系統(tǒng)。數(shù)據(jù)血緣描述了數(shù)據(jù)的來源和去向，以及數(shù)據(jù)在多個(gè)處理過程中的轉(zhuǎn)換，是組織內(nèi)使數(shù)據(jù)發(fā)揮價(jià)值的重要基礎(chǔ)能力。

　　數(shù)據(jù)地圖平臺(tái)在 2021 年接入了全鏈路核心元數(shù)據(jù)，包括但不限于：Hive、Clickhouse、Kafka、BI 報(bào)表、BI 數(shù)據(jù)集、畫像、埋點(diǎn)、MySQL、Abase。這些數(shù)據(jù)全部要通過數(shù)據(jù)血緣連接起來，進(jìn)而可以進(jìn)行影響分析、內(nèi)部審計(jì)、SLA 保障、歸因分析、理解和查找數(shù)據(jù)、自動(dòng)化推薦等操作。

　　隨著內(nèi)部數(shù)據(jù)不斷膨脹，簡單的數(shù)據(jù)血緣圖譜已經(jīng)無法滿足萬級(jí)表血緣的關(guān)系展示。一些突出的問題包括看不清單個(gè)表的直接上下游，看不清數(shù)據(jù)鏈路，整體情況等等。因此需要重構(gòu)一種更清晰、靈活、便利的方式。下圖簡單展示了優(yōu)化后的使用效果。

　　在新版血緣圖譜中，我們可以直接清晰的看到每個(gè)表的多層上下游依賴關(guān)系，甚至可以直接看到一些特殊場(chǎng)景下用戶關(guān)注的表屬性，通過點(diǎn)擊節(jié)點(diǎn)高亮查看數(shù)據(jù)鏈路，更可以看清每層的統(tǒng)計(jì)信息。在下文中我們將詳細(xì)拆解優(yōu)化的全過程。

　　需求發(fā)現(xiàn)

　　要做出一個(gè)能滿足用戶需求的圖產(chǎn)品，首先是要清楚用戶想從圖中獲取什么信息，從而有針對(duì)性的將這些信息展示出來。從血緣圖譜的背景本身可以推斷出用戶希望在圖譜中查看表之間的關(guān)系，查看關(guān)系鏈路，而更多的使用場(chǎng)景待發(fā)掘。因此我們對(duì)內(nèi)部重度用戶進(jìn)行了訪談，整理得出了以下不同用戶角色使用數(shù)據(jù)血緣圖譜的用戶場(chǎng)景。

　　結(jié)合訪談結(jié)果和用戶的日常反饋，數(shù)據(jù)血緣圖譜的場(chǎng)景按目前用戶的使用頻率從大到小排序依次為：

　　抽象出幾個(gè)主要需求即為：

　　表血緣關(guān)系查看：能從圖中清楚的瀏覽用戶關(guān)注的表的上下游血緣關(guān)系，最好還能便捷的查看一些場(chǎng)景相關(guān)的表屬性。

　　表血緣鏈路查看：能清晰的查看到某個(gè)上游/下游表到用戶關(guān)注表的鏈路情況。

　　按關(guān)鍵指標(biāo)分組查看：例如當(dāng)表數(shù)據(jù)發(fā)生變更時(shí)，分組查看所有下游表的負(fù)責(zé)人以便通知變更。

　　篩選關(guān)鍵信息查看：例如用戶找數(shù)據(jù)指標(biāo)的時(shí)候，僅看相關(guān)的報(bào)表更高效。

　　問題分析

　　其實(shí)上述需求舊版血緣圖譜都有一定程度上的滿足，我們需要去找出舊版血緣圖譜提供的功能為什么不滿足用戶需求，有哪些問題需要在新版中注意避免。

　　概覽：在數(shù)據(jù)量較小的情況下可用，在數(shù)據(jù)量大的時(shí)候完全不可用�？床磺迕繉佑卸嗌賯�(gè)節(jié)點(diǎn)，層級(jí)關(guān)系是怎么樣的，且鏈路查看困難。

　　節(jié)點(diǎn)較少，比較清晰

　　大量節(jié)點(diǎn)，查看困難

　　舊版血緣圖譜中功能細(xì)節(jié)粗糙：

　　用戶無法直觀的區(qū)分節(jié)點(diǎn)：舊版節(jié)點(diǎn)上顯示了表類型、庫名、表名。因此表名只能顯示幾個(gè)字符，不具備辨識(shí)度。

　　無法知曉表到表之間的任務(wù)：舊版血緣圖譜僅在側(cè)邊欄列出了與當(dāng)前表相關(guān)的任務(wù)有哪些并未列出加工邏輯的對(duì)應(yīng)關(guān)系，歸因分析困難。

　　分組結(jié)構(gòu)不清晰：舊版是在原圖中框出節(jié)點(diǎn)來展示分組的。一方面是空間利用率更低，另一方面是看節(jié)點(diǎn)時(shí)難定位到所屬分組，看分組時(shí)則無法看清包含的節(jié)點(diǎn)。

　　篩選功能不直觀：符合篩選條件的節(jié)點(diǎn)高亮展示，而被篩掉的表仍在圖中，無法有效提升用戶瀏覽效率。

　　方案設(shè)計(jì)

　　用戶在使用過程中看重的是查看關(guān)系的效率和屬性的完備度，因此在設(shè)計(jì)優(yōu)化方案時(shí)會(huì)盡量從這兩點(diǎn)出發(fā)去考慮。

　　首先是表數(shù)據(jù)查看的效率問題�？床磺灞砻�，無法區(qū)分相同前綴的表是用戶痛點(diǎn)之一。首先我們統(tǒng)計(jì)了現(xiàn)有表的平均字符數(shù)是 47 位，于是調(diào)寬了節(jié)點(diǎn)讓用戶能更直觀的區(qū)分表名。用數(shù)據(jù)地圖平臺(tái)中通用的類型圖表來代替色塊圖例，讓數(shù)據(jù)類型一目了然。

　　其次對(duì)于數(shù)據(jù)量大時(shí)看不清數(shù)據(jù)關(guān)系的問題，我們需要一個(gè)更緊湊清晰的數(shù)據(jù)呈現(xiàn)方式。通過需求分析和用戶調(diào)研，我們了解到用戶關(guān)心的是節(jié)點(diǎn)所在層級(jí)和節(jié)點(diǎn)之間的聯(lián)系。對(duì)于同一層級(jí)節(jié)點(diǎn)的先后順序，次層級(jí)節(jié)點(diǎn)之間的關(guān)系不是很看重。

　　說到緊湊的布局方式，自然而然我們就想到了列表。如果能用一個(gè)列表來承載層級(jí)血緣的節(jié)點(diǎn)，用連線來連接不同層級(jí)的節(jié)點(diǎn)，那么久可以表達(dá)節(jié)點(diǎn)之間的血緣關(guān)系了。當(dāng)節(jié)點(diǎn)較多超出一屏?xí)r可以拖動(dòng)此列滾動(dòng)條來查看更多節(jié)點(diǎn)，連線隨之刷新位置。當(dāng)層級(jí)不滿一屏?xí)r整體居中展示，層級(jí)過多超過一屏?xí)r可以左右滑動(dòng)查看。這樣在保留層級(jí)結(jié)構(gòu)信息的同時(shí)最大程度的利用了可視區(qū)域，展示出了盡可能多的數(shù)據(jù)。

　　新版血緣圖譜支持了點(diǎn)擊任意節(jié)點(diǎn)則高亮該節(jié)點(diǎn)到主節(jié)點(diǎn)的鏈路功能。配合列滾動(dòng)和連線刷新，不管數(shù)據(jù)量多大總能看清一整條數(shù)據(jù)鏈路。

　　我們還在每列列表頂部增加了層級(jí)信息和節(jié)點(diǎn)統(tǒng)計(jì)，讓用戶能同時(shí)查看每個(gè)節(jié)點(diǎn)細(xì)節(jié)和節(jié)點(diǎn)的整體分布。最終實(shí)現(xiàn)效果如下圖：

　　當(dāng)用戶想去找數(shù)，理解數(shù)或做歸因分析時(shí)，不僅要了解一個(gè)表的上游依賴，更需要理解表的加工邏輯。因此我們?cè)诠?jié)點(diǎn)的連線上新增了任務(wù)信息。當(dāng)用戶 hover 到連線上后，連線會(huì)加粗高亮并彈出任務(wù)信息。我們還附上了大數(shù)據(jù)開發(fā)平臺(tái)的對(duì)應(yīng)任務(wù)鏈接，點(diǎn)擊鏈接即可跳轉(zhuǎn)到新頁面查看任務(wù)邏輯詳情。

　　在設(shè)計(jì)分組功能時(shí)，采用了每列獨(dú)立分組的方式。一般認(rèn)為用戶會(huì)關(guān)注有對(duì)應(yīng)分組數(shù)據(jù)的節(jié)點(diǎn)，因此總將有分組的數(shù)據(jù)放在上面，無分組數(shù)據(jù)的置底，這樣排序能提升用戶的瀏覽效率。

　　舊版血緣圖譜的篩選功能是在前端處理的，由于一些性能限制導(dǎo)致篩選后只能顯示部分?jǐn)?shù)據(jù)，用戶無法得知符合條件的節(jié)點(diǎn)是否已經(jīng)全部展示。新版血緣圖譜針對(duì)這個(gè)用戶痛點(diǎn)，將前端篩選改為了服務(wù)端篩選，盡量展示全符合要求的數(shù)據(jù)。每個(gè)層級(jí)的頂欄對(duì)應(yīng)更新為篩選后的統(tǒng)計(jì)信息。同時(shí)更新連線，如果篩選后節(jié)點(diǎn)之間是有關(guān)聯(lián)的，也會(huì)展示關(guān)聯(lián)關(guān)系和高亮關(guān)系鏈路。

　　不同職能的用戶在不同場(chǎng)景下使用血緣圖譜時(shí)關(guān)注的節(jié)點(diǎn)屬性并不相同，如果血緣圖譜可以直接在圖上顯示用戶當(dāng)前想關(guān)注的表屬性就能幫助用戶更高效的解決問題。于是我們?cè)谘�緣圖譜上設(shè)計(jì)了屬性展示功能，用戶可以勾選自己感興趣的屬性直接顯示到圖中。比如下圖中展示了每個(gè)節(jié)點(diǎn)表熱度和生命周期兩個(gè)屬性。

　　技術(shù)實(shí)現(xiàn)

　　技術(shù)選型

　　在編碼實(shí)現(xiàn)之前，我們需要進(jìn)行技術(shù)選型。好的選型往往能讓編碼事半功倍。在做技術(shù)選型時(shí)，我們會(huì)主要考慮實(shí)現(xiàn)復(fù)雜度、研發(fā)周期、可擴(kuò)展性三個(gè)角度。分析整個(gè)血緣圖譜的需求：

　　Canvas 實(shí)現(xiàn)滾動(dòng)條，節(jié)點(diǎn)文字標(biāo)簽混排很復(fù)雜，要達(dá)到 HTML 的美觀度需要大量調(diào)試，后續(xù)迭代要新增屬性標(biāo)簽，進(jìn)行流式布局會(huì)很頭痛。開放組件給別的產(chǎn)品復(fù)用也有很大的定制成本。而這些問題使用 React 框架渲染就可以輕松解決。

　　如果用 DOM 實(shí)現(xiàn)不但很難實(shí)現(xiàn)箭頭，在連線高亮?xí)r也很難靈活處理層疊關(guān)系。在大數(shù)據(jù)量下連線很多，還容易出現(xiàn)性能問題。而這是 Canvas 的優(yōu)勢(shì)。

　　于是我們結(jié)合兩者之長，選用了 React + Canvas 的混合模式來實(shí)現(xiàn)血緣圖譜。Canvas 居于底部，僅負(fù)責(zé)畫連線。React 在上層負(fù)責(zé)渲染節(jié)點(diǎn)響應(yīng) hover 等交互。DOM 層疊關(guān)系如下：

　　整個(gè)血緣圖譜的初始化流程如下：

　　數(shù)據(jù)預(yù)處理：服務(wù)端給到點(diǎn)邊結(jié)構(gòu)的數(shù)據(jù)。由于兩個(gè)節(jié)點(diǎn)之間可能存在多個(gè)任務(wù)，對(duì)應(yīng)會(huì)有多條連線記錄。而血緣圖譜中相同兩個(gè)節(jié)點(diǎn)之間僅一條連線，對(duì)應(yīng)多個(gè)任務(wù)。先做連線的合并處理。

　　計(jì)算節(jié)點(diǎn)層級(jí)：服務(wù)端會(huì)給到點(diǎn)邊結(jié)構(gòu)的數(shù)據(jù)，根據(jù)主節(jié)點(diǎn)的連線關(guān)系向來源和去向兩個(gè)方向做廣度遍歷來確定每個(gè)節(jié)點(diǎn)的層級(jí)。

　　數(shù)據(jù)分組：按分組條件對(duì)每列數(shù)據(jù)進(jìn)行分組計(jì)算。

　　節(jié)點(diǎn)布局：根據(jù)層級(jí)和分組情況布局節(jié)點(diǎn)，相對(duì)應(yīng)的每個(gè)節(jié)點(diǎn)有 { x, y, width, height 屬性以確定每個(gè)節(jié)點(diǎn)的定位。

　　初始化畫布：畫布用于繪制連線，響應(yīng)連線的交互。采用內(nèi)部自研的圖形渲染引擎實(shí)現(xiàn)。

　　渲染節(jié)點(diǎn)：根據(jù)節(jié)點(diǎn)的位置和分組情況用 React 渲染出每一列節(jié)點(diǎn) DOM。

　　渲染畫布：根據(jù)前景的列和節(jié)點(diǎn)位置調(diào)整畫布，繪制連線。在渲染連線時(shí)分兩個(gè)圖層：默認(rèn)狀態(tài)連線在底層;高亮鏈路和高亮連線狀態(tài)下的連線在上層。這樣做的好處是高亮的連線永遠(yuǎn)在默認(rèn)狀態(tài)的上方，不用特殊處理圖形的層疊關(guān)系。

　　實(shí)現(xiàn)細(xì)節(jié)

　　用這種混合模式的一個(gè)挑戰(zhàn)就是 Canvas 和 DOM 的刷新率和同步率。在血緣圖譜中滾動(dòng)橫向滾動(dòng)條和每一列的縱向滾動(dòng)條時(shí) Canvas 要進(jìn)行及時(shí)的刷新以保證連線和節(jié)點(diǎn)的相對(duì)位置一定。

　　當(dāng)圖譜橫向滾動(dòng)時(shí)，每條連線的斜率不變，只是端點(diǎn)左右平移了。我們可以通過更新繪圖矩陣來加速這種情況下的更新，不需要去重計(jì)算每條連線的位置。具體做法是監(jiān)聽容器的滾動(dòng)事件，根據(jù)容器的 scrollLeft 屬性來更新繪圖矩陣后重繪。

　　當(dāng)圖譜縱向滾動(dòng)時(shí)，與當(dāng)前滾動(dòng)的列中節(jié)點(diǎn)相連的連線斜率和端點(diǎn)都有變化，而與滾動(dòng)列不直接相連的連線無需更新。我們僅重計(jì)算并更新與當(dāng)前列連接的線條位置。

　　另一個(gè)挑戰(zhàn)是 DOM 節(jié)點(diǎn)在大數(shù)據(jù)量下的性能問題。通常情況下我們認(rèn)為 Canvas 在大數(shù)據(jù)量渲染有更好的性能，而萬級(jí)的 DOM 節(jié)點(diǎn)就會(huì)讓用戶在使用中感受到卡頓了。這時(shí)候我們想到了按需渲染。 用戶在圖譜可視區(qū)域中一屏能看到的節(jié)點(diǎn)數(shù)量是有限的，高度為 1120 的容器中，一列僅存在至多 30 個(gè)節(jié)點(diǎn)。如果僅渲染可見的節(jié)點(diǎn)，則能保證使用 過程的流暢。具體做法是在節(jié)點(diǎn)布局時(shí)增加以下步驟：

　　根據(jù)視口的位置(主要是圖容器的橫向滾動(dòng)距離 scrollLeft )和每一列的滾動(dòng)距離(主要是每一列容器的縱向滾動(dòng)距離 scrollTop )計(jì)算目前的可視范圍。

　　計(jì)算節(jié)點(diǎn)坐標(biāo)時(shí)判斷是否在可視范圍的上半屏和下半屏內(nèi)，如果在此范圍內(nèi)則打標(biāo)。多顯示一屏的節(jié)點(diǎn)是希望在用戶上下滾動(dòng)瀏覽節(jié)點(diǎn)時(shí)不會(huì)出現(xiàn)空白區(qū)域閃一下等體驗(yàn)不佳的問題。

　　計(jì)算出每一列的真實(shí)長度。

　　在 React 渲染時(shí)更新每列容器的長度，將節(jié)點(diǎn)根據(jù)坐標(biāo)絕對(duì)定位到正確的位 置上。看起來就跟全量渲染的效果一致，渲染效率大幅提升。

　　然而問題并不止于此。在進(jìn)行大數(shù)據(jù)量的縱向滾動(dòng)時(shí)，會(huì)發(fā)現(xiàn)幀率很低，交 互還是不流暢。分析得知是由于列表滾動(dòng)時(shí)會(huì)在短時(shí)間內(nèi)進(jìn)行大量線條重計(jì)算和渲染。于是還要在 Canvas 繪制上進(jìn)行優(yōu)化。

　　我們從上圖可以看到在單層節(jié)點(diǎn)很多的情況下，主節(jié)點(diǎn)與不可見節(jié)點(diǎn)的連線可見，但是沒有任何價(jià)值，只是加重了用戶對(duì)當(dāng)前節(jié)點(diǎn)連線查看的負(fù)擔(dān)。因此我們對(duì)線條也進(jìn)行了渲染優(yōu)化，僅當(dāng)一條連線兩端的節(jié)點(diǎn)都在可見范圍中時(shí)才渲染連線，在連線的 Tooltip 上增加了來源去向的展示輔助查看。至此我們做到了在復(fù)雜情況下的流暢展示血緣數(shù)據(jù)。

　　總結(jié)

　　以上就是數(shù)據(jù)血緣圖譜的整個(gè)優(yōu)化過程。在這個(gè)過程中，我總結(jié)起來就是在了解用戶訴求的前提下，克制地表達(dá)關(guān)系圖中的信息，在合適的場(chǎng)景下突出核心的內(nèi)容。做圖分析產(chǎn)品時(shí)不需要拘泥于某種形式，而是真正的從用戶需求出發(fā)，為用戶服務(wù)。