泰康在線的 NebulaGraph 業務實踐

406次閱讀

泰康在線作為一家互聯網保險公司，擁有過億的海量客戶群體。對這些客戶進行精準營銷，或者是保險業務里的風險控制，就需要對客戶之間的關聯關系、客戶與特征標簽的關系，進行高效的管理和計算處理。

在技術方面也存在類似的事物間關聯關系管理的訴求。比如數據治理，我們需要建立多個系統間的數據血緣關系。應用系統監控，也同樣需要管理服務器、應用、接口間的相互關聯關系。

傳統的關系型數據庫，在管理深度關聯關系方面，存在明顯的性能問題。而圖數據庫在這方面具有天然的優勢，能夠非常方便地存儲實體間的關聯關系，并可以進行靈活的擴展。特別是分布式圖數據庫，能夠有效處理海量的關聯關系的存儲甚至是計算問題。

于是，在 2020 年下半年，泰康在線的技術團隊啟動了圖數據庫的調研。

技術選型

對于圖數據庫的選擇，我們技術選型的要求如下：

開源軟件且社區活躍。畢竟我們還處于探索階段，必須節省成本。
能夠支持十億級節點、百億級邊。這是業務數據規模決定的。
分布式架構，支持橫向擴展。
多跳查詢延遲在毫秒級。這是為了支持某些 OLTP 場景。
學習門檻低。

圖數據庫調研

基于上述選型要求，我們對 DB-Engines 排名靠前的圖數據庫進行了相關調研。在這里面，Neo4j、ArangoDB 雖然開源，但是只有單機版本開源可用；JanusGraph、HugeGraph，具有通用的圖語義解釋層、提供了圖遍歷的能力，但是受到存儲層或者架構限制，多跳遍歷的性能較差，很難滿足 OLTP 場景下對低延時的要求；DGraph、NebulaGraph，根據圖數據的特點對數據存儲模型、點邊分布、執行引擎進行了全新設計，對圖的多跳遍歷進行了深度優化，能夠滿足我們的選型要求。通過查閱相關資料，我們發現NebulaGraph在性能、社區活躍度方面，都比DGraph要高一些。所以，最終我們選擇了 Nebula Graph。

在實際應用之前，我們對 Nebula Graph 進行了一系列的技術調研。其中，我們選擇了理賠業務數據進行了數據導入、多跳查詢的實際測試。我們需要的版本是 Nebula Graph 2.0，導入工具采用 nebulagraph-importer，導入方式為 csv 文件導入。測試數據為 7,000 萬理賠數據，包含約 1.5 億節點、2.1 億邊。實際測試環境，我們的 Nebula Graph 2.0 部署在 3 臺物理機上，每臺物理機配置如下：

CPU： 2核（Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz）
內存：128G
硬盤：SAS盤

實測數據導入速度：點導入速度約 75 萬/秒，邊導入速度約 62 萬/秒。

這個導入速度，已經完全滿足我們的業務場景要求。在多跳查詢方面，我們也進行了簡單的測試，實際查詢速度基本都不到 100 毫秒，滿足我們的要求。

通過這些調研，我們發現 Nebula Graph 完全能夠滿足我們的業務場景要求。于是，我們最終選擇 Nebula Graph 作為我們圖計算平臺的基礎組件。

解決方案設計

為了應對不同的業務場景，我們建立了初步的圖計算平臺：

其中，數據通過 Canal、Kafka、Flink 等組件處理后，進入存儲層。存儲層由多種存儲引擎組成，核心組件是 Nebula Graph。對外提供的服務方式，有 API 接口和圖計算框架 FlinkGelly，分別應用于實時交互和圖計算場景。整個平臺，可以服務于多種業務：營銷、風控、反洗錢等。目前，我們主要應用于時效要求不高的離線場景。