圖資料庫平臺建設及業務落地

1. 什麼是圖資料庫

圖資料庫(Graph database)是以圖這種資料結構儲存和查詢的資料庫。與其他資料庫不同，關係在圖資料庫中佔首要地位。這意味著應用程式不必使用外來鍵或帶外處理（如 MapReduce）來推斷資料連線。與關聯式資料庫或其他 NoSQL 資料庫相比，圖資料庫的資料模型也更加簡單，更具表現力。

圖資料庫在社交網路、知識圖譜、金融風控、個性化推薦、網路安全等領域應用廣泛。

2. 圖資料庫調研

2.1 調研背景

隨著知識圖譜等業務資料的不斷增長，現有圖資料庫 JanusGraph 應對已經比較吃力，匯入時間已經無法滿足業務的要求。因此尋找效能更好的開源屬性圖資料庫已經成為了當前迫切要做的事情。

新圖資料庫應滿足以下要求：

能夠支援 10 億節點 100 億邊 170 億屬性的大規模圖譜
全量匯入時間不超過 10h
二度查詢平均響應時間不超過 50ms，QPS 能夠達到 5000+
開源且支援分散式的屬性圖資料庫

2.2 調研過程

第一步，蒐集常見的開源分散式屬性圖資料庫，如下表：

第二步，基於美團、LightGraph、TigerGraph、GalaxyBase等圖資料庫測試報告，分析可得幾個圖資料庫效能如下：

匯入：NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB

查詢：NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB

NebulaGraph不論是在匯入還是在查詢效能上都表現優異。

第三步，為了驗證 NebulaGraph 的效能，對 NebulaGraph 和 JanusGraph 進行了一次效能對比測試，測試結果如下：

上圖中，將JanusGraph效能看作 1，NebulaGraph 匯入效能要比 JanusGraph 快一個數量級，查詢效能是 JanusGraph 的 4-7 倍。而且隨著併發量的增大，效能差距會進一步拉大，而且 JanusGraph 在從 20 個執行緒開始，三度鄰居查詢會有 error。而 NebulaGraph 沒有任何error。

NebulaGraph 全量匯入 10 億節點 100 億邊只需要 10h，滿足要求，目前正在調研 SST 匯入，可以大幅提升匯入速度。

對 NebulaGraph 使用 120 個執行緒進行二度鄰居查詢壓測，最終 QPS 在 6000+，相比單機有一些提升。成功率接近 5 個 9，而且響應實踐比較穩定，平均 18.81ms，p95 38ms，p99 也才115.6ms，符合需求。

2.3 調研結論

NebulaGraph 匯入效能、響應時間、以及穩定性均符合需求，支援資料切分，分散式版本免費開源，使用的企業也多，中文文件，文件全面，社群活躍，是開源圖資料庫的理想選擇。

3. NebulaGraph 簡介

圖片來源於NebulaGraph官網

NebulaGraph 是一款開源的、分散式的、易擴充套件的原生圖資料庫，能夠承載數千億個點和數萬億條邊的超大規模資料集，並且提供毫秒級查詢。

NebulaGraph 基於圖資料庫的特性使用C++編寫，採用shared-nothing架構，支援在不停止資料庫服務的情況下擴縮容，而且提供了非常多原生工具，例如 Nebula Graph Studio、Nebula Console、Nebula Exchange 等，可以大大降低使用圖資料庫的門檻。

圖片來源於NebulaGraph官網

NebulaGraph 由三種服務構成：Graph 服務、Meta 服務和 Storage 服務，是一種儲存與計算分離的架構。

Meta 服務負責資料管理，例如 Schema 操作、叢集管理和使用者許可權管理等。服務是由 nebula-metad 程式提供的，生產環境中，建議在 Nebula Graph 叢集中部署3個 nebula-metad 程式。請將這些程式部署在不同的機器上以保證高可用。所有 nebula-metad 程式構成了基於 Raft 協議的叢集，其中一個程式是 leader，其他程式都是 follower。

