当金融风控遇上人工智能，众安金融的实时特征平台实践
導(dǎo)讀：隨著企業(yè)數(shù)字化轉(zhuǎn)型升級，線上業(yè)務(wù)呈現(xiàn)多場景、多渠道、多元化的特征。數(shù)據(jù)要素價值的挖掘可謂分秒必爭，業(yè)務(wù)也對數(shù)據(jù)的時效性和靈活性提出了更高的要求。在龐大分散、高并發(fā)的數(shù)據(jù)來源背景下，數(shù)據(jù)的實(shí)時處理能力成為企業(yè)提升競爭力的一大因素。今天分享的是眾安金融實(shí)時特征平臺實(shí)踐。
下面的介紹分為四個部分：
分享嘉賓｜郭育波 眾安 高級技術(shù)專家
眾安金融 MLOps 簡介
什么是 MLOps
（1）定義
MLOps 是將機(jī)器學(xué)習(xí)、數(shù)據(jù)工程和 DevOps 融合在一起，從而實(shí)現(xiàn)機(jī)器學(xué)習(xí)模型的高效迭代和持續(xù)穩(wěn)定地應(yīng)用于生產(chǎn)業(yè)務(wù)的一套方法架構(gòu)。所以它是一套實(shí)踐方法論，是一套架構(gòu)方案。
（2）協(xié)作團(tuán)隊
① 數(shù)據(jù)產(chǎn)品團(tuán)隊：定義業(yè)務(wù)目標(biāo)，衡量業(yè)務(wù)價值。
② 數(shù)據(jù)工程團(tuán)隊：采集業(yè)務(wù)數(shù)據(jù)，然后對數(shù)據(jù)進(jìn)行清洗轉(zhuǎn)換。
③ 數(shù)據(jù)科學(xué)家團(tuán)隊：構(gòu)建 ML 解決方案，開發(fā)相應(yīng)的特征模型。
④ 數(shù)據(jù)應(yīng)用團(tuán)隊：模型應(yīng)用，對特征進(jìn)行持續(xù)的監(jiān)控。
眾安金融 MLOps 流程說明
（1）樣本準(zhǔn)備，產(chǎn)品業(yè)務(wù)團(tuán)隊定義業(yè)務(wù)范圍，確定建模的目標(biāo)，選擇樣本人群準(zhǔn)備訓(xùn)練集。
（2）數(shù)據(jù)處理，需要對數(shù)據(jù)進(jìn)行缺失值、異常值、錯誤值、數(shù)據(jù)格式的清洗，使用連續(xù)變量、離散變量、時間序列等進(jìn)行數(shù)據(jù)轉(zhuǎn)換。
（3）特征開發(fā)，數(shù)據(jù)處理完成后就可以進(jìn)行特征衍生，金融特征主要通過審批邏輯衍生，行為總結(jié)量化，窮舉法，去量綱，分箱，WoE，降維，One-Hot 編碼等進(jìn)行特征衍生，之后依據(jù)特征質(zhì)量，比如特征指標(biāo)（KS、IV、PSI）或者預(yù)計逾期率等進(jìn)行特征篩選。
（4）模型開發(fā)，要進(jìn)行算法的選擇和模型的擬合。
（5）模型訓(xùn)練，使用測試數(shù)據(jù)集進(jìn)行模型算法的測試驗證，進(jìn)行參數(shù)的調(diào)優(yōu)。
（6）模型應(yīng)用，模型開發(fā)好之后就需要進(jìn)行線上化的一個部署。
（7）模型監(jiān)控，上線后需要持續(xù)的監(jiān)控和模型的迭代優(yōu)化。
眾安金融為什么需要建設(shè) MLOps?
眾安金融，一方面為普惠人群提供公信征信支持，另一方面也為銀行等資金機(jī)構(gòu)來提供風(fēng)險緩釋，助力普惠金融。眾安金融為無抵押的純線上消費(fèi)貸款平臺提供信用保證保險服務(wù)，也為其他金融機(jī)構(gòu)提供信用保證保險服務(wù)。
眾安保險作為保險公司在其中承擔(dān)理賠的責(zé)任，所以就要求我們需要對風(fēng)險進(jìn)行全面識別、準(zhǔn)確計量、嚴(yán)密監(jiān)控。我們搭建了以大數(shù)據(jù)為基礎(chǔ)、以風(fēng)控規(guī)則與模型為策略，以系統(tǒng)平臺為工具的大數(shù)據(jù)風(fēng)控體系。通過利用大數(shù)據(jù)與個人信用的關(guān)聯(lián)挖掘出大量的用戶風(fēng)險特征和風(fēng)險模型，從而提升風(fēng)控的預(yù)測能力。
隨著風(fēng)控策略的精細(xì)化，模型應(yīng)用的規(guī)模化，特征使用的實(shí)時化，對我們的特征開發(fā)和模型應(yīng)用提出了更快速更實(shí)時的要求，所以我們就開始嘗試進(jìn)行特征平臺體系化的實(shí)踐。
眾安金融 MLOps 體系
（1）大數(shù)據(jù)平臺：數(shù)據(jù)開發(fā)工程師使用大數(shù)據(jù)平臺的能力采集到相關(guān)的業(yè)務(wù)數(shù)據(jù)，構(gòu)建基于主題域的離線數(shù)據(jù)體系，同時把相應(yīng)的數(shù)據(jù)回流同步到在線 NoSQL 存儲引擎，提供給實(shí)時特征平臺使用。
（2）特征工程：數(shù)據(jù)科學(xué)家在大數(shù)據(jù)平臺進(jìn)行特征工程的建設(shè)，使用離線數(shù)倉進(jìn)行特征的挖掘和特征的選擇。
（3）機(jī)器學(xué)習(xí)平臺：數(shù)據(jù)科學(xué)家借助機(jī)器學(xué)習(xí)平臺可以進(jìn)行一站式的模型開發(fā)和應(yīng)用。
（4）實(shí)時特征平臺：開發(fā)好的特征和模型需要在實(shí)時特征平臺進(jìn)行注冊，在實(shí)時特征平臺配置好相關(guān)的信息后，就可以通過實(shí)時特征平臺的數(shù)據(jù)服務(wù)能力，提供上游業(yè)務(wù)的特征查詢和模型應(yīng)用的能力。
實(shí)時特征平臺架構(gòu)設(shè)計
眾安金融特征應(yīng)用場景
眾安金融實(shí)時特征平臺服務(wù)于金融業(yè)務(wù)全流程，包含金融線上的核心業(yè)務(wù)場景如登錄，準(zhǔn)入，授信，支用，提額等實(shí)時前臺場景，后臺業(yè)務(wù)場景更多是批量的特征調(diào)用場景，此外還有催收也有對于特征和模型的使用，一開始特征平臺的初衷是為風(fēng)控體系服務(wù)，隨著業(yè)務(wù)的發(fā)展，模型也逐漸使用到了用戶營銷場景和一些資源位的用戶推薦服務(wù)中。這里值得注意的是，對風(fēng)控業(yè)務(wù)了解的同學(xué)就會知道，一次風(fēng)控策略會有多個風(fēng)控規(guī)則，每個風(fēng)控規(guī)則會查詢多個特征數(shù)據(jù)，所以一次業(yè)務(wù)交易對于實(shí)時特征平臺來說可能就會放大到幾百倍的調(diào)用。
眾安金融特征數(shù)據(jù)分類
（1）交易行為數(shù)據(jù)：包含授信，借款申請、還款的數(shù)據(jù)，調(diào)額和逾期數(shù)據(jù)等業(yè)務(wù)數(shù)據(jù)。
（2）三方征信數(shù)據(jù)：需要對接三方征信機(jī)構(gòu)的接口。
（3）設(shè)備抓取數(shù)據(jù)：在用戶授權(quán)允許的情況下獲取設(shè)備相關(guān)信息。
（4）用戶行為數(shù)據(jù)：通過用戶行為埋點(diǎn)獲取。
實(shí)時特征平臺核心能力
面對眾多的特征數(shù)據(jù)源，這就要求我們實(shí)時特征平臺具備豐富的數(shù)據(jù)接入能力，實(shí)時的數(shù)據(jù)處理能力，對于大量的特征需求也要求特征平臺具備高效的特征加工配置化能力，實(shí)時的業(yè)務(wù)調(diào)用要求平臺有快速的系統(tǒng)響應(yīng)能力，我們也是圍繞這些核心能力的要求進(jìn)行特征平臺的技術(shù)選型和架構(gòu)設(shè)計。經(jīng)過了技術(shù)迭代選型，我們采用了 Flink 作為實(shí)時計算引擎，使用阿里云的 TableStore 作為高性能的存儲引擎，然后通過微服務(wù)化的架構(gòu)實(shí)現(xiàn)了系統(tǒng)的服務(wù)化和平臺化。
實(shí)時特征平臺的業(yè)務(wù)架構(gòu)
這張圖是我們的實(shí)時特征平臺的業(yè)務(wù)架構(gòu)圖，可以看到圖的底層是特征數(shù)據(jù)源層，中間層是實(shí)時特征平臺的核心功能層，上層是整個特征平臺體系的業(yè)務(wù)應(yīng)用層，特征平臺主要有四個數(shù)據(jù)源：
（1）征信數(shù)據(jù)網(wǎng)關(guān)：提供人行征信等征信機(jī)構(gòu)的用戶信用數(shù)據(jù)，需要通過實(shí)時的接口對接來查詢征信數(shù)據(jù)。
（2）三方數(shù)據(jù)平臺：提供外部數(shù)據(jù)服務(wù)商的數(shù)據(jù)，通過調(diào)用三方數(shù)據(jù)接口服務(wù)完成實(shí)時數(shù)據(jù)對接。
（3）實(shí)時計算平臺：實(shí)時接入業(yè)務(wù)系統(tǒng)的交易數(shù)據(jù)，用戶行為數(shù)據(jù)和抓取設(shè)備數(shù)據(jù)，通過實(shí)時計算后回流到 NoSQL 在線存儲引擎。
（4）離線調(diào)用平臺：離線數(shù)據(jù)在阿里云的 MaxComputer 計算后同步到 NoSQL 存儲，實(shí)現(xiàn)歷史數(shù)據(jù)的回流，從而支撐用戶全業(yè)務(wù)時間序列的特征計算，此外一些非實(shí)時指標(biāo)也需要在離線數(shù)倉加工完成后再回流到 NoSQL 存儲引擎。
實(shí)時特征平臺的核心功能：
（1）特征網(wǎng)關(guān)：特征網(wǎng)關(guān)是特征查詢的出入口，具備鑒權(quán)限流、特征數(shù)據(jù)編排等功能。
（2）特征配置：為了支持特征的快速上線，特征平臺實(shí)現(xiàn)了特征的配置化能力，包含三方數(shù)據(jù)特征配置、實(shí)時業(yè)務(wù)特征配置、互斥規(guī)則特征配置、模型特征配置能力。
（3）特征計算：特征計算是通過微服務(wù)化的子系統(tǒng)來實(shí)現(xiàn)的，主要有三方特征計算、實(shí)時特征計算、反欺詐特征計算、模型特征計算。
（4）特征管理：特征管理后臺提供了特征變量生命周期管理能力，模型的元數(shù)據(jù)管理，還有特征跑批的任務(wù)管理。
（5）特征監(jiān)控：具備特征調(diào)用全鏈路查詢能力，對于特征計算失敗、特征值異常值、模型 PSI 值波動進(jìn)行實(shí)時告警，此外也提供了特征使用情況等統(tǒng)計分析大盤報表。
三方數(shù)據(jù)實(shí)時接入方案
（1）查詢方式：調(diào)用三方征信機(jī)構(gòu)的實(shí)時接口獲取報文數(shù)據(jù)然后進(jìn)行數(shù)據(jù)處理獲取特征結(jié)果，出于降本考慮，我們還會實(shí)現(xiàn)一套緩存機(jī)制，對于離線場景減少調(diào)用三方的次數(shù)。
（2）創(chuàng)新點(diǎn)：三方數(shù)據(jù)接入引擎可以通過純配置化的方式接入三方的數(shù)據(jù)接口，通過特征加工引擎實(shí)現(xiàn)自動化的特征生成，通過可視化界面提供配置化的能力，最后通過接口提供給上游使用三方特征計算服務(wù)。
（3）解決的難點(diǎn)：三方數(shù)據(jù)與配置化接入的難點(diǎn)是數(shù)據(jù)服務(wù)商的加密方式、簽名機(jī)制多樣性、復(fù)雜性，三方數(shù)據(jù)接入引擎通過內(nèi)置一套加解密函數(shù)和支持自定義函數(shù)的能力，結(jié)合函數(shù)的鏈?zhǔn)浇M合方式，完成了各種復(fù)雜的三方數(shù)據(jù)加解密的配置化的實(shí)現(xiàn)。
業(yè)務(wù)數(shù)據(jù)實(shí)時接入
實(shí)時業(yè)務(wù)數(shù)據(jù)的接入由兩部分組成，首先是通過 Flink 實(shí)時監(jiān)聽業(yè)務(wù)數(shù)據(jù)庫的 Binlog 數(shù)據(jù)寫入到實(shí)時數(shù)倉，還有一部分使用 Spark 完成歷史數(shù)據(jù)的回補(bǔ)，結(jié)合離線數(shù)據(jù)和實(shí)時數(shù)據(jù)就可以支持基于全量時序數(shù)據(jù)的特征加工能力，為了支持高性能的實(shí)時特征查詢，實(shí)時數(shù)據(jù)和離線數(shù)據(jù)都會回流到 NoSQL 存儲引擎。對于不同的數(shù)據(jù)，我們也會考慮不同的存儲引擎，業(yè)務(wù)交易數(shù)據(jù)主要是用 TableStore 作為存儲引擎，用戶行為特征數(shù)據(jù)使用 Redis 為主，用戶關(guān)系圖譜數(shù)據(jù)用圖數(shù)據(jù)庫進(jìn)行存儲，從整個流程來看，現(xiàn)在的數(shù)據(jù)體系是采用成熟的 Lambda 架構(gòu)。
實(shí)時特征平臺的系統(tǒng)架構(gòu)
我們實(shí)時特征平臺的架構(gòu)基本如上圖，上游業(yè)務(wù)經(jīng)過特征網(wǎng)關(guān)進(jìn)行特征的查詢，特征網(wǎng)關(guān)會進(jìn)行特征查詢權(quán)限的驗證，限流控制和特征查詢?nèi)蝿?wù)異步分發(fā)，特征網(wǎng)關(guān)首先根據(jù)特征元數(shù)據(jù)信息路由到不同的特征數(shù)據(jù)源，從特征數(shù)據(jù)源查詢到原始數(shù)據(jù)之后會再路由到不同的特征計算服務(wù)進(jìn)行特征的加工。三方特征是從三方數(shù)據(jù)平臺和征信網(wǎng)關(guān)查詢到的原始報文數(shù)據(jù)之后加工成為對應(yīng)的特征；業(yè)務(wù)特征計算用于加工內(nèi)部業(yè)務(wù)系統(tǒng)的實(shí)時特征。
信貸特征是通過實(shí)時業(yè)務(wù)數(shù)據(jù)同步后進(jìn)行特征加工計算，離線特征服務(wù)是在離線數(shù)倉 MaxComputer 完成的特征加工計算。反欺詐特征計算用于對用戶登錄設(shè)備信息，用戶行為數(shù)據(jù)和用戶關(guān)系圖譜等相關(guān)特征的加工。
在基礎(chǔ)的三方特征，業(yè)務(wù)特征計算完成后，就可以直接提供給上游業(yè)務(wù)使用，此外模型服務(wù)也會依賴這些基礎(chǔ)特征，模型特征計算是借助機(jī)器學(xué)習(xí)平臺的能力來實(shí)現(xiàn)的，我們的機(jī)器學(xué)習(xí)平臺提供了模型的訓(xùn)練，測試，發(fā)布等一體化功能，特征平臺集成了機(jī)器學(xué)習(xí)平臺的能力從而實(shí)現(xiàn)了模型特征的自動化和配置化。
實(shí)時業(yè)務(wù)特征計算詳解
特征實(shí)時計算方案選型
我覺得實(shí)時特征計算方案有兩種，第一種實(shí)時同步原始業(yè)務(wù)數(shù)據(jù)，然后在實(shí)時計算任務(wù)同時實(shí)現(xiàn)特征的加工，這是傳統(tǒng)的 ETL 模式，這種方式的優(yōu)點(diǎn)是特征查詢非常高效、查詢性能好，但是實(shí)時任務(wù)計算復(fù)雜，需要大量實(shí)時計算資源，需要特征衍生的話也是比較困難；另外一個方式是實(shí)時同步原始業(yè)務(wù)明細(xì)數(shù)據(jù)，但是特征加工是即時進(jìn)行，也就是說特征查詢時再進(jìn)行特征的計算，這樣方式特征查詢計算繁重，需要高速特征查詢引擎支持，但是實(shí)時任務(wù)比較簡單，特征衍生也比較方便，這個較新的 ELT 模式。出于我們業(yè)務(wù)對于特征頻繁衍生的要求和節(jié)省實(shí)時計算資源的考慮，我們選擇了第二種 ELT 的即時加工特征的方案。
實(shí)時業(yè)務(wù)特征數(shù)據(jù)流
實(shí)時特征數(shù)據(jù)流通過 Kafka+Flink 實(shí)現(xiàn)實(shí)時數(shù)據(jù)的同步，同時也使用 Spark 從離線數(shù)倉數(shù)據(jù)回補(bǔ)完成全量時序數(shù)據(jù)的采集，實(shí)時業(yè)務(wù)數(shù)據(jù)主要是用 TableStore 作為存儲引擎，結(jié)合實(shí)時特征計算引擎和 ID-Mapping 的多主體查詢能力實(shí)現(xiàn)了特征的配置化生成。
除了通過 Flink 實(shí)時采集的數(shù)據(jù)外，還有部分?jǐn)?shù)據(jù)需要調(diào)用業(yè)務(wù)系統(tǒng)的接口來獲取，這種數(shù)據(jù)也可以注冊為特征數(shù)據(jù)引擎的元數(shù)據(jù)，和存儲在 TableStore 里的數(shù)據(jù)一樣進(jìn)行配置化使用。我們采用了阿里云的 TableStore 這個比較穩(wěn)定的高速查詢引擎來支持實(shí)時特征查詢，但是其實(shí)云產(chǎn)品的成本也需要考慮的，所以大家也需要根據(jù)本身的現(xiàn)狀選擇合適的方案。
實(shí)時數(shù)據(jù)核心數(shù)據(jù)設(shè)計
由于我們存在多條產(chǎn)品線，每個產(chǎn)品線的用戶主鍵也都不同，而金融業(yè)務(wù)場景主要是以用戶身份證，用戶手機(jī)號等維度進(jìn)行特征的查詢，因此我們抽象了一套用戶實(shí)體關(guān)系的 ID-Mapping 表，實(shí)現(xiàn)了身份證、手機(jī)號等維度到用戶主鍵的關(guān)聯(lián)關(guān)系，特征查詢時首先會根據(jù)特征入?yún)⒉樵?ID-Mapping 表獲取用戶 ID，然后再根據(jù)用戶 ID 查詢用戶業(yè)務(wù)明細(xì)數(shù)據(jù)，主要的業(yè)務(wù)明細(xì)數(shù)據(jù)包含用戶授信數(shù)據(jù)、支用明細(xì)、還款明細(xì)、額度明細(xì)、逾期明細(xì)的用戶業(yè)務(wù)數(shù)據(jù)。
這里我們踩過的一個坑是主副表同時更新的場景，我們把主副表存儲為一份特征數(shù)據(jù)，我們主要是使用 column family 的方式存儲數(shù)據(jù)，所以在高并發(fā)的場景，可能會造成主副表同時更新帶來的不一致的情況，我們現(xiàn)在是通過一個窗口任務(wù)實(shí)現(xiàn)數(shù)據(jù)的補(bǔ)償。
下圖是主要的業(yè)務(wù)數(shù)據(jù)圖：
實(shí)時特征計算引擎
早期的特征加工是通過開發(fā)人員寫代碼來實(shí)現(xiàn)的，隨著特征需求增加，為了支撐特征的快速上線，我們借助表達(dá)式語言和 Groovy 實(shí)現(xiàn)了一套基于特征計算函數(shù)的特征配置化能力，結(jié)合 ID-Mapping 實(shí)現(xiàn)了一個特征計算引擎，計算過程可以分為如下幾步：
（1）創(chuàng)建實(shí)時 Flink 任務(wù)把用戶關(guān)系數(shù)據(jù)同步到 ID-Mapping 表，從而支持用戶多維數(shù)據(jù)查詢。
（2）創(chuàng)建實(shí)時 Flink 任務(wù)把用戶業(yè)務(wù)數(shù)據(jù)回流到阿里云的 TableStore，實(shí)現(xiàn)業(yè)務(wù)明細(xì)數(shù)據(jù)的實(shí)時同步。
（3）在特征平臺的實(shí)時特征配置頁面把上一步同步到 TableStore 的用戶業(yè)務(wù)數(shù)據(jù)表注冊為特征計算引擎邏輯數(shù)據(jù)。
（4）接下來在特征計算配置頁面選擇相關(guān)的特征元數(shù)據(jù)，填寫特征基礎(chǔ)信息，特征加工的函數(shù)，通過測試和上線等過程后這個特征就可以提供在線使用。
（5）特征查詢時首先會根據(jù)特征查詢?nèi)雲(yún)⒉樵?ID-Mapping 表獲取用戶 ID，然后根據(jù)用戶 ID 查詢 TableStore 里面的用戶明細(xì)業(yè)務(wù)數(shù)據(jù)，特征計算引擎會把根據(jù)配置的特征計算表達(dá)式進(jìn)行特征數(shù)據(jù)查詢，計算出來的數(shù)據(jù)結(jié)果就是特征值，就如第四步提到的，會把特征組下面的所有特征都計算出來。
反欺詐場景的特征應(yīng)用
反欺詐特征分類
隨著金融欺詐風(fēng)險不斷擴(kuò)大，反欺詐形勢也越來越嚴(yán)峻，特征平臺也不可避免的需要支持反欺詐特征的查詢需求，下面是我們對反欺詐特征分類的總結(jié)：
（1）用戶行為特征：主要是基于埋點(diǎn)的用戶行為數(shù)據(jù)進(jìn)行特征的衍生。比如用戶啟動的 APP 的次數(shù)、頁面訪問的時長，還有點(diǎn)擊的次數(shù)和在某個輸入框輸入的次數(shù)等。
（2）位置識別特征：主要是基于用戶的實(shí)時地理位置信息，加上 GeoHash 算法能力，實(shí)現(xiàn)位置特征的數(shù)據(jù)計算。
（3）設(shè)備關(guān)聯(lián)特征：主要是通過用戶關(guān)系圖譜來實(shí)現(xiàn)，通過獲取同一個設(shè)備下關(guān)聯(lián)到用戶的情況，可以快速地定位羊毛黨等欺詐行為。
（4）用戶圖譜關(guān)系特征：通過實(shí)時獲取用戶在登錄、注冊、授信、支用等關(guān)鍵業(yè)務(wù)場景的設(shè)備信息，結(jié)合用戶三要素和他的一些聯(lián)系人信息，構(gòu)建圖譜關(guān)系，然后通過查詢用戶的鄰邊關(guān)系、用戶關(guān)聯(lián)的用戶是否有黑灰名單的情況，進(jìn)行風(fēng)險識別。
（5）用戶社群特征：通過判斷社群的大小、社群里用戶行為的表現(xiàn)，提煉社群規(guī)則特征。
實(shí)時反欺詐特征數(shù)據(jù)流
反欺詐特征計算的數(shù)據(jù)流程和實(shí)時特征計算數(shù)據(jù)流程類似，除了數(shù)據(jù)源來源于實(shí)時業(yè)務(wù)數(shù)據(jù)外，反欺詐場景更關(guān)注是埋點(diǎn)的用戶行為數(shù)據(jù)，抓取的用戶設(shè)備數(shù)據(jù)，提取的用戶關(guān)聯(lián)關(guān)系數(shù)據(jù)，用戶行為的數(shù)據(jù)會通過埋點(diǎn)平臺（XFlow）上報到 Kafka，這些數(shù)據(jù)也會使用 Flink 進(jìn)行實(shí)時加工計算，不過和實(shí)時業(yè)務(wù)特征處理的區(qū)別是反欺詐特征是在實(shí)時數(shù)倉里面直接計算好之后存儲到 Redis，圖數(shù)據(jù)庫等存儲里面，這個是為了滿足反欺詐特征查詢的高性能要求，此外反欺詐場景也更關(guān)注實(shí)時的數(shù)據(jù)變化。從上圖可以了解到，反欺詐特征通過 HTTP API 的接口方式為特征網(wǎng)關(guān)提供特征計算服務(wù)。
關(guān)系圖譜架構(gòu)圖
用戶關(guān)系圖譜的建設(shè)情況，整體設(shè)計思路如下：
（1）首先是對于圖的數(shù)據(jù)源的選擇，要想構(gòu)建比較有價值的用戶關(guān)系圖譜，一定要找到準(zhǔn)確的數(shù)據(jù)進(jìn)行圖建模。關(guān)系圖譜的數(shù)據(jù)源主要來自用戶數(shù)據(jù)，比如手機(jī)號、身份證、設(shè)備信息、用戶三要素，聯(lián)系人等相關(guān)數(shù)據(jù)
（2）第二就是圖數(shù)據(jù)存儲引擎選型，需要關(guān)注的是引擎的穩(wěn)定性，數(shù)據(jù)的實(shí)時性，集成的方便性，查詢的高性能，存儲引擎的選擇非常重要，現(xiàn)在市面上有不少圖數(shù)據(jù)庫的技術(shù)，選型的過程中其實(shí)也碰到過不少的坑，一開始我們選擇的 OrientDB，在大數(shù)據(jù)量的情況下就出現(xiàn)了很多不穩(wěn)定的問題，所以需要重點(diǎn)考慮大數(shù)據(jù)量的處理能力和存儲引擎的穩(wěn)定性，一定要經(jīng)過全面的技術(shù)調(diào)研才能進(jìn)行生產(chǎn)的實(shí)踐.
（3）其次就是需要考慮圖數(shù)據(jù)相關(guān)的算法支撐能力，除了基本的相鄰邊查詢能力，是否有比較豐富的圖算法支持，比如在反欺詐場景使用到的是社群發(fā)現(xiàn)算法
（4）最后需要通過 API 的方式提供圖數(shù)據(jù)服務(wù)，反欺詐應(yīng)用場景提供圖數(shù)據(jù)特征的服務(wù)外，還可以賦能給營銷推薦場景
經(jīng)過多方位的選型調(diào)研，最終選擇了 NebulaGraph 作為圖數(shù)據(jù)庫，它采用的是 shared-nothing 的分布式存儲，能夠支持萬億級別的一個大規(guī)模的機(jī)型的圖的計算。NebulaGraph 的相關(guān)信息可以從他們的官網(wǎng)了解，這里就不贅述了。
反欺詐圖特征提取
通過模型團(tuán)隊對用戶關(guān)系圖譜的數(shù)據(jù)挖掘，從用戶社群的年齡分布，消費(fèi)預(yù)估水平分布等多維度統(tǒng)計數(shù)據(jù)出發(fā)，我們提取出了一些圖特征，這邊列舉了一批以供大家參考：
（1）第一方欺詐：通過圖認(rèn)為同一個人申請多次，而且每次提交的聯(lián)系人等關(guān)聯(lián)信息都不太一致，可以認(rèn)為它是有第一方欺詐的嫌疑。
（2）疑似中介代辦：有部分人的申請人都關(guān)聯(lián)到了相同一個聯(lián)系人的手機(jī)號。
（3）疑似信息冒用：就是一個人的手機(jī)號可能被很多人使用，可能它出現(xiàn)了信息的泄露。
（4）疑似團(tuán)伙欺詐：看關(guān)系圖譜社群節(jié)點(diǎn)的規(guī)模數(shù)量是否超過了一定的規(guī)模。
反欺詐策略規(guī)則。通過一兩個特征可能沒辦法精確地對反欺詐行為進(jìn)行定位，需要來組合多類的特征，形成反欺詐策略規(guī)則，從而在多方面提升對用戶反欺詐識別的準(zhǔn)確度。
問答環(huán)節(jié)
Q1：Flink 的源數(shù)據(jù)由 Kafka 輸入，那平臺是否能實(shí)現(xiàn)多條 Kafka 消息之間的關(guān)聯(lián)查詢？
A1：整個實(shí)時業(yè)務(wù)的采集我們是使用 Flink 完成明細(xì)數(shù)據(jù)的清洗，把 DWD 層的數(shù)據(jù)回流到 TableStore，然后通過實(shí)時特征計算引擎來實(shí)現(xiàn)數(shù)據(jù)的關(guān)聯(lián)，設(shè)置多個計算因子，然后通過這種方式把多條數(shù)據(jù)進(jìn)行關(guān)聯(lián)，支持最終特征的產(chǎn)生。比較少在 Flink 里面進(jìn)行這個數(shù)據(jù)的關(guān)聯(lián) Join 查詢，也就是現(xiàn)在比較流行的 ELT的模式。
Q2：特征實(shí)時計算方案，貴公司選擇方案 2，在變量很多的情況下，怎么保證接口響應(yīng)的效率？
A2：特征計算是基于特征組維度，一個特征組下面可能會有幾十上百個特征，我們現(xiàn)在的這個計算框架主要性能的消耗是在對于特征原始數(shù)據(jù)的查詢，只要把原始數(shù)據(jù)查詢出來，特征口徑計算都是在內(nèi)存里面完成。那么就需要有底層高性能的查詢引擎來支持，我們現(xiàn)在依賴于阿里云的 TableStore 查詢引擎來實(shí)現(xiàn)快速的數(shù)據(jù)查詢能力。
Q3：請教一下，使用無監(jiān)督的異常檢測算法，比如孤立森林或者 LOF，應(yīng)該怎么處理 APP 埋點(diǎn)行為數(shù)據(jù)，怎樣提取特征會比較有效果？
A3：對于模型的算法不是我在行的，我的理解是可以從特征質(zhì)量和特征算法指標(biāo)入手，但是沒有通用的一個解決方案，要根據(jù)實(shí)際的業(yè)務(wù)數(shù)據(jù)進(jìn)行算法的驗證和調(diào)優(yōu)，才能夠得到答案。
Q4：關(guān)系圖譜的社區(qū)發(fā)現(xiàn)算法有什么有效的效果評價方法嗎？然后這邊一般采用的社區(qū)發(fā)現(xiàn)算法是哪種？
A4：現(xiàn)在采用的是聯(lián)通分量算法。我們關(guān)系圖譜不只是在反欺詐特征計算使用，也給反欺詐團(tuán)隊來做反欺詐調(diào)查使用，他們會根據(jù)有欺詐嫌疑的用戶，對我們的關(guān)系圖譜進(jìn)行反向的驗證，通過實(shí)際的調(diào)研來看算法的效果。
我們是使用 Spark GraphX 的連通分類算法，通過找到子圖頂點(diǎn) ID，連通分量算法計算每個子圖中的每個頂點(diǎn)所連接的最小頂點(diǎn)值，然后使用同一個頂點(diǎn) ID 下所有的節(jié)點(diǎn) ID 組合生成一個新的 ID 作為社群 ID。
Q5：貴司大量依賴圖性能實(shí)時計算反欺詐變量，那目前性能存在瓶頸嗎？
A5：主要取決于圖社群的圖關(guān)系數(shù)據(jù)量，如果是查詢普通的用戶，整個用戶的節(jié)點(diǎn)不會有太多，基本上會在十個節(jié)點(diǎn)以內(nèi)。但是如果這個人確實(shí)是中介或者說有反欺詐嫌疑的用戶，那他的子圖會非常大，確實(shí)會出現(xiàn)查詢上的性能超時的情況。應(yīng)用到反欺詐場景，我們會設(shè)置兜底方案，比如說反欺詐的圖特征接口響應(yīng)超過了 100 毫秒，我們就會默認(rèn)讓這個用戶通過，盡量不要去影響用戶實(shí)時的業(yè)務(wù)體驗。
Q6：反欺詐的特征跟指標(biāo)的區(qū)別是什么？
A6：反欺詐的特征更關(guān)注用戶的行為特征，更偏向于對用戶行為的挖掘。
Q7：數(shù)據(jù)量級是多少？實(shí)時特征任務(wù)的執(zhí)行時長大概是多少？離線計算任務(wù)的時長是多少？可以介紹一下嗎？
A7：現(xiàn)在我們每天特征的查詢量會在八九千萬的級別。實(shí)時特征的實(shí)時任務(wù)時長，依賴于 Flink 的實(shí)時能力，在幾十毫秒之內(nèi)就可以完成這個數(shù)據(jù)的同步。我們的特征查詢依賴于阿里云 TableStore 的能力，每次的特征查詢也都在 100 毫秒左右，所以性能還是比較有保障的。
Q8：Flink 計算完成后，實(shí)時特征查詢可能缺失嗎？
A8：是有可能缺失的。因為現(xiàn)在是監(jiān)聽 Binlog 的方式實(shí)時寫入的，如果在業(yè)務(wù)高峰期，特別是在有些跑批業(yè)務(wù)場景的這個情況下，可能 Binlog 的數(shù)據(jù)量非常大，那我們整個實(shí)時數(shù)據(jù)的采集耗時可能比平時要更長。比如說這個用戶在授信過程后馬上進(jìn)行支用的話，他的一些授信的數(shù)據(jù)還沒有完全及時地寫到在線查詢引擎，可能這一次的實(shí)時查詢就會有缺失的情況。
Q9：特征計時計算場景下長窗口特征進(jìn)行計算時會不會存在效率問題，然后是如何解決的？
A9：我們現(xiàn)在的存儲其實(shí)還是基于用戶維度的存儲方式，主鍵是用戶的 userID ，那我們會通過 TableStore 的 range 查詢的方式，把用戶相關(guān)的所有數(shù)據(jù)都查詢出來。其實(shí)在金融場景，不像電商或者內(nèi)容查詢的業(yè)務(wù)場景，一個用戶的交易數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)并不太多，其實(shí)不會存在有太大的效率問題。
Q10：特征的維度如何界定？會有一些少見的數(shù)據(jù)作為維度嗎？比如優(yōu)惠券 ID 等。
A10：優(yōu)惠券 ID 等可能在營銷場景有不同的維度和特征。在風(fēng)控業(yè)務(wù)場景，特征維度基本上基于人維度的，比如用戶身份證、手機(jī)號，還有用戶這個組件的維度，比較少見基于這種優(yōu)惠券 ID 維度的特征。
Q11：有深度網(wǎng)絡(luò)方面的特征提取嗎？
A11：現(xiàn)在還沒有這方面的探索。
Q12：在實(shí)際應(yīng)用中， Flink 最大的計算時間窗口有多大，是否超過 48 小時？
A12：這個會有超過的，最大窗口的范圍會在 3 天。但是實(shí)時特征場景，窗口基本上不會太大，一般是分鐘級別。對實(shí)時性要求不高的一些特征場景，我們可以支持在 3 天的窗口。這個比較耗費(fèi)資源，這種情況會比較少。
Q13：請問目前上線的實(shí)時模型占比多嗎？然后遇到過什么問題嗎？
A13：如果相對于整個特征體系來說的話，是不多的。但是我們的模型覆蓋了整個金融業(yè)務(wù)領(lǐng)域，營銷場景其實(shí)也有，具體數(shù)量可能不太好透露。
現(xiàn)在我們遇到的問題主要是特征的開發(fā)衍生和實(shí)際的線上化的特征應(yīng)用是由兩個團(tuán)隊去開發(fā)，之間的實(shí)現(xiàn)會有些不一致的情況。在模型開發(fā)的時候，它依賴的是離線的特征挖掘。那在生產(chǎn)時候我們是用實(shí)時特征的來去作為模型的入?yún)⒆兞?#xff0c;數(shù)據(jù)會有所差異，對于模型的 PSI 穩(wěn)定性就會有一些影響。
Q14：線上線下的一致性如何解決？
A14：這是個非常大的話題，現(xiàn)在比較流行的流批一體化的方案也是在嘗試解決這個問題。從我的理解來說，首先 Lambda 架構(gòu)可能要做一些調(diào)整，通過數(shù)據(jù)湖的方式來實(shí)現(xiàn)離線實(shí)時的同一份存儲。引擎方面要統(tǒng)一和存儲方面要統(tǒng)一，當(dāng)然這個成本會比較大。最后就是特征口徑的開發(fā)，在特征挖掘開發(fā)的時候的口徑直接應(yīng)用到生產(chǎn)中，基于統(tǒng)一的口徑進(jìn)行生成應(yīng)用，那這樣才能達(dá)到和之前特征開發(fā)口徑一致。
Q15：實(shí)時特征如果獲取不到或者返回很慢，線上模型或者決策引擎怎么處理？
A15：這個是會經(jīng)常碰到的一些問題。比如說模型和決策引擎依賴特征是三方的特征，那在三方不可用的情況下，我們需要去怎么處理。這種情況要看我們對這個特征的依賴情況，如果是強(qiáng)依賴，那我們可能等待這個實(shí)時特征能夠成功獲取，然后再跑真正的模型和策略。如果是弱依賴，那在模型的開發(fā)的時候，就會考慮這種情況，會用其他的特征或者其他的方式進(jìn)行處理。那決策引擎同樣也是如此，可以定制不同的決策規(guī)則來規(guī)避這種情況。
今天的分享就到這里，謝謝大家。
謝謝你讀完本文 (///▽///)
歡迎前往 GitHub 來閱讀 NebulaGraph 源碼，或是嘗試用它解決你的業(yè)務(wù)問題 yo~ GitHub 地址：https://github.com/vesoft-inc/nebula
總結(jié)
以上是生活随笔為你收集整理的当金融风控遇上人工智能，众安金融的实时特征平台实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 1.matlab画正弦函数图
- 下一篇： 时序分析基本概念（一）——建立时间