美團圖數據庫平台建設及業務實踐

本文為 #nLive vol.001｜美團圖數據庫平台建設及業務實踐# 主題演講的文字稿，可前往 B站 觀看本次視頻

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

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

背景介紹

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

美團內部有比較多的圖數據存儲以及多跳查詢需求，總體來說有以下 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 🔗

從測試結果看 Nebula Graph 在數據導入、實時寫入及多跳查詢方面性能均優於競品。此外，Nebula Graph 社區活躍，問題的響應速度快，所以團隊最終選擇了基於 Nebula Graph 來搭建圖數據庫平台。

圖數據庫平台建設

下面介紹美團圖數據庫平台的建設，整個圖數據庫平台包括 4 層。

第一層是數據生產層，平台的圖數據主要有兩種來源，第一種是業務方把數倉中數據通過 ETL Job 轉成點和邊的 Hive 表，然后離線導入到圖數據庫中；第二種是業務線上實時產生的數據、或者通過 Spark、Flink 等流式處理產生的近線數據，實時地通過 Nebula Graph 提供的在線批量接口灌到圖數據庫中。

第二層是數據存儲層，平台支持兩種圖數據庫集群的部署方式。

• 第一種是 CP 方案，即 Consistency & Partition tolerance，這是 Nebula Graph 原生支持的集群部署方式。單集群部署，集群中機器數量大於等於副本的數量，副本數量大於等於 3 。只要集群中有大於副本數一半的機器存活，整個集群就可以對外正常提供服務。CP 方案保證了數據讀寫的強一致性，但這種部署方式下集群可用性不高。
• 第二種部署方式是 AP 方案，即 Availability & Partition tolerance，在一個應用中部署多個圖數據庫集群，每個集群數據副本數為 1 ，多集群之間進行互備。這種部署方式的好處在於整個應用對外的可用性高，但數據讀寫的一致性要差點。

第三層是數據應用層，業務方可以在業務服務中引入平台提供的圖譜 SDK，實時地對圖數據進行增刪改查。

第四層是支撐平台，提供了 Schema 管理、權限管理、數據質檢、數據增刪改查、集群擴縮容、圖譜畫像、圖數據導出、監控報警、圖可視化、集群包管理等功能。

經過這四層架構設計，目前圖數據庫平台基本具備了對圖數據的一站式自助管理功能。如果某個業務方要使用這種圖數據庫能力，那么業務方可以在這個平台上自助地創建圖數據庫集群、創建圖的 Schema、導入圖數據、配置導入數據的執行計划、引入平台提供的 SDK 對數據進行操作；平台側主要負責各業務方圖數據庫集群的穩定性。目前有三、四十個業務在平台上真正落地，基本能滿足各個業務方需求。

再介紹下圖數據庫平台中幾個核心模塊的設計。

高可用模塊設計

首先是單應用多集群高可用模塊的設計（AP 方案）。為什么有 AP 方案的設計呢？因為接入這個圖數據庫平台的業務方比較在意的指標是集群可用性。在線服務對集群的可用性要求非常高，最基礎的要求是集群可用性能達到 4 個 9，即一年里集群的不可用時間要小於一個小時，對於在線服務來說，服務或者集群的可用性是整個業務的生命線，如果這點保證不了，即使集群提供的能力再多再豐富，那么業務方也不會考慮使用，可用性是業務選型的基礎。

另外公司要求中間件要有跨區域容災能力，即要具備在多個地域部署多集群的能力。我們分析了平台接入方的業務需求，大約 80% 的場景是 T+1 全量導入數據、線上只讀；在這種場景下對圖數據的讀寫強一致性要求並不高，因此我們設計了單應用多集群這種部署方案。

部署方式可以參考上圖，一個業務方在圖數據庫平台上創建了 1 個應用並部署了 4 個集群，其中北京 2 個、上海 2 個，平時這 4 個集群同時對外提供服務。假如現在北京集群 1 掛了，那么北京集群 2 可以提供服務。如果說真那么不巧，北京集群都掛了，或者對外的網絡不可用，那么上海的集群可以提供服務，這種部署方式下，平台會盡可能地通過一些方式來保證整個應用的可用性。然后每個集群內部盡量部署同機房的機器，因為圖數據集群內部 RPC 是非常多的，如果有跨機房或者跨區域的頻繁調用，整個集群對外的性能會比較低。

