Nebula?Graph解決風(fēng)控業(yè)務(wù)實(shí)踐
互聯(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)借貸的決策問(wèn)題。
業(yè)務(wù)背景
有別于傳統(tǒng)銀行的信貸業(yè)務(wù)十天、半個(gè)月的申請(qǐng)審核時(shí)長(zhǎng),互聯(lián)網(wǎng)金融借貸第一個(gè)特點(diǎn)便是申請(qǐng)審核非??欤赡苡脩?hù)上一秒剛在手機(jī)端提交授信申請(qǐng),下一秒系統(tǒng)便會(huì)返回授信申請(qǐng)的結(jié)果。此外,互聯(lián)網(wǎng)金融借貸還有一個(gè)特點(diǎn):數(shù)據(jù)信息的真實(shí)性難以保證,用戶(hù)填寫(xiě)的信息:年收入、家庭關(guān)系、聯(lián)系人都會(huì)存在信息不實(shí)的情況。而這兩個(gè)互聯(lián)網(wǎng)金融的特點(diǎn)催生了一個(gè)產(chǎn)業(yè),就是網(wǎng)絡(luò)黑產(chǎn)。通俗來(lái)說(shuō),網(wǎng)絡(luò)黑產(chǎn)就是用戶(hù)薅“借貸”羊毛的行為。因?yàn)榫W(wǎng)絡(luò)借貸隱匿性強(qiáng),一旦黑產(chǎn)賬號(hào)實(shí)施了欺詐行為后,通過(guò)互聯(lián)網(wǎng)很難追蹤到特定的人。此外,由于借貸審批時(shí)效性的關(guān)系,黑產(chǎn)賬號(hào)能很方便地做到走量、薅到更多的錢(qián)。基于此,催生互聯(lián)網(wǎng)金融的風(fēng)控需求,需要系統(tǒng)甄別欺詐場(chǎng)景。
那如何甄別網(wǎng)絡(luò)黑產(chǎn)呢?通過(guò)用戶(hù)與不同實(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)研過(guò)圖數(shù)據(jù)庫(kù)市場(chǎng)的產(chǎn)品,首先篩選出了 JanusGraph、OrientDB。
先來(lái)說(shuō)下 JanusGraph,在眾安金融事業(yè)技術(shù)團(tuán)隊(duì)內(nèi)部 JanusGraph 有一大優(yōu)勢(shì):團(tuán)隊(duì)成員對(duì)它熟悉,不少工程師使用過(guò) JanusGraph,這從某種程度上降低了圖數(shù)據(jù)庫(kù)開(kāi)發(fā)、上手成本。使用過(guò) JanusGraph 的研發(fā)都知道它是一個(gè)分布式圖數(shù)據(jù)庫(kù),存儲(chǔ)、索引依賴(lài)開(kāi)源組件,例如:HBase(存儲(chǔ))、Elasticsearch(索引)。而之前公司的某個(gè)業(yè)務(wù)線曾使用過(guò) JanusGraph,底層搭載線上 HBase 存儲(chǔ)服務(wù),而該業(yè)務(wù)相對(duì)獨(dú)立和其他核心業(yè)務(wù)不存在強(qiáng)依賴(lài)關(guān)系。“不同的國(guó)家有不同的國(guó)情,一旦相同機(jī)制硬搬到不同的國(guó)家,可能會(huì)出現(xiàn)水土不服問(wèn)題”,目前眾安保險(xiǎn)風(fēng)控業(yè)務(wù)的基礎(chǔ)數(shù)據(jù)存儲(chǔ)在 HBase 中,假如風(fēng)控系統(tǒng)使用 JanusGraph 的話,將上百億圖數(shù)據(jù)完全導(dǎo)入 HBase 會(huì)對(duì) HBase 集群產(chǎn)生影響、增加查詢(xún)毛刺,導(dǎo)致其他業(yè)務(wù)線受到影響。此外,在大規(guī)模寫(xiě)入速度性能方面,JanusGraph 導(dǎo)入較慢。綜合上述原因,即便 JanusGraph 具有低上手成本,但其強(qiáng)依賴(lài)其他組件、導(dǎo)入性能差,所以 JanusGraph pass。
在圖數(shù)據(jù)庫(kù)產(chǎn)品調(diào)研過(guò)程中,我們發(fā)現(xiàn) OrientDB 在 DB-Engine 排名較前、功能完善。經(jīng)過(guò)性能測(cè)試,發(fā)現(xiàn)在小規(guī)模數(shù)據(jù)集下使用 OrientDB 體感良好,但一旦 Mock 數(shù)據(jù)過(guò)億,大規(guī)模數(shù)據(jù)集下使用 OrientDB 會(huì)遇到 Server 端頻繁報(bào)錯(cuò)問(wèn)題。查閱 OrientDB 官方文檔無(wú)果之后,眾安保險(xiǎn)向 OrientDB 官方 GitHub 倉(cāng)提交了 issue。但是 OrientDB 反饋?lái)憫?yīng)慢,在提交 issue 的過(guò)程中,我們還發(fā)現(xiàn)大規(guī)模數(shù)據(jù)集 Server 端頻繁報(bào)錯(cuò)問(wèn)題社區(qū)用戶(hù)兩年前提交過(guò),issue 仍未解決處于 open 狀態(tài)。此外,在大規(guī)模數(shù)據(jù)寫(xiě)入性能方面,寫(xiě)入點(diǎn)的速度尚可接受,但寫(xiě)入邊的 QPS 只有 1-2k,用這個(gè)速度開(kāi)始圖數(shù)據(jù)建模的話耗時(shí)將在天級(jí)別,這是不可接受的。綜上,雖然 OrientDB 排名靠前、功能完善,但大規(guī)模數(shù)據(jù)頻繁 Server 報(bào)錯(cuò)、社區(qū) issue 響應(yīng)慢、大規(guī)模寫(xiě)入速度不佳導(dǎo)致最后我們沒(méi)有選擇 OrientDB。
而 Nebula Graph 參與技術(shù)選型的契機(jī)是,在眾安保險(xiǎn)開(kāi)始圖數(shù)據(jù)庫(kù)選型時(shí),咨詢(xún)其他公司(京東、攜程…)從業(yè)人員公司所用圖數(shù)據(jù)庫(kù)時(shí),他們一致推薦 Nebula Graph。因此,Nebula Graph 成為眾安保險(xiǎn)圖數(shù)據(jù)庫(kù)選型的選項(xiàng)之一。而在實(shí)際測(cè)試中,我們發(fā)現(xiàn) Nebula Graph 大規(guī)模寫(xiě)入速度非常快,生產(chǎn)環(huán)境測(cè)試數(shù)據(jù)能達(dá)到 10w+ QPS。此外,Nebula Graph 存儲(chǔ)和索引依賴(lài)于本地 RocksDB 庫(kù),不依賴(lài)于其他大數(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ù)庫(kù)調(diào)研過(guò)程中,我們發(fā)現(xiàn)相較于成熟的諸如 MySQL、Oracle 此類(lèi)的 SQL 數(shù)據(jù)庫(kù),圖數(shù)據(jù)庫(kù)發(fā)展時(shí)間較短,由此產(chǎn)生的問(wèn)題是遇到部分圖數(shù)據(jù)庫(kù)產(chǎn)品問(wèn)題,搜索引擎能提供的信息較少。像之前 OrientDB 的頻繁報(bào)錯(cuò)問(wèn)題,如果社區(qū)未能提供及時(shí)的技術(shù)反饋,對(duì)于使用者來(lái)說(shuō)他可能要花費(fèi)大量時(shí)間來(lái)閱讀源碼去 Debug,人力成本便會(huì)急劇上升、性?xún)r(jià)比極低。
而 Nebula Graph 在社區(qū)支持跟反饋方面給了眾安保險(xiǎn)非常良好的體驗(yàn)。作為他們的客戶(hù),包括在最早期的 1.0,眾安保險(xiǎn)給 Nebula Graph 提交了不少使用問(wèn)題和 bug,Nebula 研發(fā)同學(xué)都能及時(shí)回復(fù)和 fix bug。到 2.0 部署時(shí),我們遇到生產(chǎn)部署問(wèn)題他們也能及時(shí)提供技術(shù)支持。這一點(diǎn)相比于其他的圖數(shù)據(jù)庫(kù)廠商,是非常值得推薦的。這也是我們選擇 Nebula Graph 作為圖數(shù)據(jù)庫(kù)來(lái)支撐眾安保險(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ù)庫(kù),不同的業(yè)務(wù)關(guān)系數(shù)據(jù)存在不同的業(yè)務(wù)庫(kù)中,包括用戶(hù)附件、設(shè)備、 GPS、IP 等等信息。
再上層,是由離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)構(gòu)成的圖數(shù)據(jù)庫(kù)加工清洗層,離線數(shù)倉(cāng)通過(guò) DataX 進(jìn)行每天 T+1 的數(shù)據(jù)回流,回流業(yè)務(wù)庫(kù)的數(shù)據(jù)存到 ODPS 中,Nebula Graph 通過(guò) Spark 來(lái)讀取當(dāng)中數(shù)據(jù)并寫(xiě)入到數(shù)據(jù)庫(kù)中。在實(shí)時(shí)數(shù)倉(cāng)方面,通過(guò)眾安保險(xiǎn)內(nèi)部的監(jiān)聽(tīng)組件 BLCS 將數(shù)據(jù)寫(xiě)到 Kafka,再經(jīng)過(guò) FlinkSQL 搭建的實(shí)時(shí)數(shù)倉(cāng)進(jìn)行數(shù)據(jù)清洗加工,最后通過(guò) Flink 實(shí)時(shí)地寫(xiě)入到 Nebula Graph 中。為了保證數(shù)據(jù)的一致性,實(shí)時(shí)數(shù)倉(cāng)每天進(jìn)行數(shù)據(jù)校驗(yàn),如果數(shù)據(jù)存在不一致,則會(huì)使用離線數(shù)據(jù)補(bǔ)齊缺失的數(shù)據(jù)。
數(shù)據(jù)清洗加工層上面則是存儲(chǔ) & 計(jì)算層,存儲(chǔ)層不用說(shuō)自然是 Nebula Graph。而計(jì)算方面,通過(guò) Nebula Graph 提供的 Spark Connector 組件,將圖數(shù)據(jù)庫(kù)中的數(shù)據(jù)讀取到 Spark 平臺(tái)通過(guò) GraphX 執(zhí)行預(yù)測(cè)模型,最后將結(jié)果寫(xiě)回 Nebula Graph 中。
最后,通過(guò)眾安保險(xiǎn)的微服務(wù)系統(tǒng)將圖數(shù)據(jù)庫(kù)存儲(chǔ) & 計(jì)算對(duì)接給上層圖應(yīng)用,提供圖探索服務(wù)、風(fēng)控特征、個(gè)案調(diào)查、預(yù)測(cè)模型等圖服務(wù)。
關(guān)系圖譜
這里簡(jiǎn)單講解眾安保險(xiǎn)內(nèi)部的圖社群探索的關(guān)系圖譜,通過(guò)上圖的關(guān)系圖譜講解具象化地介紹眾安是如何利用圖數(shù)據(jù)庫(kù)甄別欺詐場(chǎng)景,如何使用圖數(shù)據(jù)庫(kù)實(shí)踐風(fēng)控特性。
上圖有 2 類(lèi)節(jié)點(diǎn):
- 人(藍(lán)色節(jié)點(diǎn))
- 手機(jī)(綠色節(jié)點(diǎn))
存在 3 類(lèi)關(guān)系:
- 人-[申請(qǐng)]->手機(jī)
- 手機(jī)-[聯(lián)系人]->人
- 人-[綁卡]->手機(jī)
第一眼看到上面的圖,很明顯看到 2 個(gè)稠密熱點(diǎn),熱點(diǎn)手機(jī)號(hào)被五、六十填為他的家庭聯(lián)系人的手機(jī)號(hào)。按常識(shí)來(lái)說(shuō),當(dāng)代中國(guó)大多獨(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)伙可能知曉借貸評(píng)分系統(tǒng)中有一環(huán)節(jié)是對(duì)家庭聯(lián)系人的手機(jī)號(hào)進(jìn)行信用評(píng)分,團(tuán)伙希望通過(guò)關(guān)聯(lián)高信用分的手機(jī)號(hào)從而提高信用分。
基于上述特征,我們可以查詢(xún)用戶(hù)所在社群的規(guī)模、用戶(hù)是否在疑似欺詐社群中對(duì)他進(jìn)行一個(gè)初步風(fēng)控判斷。這里講述下,即便某個(gè)用戶(hù)處于異常關(guān)系網(wǎng)絡(luò)中也不代表他是個(gè)欺詐用戶(hù),處于異常社群是個(gè)判斷用戶(hù)是否為欺詐分子的充分不必要條件。因?yàn)榇嬖谝环N可能,用戶(hù)本身并非是欺詐分子,但直系親戚參與了中介代辦、團(tuán)伙欺詐,此時(shí)便會(huì)出現(xiàn)正常用戶(hù)和異常用戶(hù)都存在同一關(guān)系網(wǎng)絡(luò)的情況。
下一步,我們需要深入挖掘用戶(hù)和異常中心的“親密”離散度,探尋它們的路徑距離。通過(guò)結(jié)合 Nebula Graph 本身的路徑查找功能,分析離散度(靠近異常點(diǎn),還是處于社群邊緣)從而判斷某位用戶(hù)是否是有欺詐嫌疑。
這里以手機(jī)號(hào)為例,來(lái)幫助大家理解眾安是如何通過(guò) Nebula 來(lái)識(shí)別用戶(hù)的欺詐場(chǎng)景的。其實(shí)眾安保險(xiǎn)內(nèi)部還有設(shè)備、IP 等等關(guān)系圖譜,這里不展開(kāi)贅述。
圖模型預(yù)測(cè)
這部分來(lái)介紹下圖預(yù)測(cè)模型,
Connected Component(貸前)
Label Propagation(貸中)
Degree Statistical
剛上面部分介紹的關(guān)系圖譜是通過(guò)聯(lián)通分量(Connected Component)算法計(jì)算得出的,主要應(yīng)用在貸前的用戶(hù)授信申請(qǐng)環(huán)節(jié)。
再來(lái)是標(biāo)簽傳播(Label Propagation),不同于聯(lián)通分量,標(biāo)簽傳播更多地應(yīng)用于貸中環(huán)節(jié)。標(biāo)簽傳播主要是通過(guò)一個(gè)確定的點(diǎn) Y 去傳播、衍生出它相關(guān)點(diǎn)。舉個(gè)例子,貸中用戶(hù)名單中某個(gè)用戶(hù)是嚴(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í)別出欺詐用戶(hù)或是嚴(yán)重逾期用戶(hù)。而這個(gè)驗(yàn)證過(guò)程,如果使用傳統(tǒng)數(shù)倉(cāng)通過(guò) ODPS 做深度查詢(xún)的話,無(wú)論在執(zhí)行效率、耗時(shí),還是在 SQL 代碼編寫(xiě)方面,都是一個(gè)非常低效的過(guò)程。但,通過(guò) Nebula Graph 將點(diǎn)數(shù)據(jù)讀取到 GraphX 中進(jìn)行全圖關(guān)系度計(jì)算,將 7 度或者是 10 度關(guān)系以行的形式寫(xiě)回到 ODPS 中,提供給風(fēng)控人員使用,可以幫助他們更快地完成風(fēng)控規(guī)則制定、完成風(fēng)控任務(wù)。
未來(lái)展望
版本規(guī)劃
在主題分享時(shí),眾安保險(xiǎn)所用的 Nebula 版本為 2.0.1,后續(xù) Nebula v2.5.0 中新增水位線 watermark 功能去防止查詢(xún)遇到稠密熱點(diǎn)占用內(nèi)存過(guò)高拖垮 storage 進(jìn)程的情況。眾安保險(xiǎn)這邊會(huì)在測(cè)試環(huán)境部署 v2.5.0 版本進(jìn)行驗(yàn)證,驗(yàn)證通過(guò)之后,業(yè)務(wù)線逐步切到 v2.5.0 版本中。
更多應(yīng)用場(chǎng)景
后續(xù) Nebula 可能應(yīng)用在數(shù)倉(cāng)的表與字段的血緣依賴(lài)、調(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)控的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
influxdb數(shù)據(jù)庫(kù)常用命令及SpringBoot整合
這篇文章主要介紹了influxdb數(shù)據(jù)庫(kù)常用命令及SpringBoot整合,Influxdb是一個(gè)開(kāi)源的分布式時(shí)序、時(shí)間和指標(biāo)數(shù)據(jù)庫(kù),使用go語(yǔ)言編寫(xiě),無(wú)需外部依賴(lài),需要的朋友可以參考下2023-07-07超大數(shù)據(jù)量存儲(chǔ)常用數(shù)據(jù)庫(kù)分表分庫(kù)算法總結(jié)
這篇文章主要介紹了超大數(shù)據(jù)量存儲(chǔ)常用數(shù)據(jù)庫(kù)分表分庫(kù)算法總結(jié),本文講解了按自然時(shí)間來(lái)分表/分庫(kù)、按數(shù)字類(lèi)型hash分表/分庫(kù)、按md5值來(lái)分表/分庫(kù)三種方法,以及分表所帶來(lái)的問(wèn)題探討,需要的朋友可以參考下2015-07-07詳解數(shù)據(jù)庫(kù)中跨庫(kù)數(shù)據(jù)表的運(yùn)算
跨庫(kù)數(shù)據(jù)表,是指邏輯上同一張數(shù)據(jù)表被分別存儲(chǔ)在不同數(shù)據(jù)庫(kù)中。接下來(lái)通過(guò)本文給大家介紹數(shù)據(jù)庫(kù)中跨庫(kù)數(shù)據(jù)表的運(yùn)算方法,感興趣的朋友跟隨小編一起看看吧2018-11-11數(shù)據(jù)庫(kù)設(shè)計(jì)技巧[轉(zhuǎn)]
數(shù)據(jù)庫(kù)設(shè)計(jì)技巧[轉(zhuǎn)]...2007-01-01問(wèn)個(gè)高難度的復(fù)雜查詢(xún)(在一個(gè)時(shí)間段內(nèi)的間隔查詢(xún))
問(wèn)個(gè)高難度的復(fù)雜查詢(xún)(在一個(gè)時(shí)間段內(nèi)的間隔查詢(xún))...2007-04-04最新Navicat?16??Mac版安裝永久激活教程(親測(cè)有效)
這篇文章主要介紹了最新Navicat?16??Mac版安裝永久激活教程(親測(cè)有效),本文通過(guò)圖文并茂的形式給大家介紹的非常詳細(xì),對(duì)Navicat?16?永久激活教程感興趣的朋友一起看看吧2022-08-08