共計 2268 個字符，預(yù)計需要花費 6 分鐘才能閱讀完成。
行業(yè)資訊
數(shù)據(jù)庫
Nebula Graph 在大規(guī)模數(shù)據(jù)量級下的實踐和定制化開發(fā)是怎么樣的
這篇文章將為大家詳細講解有關(guān) Nebula Graph 在大規(guī)模數(shù)據(jù)量級下的實踐和定制化開發(fā)是怎么樣的，文章內(nèi)容質(zhì)量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
圖數(shù)據(jù)在社交推薦、多跳實時計算、風(fēng)控和安全等領(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)用于以下場景：
金融風(fē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)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