這個 AP 模塊的設計主要包含下面 4 個部分：

• 第一部分是右側的圖數據庫 Agent，它是部署在圖數據庫集群的一個進程，用來收集機器和Nebula Graph 三個核心模塊的信息，並上報到圖數據庫平台。Agent 能夠接收圖數據庫平台的命令並對圖數據庫進行操作。
• 第二部分是圖管理平台，它主要是對集群進行管理，並同步圖數據庫集群的狀態到配置中心。
• 第三部分是圖數據庫 SDK，它主要做的事情是管理連接到圖數據庫集群的連接。如果業務方發送了某個查詢請求，SDK 會進行集群的路由和負載均衡，選擇出一條高質量的連接來發送請求。此外，SDK 還會處理圖數據庫集群中問題機器的自動降級以及恢復，並且要支持平滑切換集群的數據版本。
• 第四部分是配置中心，類似 ZooKeeper，存儲集群的當前狀態。

每小時百億級數據導入模塊設計

第二個模塊是每小時百億量級數據導入模塊，上面說了業務場景里 80% 是 T+1 全量導入數據，然后線上只讀。平台在 19 年底 / 20 年初全量導入數據的方式是調用 Nebula Graph 對外提供的批量數據導入接口，這種方式的數據寫入速率大概是每小時 10 億級別，導入百億數據大概要耗費 10 個小時，這個時間有點久。此外，在以幾十萬每秒的速度導數據的過程中，會長期占用機器的 CPU、IO 資源，一方面會對機器造成損耗，另一方面數據導入過程中集群對外提供的讀性能會變弱。

為了解決上面兩個問題，平台進行了如下優化：在 Spark 集群中直接生成圖數據庫底層文件 sst file，再借助 RocksDB 的 bulkload 功能直接 ingest 文件到圖數據庫。這部分提速優化工作在 19 年底的時候就開始了，但是中間遇到 core dump 問題沒有上線。在 20 年六、七月份的時候，微信的本利大佬向社區提交了這方面的 pr，和他在線溝通之后解決了我們的問題，在這里感謝一下本利大佬 💐 。

圖數據庫平台數據導入的核心流程可以看右邊這張圖，當用戶在平台上提交了導數據操作后，圖數據庫平台會向公司的 Spark 集群提交一個 Spark 任務，在 Spark 任務中會生成圖數據庫里相關的點、邊以及點索引、邊索引相關的 sst 文件，並上傳到公司的 S3 雲存儲上。文件生成后，圖數據庫平台會通知應用里的多個集群去下載這些存儲文件，之后完成 ingest 跟 compact 操作，最后完成數據版本的切換。

平台方為兼顧各個業務方的不同需求，統一了應用導入、集群導入、離線導入、在線導入以及全量導入、增量導入這些場景，然后細分成下面九個階段，從流程上保證在導數據過程中應用整體的可用性。

• sst file生成
• sst file下載
• ingest
• compact
• 數據校驗
• 增量回溯
• 數據版本切換
• 集群重啟
• 數據預熱

實時寫入多集群數據同步模塊設計

第三個模塊是實時寫入多集群數據同步，平台有 15% 的需求場景是在實時讀取數據時，還要把新產生的業務數據實時寫入集群，並且對數據的讀寫強一致性要求不高，就是說業務方寫到圖數據庫里的數據，不需要立馬能讀到。

針對上述場景，業務方在使用單應用多集群這種部署方案時，多集群里的數據需要保證最終一致性。平台做了以下設計，第一部分是引入 Kafka 組件，業務方在服務中通過 SDK 對圖數據庫進行寫操作時，SDK 並不直接寫圖數據庫，而是把寫操作寫到 Kafka 隊列里，之后由該應用下的多個集群異步消費這個 Kafka 隊列。

