> 本文首發於 **[Nebula Graph Community 公眾號](https://c1n.cn/mUzKD)**

![Nebula Graph 的視覺化實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-visualization-practice.jpg)

本文整理自 [#視覺化 on Live ? 主題直播](https://www.bilibili.com/video/BV1u3411P7Jx?spm_id_from=333.999.0.0)，在本期直播中 3 位視覺化嘉賓講述了他們眼中的視覺化，以及他們在視覺化專案實踐中踩過的那些“坑”。

* 盧曉龍：視覺化圖探索工具 Nebula Explorer 產品負責人，視覺化技術專家；
* 苗壯：視覺化圖探索工具 Nebula Explorer 核心開發，視覺化技術專家；
* 汪洋：視覺化監控運維工具 Nebula Dashboard 產品負責人，視覺化技術專家；

## 視覺化是什麼？

從個人理解來說的話，視覺化便是將我們平時看到的某些資料或者文字這些相對抽象的東西用合理的方式，比如：圖示或者圖表，進行二次展示，更方便使用者進行互動。簡單來說，網頁上常見的按鈕、圖示，比如輸入：[https://www.baidu.com/](https://www.baidu.com/) 之後標藍的“百度一下”按鈕，右下角的輔助功能圖示，都是一種簡單、基礎的視覺化展示。如果沒有這些小圖示，你可能需要呼叫終端執行某條命令才能方便地完成對應操作。而視覺化則能大大地降低操作成本以及更容易讓使用者理解對應操作。

上面的例子，我們講到的是 UI 視覺化。提到 UI，我們來讀取下十幾年前的記憶。大家知道早年間，電腦技術還不發達，大家看的都是命令列。而現在的話，為什麼計算機能飛入尋常百姓家呢？就是因為計算機或者說電腦有了介面，有了 UI，有了符合人直覺的東西。所以說，能提升效率的視覺東西就叫做視覺化。如果要給一個定義的話，視覺化大概有兩點：

1. 上段例子和 GUI，此類視覺化人人可見，但在我看來並非體現視覺化的最大亮點；

2. 設計，或者是美術，這是視覺化的靈魂。 因為有了這個東西，它會給視覺化賦予生命的意義。通俗來說，一個東西好不好用，往往不是你能把它做出來它就是好用的；但如果它的互動好、體驗好、視覺效果好，能符合人的直覺，挖掘出來一些資訊，這便算是一個好的視覺化。所以說，我認為視覺化還是要兩部分，一部分是物理意義上的，即第一部分說的渲染，第二部分的話就是它的設計體驗，這涉及了軟硬體。

其實，可以把視覺化這個概念分為廣義和狹義兩個維度來看。

廣義的視覺化，可以理解為把一個複雜的資訊透過一定的處理，讓這個資訊更簡單、直觀呈現在使用者眼前，讓使用者更方便地去接受一些資訊。這便屬於視覺化範疇，像 GUI，其實它就是一種視覺化，把底層的命令透過一種視覺化的方式抽象出來，讓使用者可以更方便的和機器做互動。

而狹義來說，也就是針對的場景的應用。比如說，伴隨著網際網路的發展，我們應對的資料量會越來越大，我們要把這些資料透過一定的方式呈現出來，呈現的效果越好，資料表達也就越好越能被理解。如何在當前硬體存在一定效能瓶頸的基礎上，更流暢地展示更多的資料，可能是當前視覺化的意義所在。這麼來看，視覺化在狹義的角度上來看，它可能就是圖表、Canvas 動畫，或是元宇宙興起的 VR 技術、瀏覽器渲染、3D 渲染，這些視覺化可研究的方向。

具體來說，因為 Nebula 是一款分散式圖資料庫，我們提到的視覺化更多的是資料視覺化。比如，Nebula Dashboard 是一款視覺化運維監控產品，在這塊的視覺化實踐不只是圖示、動畫，更多的是如何把複雜的運維資訊透過簡單的方式，讓使用者更容易地 Control 叢集。

![](https://docs-cdn.nebula-graph.com.cn/figures/intro-overview-2022-4-14_cn.gif)

## 視覺化技術

在不同的階段、不同的場景下，我們會選擇不同的視覺化技術以便更好地服務於產品和業務。

就視覺化技術來說，前端展示常見的視覺化渲染技術是 SVG、Canvas、CSS 和 WebGL，而用什麼東西去畫 SVG、Canvas 便是另外一個話題。像 Nebula 社群常提到的 D3，其實並非是一種視覺化技術，本質上它是一個視覺化演算法工具，可在網頁上使用也可在終端應用。而 D3 本身有些周邊工具去做簡單 SVG 封裝，這比較偏上層應用工具，比如像是圖表庫 ECharts 就是這類。

而 Nebula Dashboard 產品負責人汪洋表示常見視覺化渲染技術如上所述的 CSS 和 SVG 等等，會根據所面臨的應用場景、計算資源，針對性地定製化開發。比如：為了方便第三方接入，視覺化庫的設計人員會抽象語法、讓語法糖更加科學、規範；對效能要求高的場景，便會去封裝工具以便獲得高效能。這裡他提到了螞蟻開源的視覺化引擎：G2 [https://github.com/antvis/g2/](https://github.com/antvis/g2/)，G2 受啟發於《The Grammar of Graphics》一書的理念，設計這套基於圖形語法理論的視覺化底層引擎，G2 的這套語法實現也是業界比較公認給的科學規範。同其他視覺化庫相比，G2 在語法設計這塊更像是一個完整的產品。

談及 G2，視覺化圖探索工具 Nebula Explorer 核心開發苗壯表示雖然 G2 語法規範、科學，但是如果真的要做資料視覺化並非是一個十分順手的視覺化工具，因為它基於圖形語法理論，需要一定的專業知識，因此會有一定的門檻。更多時候，G2 可能還是作為一個視覺化圖表庫被使用而非視覺化庫。

### 視覺化的效能問題

![](https://docs-cdn.nebula-graph.com.cn/figures/visualization-22-04-06_cn.gif)

Nebula Explorer 是一款圖探索工具，單個頁面會面臨節點資料展示的問題。社群也常有使用者問及，單個畫布頁面能渲染多少個節點資料。針對視覺化效能問題，核心產品開發苗壯說到：視覺化效能並非是一個絕對效能，它往往伴隨著使用者體驗。而使用者體驗和效能某種程度是成反比的，效能越好那使用者的體驗並非越佳，呈現的資訊也會相對較少；而呈現更多的資料，則會消耗更多的硬體資源。這便是一項平衡問題。

而提高視覺化效能的方法有二：一種是提高硬體配置，之前很流行的梗——分散式併發不夠咋整？加臺機器，沒有什麼是加機器解決不了的。但加機器這種簡單粗暴的方法非良策，雖然解決了物理限制但是加入了成本問題，除了機器成本還有對應的系統維護成本。一臺機器，或者多臺機器加入之後必然會帶來系統的複雜度增加。此外，加機器並非是通用解決方法，有些使用者不一定能做到隨心所欲地新增機器。另外一種是最佳化演算法，相比加機器，方法二更難，本身目前演算法都很完善，再繼續最佳化也只是邊際遞減效應。

### Nebula 視覺化工具的最佳化實踐

Nebula Explorer 最佳化效能也是從上面兩個軟硬體方向來展開。硬體方面，不同使用者的硬體效能不一樣，Explorer 開發過程中會選用比較好的硬體來實現酷炫特效的呈現；而針對硬體效能較差的使用者，則提供高畫質和普通畫質兩個模式，自適應適配使用者硬體從而達到一個比較好的呈現效果。像 Explorer 的 3D 圖探索模式雖然看過去很酷炫，很“吃”計算資源的樣子，但是本身這個功能的硬體要求並非想象中高，任意一臺手機的 GPU 配置都能執行 Explorer 3D 模式，相對而言的 CPU 效能更決定使用者體驗。

其實，除了軟硬體上的效能最佳化，還有產品設計上的策略最佳化。像是一些比較難以解決的效能問題，可設法規避它。效能最佳化上，有個亙古不變的原則，這個原則就是要保證 1 秒鐘渲染 60 幀。即便在特殊場景下，無法保證一秒鐘 60 幀，做到 40 幀數以上也能保證系統的流暢度。這裡就像是 React 的最佳化實現，它將很多大任務拆解成多個小任務，等系統空閒了再塞進去小任務。還有一種思路，如果是程式碼層面解決不了的問題，可以修改相對應的互動方式。比如一個長耗時任務，在跑，這時候如果頁面不可點選，你會覺得很卡頓對吧？而，這時候加入一個 loading 動畫，便會大大地降低使用者的等待焦慮，會讓使用者覺得沒那麼卡頓。

這裡，講個親身經歷：Nebula Dashboard 剛上線視覺化大屏時，踩過的效能坑。視覺化大屏剛上線時，只是覺得是個簡單大屏可能不會涉及太大的效能問題。結果，一上線 CPU 瘋狂轉，當時就懵逼了：Nebula Dashboard 視覺化大屏只有 7、8 個圖表。雖然介面酷炫，但是其實整個網路請求也就只有十幾個，於是排除了 CPU 在請求計算耗資源過高的問題。此外，大屏上線時，並不存在很多併發情況…經過一輪的排查，最後定位是 SVG 過度消耗資源。所以我們調整了動畫實現方案：對 CPU 要求比較高的動畫，進行降級，減少渲染次數和渲染頻率。這就有點像是圖片壓縮，你丟一個 1 MB 的圖片到壓縮網站，壓縮完可能是 200 KB，這時候其實使用者肉眼是無法察覺。

### 視覺化技術選型

上面講到硬體和軟體能提升視覺化效能，但是技術選型選的好不好，也能左右你的系統系能。

在 Nebula Explorer v2.2 版本之前，由於技術選型和業務邏輯組織問題，一旦遇到上百個節點顯示問題，便會遭遇卡頓，動畫明顯不流暢。之後，便對 Nebula Explorer 進行重構，替換了當時的渲染引擎 G6。G6 是基於 G2 的一套圖視覺化引擎，可能由於 G6 過於專注業務場景，以及缺少高效能場景的驗證，在 Nebula Explorer 這邊表現差強人意。改用 Force Graph 之後，效能提升了差不多 10 倍左右。當然並非說 G6 的效能不行，而是 Nebula Explorer 自身的視覺化需求和 G6 並不 MATCH。

同 Nebula Explorer 相反，Nebula Dashboard 不存在成千上萬的點資料展示，而是數量相對固定的圖表展示以及對應的運維操作執行。監控圖表的話，目前來說市場比較認可的是 Grafana，而 Grafana 本身也是一款開源產品。於是，我們去研究了 Grafana 的實現，發現它底層用了輕量級的 uPlot https://github.com/leeoniya/uPlot。因為 uPlot 是個小於 40kb，特色是繪製時間序列圖，方便做定製化開發。而 Nebula Dashboard 除了監控之外，還有一個比較重要的功能是針對叢集的管理運維操作。這與 Grafana 專注於監控的設定是背離的，加上 Nebula Dashboard 選型的三個標準是：第一，易開發上手；第二，開源社群活躍；第三，基礎庫多可提升開發效率。最終，選用 G2 作為 Nebula Dashboard 的視覺化底層工具，以便提高開發效率。

## 視覺化產品設計

Nebula Explorer 有 2D 和 3D 兩種圖探索模式，當中涉及了頁面如何佈局的問題。在 Nebula Explorer 設計中，採用演算法來實現特定點群的聚合和雜湊；以及全圖鳥瞰模式在 3D 模式中進行展示，因為主流的電腦為 1920*1080，一個平面最多展示百萬個畫素點，然後這時候換個角度，我們採用 3D 模式所能呈現的資料便會比 2D 多。

## 視覺化小知識

### 關於渲染

VR、監控指標、多點展示，在計算底層渲染時渲染圖形的方式大多相同。舉個例子，有些計算機系統使用 OpenGL 技術渲染的 3D 圖形是由若干個三角形（triangle）拼接而成，而 Nebula Explorer 計算渲染方面也是如此，即，你看到的一個球形節點，其實是由若干個三角形構成併線性插值了不同的頂點顏色。除計算機的光柵化繪圖法之外，近幾年流行的光線追蹤渲染也是一門效果較好的渲染技術，該技術利用光線射出，反射，損耗的物理模擬方式，得到畫素點的最終顏色，在視覺上會更接近真實世界。

交流圖資料庫技術？加入 Nebula 交流群請先[填寫下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手會拉你進群~~

視覺化技術在 Nebula Graph 中的應用

相關文章