互聯(lián)網(wǎng)金融的借貸同傳統(tǒng)信貸業(yè)務(wù)有所區(qū)別，相較于傳統(tǒng)信貸業(yè)務(wù)，互聯(lián)網(wǎng)金融具有響應(yīng)快、數(shù)據(jù)規(guī)模大、風(fēng)險高等特點。眾安保險主要業(yè)務(wù)是做信用保證保險，為了服務(wù)業(yè)務(wù)，大數(shù)據(jù)團(tuán)隊搭建了風(fēng)控系統(tǒng)用于處理互聯(lián)網(wǎng)借貸的決策問題。

業(yè)務(wù)背景

有別于傳統(tǒng)銀行的信貸業(yè)務(wù)十天、半個月的申請審核時長，互聯(lián)網(wǎng)金融借貸第一個特點便是申請審核非常快，可能用戶上一秒剛在手機端提交授信申請，下一秒系統(tǒng)便會返回授信申請的結(jié)果。此外，互聯(lián)網(wǎng)金融借貸還有一個特點：數(shù)據(jù)信息的真實性難以保證，用戶填寫的信息：年收入、家庭關(guān)系、聯(lián)系人都會存在信息不實的情況。而這兩個互聯(lián)網(wǎng)金融的特點催生了一個產(chǎn)業(yè)，就是網(wǎng)絡(luò)黑產(chǎn)。通俗來說，網(wǎng)絡(luò)黑產(chǎn)就是用戶薅“借貸”羊毛的行為。因為網(wǎng)絡(luò)借貸隱匿性強，一旦黑產(chǎn)賬號實施了欺詐行為后，通過互聯(lián)網(wǎng)很難追蹤到特定的人。此外，由于借貸審批時效性的關(guān)系，黑產(chǎn)賬號能很方便地做到走量、薅到更多的錢?；诖耍呱ヂ?lián)網(wǎng)金融的風(fēng)控需求，需要系統(tǒng)甄別欺詐場景。

那如何甄別網(wǎng)絡(luò)黑產(chǎn)呢？通過用戶與不同實體、設(shè)備、GPS 與手機號之間的關(guān)聯(lián)關(guān)系，以及社群發(fā)現(xiàn)查看社群中的個體是否有欺詐風(fēng)險、進(jìn)行反欺詐的個案調(diào)查，能很好地進(jìn)行借貸風(fēng)控。目前，眾安保險的風(fēng)控是基于 Nebula Graph 實現(xiàn)的。

為什么選擇 Nebula Graph

在眾安保險技術(shù)選型之初，團(tuán)隊成員調(diào)研過圖數(shù)據(jù)庫市場的產(chǎn)品，首先篩選出了 JanusGraph、OrientDB。

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

在圖數(shù)據(jù)庫產(chǎn)品調(diào)研過程中，我們發(fā)現(xiàn) OrientDB 在 DB-Engine 排名較前、功能完善。經(jīng)過性能測試，發(fā)現(xiàn)在小規(guī)模數(shù)據(jù)集下使用 OrientDB 體感良好，但一旦 Mock 數(shù)據(jù)過億，大規(guī)模數(shù)據(jù)集下使用 OrientDB 會遇到 Server 端頻繁報錯問題。查閱 OrientDB 官方文檔無果之后，眾安保險向 OrientDB 官方 GitHub 倉提交了 issue。但是 OrientDB 反饋響應(yīng)慢，在提交 issue 的過程中，我們還發(fā)現(xiàn)大規(guī)模數(shù)據(jù)集 Server 端頻繁報錯問題社區(qū)用戶兩年前提交過，issue 仍未解決處于 open 狀態(tài)。此外，在大規(guī)模數(shù)據(jù)寫入性能方面，寫入點的速度尚可接受，但寫入邊的 QPS 只有 1-2k，用這個速度開始圖數(shù)據(jù)建模的話耗時將在天級別，這是不可接受的。綜上，雖然 OrientDB 排名靠前、功能完善，但大規(guī)模數(shù)據(jù)頻繁 Server 報錯、社區(qū) issue 響應(yīng)慢、大規(guī)模寫入速度不佳導(dǎo)致最后我們沒有選擇 OrientDB。

而 Nebula Graph 參與技術(shù)選型的契機是，在眾安保險開始圖數(shù)據(jù)庫選型時，咨詢其他公司（京東、攜程…）從業(yè)人員公司所用圖數(shù)據(jù)庫時，他們一致推薦 Nebula Graph。因此，Nebula Graph 成為眾安保險圖數(shù)據(jù)庫選型的選項之一。而在實際測試中，我們發(fā)現(xiàn) Nebula Graph 大規(guī)模寫入速度非?？欤a(chǎn)環(huán)境測試數(shù)據(jù)能達(dá)到 10w+ QPS。此外，Nebula Graph 存儲和索引依賴于本地 RocksDB 庫，不依賴于其他大數(shù)據(jù)組件，符合業(yè)務(wù)需求。在大數(shù)據(jù)生態(tài)支持方面，Nebula Graph 支持主流的 Spark（nebula-spark-connector）和 Flink（nebula-flink-connector）。在社區(qū)響應(yīng)和反饋時效上，Nebula Graph 也給了我們比較好的體驗。