第二部分是集群在應用級別可配置消費並發度，來控制數據寫入集群的速度。具體流程是

• SDK 對用戶寫操作語句做語法解析，將其中點邊的批量操作拆解成對單個點邊操作，即對寫語句做一次改寫
• Agent 消費 Kafka 時確保每個點及其出邊相關操作在單個線程里順序執行，保證這點就能保證各個集群執行完寫操作后最終的結果是一致的。
• 並發擴展：通過改變 Kafka 分片數、Agent 中消費 Kafka 線程數來變更和調整 Kafka 中操作的消費速度。
• 如果未來 Nebula Graph 支持事務的話，上面的配置需要調整成單分片單線程消費，平台需要對設計方案再做優化調整。

第三部分是在實時寫入數據過程中，圖數據庫平台可以同步生成一個全量數據版本，並做平滑切換，通過右圖里的流程來確保數據的不重不漏不延遲。

圖可視化模塊設計

第四個模塊是圖可視化模塊，平台在 2020 年上半年調研了 Nebula Graph 官方的圖可視化設計跟一些第三方開源的可視化組件，然后在圖數據庫平台上增加了通用的圖可視化功能，主要是用於解決子圖探索問題；當用戶在圖數據庫平台通過可視化組件查看圖數據時，能盡量通過恰當的交互設計來避免因為節點過多而引發爆屏。

目前，平台上的可視化模塊有下面幾個功能。

第一個是通過 ID 或者索引查找頂點。

第二個是能查看頂點和邊的卡片（卡片中展示點邊屬性和屬性值），可以單選、多選、框選以及按類型選擇頂點。

第三個是圖探索，當用戶點擊某個頂點時，系統會展示它的一跳鄰居信息，包括：該頂點有哪些出邊？通過這個邊它能 Touch 到幾個點？該頂點的入邊又是什么情況？通過這種一跳信息的展示，用戶在平台上探索子圖的時候，可快速了解到周邊的鄰居信息，更快地進行子圖探索。在探索過程中，平台也支持對邊進行過濾。

第四個是圖編輯能力，讓平台用戶在不熟悉 Nebula Graph 語法的情況下也能增刪改點邊數據，對線上數據進行臨時的干預。

業務實踐

下面來介紹下接入我們平台的一些落地項目。

第一個項目是智能助理，它的數據是基於美團商戶數據、用戶評論構建的餐飲娛樂知識圖譜，覆蓋美食、酒店、旅游等領域，包含 13 類實體和 22 類關系。目前點邊數量大概在百億級別，數據是 T+1 全量更新，主要用於解決搜索或者智能助理里 KBQA（全稱：Knowledge Based Question Answer）類的問題。核心處理流程是通過 NLP 算法識別關系和實體后構造出 Nebula Graph SQL 語句，再到圖數據庫獲取數據。

典型的應用場景有商場找店，比如，某個用戶想知道望京新薈城這個商場有沒有海底撈，智能助理就能快速查出結果告訴用戶。

還有一個典型場景是標簽找店，想知道望京 SOHO 附近有沒有適合情侶約會的餐廳，或者你可以多加幾個場景標簽，系統都能給你查找出來。

第二個是搜索召回，數據主要是基於醫美商家信息構建的醫美知識圖譜，包含 9 類實體和 13 類關系，點邊數量在百萬級別，同樣也是 T+1 全量更新，主要用於大搜底層實時召回，返回與 query 相關的商戶、產品或醫生信息，解決醫美類搜索詞少結果、無結果問題。比如，某個用戶搜“啤酒肚”這種症狀、或者“潤百顏”這類品牌，系統都能給他召回相關的醫美門店。

