Nebula Graph 在網易遊戲業務中的實踐

網際網路金融的借貸同傳統信貸業務有所區別，相較於傳統信貸業務，網際網路金融具有響應快、資料規模大、風險高等特點。眾安保險主要業務是做信用保證保險，為了服務業務，大資料團隊搭建了風控系統用於處理網際網路借貸的決策問題。本文主要講述 Nebula Graph 是如何透過眾安保險的選型，以及 Nebula Graph 又是如何落地到具體業務場景幫助眾安保險解決風控問題。

業務背景

有別於傳統銀行的信貸業務十天、半個月的申請稽核時長，網際網路金融借貸第一個特點便是申請稽核非常快，可能使用者上一秒剛在手機端提交授信申請，下一秒系統便會返回授信申請的結果。此外，網際網路金融借貸還有一個特點：資料資訊的真實性難以保證，使用者填寫的資訊：年收入、家庭關係、聯絡人都會存在資訊不實的情況。而這兩個網際網路金融的特點催生了一個產業，就是網路黑產。通俗來說，網路黑產就是使用者薅“借貸”羊毛的行為。因為網路借貸隱匿性強，一旦黑產賬號實施了欺詐行為後，透過網際網路很難追蹤到特定的人。此外，由於借貸審批時效性的關係，黑產賬號能很方便地做到走量、薅到更多的錢。基於此，催生網際網路金融的風控需求，需要系統甄別欺詐場景。

那如何甄別網路黑產呢？透過使用者與不同實體、裝置、GPS 與手機號之間的關聯關係，以及社群 NULL 發現檢視社群中的個體是否有欺詐風險、進行反欺詐的個案調查，能很好地進行借貸風控。目前，眾安保險的風控是基於 Nebula Graph 實現的。

為什麼選擇 Nebula Graph

在眾安保險技術選型之初，團隊成員調研過圖資料庫市場的產品，首先篩選出了 JanusGraph、OrientDB。

先來說下 JanusGraph，在眾安金融事業技術團隊內部 JanusGraph 有一大優勢：團隊成員對它熟悉，不少工程師使用過 JanusGraph，這從某種程度上降低了圖資料庫開發、上手成本。使用過 JanusGraph 的研發都知道它是一個分散式圖資料庫，儲存、索引依賴開源元件，例如：HBase（儲存）、Elasticsearch（索引）。而之前公司的某個業務線曾使用過 JanusGraph，底層搭載線上 HBase 儲存服務，而該業務相對獨立和其他核心業務不存在強依賴關係。“不同的國家有不同的國情，一旦相同機制硬搬到不同的國家，可能會出現水土不服問題”，目前眾安保險風控業務的基礎資料儲存在 HBase 中，假如風控系統使用 JanusGraph 的話，將上百億圖資料完全匯入 HBase 會對 HBase 叢集產生影響、增加查詢毛刺，導致其他業務線受到影響。此外，在大規模寫入速度效能方面，JanusGraph 匯入較慢。綜合上述原因，即便 JanusGraph 具有低上手成本，但其強依賴其他元件、匯入效能差，所以 JanusGraph pass。

在圖資料庫產品調研過程中，我們發現 OrientDB 在 DB-Engine 排名較前、功能完善。經過效能測試，發現在小規模資料集下使用 OrientDB 體感良好，但一旦 Mock 資料過億，大規模資料集下使用 OrientDB 會遇到 Server 端頻繁報錯問題。查閱 OrientDB 官方文件無果之後，眾安保險向 OrientDB 官方 GitHub 倉提交了 issue。但是 OrientDB 反饋響應慢，在提交 issue 的過程中，我們還發現大規模資料集 Server 端頻繁報錯問題社群使用者兩年前提交過，issue 仍未解決處於 open 狀態。此外，在大規模資料寫入效能方面，寫入點的速度尚可接受，但寫入邊的 QPS 只有 1-2k，用這個速度開始圖資料建模的話耗時將在天級別，這是不可接受的。綜上，雖然 OrientDB 排名靠前、功能完善，但大規模資料頻繁 Server 報錯、社群 issue 響應慢、大規模寫入速度不佳導致最後我們沒有選擇 OrientDB。

