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

本文爲 #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 對數據進行操做；平臺側主要負責各業務方圖數據庫集羣的穩定性。目前有3、四十個業務在平臺上真正落地，基本能知足各個業務方需求。

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

高可用模塊設計

首先是單應用多集羣高可用模塊的設計（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 年6、七月份的時候，微信的本利大佬向社區提交了這方面的 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 拉你進交流羣~~