Nebula Graph在大規(guī)模數(shù)據(jù)量級下的實踐和定制化開發(fā)是怎么樣的

這篇文章將為大家詳細講解有關(guān)Nebula Graph在大規(guī)模數(shù)據(jù)量級下的實踐和定制化開發(fā)是怎么樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

圖數(shù)據(jù)在社交推薦、多跳實時計算、風控和安全等領(lǐng)域有可期待的前景。如何用圖數(shù)據(jù)庫高效存儲和查詢大規(guī)模異構(gòu)圖數(shù)據(jù)，是一個重大挑戰(zhàn)。本文描述了開源分布式圖數(shù)據(jù)庫 Nebula Graph 實踐中遇到的問題，并通過深度定制，實現(xiàn)：大數(shù)據(jù)集存儲、小時級全量導(dǎo)入、多版本控制、秒級回滾、毫秒級訪問等特性。

背景

為大眾所熟知的圖數(shù)據(jù)庫大多在大數(shù)據(jù)集合上束手無策，如：Neo4j 的社區(qū)版本，采用 Cypher語言，由單機單副本提供服務(wù)，廣泛應(yīng)用于圖譜領(lǐng)域?；ヂ?lián)網(wǎng)公司只能在小數(shù)據(jù)集合下使用，還要解決 Neo4j 多副本一致性容災(zāi)的問題。 JanusGraph 雖然通過外置元數(shù)據(jù)管理、kv 存儲和索引的方式解決了大數(shù)據(jù)集合存儲問題，但其存在廣為詬病的性能問題。我們看到大部分圖數(shù)據(jù)庫在對比性能時都會提到和 JanusGraph 相比有幾十倍以上的性能提升。

面臨大數(shù)據(jù)量挑戰(zhàn)的互聯(lián)網(wǎng)公司，普遍走向了自研之路，為了貼合業(yè)務(wù)需求，僅支持有限的查詢語義。國內(nèi)主流互聯(lián)網(wǎng)公司如何解決圖數(shù)據(jù)庫的挑戰(zhàn)呢：

• 螞蟻金服：

  金融級圖數(shù)據(jù)庫，通過自定義類語言為業(yè)務(wù)方提供服務(wù)，全量計算下推，提供毫秒級延時。主要應(yīng)用于以下場景：

• 金融風控場景：萬億級邊資金網(wǎng)絡(luò)，存儲實時交易信息，實時欺詐檢測。

• 推薦場景：股票證券推薦。

• 螞蟻森林：萬億級的圖存儲能力，低延時強一致關(guān)系數(shù)據(jù)查詢更新。

• GNN：用于小時級 GNN 訓(xùn)練。嘗試動態(tài)圖 GNN 在線推理。

• 
   iGraph 是圖索引及查詢系統(tǒng)，存儲用戶的行為信息，是阿里數(shù)據(jù)中臺四駕馬車之一。通過 Gremlin 語言為業(yè)務(wù)方提供電商圖譜實時查詢。

• 
   ByteGraph 通過在 kv 上增加統(tǒng)一 cache 層，關(guān)系數(shù)據(jù)拆分為 B+ 樹以應(yīng)對高效的邊訪問和采樣，類似 Facebook 的 TAO [6]。

• …

架構(gòu)圖

實踐

從哪里開始呢？

我們選擇從 Nebula Graph[4] 開始我們的圖數(shù)據(jù)庫之旅，其吸引我們的有以下幾點：

• 數(shù)據(jù)集分片，每條邊獨立存儲，超大規(guī)模數(shù)據(jù)集存儲潛力。

• 定制強一致存儲引擎，具有計算下推和 MMP 優(yōu)化的潛力。

• 創(chuàng)始團隊有豐富的圖數(shù)據(jù)庫經(jīng)驗，大數(shù)據(jù)集合下模型抽象思路經(jīng)過驗證。

實踐中的問題

內(nèi)存爆炸

