本文為 #nLive vol.001｜美團圖資料庫平臺建設及業務實踐# 主題演講的文字稿，可前往 觀看本次視訊

大家好，我是來自美團的趙登昌，今天我給大家分享下美團圖資料庫平臺的建設以及業務實踐。

這是本次報告的提綱，主要包括以下六方面內容。

背景介紹

首先介紹下美團在圖資料方面的業務需求。

美團內部有比較多的圖資料儲存以及多跳查詢需求，總體來說有以下 4 個方面：

第一個方面是知識圖譜方向，美團內部有美食圖譜、商品圖譜、旅遊圖譜在內的近 10 個領域知識圖譜，資料量級大概在千億級別。在迭代、挖掘資料的過程中，需要一種元件對這些圖譜資料進行統一管理。

第二個方面是安全風控。業務部門有內容風控的需求，希望在商戶、使用者、評論中通過多跳查詢來識別虛假評價；在支付時進行金融風控驗證，實時多跳查詢風險點。

第三個方面是鏈路分析，比如說：資料血緣管理，公司資料平臺上有很多 ETL Job，Job 和 Job 之間存在強弱依賴關係，這些強弱依賴關係形成了一張圖，在進行 ETL Job 的優化或者故障處理時，需要對這個圖進行分析。類似的需求還有程式碼分析、服務治理等。

第四個方面是組織架構管理，包括：公司組織架構的管理，實線彙報鏈、虛線彙報鏈、虛擬組織的管理，以及商家連鎖門店的管理。比如，需要管理一個商家在不同區域都有哪些門店，能夠進行多層關係查詢或者逆向關係搜尋。

總體來說，我們需要一種元件來管理千億級別的圖資料，解決圖資料儲存以及多跳查詢問題。

傳統的關係型資料庫、NoSQL 資料庫可以用來儲存圖資料，但是不能很好處理圖上多跳查詢這一高頻操作。Neo4j 公司在社交場景做了 MySQL 和 Neo4j 的多跳查詢效能對比，具體測試場景是，在一個 100 萬人、每個人大概有 50 個朋友的社交網路裡找最大深度為 5 的朋友的朋友。從測試結果看，查詢深度增大到 5 時， MySQL 已經查不出結果了，但 Neo4j 依然能在秒級返回資料。實驗結果表明多跳查詢中圖資料庫優勢明顯。

圖資料庫選型

下面介紹我們的圖資料庫選型工作。

我們主要有以下 5 個圖資料庫選型要求

• A. 專案開源，暫時不考慮需要付費的圖資料庫；
• B. 分散式的架構設計，具備良好的可擴充套件性；
• C. 毫秒級的多跳查詢延遲；
• D. 支援千億量級點邊儲存；
• E. 具備批量從數倉匯入資料的能力。

我們分析了 DB-Engine 上排名 Top30 的圖資料庫，剔除不開源的專案後，把剩下的圖資料庫分成三類。

• 第一類包括 Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。此類圖資料庫只有單機版本開源可用，效能比較優秀，但是不能應對分散式場景中資料的規模增長，即不滿足選型要求 B、D；
• 第二類包括 JanusGraph、HugeGraph。此類圖資料庫在現有儲存系統之上新增了通用的圖語義解釋層，圖語義層提供了圖遍歷的能力，但是受到儲存層或者架構限制，不支援完整的計算下推，多跳遍歷的效能較差，很難滿足 OLTP 場景下對低延時的要求，即不滿足選型要求 C；
• 第三類包括 Dgraph、Nebula Graph。此類圖資料庫根據圖資料的特點對資料儲存模型、點邊分佈、執行引擎進行了全新設計，對圖的多跳遍歷進行了深度優化，基本滿足我們對圖資料庫的選型要求

之後我們在一個公開社交資料集上（大約 200 億點邊）對 Nebula Graph 、Dgraph 、HugeGraph 進行了深度效能測評。主要從三個方面進行評測：

• 批量資料的匯入
• 實時寫入效能測試
• 資料多跳查詢效能測試

測試詳情見 Nebula 論壇：主流開源分散式圖資料庫Benchmark