> 本文整理自 Akulaku 反欺詐團隊在 nMeetup·深圳場的演講，B站影片見：[https://www.bilibili.com/video/BV1nQ4y1B7Qd](https://www.bilibili.com/video/BV1nQ4y1B7Qd)

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak01.png)

這次主要來介紹下 Nebula 在 Akulaku 智慧風控的實踐。分為以下 6 個部分內容：

* 圖的基本概念與應用場景概述
* 圖資料庫選型
* 圖資料庫平臺建設
* Nebula 應用案例
* 圖模型的訓練與部署
* 總結與展望

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak02.png)

先來講解下圖的基本概念，圖是由節點和邊構成的描述關聯關係的集合。圖最大的優勢就是比較形象，比如上圖便是一個脫敏之後的欺詐團伙的圖結構，可以看到某個使用者和其他節點的關聯關係是否存在異常。如果我們使用的是單純的行式資料庫（關係型資料庫）是看不出來異常的，但是從圖的角度就可以很容易地發現資料的異常。

再來講解下圖的應用場景，在 Akulaku 的場景中主要是圖譜關係挖掘和視覺化分析，以及圖查詢替代複雜查詢。這裡解釋下圖查詢替代複雜查詢，你的應用背景可能和圖無關，但是涉及的後端操作具有一定的深度，用圖的關係進行查詢建模，就比較容易理解查詢語句和維護操作。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak03.png)

再者是圖資料庫選型這塊，先來講一下 Akulaku 在圖資料庫選型上踩過的坑。剛開始我們使用 Neo4j，主要做一些關聯性特徵，Neo4j 查詢效率較高但是可擴充套件性是短板，分散式的 Neo4j 效能和單機版效率相差不大。我們也嘗試過其他圖資料庫，這裡要說下我們的業務需求：

* 良好的可擴充套件性
* 快速的資料匯入
* 良好的查詢效率

展開來講，Neo4j 不具備良好的可擴充套件性，所以 pass。由於我們的圖規模非常大，主要是面向金融風控場景，圖的規模能達到十億節點、百億級別邊，所以需要快速的資料匯入來做初始化。這裡要說下我們嘗試用過 Dgraph，之前我們閱讀過它的相關學術論文，論文寫得非常的好但是工程實現欠佳。尤其是批次匯入這塊，當你匯入的資料超過一定量級之後會產生類似記憶體洩漏的問題，所以 Dgraph pass。

最後一點是良好的查詢效率，這裡要講下 JanusGraph，它的優點是後端可以整合其他儲存引擎，這也是當時測試 JanusGraph 的主要原因。但是當我們匯入和初始化資料之後，發現它的查詢效率非常的糟糕。

這裡看下 Akulaku 團隊對 Nebula Graph 做的可擴充套件性和查詢效能測試：

* **圖規模**：10億點，100億邊
* **測試方式**：nebula-bench [https://github.com/vesoft-inc/nebula-bench](https://github.com/vesoft-inc/nebula-bench)
* **查詢語句**：
    * 兩個一度查詢
    * 兩個二度查詢
    * 一個三度查詢
* **隨機源**：註冊手機號隨機抽樣 500 W個 phone

壓測時從隨機源 phone 隨機查詢其中 1 個資料。橫軸為併發，縱軸為 QPS，不同顏色的曲線代表併發節點的個數，這裡可以看到整個 Nebula Graph 的查詢效能是比較好的。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak04.png)

圖上可以看到，可擴充套件性大概在 12 臺機器的時達到較高的效能，後續再新增節點個數，分散式的開銷就要開始大於併發帶來的效益。所以你會看到這個節點個數提高，查詢效能會有所下降。這裡說下我們做的查詢，隨機抽取 500 萬個節點，進行多批查詢，每一批查詢中包含兩個一度查詢，兩個二度查詢和一個三度查詢。測試過程中，我們還遇到熱點問題，上圖是最後驗證的結果。

壓測時，使用的 Nebula 版本是 v1.x，後來 Nebula v2.x 釋出之後，Akulaku 團隊開始嘗試升級。但剛升級嘗試 2.0.1 時，發現一些問題：

* Leader change
    * 匯入資料的時候頻繁出現 leader change，導致寫入失敗
    * 查詢資料的時候沒有發現
* 觀察到 CPU 負載較高，主要是超大子圖導致

第一個問題主要發生在匯入資料的時候，會頻繁出現 leader change，這個問題會影響到線上呼叫效率。還有個觀察到的現象是，CPU 負載高，這是由部分超大節點導致的負載過高。所以就先回滾到了 v1.2 版本。在 v2.5.0 釋出之後，Akulaku 團隊又重新做了一個測試，和之前的壓測方式差不多。