而 Nebula Graph 參與技術選型的契機是，在眾安保險開始圖資料庫選型時，諮詢其他公司（京東、攜程…）從業人員公司所用圖資料庫時，他們一致推薦 Nebula Graph。因此，Nebula Graph 成為眾安保險圖資料庫選型的選項之一。而在實際測試中，我們發現 Nebula Graph 大規模寫入速度非常快，生產環境測試資料能達到 10w+ QPS。此外，Nebula Graph 儲存和索引依賴於本地 RocksDB 庫，不依賴於其他大資料元件，符合業務需求。在大資料生態支援方面，Nebula Graph 支援主流的 Spark（）和 Flink（）。在社群響應和反饋時效上，Nebula Graph 也給了我們比較好的體驗。

這裡額外講下社群支援，在整個圖資料庫調研過程中，我們發現相較於成熟的諸如 MySQL、Oracle 此類的 SQL 資料庫，圖資料庫發展時間較短，由此產生的問題是遇到部分圖資料庫產品問題，搜尋引擎能提供的資訊較少。像之前 OrientDB 的頻繁報錯問題，如果社群未能提供及時的技術反饋，對於使用者來說他可能要花費大量時間來閱讀原始碼去 Debug，人力成本便會急劇上升、價效比極低。

而 Nebula Graph 在社群支援跟反饋方面給了眾安保險非常良好的體驗。作為他們的客戶，包括在最早期的 1.0，眾安保險給 Nebula Graph 提交了不少使用問題和 bug，Nebula 研發同學都能及時回覆和 fix bug。到 2.0 部署時，我們遇到生產部署問題他們也能及時提供技術支援。這一點相比於其他的圖資料庫廠商，是非常值得推薦的。這也是我們選擇 Nebula Graph 作為圖資料庫來支撐眾安保險業務的根本性原因。

金融風控業務實踐

下圖為眾安保險基於 Nebula Graph 的風控系統架構圖，它集資料處理、加工清洗、計算、圖服務應用為一體。

如上圖所示，最底層為業務庫，不同的業務關係資料存在不同的業務庫中，包括使用者附件、裝置、 GPS、IP 等等資訊。

再上層，是由離線數倉和實時數倉構成的圖資料庫加工清洗層，離線數倉透過 DataX 進行每天 T+1 的資料迴流，迴流業務庫的資料存到 ODPS 中，Nebula Graph 透過 Spark 來讀取當中資料並寫入到資料庫中。在實時數倉方面，透過眾安保險內部的監聽元件 BLCS 將資料寫到 Kafka，再經過 FlinkSQL 搭建的實時數倉進行資料清洗加工，最後透過 Flink 實時地寫入到 Nebula Graph 中。為了保證資料的一致性，實時數倉每天進行資料校驗，如果資料存在不一致，則會使用離線資料補齊缺失的資料。

資料清洗加工層上面則是儲存 & 計算層，儲存層不用說自然是 Nebula Graph。而計算方面，透過 Nebula Graph 提供的 Spark Connector 元件，將圖資料庫中的資料讀取到 Spark 平臺透過 GraphX 執行預測模型，最後將結果寫回 Nebula Graph 中。

最後，透過眾安保險的微服務系統將圖資料庫儲存 & 計算對接給上層圖應用，提供圖探索服務、風控特徵、個案調查、預測模型等圖服務。

關係圖譜

這裡簡單講解眾安保險內部的圖社群探索的關係圖譜，透過上圖的關係圖譜講解具象化地介紹眾安是如何利用圖資料庫甄別欺詐場景，如何使用圖資料庫實踐風控特性。