第三個是圖譜推薦理由，數據來自用戶的畫像信息、商戶的特征信息、用戶半年內收藏/購買行為，現在的數據量級是 10 億級別， T+1 全量更新。這個項目的目標是給出美食列表推薦商戶的可解釋理由。為什么會做這個事呢？現在美團 App 和點評 App 上默認的商戶推薦列表是由深度學習模型生成的，但模型並不會給出生成這個列表的理由，缺少可解釋性。然而在圖譜里用戶跟商戶之間天然存在多條連通路徑，我們希望能選出一條合適路徑來生成推薦理由，在 App 界面上展示給用戶推薦某家店的原因。比如我們可以基於用戶的協同過濾算法來生成推薦理由，在家鄉、消費水平、偏好類目、偏好菜系等多個組合維度中找出多條路徑，然后給這些路徑打分，選出一條分值較高的路徑，之后按照特定 pattern 產出推薦理由。通過上述方式，就可以獲得在北京喜歡北京菜的山東老鄉都說這家店很贊，或者廣州老鄉都中意他家的正宗北京炸醬面這類理由。

第四個是代碼依賴分析，是把公司里的代碼庫中代碼依賴關系寫到圖數據庫。公司代碼庫里有很多服務代碼，這些服務都會有對外提供的接口，這些接口的實現依賴於該服務中某些類的成員函數，這些類的成員函數又依賴了本類的成員變量、成員函數、或者其它類的成員函數，那么它們之間的依賴關系就形成了一張圖，我們把這個圖寫到圖數據庫里，做什么事呢？

典型場景是 QA 的精准測試，當 RD 完成需求並向公司的代碼倉庫提交了他的 pr 后，這些更改會實時地寫到圖數據庫中，所以 RD 就能查到他所寫的代碼影響了哪些外部接口，並且能展示出調用路徑來。如果 RD 本來是要改接口 A 的行為，他改了很多東西，但是他可能並不知道他改的東西也會影響到對外接口 B、C、D，這時候就可以用代碼依賴分析來做個 Check。

第五個是服務治理，美團內部有幾十萬個微服務，這些微服務之間存在互相調用關系，這些調用關系形成了一張圖。我們把這些調用關系實時寫入圖數據庫里，然后做一些服務鏈路治理和告警優化工作。

第六個項目是數據血緣，把數倉中 ETL 任務的依賴關系寫到了圖數據庫中，大概是千萬級別的數據量級，數據實時寫入，每天凌晨做一次全量 reload，主要是用來查找數據任務的上下游依賴。比如說，通過這個 FIND NOLOOP PATH FROM hash('task1') OVER depend WHERE depend.type == '強依賴' UPTO 50 STEPS 語句找出 task1 這個任務的所有強依賴路徑。這里，我們針對 Nebula Graph 官方的 FIND PATH 功能做了一些加強，添加了無環路徑的檢索跟 WHERE 語句過濾。

美團和 Nebula

最后，來介紹下團隊對社區的貢獻。

為了更好地滿足圖數據庫平台上用戶的需求，我們對 Nebula Graph 1.0的內核做了部分功能的擴充和部分性能的優化，並把相對來說比較通用的功能給 Nebula Graph 社區提了 PR，也向社區公眾號投稿了一篇 主流開源分布式圖數據庫Benchmark 🔗 。

當然，我們通過 Nebula Graph 解決了公司內的很多業務問題，目前對 Nebula Graph 社區做的貢獻還比較少，后續會加強在社區技術共享方面的工作，希望能夠培養出越來越多的 Nebula Committer。

美團圖數據庫平台的未來規划

未來規划主要有兩個方面，第一方面是等 Nebula Graph 2.0 的內核相對穩定后，在我們圖數據庫平台上適配 Nebula Graph 2.0 內核。第二方面是去挖掘更多的圖數據價值。現在美團圖數據庫平台支持了圖數據存儲及多跳查詢這種基本能力，后續我們打算基於 Nebula Graph 去探索一下圖學習、圖計算的能力，給平台用戶提供更多挖掘圖數據價值的功能。

以上為本次美團 NLP 技術專家——趙登昌老師帶來的圖數據庫平台建設方面的分享。

如果你對【圖存儲】、【圖學習】、【圖計算】感興趣，歡迎向趙登昌老師投遞簡歷，投遞郵箱：[e-mail]。

喜歡這篇文章？來來來，給我們的 GitHub 點個 star 表鼓勵啦~~ 🙇‍♂️🙇‍♀️ [手動跪謝]

交流圖數據庫技術？交個朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你進交流群~~