Graph 服務主要負責處理查詢請求，包括解析查詢語句、校驗語句、生成執行計劃以及按照執行計劃執行四個大步驟，服務是由 nebula-graphd 程式提供的，可以部署多個。

Storage 服務負責儲存資料，服務是由 nebula-storaged 程式提供的，所有nebula-storaged 程式構成了基於 Raft 協議的叢集，資料在 nebula-storaged 中分割槽儲存，每個分割槽都有一個 leader，其它副本集構成該分割槽的 follower。

4. 圖資料庫平臺建設

之前在使用的 JanusGraph 時候，遇到過匯入緩慢、查詢慢、高併發OOM（JanusGraph 執行緒池採用無界佇列導致）、FULL GC（業務 Gremlin語句中包含 Value 導致元空間不斷膨脹導致）等問題，這些在切到NebulaGraph後基本得到了解決。

JanusGraph並沒有好用的管理介面，所上圖所示，我們開發了一套包含多圖管理、Schema管理、圖視覺化、圖匯入、許可權管理的管理介面。

而 NebulaGraph Studio 提供多圖管理、Schema管理、圖視覺化、圖匯入等功能，省去了很多開發工作，降低了使用門檻。

整個圖資料庫平臺的結構如上圖所示，基於 NebulaGraph 和 NebulaGraph 官方工具，著重開發了全量匯入、增量匯入、圖匯出、備份/還原、查詢工程（圖檢索）等功能。

官方匯入工具需要提供匯入配置檔案，為了更便於業務使用，我們設計了一個schema配置表格，業務只需填好表格，匯入的時候會自動創圖，建立圖的schema，自動生成匯入配置檔案，自動匯入資料，自動平衡資料，平衡leader，建立索引，執行compact任務。當前還是批量寫入的匯入方式，後續會調研 SST 匯入，匯入效能可進一步提升。

官方提供的匯入工具採用的是非同步客戶端，匯入時極難控制匯入速率，設定過大，容易導致圖資料庫請求積壓，影響叢集的穩定執行。設定過小，速度無法達到最優，匯入過慢。我們修改了官方匯入工具原始碼，將非同步客戶端改成了同步客戶端，可以兼顧效能和穩定性。

官方沒有提供匯出工具，我們基於官方的 nebula-spark 開發了一個匯出工具，除了能夠匯出資料，還能夠匯出 Schema 配置以及索引配置，便於業務做資料遷移。

為了支援資料回滾，我們開發了指定圖譜的資料快速備份和還原的功能，不過該功能無法備份圖譜後設資料，全量匯入會刪除並重建圖譜，由於後設資料發生變化，之前的備份就沒有用了。後續會嘗試全量匯入只清理資料不刪圖的方式來避免這個問題。

知識圖譜業務的邊型別非常多，經常一次查詢需要查詢幾十上百種邊，每種型別的邊其實只需要返回 Top 10（根據rank排序）個結果就好。這種情況通過 nGQL 很不好實現，只能查詢這些邊的所有資料，或者所有邊合在一起的 Top N 個資料，前者有效能問題，後者經常只能返回部分型別邊的資料，無法滿足需求。針對這種情況，我們對邊進行了分類，對於數量較少的那些邊型別，一條語句查詢所有資料。對於數量多的邊型別，使用多執行緒並行查詢每條邊的Top 10，這樣就能進行一定的規避。

為了保證服務的高可用，我們實現了雙機房部署。為了不讓上層業務感知機房切換，在圖資料庫上層做了查詢工程（圖檢索），業務直接呼叫查詢工程的服務，查詢工程會根據叢集狀態選擇合適的圖資料庫叢集查詢。另外，為了向上層業務遮蔽底層圖資料庫變更和版本升級，查詢工程會管理所有業務的查詢語句。遇到圖資料庫因為版本升級出現查詢語句不相容的時候，只需要在查詢工程中將圖查詢語言進行調整就好，避免波及上層業務。同時，查詢工程也對查詢結果進行了快取，可以極大的提高圖查詢的吞吐量。

