Nebula Graph在大規模數據量級下的實踐和定制化開發是怎么樣的

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

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

背景

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

面臨大數據量挑戰的互聯網公司，普遍走向了自研之路，為了貼合業務需求，僅支持有限的查詢語義。國內主流互聯網公司如何解決圖數據庫的挑戰呢：

• 螞蟻金服：

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

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

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

• 螞蟻森林：萬億級的圖存儲能力，低延時強一致關系數據查詢更新。

• GNN：用于小時級 GNN 訓練。嘗試動態圖 GNN 在線推理。

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

• 
   ByteGraph 通過在 kv 上增加統一 cache 層，關系數據拆分為 B+ 樹以應對高效的邊訪問和采樣，類似 Facebook 的 TAO [6]。

• …

架構圖

實踐

從哪里開始呢？

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

• 數據集分片，每條邊獨立存儲，超大規模數據集存儲潛力。

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

• 創始團隊有豐富的圖數據庫經驗，大數據集合下模型抽象思路經過驗證。

實踐中的問題

內存爆炸

本質上這是一個性能 VS 資源的問題，數據規模龐大的應用中，內存占用是一個不容忽視的問題。RocksDB 內存由三部分構成：block cache、index 和 bloom filter、iter pined block。

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

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

多版本控制

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

• 周期性數據：比如，按天計算相似用戶列表，導入后數據生效。

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

如下是數據在 rocksdb 的存儲模型：

vertex 存儲格式

edge 存儲格式

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

通過這樣的方式，業務代碼可以無感更新數據版本，并做到了秒級回滾。

舉例：

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

  alter edge friend reserve_versions = 1 2 3 active_version = 1

• 數據源為歷史數據+實時導入數據。

  alter edge friend max_version = 1592147484

快速批量導入

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

整個過程導入速度快，約數個小時內完成全部過程。計算過程主要離線完成，對圖數據庫請求影響小。

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