美團圖資料庫平臺建設及業務實踐

本文為 #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 技術專家——趙登昌老師帶來的圖資料庫平臺建設方面的分享。

如果你對【圖儲存】、【圖學習】、【圖計算】感興趣，歡迎向趙登昌老師投遞簡歷，投遞郵箱：zhaodengchang@meituan.com。

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

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