本文做者系微信技術專家李本利git
首發於 Nebula Graph 官方博客：https://nebula-graph.com.cn/posts/nebula-graph-for-social-networking/github
圖數據在社交推薦、多跳實時計算、風控和安全等領域有可期待的前景。如何用圖數據庫高效存儲和查詢大規模異構圖數據，是一個重大挑戰。本文描述了開源分佈式圖數據庫 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]。併發
-
...app
架構圖
實踐
從哪裏開始呢？
咱們選擇從 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 到數據庫中，以後進行版本切換控制請求訪問最新版本數據。
整個過程導入速度快，約數個小時內完成所有過程。計算過程主要離線完成，對圖數據庫請求影響小。
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