圖資料庫 Nebula Graph 在 Boss 直聘的應用

nebulagraph發表於2020-12-23

BOSS 直聘圖資料庫實踐

本文首發於 Nebula Graph 官方部落格:https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/

摘要:在本文中,BOSS 直聘大資料開發工程師主要分享一些他們內部的技術指標和選型,以及很多小夥伴感興趣的 Dgraph 對比使用經驗。

業務背景

在 Boss 直聘的安全風控技術中,需要用到大規模圖儲存和挖掘計算,之前主要基於自建的高可用 Neo4j 叢集來保障相關應用,而在實時行為分析方面,需要一個支援日增 10 億關係的圖資料庫,Neo4j 無法滿足應用需求。

針對這個場景,前期我們主要使用 Dgraph,踩過很多坑並和 Dgraph 團隊連線會議,在使用 Dgraph 半年後最終還是選擇了更貼合我們需求的 Nebula Graph。具體的對比 Benchmark 已經有很多團隊在論壇分享了,這裡就不再贅述,主要分享一些技術指標和選型,以及很多小夥伴感興趣的 Dgraph 對比使用經驗。

技術指標

硬體

配置如下:

  • 處理器:Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz 80(cores)
  • 記憶體:DDR4,128G
  • 儲存:1.8T SSD
  • 網路:萬兆

Nebula Graph 部署 5 個節點,按官方建議 3 個 metad / 5 個 graphd / 5 個 storaged

軟體

  • Nebula Graph 版本:V1.1.0
  • 作業系統:CentOS Linux release 7.3.1611 (Core)

配置

主要調整的配置和 storage 相關
# 按照文件建議,配置記憶體的 3 分之 1
--rocksdb_block_cache=40960

# 引數配置減小記憶體使用
--enable_partitioned_index_filter=true
--max_edge_returned_per_vertex=100000

指標

目前安全行為圖儲存 3 個月行為,近 500 億邊,10 分鐘聚合寫入一次,日均寫入點 3,000 萬,日均寫入邊 5.5 億,插入延時 <=20 ms。

BOSS 直聘圖資料庫實踐

BOSS 直聘圖資料庫實踐

BOSS 直聘圖資料庫實踐

讀延時 <= 100 ms,業務側介面讀延時 <= 200 ms,部分超大請求 < 1 s

BOSS 直聘圖資料庫實踐

BOSS 直聘圖資料庫實踐

當前磁碟空間佔用 600G * 5 左右

BOSS 直聘圖資料庫實踐

CPU 耗用 500% 左右,記憶體使用穩定在 60 G 左右

BOSS 直聘圖資料庫實踐

Dgraph 使用對比

目前來說原生分散式圖資料庫國內選型主要比對 Dgraph和 Nebula Graph,前者我們使用半年,整體使用對比如下,這些都是我們踩過坑的地方。

BOSS 直聘圖資料庫實踐

就我們使用經驗,Dgraph 設計理念很好,但是目前還不太滿足我們業務需求,GraphQL 的原生支援還是有很大吸引力,但是儲存結構決定容易 OOM(邊儲存也分組的話會優化很多,官方之前計劃優化);另外,採用自己編寫的 badger 和 ristretto,目前最大的問題是從官方釋放的使用案例來看,未經大規模資料場景驗證,在我們實際使用中,大資料量和高 QPS 寫入場景下容易出現崩潰和 OOM,且如果採用 SSD 儲存海量資料,Dgraph 的磁碟放大和記憶體佔用也需要優化。

如果沒有高 QPS 寫入,目前 Dgraph 還是值得一試,對於很多快速原型的場景,作為 GraphQL 原生圖資料庫使其非常適合做基於圖的資料中臺,這是目前的一個大趨勢,它也上線了自己的雲服務,業內標杆 TigerGraph 也在做相關探索,另外事務的完善支援也是它的優勢,這塊暫時用不到,所以沒做相關評測。實測 Dgraph 線上寫入併發不高或只是離線匯入資料使用的情況下還是很穩定的,如果想借助它的高可用和事務功能,可以嘗試下。

對比來說,Nebula Graph 很優秀,特別是工程化方面,體現在很多細節,可以看出開發團隊在實際使用和實現上做較了較好的平衡:

  • 1.支援手動控制資料平衡時機,自動固然很好,但是容易導致很多問題
  • 2.控制記憶體佔用(enable_partitioned_index_filter 優化和設定單次最大返回邊數目),都放在記憶體固然快,但有時候也需要考慮資料量和效能的平衡
  • 3.多圖物理隔離,多張圖實在太有必要
  • 4.nGQL 最大程度接近最常用 MySQL 語句,2 期相容 Cypher 更加完美;對比 GraphQL 固然香,但寫起復雜圖查詢真的讓人想爆炸,可能還是更加適合做資料中臺查詢語言
  • 5.和圖計算框架的結合,最近釋放的 Spark GraphX 結合演算法非常有用,原先我們的圖計算都是基於 GraphX 從 Neo4j 抽取後離線計算團伙,後續打算嘗試 Nebula Graph 抽取

這裡主要從實際經驗對比分享,二者都在持續優化,都在快速迭代,建議使用前多看看最新版本 release說明。

建議

當前 Nebula Graph 做得很優秀,結合我們現在的需求也提一點點建議:

  • 1.更多離線演算法,包括:現有的圖神經網路這塊的支援,圖線上查詢多用在分析,真正線上應用目前很多還是圖計算離線算完後入庫供查詢
  • 2.Plato 框架的合併支援,Spark GraphX 相對計算效率還是低一些,如果能整合騰訊的 Plato 框架更好
  • 3.借鑑 TigerGraph 和 Dgraph,支援固化 nGQL 查詢語句直接生成服務 REST 端點HTTP 傳入引數即可查詢,這樣可快速生成資料查詢介面,不用後臺再單獨連線資料庫寫 SQL 提供資料服務

目前 Boss 直聘將 Nebula Graph 圖資料庫應用在安全業務,相關應用已經線上穩定執行大半年,本文分享了一點經驗,拋磚引玉,期望更多技術夥伴來挖掘Nebula這座寶庫。

Dgraph 遇到的一些問題,供有需要小夥伴參考

  • 給 Dgraph 一些 issues
  • 給 Dgraph 提交的 PRs

參考文章

本文系 Boss直聘·安全技術中心 文洲 撰寫

推薦閱讀

相關文章