這里額外講下社區(qū)支持，在整個圖數(shù)據(jù)庫調(diào)研過程中，我們發(fā)現(xiàn)相較于成熟的諸如 MySQL、Oracle 此類的 SQL 數(shù)據(jù)庫，圖數(shù)據(jù)庫發(fā)展時間較短，由此產(chǎn)生的問題是遇到部分圖數(shù)據(jù)庫產(chǎn)品問題，搜索引擎能提供的信息較少。像之前 OrientDB 的頻繁報錯問題，如果社區(qū)未能提供及時的技術(shù)反饋，對于使用者來說他可能要花費大量時間來閱讀源碼去 Debug，人力成本便會急劇上升、性價比極低。

而 Nebula Graph 在社區(qū)支持跟反饋方面給了眾安保險非常良好的體驗。作為他們的客戶，包括在最早期的 1.0，眾安保險給 Nebula Graph 提交了不少使用問題和 bug，Nebula 研發(fā)同學(xué)都能及時回復(fù)和 fix bug。到 2.0 部署時，我們遇到生產(chǎn)部署問題他們也能及時提供技術(shù)支持。這一點相比于其他的圖數(shù)據(jù)庫廠商，是非常值得推薦的。這也是我們選擇 Nebula Graph 作為圖數(shù)據(jù)庫來支撐眾安保險業(yè)務(wù)的根本性原因。

金融風(fēng)控業(yè)務(wù)實踐

下圖為眾安保險基于 Nebula Graph 的風(fēng)控系統(tǒng)架構(gòu)圖，它集數(shù)據(jù)處理、加工清洗、計算、圖服務(wù)應(yīng)用為一體。

如上圖所示，最底層為業(yè)務(wù)庫，不同的業(yè)務(wù)關(guān)系數(shù)據(jù)存在不同的業(yè)務(wù)庫中，包括用戶附件、設(shè)備、 GPS、IP 等等信息。

再上層，是由離線數(shù)倉和實時數(shù)倉構(gòu)成的圖數(shù)據(jù)庫加工清洗層，離線數(shù)倉通過 DataX 進(jìn)行每天 T+1 的數(shù)據(jù)回流，回流業(yè)務(wù)庫的數(shù)據(jù)存到 ODPS 中，Nebula Graph 通過 Spark 來讀取當(dāng)中數(shù)據(jù)并寫入到數(shù)據(jù)庫中。在實時數(shù)倉方面，通過眾安保險內(nèi)部的監(jiān)聽組件 BLCS 將數(shù)據(jù)寫到 Kafka，再經(jīng)過 FlinkSQL 搭建的實時數(shù)倉進(jìn)行數(shù)據(jù)清洗加工，最后通過 Flink 實時地寫入到 Nebula Graph 中。為了保證數(shù)據(jù)的一致性，實時數(shù)倉每天進(jìn)行數(shù)據(jù)校驗，如果數(shù)據(jù)存在不一致，則會使用離線數(shù)據(jù)補齊缺失的數(shù)據(jù)。

數(shù)據(jù)清洗加工層上面則是存儲 & 計算層，存儲層不用說自然是 Nebula Graph。而計算方面，通過 Nebula Graph 提供的 Spark Connector 組件，將圖數(shù)據(jù)庫中的數(shù)據(jù)讀取到 Spark 平臺通過 GraphX 執(zhí)行預(yù)測模型，最后將結(jié)果寫回 Nebula Graph 中。

最后，通過眾安保險的微服務(wù)系統(tǒng)將圖數(shù)據(jù)庫存儲 & 計算對接給上層圖應(yīng)用，提供圖探索服務(wù)、風(fēng)控特征、個案調(diào)查、預(yù)測模型等圖服務(wù)。

關(guān)系圖譜

這里簡單講解眾安保險內(nèi)部的圖社群探索的關(guān)系圖譜，通過上圖的關(guān)系圖譜講解具象化地介紹眾安是如何利用圖數(shù)據(jù)庫甄別欺詐場景，如何使用圖數(shù)據(jù)庫實踐風(fēng)控特性。

上圖有 2 類節(jié)點：

• 人（藍(lán)色節(jié)點）
• 手機（綠色節(jié)點）

存在 3 類關(guān)系：

• 人-[申請]->手機
• 手機-[聯(lián)系人]->人
• 人-[綁卡]->手機

