本文作者系微信技術專家李本利
圖資料在社交推薦、多跳實時計算、風控和安全等領域有可期待的前景。如何用圖資料庫高效存儲和查詢大規模異構圖資料，是一個重大挑戰。本文描述了開源分布式圖資料庫
Nebula Graph實踐中遇到的問題，并通過深度定制，實作：大資料集存儲、小時級全量導入、多版本控制、秒級復原、毫秒級通路等特性。
背景
為大衆所熟知的圖資料庫大多在大資料集合上束手無策，如：Neo4j 的社群版本，采用 Cypher語言，由單機單副本提供服務，廣泛應用于圖譜領域。網際網路公司隻能在小資料集合下使用，還要解決
Neo4j多副本一緻性容災的問題。
JanusGraph雖然通過外置中繼資料管理、kv 存儲和索引的方式解決了大資料集合存儲問題，但其存在廣為诟病的性能問題。我們看到大部分圖資料庫在對比性能時都會提到和 JanusGraph 相比有幾十倍以上的性能提升。
面臨大資料量挑戰的網際網路公司，普遍走向了自研之路，為了貼合業務需求，僅支援有限的查詢語義。國内主流網際網路公司如何解決圖資料庫的挑戰呢：
- 螞蟻金服： GeaBase
[1]
金融級圖資料庫，通過自定義類語言為業務方提供服務，全量計算下推，提供毫秒級延時。主要應用于以下場景：
- 金融風控場景：萬億級邊資金網絡，存儲實時交易資訊，實時欺詐檢測。
- 推薦場景：股票證券推薦。
- 螞蟻森林：萬億級的圖存儲能力，低延時強一緻關系資料查詢更新。
- GNN：用于小時級 GNN 訓練。嘗試動态圖 GNN 線上推理。[7]
-
阿裡巴巴：iGraph[2]
iGraph 是圖索引及查詢系統，存儲使用者的行為資訊，是阿裡資料中台四駕馬車之一。通過 Gremlin 語言為業務方提供電商圖譜實時查詢。
-
今日頭條：ByteGraph[3]
ByteGraph 通過在 kv 上增加統一 cache 層，關系資料拆分為 B+ 樹以應對高效的邊通路和采樣，類似 Facebook 的 TAO [6]。
- ...
架構圖
實踐
從哪裡開始呢？
我們選擇從
[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 到資料庫中，之後進行版本切換控制請求通路最新版本資料。
整個過程導入速度快，約數個小時内完成全部過程。計算過程主要離線完成，對圖資料庫請求影響小。
shared nothing
這是近年來老生常談的并發加速方式，然而要落地還是考驗工程師的程式設計功底。meta cache 通路頻繁，并用 shared_ptr 進行封裝，也就成為了原子操作碰撞的高發地。為了能夠實作真正的 shared nothing，我們将每一份 meta cache 拷貝為 thread local，具體解決方案請參考該
pull request[8]
小結
圖資料庫路阻且長，且行且珍惜。如果對于本文有什麼疑問，可以在 GitHub[9] 上找找。
參考文獻
- Fu, Zhisong, Zhengwei Wu, Houyi Li, Yize Li, Min Wu, Xiaojie Chen, Xiaomeng Ye, Benquan Yu, and Xi Hu. "GeaBase: a high-performance distributed graph database for industry-scale applications." International Journal of High Performance Computing and Networking 15, no. 1-2 (2019): 12-21.
- https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247489027&idx=3&sn=c149ce488cfc5231d4273d6da9dc8679&chksm=fbb29ffdccc516ebb8313b9202cfd78ea199da211c55b0a456a9e632a33e7d5b838d8da8bc6a&mpshare=1&scene=1&srcid=0614MWpeEsBc1RaBrl4htn3D&sharer_sharetime=1592106638907&sharer_shareid=a2497c4756f8bac1bcbef9edf86a86ac&rd2werd=1#wechat_redirect
- https://zhuanlan.zhihu.com/p/109401046
- https://github.com/vesoft-inc/nebula
- https://www.infoq.cn/article/SPYkxplsq7f36L1QZIY7
- Bronson, Nathan, Zach Amsden, George Cabrera, Prasad Chakka, Peter Dimov, Hui Ding, Jack Ferris et al. "{TAO}: Facebook’s distributed data store for the social graph." In Presented as part of the 2013 {USENIX} Annual Technical Conference ({USENIX}{ATC} 13), pp. 49-60. 2013.
- http://blog.itpub.net/69904796/viewspace-2653498/
- https://github.com/vesoft-inc/nebula/pull/2165
- https://github.com/xuguruogu/nebula
- 騰訊高性能分布式圖計算架構柏拉圖 https://github.com/Tencent/plato
🤩 加入 Nebula Graph 交流群，請聯系 Nebula Graph 官方小助手微信号：
NebulaGraphbot