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

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

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

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

為什么選擇 Nebula Graph

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

先來說下 JanusGraph，在眾安金融事業(yè)技術(shù)團(tuán)隊(duì)內(nèi)部 JanusGraph 有一大優(yōu)勢：團(tuán)隊(duì)成員對它熟悉，不少工程師使用過 JanusGraph，這從某種程度上降低了圖數(shù)據(jù)庫開發(fā)、上手成本。使用過 JanusGraph 的研發(fā)都知道它是一個(gè)分布式圖數(shù)據(jù)庫，存儲(chǔ)、索引依賴開源組件，例如：HBase（存儲(chǔ)）、Elasticsearch（索引）。而之前公司的某個(gè)業(yè)務(wù)線曾使用過 JanusGraph，底層搭載線上 HBase 存儲(chǔ)服務(wù)，而該業(yè)務(wù)相對獨(dú)立和其他核心業(yè)務(wù)不存在強(qiáng)依賴關(guān)系。“不同的國家有不同的國情，一旦相同機(jī)制硬搬到不同的國家，可能會(huì)出現(xiàn)水土不服問題”，目前眾安保險(xiǎn)風(fēng)控業(yè)務(wù)的基礎(chǔ)數(shù)據(jù)存儲(chǔ)在 HBase 中，假如風(fēng)控系統(tǒng)使用 JanusGraph 的話，將上百億圖數(shù)據(jù)完全導(dǎo)入 HBase 會(huì)對 HBase 集群產(chǎn)生影響、增加查詢毛刺，導(dǎo)致其他業(yè)務(wù)線受到影響。此外，在大規(guī)模寫入速度性能方面，JanusGraph 導(dǎo)入較慢。綜合上述原因，即便 JanusGraph 具有低上手成本，但其強(qiáng)依賴其他組件、導(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 會(huì)遇到 Server 端頻繁報(bào)錯(cuò)問題。查閱 OrientDB 官方文檔無果之后，眾安保險(xiǎn)向 OrientDB 官方 GitHub 倉提交了 issue。但是 OrientDB 反饋響應(yīng)慢，在提交 issue 的過程中，我們還發(fā)現(xiàn)大規(guī)模數(shù)據(jù)集 Server 端頻繁報(bào)錯(cuò)問題社區(qū)用戶兩年前提交過，issue 仍未解決處于 open 狀態(tài)。此外，在大規(guī)模數(shù)據(jù)寫入性能方面，寫入點(diǎn)的速度尚可接受，但寫入邊的 QPS 只有 1-2k，用這個(gè)速度開始圖數(shù)據(jù)建模的話耗時(shí)將在天級(jí)別，這是不可接受的。綜上，雖然 OrientDB 排名靠前、功能完善，但大規(guī)模數(shù)據(jù)頻繁 Server 報(bào)錯(cuò)、社區(qū) issue 響應(yīng)慢、大規(guī)模寫入速度不佳導(dǎo)致最后我們沒有選擇 OrientDB。

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

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

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

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

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

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

再上層，是由離線數(shù)倉和實(shí)時(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í)時(shí)數(shù)倉方面，通過眾安保險(xiǎn)內(nèi)部的監(jiān)聽組件 BLCS 將數(shù)據(jù)寫到 Kafka，再經(jīng)過 FlinkSQL 搭建的實(shí)時(shí)數(shù)倉進(jìn)行數(shù)據(jù)清洗加工，最后通過 Flink 實(shí)時(shí)地寫入到 Nebula Graph 中。為了保證數(shù)據(jù)的一致性，實(shí)時(shí)數(shù)倉每天進(jìn)行數(shù)據(jù)校驗(yàn)，如果數(shù)據(jù)存在不一致，則會(huì)使用離線數(shù)據(jù)補(bǔ)齊缺失的數(shù)據(jù)。

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

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

關(guān)系圖譜

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

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

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

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

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

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

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

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

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

圖模型預(yù)測

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

Connected Component（貸前）

Label Propagation（貸中）

Degree Statistical

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

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

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

未來展望

版本規(guī)劃

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

更多應(yīng)用場景

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

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

最新評論