上圖有 2 類節點：

人（藍色節點）
手機（綠色節點）

存在 3 類關係：

人-[申請]->手機
手機-[聯絡人]->人
人-[綁卡]->手機

第一眼看到上面的圖，很明顯看到 2 個稠密熱點，熱點手機號被五、六十填為他的家庭聯絡人的手機號。按常識來說，當代中國大多獨生子女家庭，加上旁系關係，也很難出現五、六十個人同時將同一個手機號填為他的家庭聯絡人的手機號。所以，這個手機號關聯人可能是欺詐團伙分子，黑產團伙可能知曉借貸評分系統中有一環節是對家庭聯絡人的手機號進行信用評分，團伙希望透過關聯高信用分的手機號從而提高信用分。

基於上述特徵，我們可以查詢使用者所在社群的規模、使用者是否在疑似欺詐社群中對他進行一個初步風控判斷。這裡講述下，即便某個使用者處於異常關係網路中也不代表他是個欺詐使用者，處於異常社群是個判斷使用者是否為欺詐分子的充分不必要條件。因為存在一種可能，使用者本身並非是欺詐分子，但直系親戚參與了中介代 NULL 辦、團伙欺詐，此時便會出現正常使用者和異常使用者都存在同一關係網路的情況。

下一步，我們需要深入挖掘使用者和異常中心的“親密”離散度，探尋它們的路徑距離。透過結合 Nebula Graph 本身的路徑查詢功能，分析離散度（靠近異常點，還是處於社群邊緣）從而判斷某位使用者是否是有欺詐嫌疑。

這裡以手機號為例，來幫助大家理解眾安是如何透過 Nebula 來識別使用者的欺詐場景的。其實眾安保險內部還有裝置、IP 等等關係圖譜，這裡不展開贅述。

圖模型預測

這部分來介紹下圖預測模型，

Connected Component（貸前）
Label Propagation（貸中）
Degree Statistical

剛上面部分介紹的關係圖譜是透過聯通分量（Connected Component）演算法計算得出的，主要應用在貸前的使用者授信申請環節。

再來是標籤傳播（Label Propagation），不同於聯通分量，標籤傳播更多地應用於貸中環節。標籤傳播主要是透過一個確定的點 Y 去傳播、衍生出它相關點。舉個例子，貸中使用者名稱單中某個使用者是嚴重逾期人員，這個人員便是打上逾期標籤的確定點 Y，結合既定的風控規則檢視點 Y 關聯延伸的點中哪些點出現相似逾期行為，從而判斷這些點是否屬於嚴重逾期的社群。這便是貸中的標籤傳播演算法。

最後一個演算法是 Degree Statistical，全圖關係度數，主要供風控人員使用。風控人員在做風控特徵時，可能會提出幾十、上百個圖特徵，基於這些特徵資料需要用歷史的資料去驗證，檢視哪些特徵可以真正地識別出欺詐使用者或是嚴重逾期使用者。而這個驗證過程，如果使用傳統數倉透過 ODPS 做深度查詢的話，無論在執行效率、耗時，還是在 SQL 程式碼編寫方面，都是一個非常低效的過程。但，透過 Nebula Graph 將點資料讀取到 GraphX 中進行全圖關係度計算，將 7 度或者是 10 度關係以行的形式寫回到 ODPS 中，提供給風控人員使用，可以幫助他們更快地完成風控規則制定、完成風控任務。

未來展望

版本規劃

在主題分享時，眾安保險所用的 Nebula 版本為 2.0.1，後續 Nebula v2.5.0 中新增水位線 watermark 功能去防止查詢遇到稠密熱點佔用記憶體過高拖垮 storage 程式的情況。眾安保險這邊會在測試環境部署 v2.5.0 版本進行驗證，驗證透過之後，業務線逐步切到 v2.5.0 版本中。

Nebula Graph 在眾安保險的圖實踐