* **圖規模**：10億點，100億邊
* **機器配置**：7 臺，256G，32 核
* **測試方式**：nebula-bench [https://github.com/vesoft-inc/nebula-bench](https://github.com/vesoft-inc/nebula-bench)
* **查詢語句**：
    * 兩個一度查詢
    * 兩個二度查詢
    * 一個三度查詢
* **隨機源**：註冊手機號隨機抽樣 500 W個 phone

在這個版本中，之前遇到的 leader change 和 CPU 負載過高的問題解決了。所以 Akulaku 團隊嘗試將 v2.5.0 應用到業務中。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak05.png)

上圖右側是併發數，左側是 QPS。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak06.png)

下面來講下圖分析平臺，主要圍繞兩塊引擎：圖資料庫平臺 Nebula Graph 和實時圖計算引擎。因為 Akulaku 這邊主要對接的應用場景為反欺詐，對實效性要求高，所以需要一系列的實時圖演算法。為了開發圖演算法，圖分析平臺需要一個實時圖計算引擎。這些引擎依賴於離線排程，比如：landsat 任務排程平臺、離線數倉、實時數倉的監控和任務監控等等模組。這塊內容底層又依賴於大資料叢集，比如常見的 Spark、Hive、Hadoop、Flink、HBase 等等。

所以這張圖從上到下就是應用-平臺-基礎設施。

如果我們單獨看一個圖資料庫平臺：

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak07.png)

圖資料庫平臺搭建這塊，Akulaku 團隊主要做了兩件事情：一個是資料匯入和高可用，資料匯入的話它是基於離線數倉，它既有批次寫入，也有基於實時資料來源的實時寫入。實時的資料來源這塊，圖資料庫儲存有兩種模式：

一種是雙叢集的主備，即線上服務由兩個主從叢集提供，實時資料來源會對主從叢集做雙寫；

另外一種是單叢集的方案，即每個應用可以有單獨例項。

這樣構建圖資料庫儲存，支撐平臺需要監控（服務和資料）、敏感資料沙箱、叢集擴縮容、排程系統等等這些支撐模組。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak08.png)

從業務角度，整個平臺的建設是為了基於圖關係進行探索和視覺化展示，上圖只是個示意圖並非業務中實際使用的圖。

上文說到應用場景，現在來具體講下 Nebula 在 Akulaku 的具體應用案例。

首先，主要應用在視覺化欺詐案例分析與深度關聯挖掘。第二，裝置 ID 關聯計算。最後也是最常見的一個應用，用於各種圖模型的部署，包括標籤傳播等等。下面詳細來講解下。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak09.png)

上圖是圖視覺化的欺詐案例的分析，上圖依舊是個示意圖並非真實資料圖。反欺詐的調查人員透過圖關係，使用圖資料庫的視覺化的工具，對關聯關係進行展開分析，包括圖譜的下段等等操作，去檢視的節點屬性。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak10.png)

第二個案例，是裝置 ID 關聯計算，這屬於剛才圖概念部分說到的，它可能本身跟圖沒什麼關係，只是用圖來表示比較自然，而且也更加容易維護。具體展開來說，裝置的 ID 需要透過一系列的要素來計算，但是欺詐分子會透過不停變更這些要素來試圖繞過反欺詐策略。但其實變更要素時，它只能變更某一要素，其他要素和該要素還是保持著一定的關聯。透過一定規則，用關聯關係就能把它實際的對映關係找到。這個查詢深度並不深，就是個一度的查詢，其主要的難度並不在於邏輯，而是資料的一致性。舉個例子，併發地操作計算裝置的 ID 的話，那就會有資料一致性的問題。比如，刪了一條不該刪的邊，加了一個不該加的資料，所以這個過程就需要對資料加鎖。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak11.png)

具體加鎖的方法，就是加鎖某批涉及計算裝置 ID 資訊的節點，等計算完成後再釋放節點，然後其他程式才能夠對這個資料進行修改。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak12.png)

第三大類應用是圖模型訓練與部署，比如像部署子圖展開類的圖模型。這裡來解釋下圖模型，就是這個模型的結果是抽取的子圖經過計算得到，這裡的子圖一般由中心節點展開得到。具體的子圖展開的圖模型有哪些？比如，以當前節點為中心的子圖特徵，基於當前子圖的標籤傳播的結果，或者是圖卷積的模型。下面說下這裡的難點在哪？

第一，回測上邏輯複雜。回測，主要指的是資料回溯，根據場景要求需獲取事件發生時的圖關係，進行特徵抽取和模型構建， 邏輯相對複雜。此外，在圖模型的部署上時效性要求也很高。如果這個模型是反欺詐場景的話，一般要將模型部署在授信或者是下單環節，時效性要求較高。根據圖模型訓練與部署應用場景的不同特點，會有下列 4 個思考的角度：

