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

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

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

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

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

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

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

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

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

抽象出幾個主要需求即為：

1. 表血緣關系查看：能從圖中清楚的瀏覽用戶關注的表的上下游血緣關系，最好還能便捷的查看一些場景相關的表屬性。
2. 表血緣鏈路查看：能清晰的查看到某個上游/下游表到用戶關注表的鏈路情況。
3. 按關鍵指標分組查看：例如當表數(shù)據(jù)發(fā)生變更時，分組查看所有下游表的負責人以便通知變更。
4. 篩選關鍵信息查看：例如用戶找數(shù)據(jù)指標的時候，僅看相關的報表更高效。

問題分析

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

• 概覽：在數(shù)據(jù)量較小的情況下可用，在數(shù)據(jù)量大的時候完全不可用。看不清每層有多少個節(jié)點，層級關系是怎么樣的，且鏈路查看困難。

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

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

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

• 用戶無法直觀的區(qū)分節(jié)點：舊版節(jié)點上顯示了表類型、庫名、表名。因此表名只能顯示幾個字符，不具備辨識度。
• 無法知曉表到表之間的任務：舊版血緣圖譜僅在側(cè)邊欄列出了與當前表相關的任務有哪些并未列出加工邏輯的對應關系，歸因分析困難。
• 分組結構不清晰：舊版是在原圖中框出節(jié)點來展示分組的。一方面是空間利用率更低，另一方面是看節(jié)點時難定位到所屬分組，看分組時則無法看清包含的節(jié)點。
• 篩選功能不直觀：符合篩選條件的節(jié)點高亮展示，而被篩掉的表仍在圖中，無法有效提升用戶瀏覽效率。

方案設計

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

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

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

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

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

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

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

在設計分組功能時，采用了每列獨立分組的方式。一般認為用戶會關注有對應分組數(shù)據(jù)的節(jié)點，因此總將有分組的數(shù)據(jù)放在上面，無分組數(shù)據(jù)的置底，這樣排序能提升用戶的瀏覽效率。

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

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

技術實現(xiàn)

技術選型

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

1. Canvas 實現(xiàn)滾動條，節(jié)點文字標簽混排很復雜，要達到 HTML 的美觀度需要大量調(diào)試，后續(xù)迭代要新增屬性標簽，進行流式布局會很頭痛。開放組件給別的產(chǎn)品復用也有很大的定制成本。而這些問題使用 React 框架渲染就可以輕松解決。
2. 如果用 DOM 實現(xiàn)不但很難實現(xiàn)箭頭，在連線高亮時也很難靈活處理層疊關系。在大數(shù)據(jù)量下連線很多，還容易出現(xiàn)性能問題。而這是 Canvas 的優(yōu)勢。

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

整個血緣圖譜的初始化流程如下：

• 數(shù)據(jù)預處理：服務端給到點邊結構的數(shù)據(jù)。由于兩個節(jié)點之間可能存在多個任務，對應會有多條連線記錄。而血緣圖譜中相同兩個節(jié)點之間僅一條連線，對應多個任務。先做連線的合并處理。
• 計算節(jié)點層級：服務端會給到點邊結構的數(shù)據(jù)，根據(jù)主節(jié)點的連線關系向來源和去向兩個方向做廣度遍歷來確定每個節(jié)點的層級。
• 數(shù)據(jù)分組：按分組條件對每列數(shù)據(jù)進行分組計算。
• 節(jié)點布局：根據(jù)層級和分組情況布局節(jié)點，相對應的每個節(jié)點有 { x, y, width, height 屬性以確定每個節(jié)點的定位。
• 初始化畫布：畫布用于繪制連線，響應連線的交互。采用內(nèi)部自研的圖形渲染引擎實現(xiàn)。
• 渲染節(jié)點：根據(jù)節(jié)點的位置和分組情況用 React 渲染出每一列節(jié)點 DOM。
• 渲染畫布：根據(jù)前景的列和節(jié)點位置調(diào)整畫布，繪制連線。在渲染連線時分兩個圖層：默認狀態(tài)連線在底層；高亮鏈路和高亮連線狀態(tài)下的連線在上層。這樣做的好處是高亮的連線永遠在默認狀態(tài)的上方，不用特殊處理圖形的層疊關系。

實現(xiàn)細節(jié)

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

• 當圖譜橫向滾動時，每條連線的斜率不變，只是端點左右平移了。我們可以通過更新繪圖矩陣來加速這種情況下的更新，不需要去重計算每條連線的位置。具體做法是監(jiān)聽容器的滾動事件，根據(jù)容器的 scrollLeft 屬性來更新繪圖矩陣后重繪。
• 當圖譜縱向滾動時，與當前滾動的列中節(jié)點相連的連線斜率和端點都有變化，而與滾動列不直接相連的連線無需更新。我們僅重計算并更新與當前列連接的線條位置。

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

• 根據(jù)視口的位置（主要是圖容器的橫向滾動距離 scrollLeft ）和每一列的滾動距離（主要是每一列容器的縱向滾動距離 scrollTop ）計算目前的可視范圍。
• 計算節(jié)點坐標時判斷是否在可視范圍的上半屏和下半屏內(nèi)，如果在此范圍內(nèi)則打標。多顯示一屏的節(jié)點是希望在用戶上下滾動瀏覽節(jié)點時不會出現(xiàn)空白區(qū)域閃一下等體驗不佳的問題。
• 計算出每一列的真實長度。

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

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

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

總結

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