本質(zhì)上這是一個性能 VS 資源的問題，數(shù)據(jù)規(guī)模龐大的應(yīng)用中，內(nèi)存占用是一個不容忽視的問題。RocksDB 內(nèi)存由三部分構(gòu)成：block cache、index 和 bloom filter、iter pined block。

• block cache 優(yōu)化：采用全局 LRU cache，控制機器上所有 rocksdb 實例的 cache 占用。

• bloom filter 優(yōu)化：一條邊被設(shè)計為一個 kv 存入到 rocksdb，如果全部 key 保存 bloom filter，每個 key 占用 10bit 空間，那么整個 filter 內(nèi)存占用遠超機器內(nèi)存。觀察到我們大部分的請求模式是獲取某一個點的邊列表，因此采用 prefix bloom filter；索引到點屬性這一層實際上即可以對大多數(shù)請求進行加速。經(jīng)過這個優(yōu)化，單機 filter 所占用內(nèi)存在 G 這個級別，大多數(shù)請求訪問速度并未明顯降低。

多版本控制

實踐中，圖數(shù)據(jù)需要進行快速回滾，定期全量導(dǎo)入，自動訪問最新版本數(shù)據(jù)。我們把數(shù)據(jù)源大致可以分為兩種類型：

• 周期性數(shù)據(jù)：比如，按天計算相似用戶列表，導(dǎo)入后數(shù)據(jù)生效。

• 歷史數(shù)據(jù)+實時數(shù)據(jù)：比如，歷史數(shù)據(jù)按天刷新，和實時寫入的數(shù)據(jù)進行合并成為全量數(shù)據(jù)。

如下是數(shù)據(jù)在 rocksdb 的存儲模型：

vertex 存儲格式

edge 存儲格式

其中實時寫入的數(shù)據(jù) version 記錄為時間戳。離線導(dǎo)入的數(shù)據(jù) version 需要自己指定。我們將該字段和離線導(dǎo)入模塊聯(lián)合使用，用三個配置項進行版本控制：reserve_versions（需要保留的版本列表）、active_version（用戶請求訪問到的版本號）、max_version（保留某個版本之后數(shù)據(jù)，把歷史數(shù)據(jù)和實時寫入數(shù)據(jù)進行合并）。這樣可以高效管理離線數(shù)據(jù)和在線數(shù)據(jù)，不再使用的數(shù)據(jù)在下一次 compaction 中被清除出磁盤。

通過這樣的方式，業(yè)務(wù)代碼可以無感更新數(shù)據(jù)版本，并做到了秒級回滾。

舉例：

• 保留 3 個版本，激活其中一個版本：

  alter edge friend reserve_versions = 1 2 3 active_version = 1

• 數(shù)據(jù)源為歷史數(shù)據(jù)+實時導(dǎo)入數(shù)據(jù)。

  alter edge friend max_version = 1592147484

快速批量導(dǎo)入

實踐中導(dǎo)入大量數(shù)據(jù)是常規(guī)操作，如果不經(jīng)任何優(yōu)化，將需要導(dǎo)入的數(shù)據(jù)轉(zhuǎn)為請求發(fā)給圖數(shù)據(jù)庫，不僅嚴重影響線上請求，而且大數(shù)據(jù)量導(dǎo)入耗時超過一天。對導(dǎo)入速度進行優(yōu)化迫在眉睫。業(yè)界解決這個問題一般采用 SST Ingest 方式[5]。我們也是采用類似方式，通過例行調(diào)度 spark 任務(wù)，離線生成磁盤文件。然后數(shù)據(jù)節(jié)點拉取自己所需要的數(shù)據(jù)，并 ingest 到數(shù)據(jù)庫中，之后進行版本切換控制請求訪問最新版本數(shù)據(jù)。

整個過程導(dǎo)入速度快，約數(shù)個小時內(nèi)完成全部過程。計算過程主要離線完成，對圖數(shù)據(jù)庫請求影響小。

關(guān)于Nebula Graph在大規(guī)模數(shù)據(jù)量級下的實踐和定制化開發(fā)是怎么樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。