1. 業務環節的時效性要求。比如說，授信環節相對來說它的時效性要求會比下單環節要低一些；
2. 子圖規模。看部署模型涉及到的子圖規模是多大，如果很大的話，允不允許取樣？如果取樣不允許的話，我們用什麼方法處理？
3. 圖更新頻率和模型呼叫量相比，誰比較多？
4. 回測複雜度，它的資料量是大還是比較小？

下面舉幾個例子。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak13.png)

第一個例子，授信環節的子圖特徵。

具體來說，授信環節時，需要獲得一個 uid 所屬的子圖的特徵計算，比如說，N 度子圖節點的佔比或者是拓撲特徵。這個業務環節的時效性要求相對低一些，這是第一個特點。第二個特點，子圖規模可能大，可能會遇到爆炸節點的情況，但又不允許取樣。第三個特點，子圖更新資料量是遠遠大於模型的呼叫量。這代表什麼呢？就是單位時間授信申請的授信額度申請量，是遠小於圖更新的頻率。第四個特點，回測比較小。

針對上面的 4 個特點，採取什麼方案呢？因為它更新的資料量遠遠大於模型的呼叫量，所以最好是在模型呼叫的時候直接去計算它的特徵，而分數回測是可以基於圖資料庫的，就是說直接按照歷史模型呼叫的事件來做分數的回測。由於模型計算是在業務環節呼叫時去做查詢，所以需要確保這個圖資料庫叢集的可用性。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak14.png)

第二個例子是下單環節的標籤傳播。

具體來說，標籤傳播是從節點上的一個標籤，比如黑灰標籤或者特定的業務屬性標籤，根據一定的規則做傳播。那麼，標籤傳播場景有什麼特點？

第一點，業務環節的時效性要求會比較高，因為它是下單環節，不能有很大的延遲，否則就會卡單。第二點，子圖規模和上面一樣，存在爆炸子圖的可能。比如說，三度子圖可能是幾百萬的數量級，而且這個子圖不能取樣。為什麼不能取樣呢？因為標籤傳播涉及業務規則，取樣可能會影響分數的穩定性，所以一般來說不允許取樣。第三點，更新的資料量是遠小於模型的呼叫量，即圖更新的頻率小，但是呼叫的次數多。那，什麼時候做子圖計算呢？在資料更新的時候進行計算，這樣需要計算的資料量比較小。而下單環節的標籤傳播回測的資料量會比較大，單純從數量來說，下單的數量會遠大於授信申請的數量。

針對上述特點，更新資料量小於模型呼叫量（在業務環節呼叫分數的數量）的話，在圖更新時去計算模型的結果。這樣做有個好處，就是你呼叫結果和模型計算的過程，和呼叫分數的過程是解耦的。也就是說，業務環節直接呼叫分數，計算又不是實際環節的呼叫，只是這裡需要允許一定的延遲。這樣處理，相當於有兩個流程，一個是離線流程，T+1 做分數校正；一個是實時流程，上圖右側實時圖模型的部署。實時資料來源的資料一更新，系統便去更新標籤傳播的值，而業務環節的分數呼叫是透過模型結果的查詢服務來調取，而不是直接去查圖資料庫，這樣就分離了查詢和計算，甚至能做到無痛升級圖資料庫，也不影響線上服務。

上面的處理方案因為有兩個資料流（離線資料流和實時資料流），所以系統複雜度較高，而且需要保持資料的同步。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak15.png)

第三個例子，下單環節的圖卷積。

具體來說，基於屬性圖的節點屬性計算圖卷積，下單環節呼叫圖卷積結果。它的特點和上一個例子有點相似，業務環節的時效性要求高。子圖規模也可能存在爆炸子圖，同樣也不允許取樣。這個場景下，它和前面第二個例子一樣，更新的資料量會小於模型的呼叫量，下單環節下單量比較大，回測的資料量也是比較大。所有我們有一個上圖右側的架構處理，就是系統有一個 T+1 的校正。即每天有個整體的 T+1 的圖卷積過程去更新圖卷積結果，並且實時地透過實時資料來源去驅動分數的區域性更新。所以，它是一個 T+1 的全量重新整理，加一個實時的區域性重新整理。

以上為 Nebula 在 Akulaku 團隊的三個應用。

![Akulaku 的智慧風控實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/ak16.png)

總的來說，Nebula 對 Akulaku 最大的價值是優異的匯入效能，以及可擴充套件性。這裡說下它的匯入速度，非常的快，QPS 能夠達到 11 萬，當然是非同步寫入。這個資料比其他的圖資料庫好很多，當然可擴充套件性也非常好。具體應用上，Nebula Graph 其實應用到 Akulaku 圖學習模型的部署的很多場景中，後續我們會著力於提高這個平臺的穩定性，持續地反饋建議到社群來共建產品。此外，會進一步最佳化圖分析的平臺，降低圖模型、回測和模型部署的難度。

Nebula 在 Akulaku 智慧風控的實踐：圖模型的訓練與部署

相關文章