當然我們還遇到一些問題，如rank因大小端問題導致排序失效、查詢結果只返回邊型別id等，因為篇幅原因，在此不一一列舉，這些問題通過 NebulaGraph 社群幫助，已經得到了規避或解決。

*注意：以上提到的NebulaGraph問題僅針對 V1.2.0 版本，很多問題後續版本已經修復。

5. 業務落地

5.1 知識圖譜及智慧問答

在使用圖譜之前，小布助手只支援基於文件的問答 DBQA，DBQA 利用的是非結構化的文字，適合回答 Why、How 等解釋性、論述性問題，而對於事實性問題回答準確率和覆蓋率不高。

在使用圖譜後，小布助手支援基於知識庫的問答 KBQA，在 What、When 等事實性問題的準確率和覆蓋率大幅度提升。例如：xxx的老婆是？xxx奧特曼的體重是多少？北京的面積是多少？

除了事實性問答，小布助手還可以利用圖譜的推理能力實現一些複雜問答：例如：xxx和xxx是什麼關係？OPPO釋出的第一款手機是什麼？xxx和xxx共同參演的電影有哪些？出生在xx的雙子座明星有哪些？

由於知識圖譜存在規模龐大的半結構化資料，而且資料之間存在很多的關聯關係，使用關係型資料庫是無法滿足儲存和查詢要求的，而圖資料庫恰恰能夠解決大規模圖譜儲存和多跳查詢的挑戰。

5.2 內容標籤

在一些推薦場景中，需要理解視訊、音訊或文字的內容，給其打上和內容相關的標籤。例如在短視訊推薦中，理解視訊的內容有利於對使用者進行精準推薦。

對於影視類視訊，將演員、影視節目、扮演角色構造成一個影視娛樂圖譜，當有新的影視類短視訊釋出時，可以通過視訊中人臉識別出演員、標題或字幕中識別出影視角色，利用圖譜快速推理出對應的影視作品，給視訊打上內容標籤，從而提升推薦效果。

5.3 資料血緣

在數倉中，經常需要執行各種 ETL Job，資料表和任務非常多，如何直觀的觀察資料表上下游與任務之間的關係變成一個亟需解決的問題。

使用關係型資料庫處理多層級的關聯查詢非常麻煩，不僅開發工作量大，而且查詢效能極慢。而使用圖資料庫，不僅大大減少了開發工作量，而且能夠快速的查出表的上下游關係，便於直觀觀察資料的血緣關係。

5.4 服務架構拓撲

在服務資源管理中，業務資源會分為多個層級，每個層級下面有對應的伺服器、服務和管理人員，如果使用關聯式資料庫來處理，當需要展示多級資源的時候，查詢會很麻煩，效能會很差。這個時候，可以將資源、管理人員、伺服器、業務層級之間的關係放到圖資料庫中，展示的時候，一條查詢語句就能搞定，查詢速度還很快。

6. 總結

通過知識圖譜等業務實踐落地，完成了從 JanusGraph 向 NebulaGraph 的轉變，匯入效能提升了一個數量級，查詢效能以及併發能力都有 3-6 倍的提升。而且，NebulaGraph 比JanusGraph 更穩定。在實踐的過程中，也遇到過很多問題，得到了 NebulaGraph 社群非常多的幫助，十分感謝社群的支援！

圖資料庫在最近這幾年發展很快，Neo4J 今年上半年融資3.25億美金，重新整理了資料庫的融資記錄。Gartner 釋出的報告指出：“到 2023 年，圖技術將促進全球 30% 企業的快速決策場景化。圖技術應用的年增長率超過 100%。”隨著 5G 和物聯網的普及，圖資料庫將成為處理關係的基礎設施。