第一眼看到上面的圖，很明顯看到 2 個稠密熱點，熱點手機號被五、六十填為他的家庭聯(lián)系人的手機號。按常識來說，當(dāng)代中國大多獨生子女家庭，加上旁系關(guān)系，也很難出現(xiàn)五、六十個人同時將同一個手機號填為他的家庭聯(lián)系人的手機號。所以，這個手機號關(guān)聯(lián)人可能是欺詐團(tuán)伙分子，黑產(chǎn)團(tuán)伙可能知曉借貸評分系統(tǒng)中有一環(huán)節(jié)是對家庭聯(lián)系人的手機號進(jìn)行信用評分，團(tuán)伙希望通過關(guān)聯(lián)高信用分的手機號從而提高信用分。

基于上述特征，我們可以查詢用戶所在社群的規(guī)模、用戶是否在疑似欺詐社群中對他進(jìn)行一個初步風(fēng)控判斷。這里講述下，即便某個用戶處于異常關(guān)系網(wǎng)絡(luò)中也不代表他是個欺詐用戶，處于異常社群是個判斷用戶是否為欺詐分子的充分不必要條件。因為存在一種可能，用戶本身并非是欺詐分子，但直系親戚參與了中介代辦、團(tuán)伙欺詐，此時便會出現(xiàn)正常用戶和異常用戶都存在同一關(guān)系網(wǎng)絡(luò)的情況。

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

這里以手機號為例，來幫助大家理解眾安是如何通過 Nebula 來識別用戶的欺詐場景的。其實眾安保險內(nèi)部還有設(shè)備、IP 等等關(guān)系圖譜，這里不展開贅述。

圖模型預(yù)測

這部分來介紹下圖預(yù)測模型，

Connected Component（貸前）

Label Propagation（貸中）

Degree Statistical

剛上面部分介紹的關(guān)系圖譜是通過聯(lián)通分量（Connected Component）算法計算得出的，主要應(yīng)用在貸前的用戶授信申請環(huán)節(jié)。

再來是標(biāo)簽傳播（Label Propagation），不同于聯(lián)通分量，標(biāo)簽傳播更多地應(yīng)用于貸中環(huán)節(jié)。標(biāo)簽傳播主要是通過一個確定的點 Y 去傳播、衍生出它相關(guān)點。舉個例子，貸中用戶名單中某個用戶是嚴(yán)重逾期人員，這個人員便是打上逾期標(biāo)簽的確定點 Y，結(jié)合既定的風(fēng)控規(guī)則查看點 Y 關(guān)聯(lián)延伸的點中哪些點出現(xiàn)相似逾期行為，從而判斷這些點是否屬于嚴(yán)重逾期的社群。這便是貸中的標(biāo)簽傳播算法。

最后一個算法是 Degree Statistical，全圖關(guān)系度數(shù)，主要供風(fēng)控人員使用。風(fēng)控人員在做風(fēng)控特征時，可能會提出幾十、上百個圖特征，基于這些特征數(shù)據(jù)需要用歷史的數(shù)據(jù)去驗證，查看哪些特征可以真正地識別出欺詐用戶或是嚴(yán)重逾期用戶。而這個驗證過程，如果使用傳統(tǒng)數(shù)倉通過 ODPS 做深度查詢的話，無論在執(zhí)行效率、耗時，還是在 SQL 代碼編寫方面，都是一個非常低效的過程。但，通過 Nebula Graph 將點數(shù)據(jù)讀取到 GraphX 中進(jìn)行全圖關(guān)系度計算，將 7 度或者是 10 度關(guān)系以行的形式寫回到 ODPS 中，提供給風(fēng)控人員使用，可以幫助他們更快地完成風(fēng)控規(guī)則制定、完成風(fēng)控任務(wù)。

未來展望

版本規(guī)劃

在主題分享時，眾安保險所用的 Nebula 版本為 2.0.1，后續(xù) Nebula v2.5.0 中新增水位線 watermark 功能去防止查詢遇到稠密熱點占用內(nèi)存過高拖垮 storage 進(jìn)程的情況。眾安保險這邊會在測試環(huán)境部署 v2.5.0 版本進(jìn)行驗證，驗證通過之后，業(yè)務(wù)線逐步切到 v2.5.0 版本中。

更多應(yīng)用場景

后續(xù) Nebula 可能應(yīng)用在數(shù)倉的表與字段的血緣依賴、調(diào)度平臺任務(wù)關(guān)系的管理中，眾安保險基礎(chǔ)平臺部的同學(xué)正在動手用 Nebula Graph 去替換已有的傳統(tǒng)實現(xiàn)方案。

以上就是Nebula Graph解決風(fēng)控業(yè)務(wù)實踐的詳細(xì)內(nèi)容，更多關(guān)于Nebula Graph解決風(fēng)控的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論