一、眾安金融 MLOps 簡介

1、什么是 MLOps

（1）定義

MLOps 是將機器學習、數(shù)據(jù)工程和 DevOps 融合在一起，從而實現(xiàn)機器學習模型的高效迭代和持續(xù)穩(wěn)定地應(yīng)用于生產(chǎn)業(yè)務(wù)的一套方法架構(gòu)。所以它是一套實踐方法論，是一套架構(gòu)方案。

（2）協(xié)作團隊

① 數(shù)據(jù)產(chǎn)品團隊：定義業(yè)務(wù)目標，衡量業(yè)務(wù)價值。

② 數(shù)據(jù)工程團隊：采集業(yè)務(wù)數(shù)據(jù)，然后對數(shù)據(jù)進行清洗轉(zhuǎn)換。

③ 數(shù)據(jù)科學家團隊：構(gòu)建 ML 解決方案，開發(fā)相應(yīng)的特征模型。

④ 數(shù)據(jù)應(yīng)用團隊：模型應(yīng)用，對特征進行持續(xù)的監(jiān)控。

2、眾安金融 MLOps 流程說明

（1）樣本準備，產(chǎn)品業(yè)務(wù)團隊定義業(yè)務(wù)范圍，確定建模的目標，選擇樣本人群準備訓練集。

（2）數(shù)據(jù)處理，需要對數(shù)據(jù)進行缺失值、異常值、錯誤值、數(shù)據(jù)格式的的清洗，使用連續(xù)變量、離散變量、時間序列等進行數(shù)據(jù)轉(zhuǎn)換。

（3）特征開發(fā)，數(shù)據(jù)處理完成后就可以進行特征衍生，金融特征主要通過審批邏輯衍生，行為總結(jié)量化，窮舉法，去量綱，分箱，WoE，降維，One-Hot 編碼等進行特征衍生，之后依據(jù)特征質(zhì)量，比如特征指標（ks、iv、psi）或者預計逾期率等進行特征篩選。

（4）模型開發(fā)，要進行算法的選擇和模型的擬合。

（5）模型訓練，使用測試數(shù)據(jù)集進行模型算法的測試驗證，進行參數(shù)的調(diào)優(yōu)。

（6）模型應(yīng)用，模型開發(fā)好之后就需要進行線上化的一個部署。

（7）模型監(jiān)控，上線后需要持續(xù)的監(jiān)控和模型的迭代優(yōu)化。

3、眾安金融為什么需要建設(shè) MLOps?

眾安金融，一方面為普惠人群提供公信征信支持，另一方面也為銀行等資金機構(gòu)來提供風險緩釋，助力普惠金融。眾安金融為無抵押的純線上消費貸款平臺提供信用保證保險服務(wù)，也為其他金融機構(gòu)提供信用保證保險服務(wù)。

眾安保險作為保險公司在其中承擔理賠的責任，所以就要求我們需要對風險進行全面識別、準確計量、嚴密監(jiān)控。我們搭建了以大數(shù)據(jù)為基礎(chǔ)、以風控規(guī)則與模型為策略，以系統(tǒng)平臺為工具的大數(shù)據(jù)風控體系。通過利用大數(shù)據(jù)與個人信用的關(guān)聯(lián)挖掘出大量的用戶風險特征和風險模型，從而提升風控的預測能力。

隨著風控策略的精細化，模型應(yīng)用的規(guī)?；卣魇褂玫膶崟r化，對我們的特征開發(fā)和模型應(yīng)用提出了更快速更實時的要求，所以我們就開始嘗試進行特征平臺體系化的實踐。

4、眾安金融 MLOps 體系

（1）大數(shù)據(jù)平臺：數(shù)據(jù)開發(fā)工程師使用大數(shù)據(jù)平臺的能力采集到相關(guān)的業(yè)務(wù)數(shù)據(jù)，構(gòu)建基于主題域的離線數(shù)據(jù)體系，同時把相應(yīng)的數(shù)據(jù)回流同步到在線 NoSQL 存儲引擎，提供給實時特征平臺使用。

（2）特征工程：數(shù)據(jù)科學家在大數(shù)據(jù)平臺進行特征工程的建設(shè)，使用離線數(shù)倉進行特征的挖掘和特征的選擇。

（3）機器學習平臺：數(shù)據(jù)科學家借助機器學習平臺可以進行一站式的模型開發(fā)和應(yīng)用。

（4）實時特征平臺：開發(fā)好的特征和模型需要在實時特征平臺進行注冊，在實時特征平臺配置好相關(guān)的信息后，就可以通過實時特征平臺的數(shù)據(jù)服務(wù)能力，提供上游業(yè)務(wù)的特征查詢和模型應(yīng)用的能力。

二、實時特征平臺架構(gòu)設(shè)計

1、眾安金融特征應(yīng)用場景

眾安金融實時特征平臺服務(wù)于金融業(yè)務(wù)全流程，包含金融線上的核心業(yè)務(wù)場景如登錄，準入，授信，支用，提額等實時前臺場景，后臺業(yè)務(wù)場景更多是批量的特征調(diào)用場景，此外還有催收也有對于特征和模型的使用，一開始特征平臺的初衷是為風控體系服務(wù)，隨著業(yè)務(wù)的發(fā)展，模型也逐漸使用到了用戶營銷場景和一些資源位的用戶推薦服務(wù)中。這里值得注意的是，對風控業(yè)務(wù)了解的同學就會知道，一次風控策略會有多個風控規(guī)則，每個風控規(guī)則會查詢多個特征數(shù)據(jù)，所以一次業(yè)務(wù)交易對于實時特征平臺來說可能就會放大到幾百倍的調(diào)用。

2、眾安金融特征數(shù)據(jù)分類

（1）交易行為數(shù)據(jù)：包含授信，借款申請、還款的數(shù)據(jù)，調(diào)額和逾期數(shù)據(jù)等業(yè)務(wù)數(shù)據(jù)。

（2）三方征信數(shù)據(jù)：需要對接三方征信機構(gòu)的接口。

（3）設(shè)備抓取數(shù)據(jù)：在用戶授權(quán)允許的情況下獲取設(shè)備相關(guān)信息。

（4）用戶行為數(shù)據(jù)：通過用戶行為埋點獲取。

3、實時特征平臺核心能力

面對眾多的特征數(shù)據(jù)源，這就要求我們實時特征平臺具備豐富的數(shù)據(jù)接入能力，實時的數(shù)據(jù)處理能力，對于大量的特征需求也要求特征平臺具備高效的特征加工配置化能力，實時的業(yè)務(wù)調(diào)用要求平臺有快速的系統(tǒng)響應(yīng)能力，我們也是圍繞這些核心能力的要求進行特征平臺的技術(shù)選型和架構(gòu)設(shè)計。經(jīng)過了技術(shù)迭代選型，我們采用了 Flink 作為實時計算引擎，使用阿里云的 TableStore 作為高性能的存儲引擎，然后通過微服務(wù)化的架構(gòu)實現(xiàn)了系統(tǒng)的服務(wù)化和平臺化。

4、實時特征平臺的業(yè)務(wù)架構(gòu)

這張圖是我們的實時特征平臺的業(yè)務(wù)架構(gòu)圖，可以看到圖的底層是特征數(shù)據(jù)源層，中間層是實時特征平臺的核心功能層，上層是整個特征平臺體系的業(yè)務(wù)應(yīng)用層，特征平臺主要有四個數(shù)據(jù)源：

（1）征信數(shù)據(jù)網(wǎng)關(guān)：提供人行征信等征信機構(gòu)的用戶信用數(shù)據(jù)，需要通過實時的接口對接來查詢征信數(shù)據(jù)。

（2）三方數(shù)據(jù)平臺：提供外部數(shù)據(jù)服務(wù)商的數(shù)據(jù)，通過調(diào)用三方數(shù)據(jù)接口服務(wù)完成實時數(shù)據(jù)對接。

（3）實時計算平臺：實時接入業(yè)務(wù)系統(tǒng)的交易數(shù)據(jù)，用戶行為數(shù)據(jù)和抓取設(shè)備數(shù)據(jù)，通過實時計算后回流到 NoSQL 在線存儲引擎。

（4）離線調(diào)用平臺：離線數(shù)據(jù)在阿里云的 MaxComputer 計算后同步到 NoSQL 存儲，實現(xiàn)歷史數(shù)據(jù)的回流，從而支撐用戶全業(yè)務(wù)時間序列的特征計算，此外一些非實時指標也需要在離線數(shù)倉加工完成后再回流到 NoSQL 存儲引擎。

實時特征平臺的核心功能：

?（1）特征網(wǎng)關(guān)：特征網(wǎng)關(guān)是特征查詢的出入口，具備鑒權(quán)限流，特征數(shù)據(jù)編排等功能。

（2）特征配置：為了支持特征的快速上線，特征平臺實現(xiàn)了特征的配置化能力，包含三方數(shù)據(jù)特征配置，實時業(yè)務(wù)特征配置，互斥規(guī)則特征配置，模型特征配置能力。

（3）特征計算：特征計算是通過微服務(wù)化的子系統(tǒng)來實現(xiàn)的，主要有三方特征計算，實時特征計算，反欺詐特征計算，模型特征計算。

（4）特征管理：特征管理后臺提供了特征變量生命周期管理能力，模型的元數(shù)據(jù)管理，還有特征跑批的任務(wù)管理。

（5）特征監(jiān)控：具備特征調(diào)用全鏈路查詢能力，對于特征計算失敗，特征值異常值，模型PSI值波動進行實時告警，此外也提供了特征使用情況等統(tǒng)計分析大盤報表。?

5、三方數(shù)據(jù)實時接入方案

（1）查詢方式：調(diào)用三方征信機構(gòu)的實時接口獲取報文數(shù)據(jù)然后進行數(shù)據(jù)處理獲取特征結(jié)果，出于降本考慮，我們還會實現(xiàn)一套緩存機制，對于離線場景減少調(diào)用三方的次數(shù)。

（2）創(chuàng)新點：三方數(shù)據(jù)接入引擎可以通過純配置化的方式接入三方的數(shù)據(jù)接口，通過特征加工引擎實現(xiàn)自動化的特征生成，通過可視化界面提供配置化的能力，最后通過接口提供給上游使用三方特征計算服務(wù)。

（3）解決的難點：三方數(shù)據(jù)與配置化接入的難點是數(shù)據(jù)服務(wù)商的加密方式、簽名機制多樣性、復雜性，三方數(shù)據(jù)接入引擎通過內(nèi)置一套加解密函數(shù)和支持自定義函數(shù)的能力，結(jié)合函數(shù)的鏈式組合方式，完成了各種復雜的三方數(shù)據(jù)加解密的配置化的實現(xiàn)。

6、業(yè)務(wù)數(shù)據(jù)實時接入

實時業(yè)務(wù)數(shù)據(jù)的接入由兩部分組成，首先是通過 Flink 實時監(jiān)聽業(yè)務(wù)數(shù)據(jù)庫的 Binlog 數(shù)據(jù)寫入到實時數(shù)倉，還有一部分使用 Spark 完成歷史數(shù)據(jù)的回補，結(jié)合離線數(shù)據(jù)和實時數(shù)據(jù)就可以支持基于全量時序數(shù)據(jù)的特征加工能力，為了支持高性能的實時特征查詢，實時數(shù)據(jù)和離線數(shù)據(jù)都會回流到 NoSQL 存儲引擎。對于不同的數(shù)據(jù)，我們也會考慮不同的存儲引擎，業(yè)務(wù)交易數(shù)據(jù)主要是用 TableStore 作為存儲引擎，用戶行為特征數(shù)據(jù)使用 Redis 為主，用戶關(guān)系圖譜數(shù)據(jù)用圖數(shù)據(jù)庫進行存儲，從整個流程來看，現(xiàn)在的數(shù)據(jù)體系是采用成熟的 Lambda 架構(gòu)。

7、實時特征平臺的系統(tǒng)架構(gòu)

?我們實時特征平臺的架構(gòu)基本如上圖，上游業(yè)務(wù)經(jīng)過特征網(wǎng)關(guān)進行特征的查詢，特征網(wǎng)關(guān)會進行特征查詢權(quán)限的驗證，限流控制和特征查詢?nèi)蝿?wù)異步分發(fā)，特征網(wǎng)關(guān)首先根據(jù)特征元數(shù)據(jù)信息路由到不同的特征數(shù)據(jù)源，從特征數(shù)據(jù)源查詢到原始數(shù)據(jù)之后會再路由到不同的特征計算服務(wù)進行特征的加工。三方特征是從三方數(shù)據(jù)平臺和征信網(wǎng)關(guān)查詢到的原始報文數(shù)據(jù)之后加工成為對應(yīng)的特征；業(yè)務(wù)特征計算用于加工內(nèi)部業(yè)務(wù)系統(tǒng)的實時特征。

信貸特征是通過實時業(yè)務(wù)數(shù)據(jù)同步后進行特征加工計算，離線特征服務(wù)是在離線數(shù)倉 MaxComputer 完成的特征加工計算。反欺詐特征計算用于對用戶登錄設(shè)備信息，用戶行為數(shù)據(jù)和用戶關(guān)系圖譜等相關(guān)特征的加工。

在基礎(chǔ)的三方特征，業(yè)務(wù)特征計算完成后，就可以直接提供給上游業(yè)務(wù)使用，此外模型服務(wù)也會依賴這些基礎(chǔ)特征，模型特征計算是借助機器學習平臺的能力來實現(xiàn)的，我們的機器學習平臺提供了模型的訓練，測試，發(fā)布等一體化功能，特征平臺集成了機器學習平臺的能力從而實現(xiàn)了模型特征的自動化和配置化。?

三、實時業(yè)務(wù)特征計算詳解

1、特征實時計算方案選型 

我覺得實時特征計算方案有兩種，第一種實時同步原始業(yè)務(wù)數(shù)據(jù)，然后在實時計算任務(wù)同時實現(xiàn)特征的加工，這是傳統(tǒng)的 ETL 模式，這種方式的優(yōu)點是特征查詢非常高效，查詢性能好，但是實時任務(wù)計算復雜，需要大量實時計算資源，需要特征衍生的話也是比較困難；另外一個方式是實時同步原始業(yè)務(wù)明細數(shù)據(jù)，但是特征加工是即時進行，也就是說特征查詢時再進行特征的計算，這樣方式特征查詢計算繁重，需要高速特征查詢引擎支持，但是實時任務(wù)比較簡單，特征衍生也比較方便，這個較新的 ELT 模式。出于我們業(yè)務(wù)對于特征頻繁衍生的要求和節(jié)省實時計算資源的考慮，我們選擇了第 ELT 的即時加工特征的方案。

2、實時業(yè)務(wù)特征數(shù)據(jù)流 

實時特征數(shù)據(jù)流通過 Kafka+Flink 實現(xiàn)實時數(shù)據(jù)的同步，同時也使用 Spark 從離線數(shù)倉數(shù)據(jù)回補完成全量時序數(shù)據(jù)的采集，實時業(yè)務(wù)數(shù)據(jù)主要是用 TableStore 作為存儲引擎，結(jié)合實時特征計算引擎和 ID-Mapping 的多主體查詢能力實現(xiàn)了特征的配置化生成。

除了通過 Flink 實時采集的數(shù)據(jù)外，還有部分數(shù)據(jù)需要調(diào)用業(yè)務(wù)系統(tǒng)的接口來獲取，這種數(shù)據(jù)也可以注冊為特征數(shù)據(jù)引擎的元數(shù)據(jù)，和存儲在 TableStore 里的數(shù)據(jù)一樣進行配置化使用。我們采用了阿里云的 TableStore 這個比較穩(wěn)定的高速查詢引擎來支持實時特征查詢，但是其實云產(chǎn)品的成本也需要考慮的，所以大家也需要根據(jù)本身的現(xiàn)狀選擇合適的方案。

3、實時數(shù)據(jù)核心數(shù)據(jù)設(shè)計 

由于我們存在多條產(chǎn)品線，每個產(chǎn)品線的用戶主鍵也都不同，而金融業(yè)務(wù)場景主要是以用戶身份證，用戶手機號等維度進行特征的查詢，因此我們抽象了一套用戶實體關(guān)系的 ID-Mapping 表，實現(xiàn)了身份證，手機號等維度到用戶主鍵的關(guān)聯(lián)關(guān)系，特征查詢時首先會根據(jù)特征入?yún)⒉樵?ID-Mapping 表獲取用戶 ID，然后再根據(jù)用戶 ID 查詢用戶業(yè)務(wù)明細數(shù)據(jù)，主要的業(yè)務(wù)明細數(shù)據(jù)包含用戶授信數(shù)據(jù)，支用明細，還款明細，額度明細，逾期明細的用戶業(yè)務(wù)數(shù)據(jù)。這里我們踩過的一個坑是主副表同時更新的場景，我們把主副表存儲為一份特征數(shù)據(jù)，我們主要是使用 column family 的方式存儲數(shù)據(jù)，所以在高并發(fā)的場景，可能會造成主副表同時更新帶來的不一致的情況，我們現(xiàn)在是通過一個窗口任務(wù)實現(xiàn)數(shù)據(jù)的補償。下圖是主要的業(yè)務(wù)數(shù)據(jù)圖：

4、實時特征計算引擎 

早期的特征加工是通過開發(fā)人員寫代碼來實現(xiàn)的，隨著特征需求增加，為了支撐特征的快速上線，我們借助表達式語言和 Groovy 實現(xiàn)了一套基于特征計算函數(shù)的特征配置化能力，結(jié)合 ID-Mapping 實現(xiàn)了一個特征計算引擎，計算過程可以分為如下幾步：

（1）創(chuàng)建實時 Flink 任務(wù)把用戶關(guān)系數(shù)據(jù)同步到 ID-Mapping 表，從而支持用戶多維數(shù)據(jù)查詢。

（2）創(chuàng)建實時 Flink 任務(wù)把用戶業(yè)務(wù)數(shù)據(jù)回流到阿里云的 TableStore，實現(xiàn)業(yè)務(wù)明細數(shù)據(jù)的實時同步。

（3）在特征平臺的實時特征配置頁面把上一步同步到 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 里面的用戶明細業(yè)務(wù)數(shù)據(jù)，特征計算引擎會把根據(jù)配置的特征計算表達式進行特征數(shù)據(jù)查詢，計算出來的數(shù)據(jù)結(jié)果就是特征值，就和第四步提到的，會把特征組下面的所有特征都計算出來。

四、反欺詐場景的特征應(yīng)用

1、反欺詐特征分類 

隨著金融欺詐風險不斷擴大，反欺詐形勢也越來越嚴峻，特征平臺也不可避免的需要支持反欺詐特征的查詢需求，總結(jié)下了我們的反欺詐特征分類如下：

（1）用戶行為特征：主要是基于埋點的用戶行為數(shù)據(jù)進行特征的衍生。比如用戶啟動的  APP 的次數(shù)、頁面訪問的時長，還有點擊的次數(shù)和在某個輸入框輸入的次數(shù)等。

（2）位置識別特征：主要是基于用戶的實時地理位置信息，加上 GeoHash 算法能力，實現(xiàn)位置特征的數(shù)據(jù)計算。

（3）設(shè)備關(guān)聯(lián)特征：主要是通過用戶關(guān)系圖譜來實現(xiàn)，通過獲取同一個設(shè)備下關(guān)聯(lián)到用戶的情況，可以快速地定位羊毛黨等欺詐行為。

（4）用戶圖譜關(guān)系特征：通過實時的獲取用戶在登錄、注冊、授信、資用等關(guān)鍵業(yè)務(wù)場景的設(shè)備信息，結(jié)合用戶三要素和他的一些聯(lián)系人信息，構(gòu)建圖譜關(guān)系，然后通過查詢用戶的鄰邊關(guān)系、用戶關(guān)聯(lián)的用戶是否有黑灰名單的情況，進行風險識別。

（5）用戶社群特征：通過判斷社群的大小、社群里用戶行為的表現(xiàn)，提煉社群規(guī)則特征。

2、實時反欺詐特征數(shù)據(jù)流 

反欺詐特征計算的數(shù)據(jù)流程和實時特征計算數(shù)據(jù)流程類似，除了數(shù)據(jù)源來源于實時業(yè)務(wù)數(shù)據(jù)外，反欺詐場景更關(guān)注是埋點的用戶行為數(shù)據(jù)，抓取的用戶設(shè)備數(shù)據(jù)，提取的用戶關(guān)聯(lián)關(guān)系數(shù)據(jù)，用戶行為的數(shù)據(jù)會通過埋點平臺（XFlow）上報到 Kafka，這些數(shù)據(jù)也會是使用 Flink 進行實時加工計算，不過和實時業(yè)務(wù)特征處理的區(qū)別是反欺詐特征是在實時數(shù)倉里面直接計算好之后存儲到 Redis，圖數(shù)據(jù)庫等存儲里面，這個是為了滿足反欺詐特征查詢的高性能要求，此外反欺詐場景也更關(guān)注實時的數(shù)據(jù)變化。從上圖可以了解到，反欺詐特征通過 HTTP API 的接口方式為特征網(wǎng)關(guān)提供特征計算服務(wù)。

3、關(guān)系圖譜架構(gòu)圖 

用戶關(guān)系圖譜的建設(shè)情況，整體設(shè)計思路如下：

?（1）首先是對于圖的數(shù)據(jù)源的選擇，要想構(gòu)建比較有價值的用戶關(guān)系圖譜，一定要找到準確的數(shù)據(jù)進行圖建模。關(guān)系圖譜的數(shù)據(jù)源主要來自用戶數(shù)據(jù)，比如手機號、身份證、設(shè)備信息、用戶三要素，聯(lián)系人等相關(guān)數(shù)據(jù)

（2）第二就是圖數(shù)據(jù)存儲引擎選型，需要關(guān)注的是引擎的穩(wěn)定性，數(shù)據(jù)的實時性，集成的方便性，查詢的高性能，存儲引擎的選擇非常重要，現(xiàn)在市面上有不少圖數(shù)據(jù)庫的技術(shù)，選型的過程中其實也碰到過不少的坑，一開始我們選擇的 orientdb，在大數(shù)據(jù)量的情況下就出現(xiàn)了很多不穩(wěn)定的問題，所以需要重點考慮大數(shù)據(jù)量的處理能力和存儲引擎的穩(wěn)定性，一定要經(jīng)過全面的技術(shù)調(diào)研才能進行生產(chǎn)的實踐

（3）其次就是需要考慮圖數(shù)據(jù)相關(guān)的算法支撐能力，除了基本的相鄰邊查詢能力，是否有比較豐富的圖算法支持，比如在反欺詐場景使用到的是社群發(fā)現(xiàn)算法

（4）最后需要通過 API 的方式提供圖數(shù)據(jù)服務(wù)，反欺詐應(yīng)用場景提供圖數(shù)據(jù)特征的服務(wù)外，還可以賦能給營銷推薦場景

經(jīng)過多方位的選型調(diào)研，最終選擇了 Nebula?Graph 作為圖數(shù)據(jù)庫，它采用的是 shard-nothing 的分布式存儲，能夠支持萬億級別的一個大規(guī)模的機型的圖的計算。NebulaGraph 的相關(guān)信息可以從他們的官網(wǎng)了解，這里就不贅述了。

4、反欺詐圖特征提取 

通過模型團隊對用戶關(guān)系圖譜的數(shù)據(jù)挖掘，從用戶社群的年齡分布，消費預估水平分布等多維度統(tǒng)計數(shù)據(jù)出發(fā)，我們提取出了一些圖特征，這邊列舉了一批以供大家參考：

（1）第一方欺詐：通過圖認為同一個人申請多次，而且每次提交的聯(lián)系人等關(guān)聯(lián)信息都不太一致，可以認為它是有第一方欺詐的嫌疑。

（2）疑似中介代辦：有部分人的申請人都關(guān)聯(lián)到了相同一個聯(lián)系人的手機號。

（3）疑似信息冒用：就是一個人的手機號可能被很多人使用，可能它出現(xiàn)了信息的泄露。

（4）疑似團伙欺詐：看關(guān)系圖譜社群節(jié)點的規(guī)模數(shù)量是否超過了一定的規(guī)模。

反欺詐策略規(guī)則。通過一兩個特征可能沒辦法精確地對反欺詐行為進行定位，需要來組合多類的特征，形成反欺詐策略規(guī)則，從而在多方面提升對用戶反欺詐識別的準確度。

五、問答環(huán)節(jié)

Q1：Flink 的源數(shù)據(jù)由 Kafka 輸入，那平臺是否能實現(xiàn)多條 Kafka 消息之間的關(guān)聯(lián)查詢？

A1：整個實時業(yè)務(wù)的采集我們是使用 Flink 完成明細數(shù)據(jù)的清洗，把 DWD 層的數(shù)據(jù)回流到 TableStore，然后通過實時特征計算引擎來實現(xiàn)數(shù)據(jù)的關(guān)聯(lián)，設(shè)置多個計算因子，然后通過這種方式把多條數(shù)據(jù)進行關(guān)聯(lián)，支持最終特征的產(chǎn)生。比較少在 Flink 里面進行這個數(shù)據(jù)的關(guān)聯(lián) Join 查詢，也就是現(xiàn)在比較流行的 ELT的模式。

Q2：特征實時計算方案，貴公司選擇方案 2，在變量很多的情況下，怎么保證接口響應(yīng)的效率？

A2：特征計算是基于特征組維度，一個特征組下面可能會有幾十上百個特征，我們的現(xiàn)在的這個計算框架主要性能的消耗是在對于特征原始數(shù)據(jù)的查詢，只要把原始數(shù)據(jù)查詢出來，特征口徑計算都是在內(nèi)存里面完成。那么就需要有底層高性能的查詢引擎來支持，我們現(xiàn)在依賴于阿里云的 TableStore 查詢引擎來實現(xiàn)快速的數(shù)據(jù)查詢能力。

Q3：請教一下，使用無監(jiān)督的異常檢測算法，比如孤立森林或者 LOFO，應(yīng)該怎么處理 APP 埋點行為數(shù)據(jù)，怎樣提取特征會比較有效果？

A3：對于模型的算法不是我所在行的，我的理解是可以從特征質(zhì)量和特征算法指標入手，但是沒有通用的一個解決方案，要根據(jù)實際的業(yè)務(wù)數(shù)據(jù)進行算法的驗證和調(diào)優(yōu)，才能夠得到答案。

Q4：關(guān)系圖譜的社區(qū)發(fā)現(xiàn)算法有什么有效的效果評價方法嗎？然后這邊一般采用的社區(qū)發(fā)現(xiàn)算法是哪種？

A4：現(xiàn)在采用的是聯(lián)通分量算法。我們關(guān)系圖譜不只是在反欺詐特征計算使用，也給反欺詐團隊來做反欺詐調(diào)查使用，他們會根據(jù)有欺詐嫌疑的用戶，對我們的關(guān)系圖譜進行反向的驗證，通過實際的調(diào)研來看算法的效果。

我們是使用 Spark Graphx 的連通分類算法，通過找到子圖頂點 ID，連通分量算法計算每個子圖中的每個頂點所連接的最小頂點值，然后使用同一個頂點 ID 的下所有的節(jié)點 ID 組合生成一個新的 ID 作為社群 ID。

Q5：貴司大量依賴圖性能實時計算反欺詐變量，那目前性能存在瓶頸嗎？

A5：主要取決于圖社群的圖關(guān)系數(shù)據(jù)量，如果是查詢普通的用戶，整個用戶的節(jié)點不會有太多，基本上會在十個節(jié)點以內(nèi)。但是如果這個人確實是中介或者說有反欺詐嫌疑的用戶，那他的子圖會非常大，確實會出現(xiàn)查詢上的性能超時的情況。應(yīng)用到反欺詐場景，我們會設(shè)置兜底方案，比如說反欺詐的圖特征接口響應(yīng)超過了 100 毫秒，我們就會默認讓這個用戶通過，盡量不要去影響用戶實時的業(yè)務(wù)體驗。

Q6：反欺詐的特征跟指標的區(qū)別是什么？

A6：反欺詐的特征更關(guān)注用戶的行為特征，更偏向于對用戶行為的挖掘。

Q7：數(shù)據(jù)量級是多少？實時特征任務(wù)的執(zhí)行時長大概是多少？離線計算任務(wù)的時長是多少？可以介紹一下嗎？

A7：現(xiàn)在我們每天特征的查詢量會在八九千萬的級別。實時特征的實時任務(wù)時長，依賴于 Flink 的實時能力，在幾十毫秒之內(nèi)就可以完成這個數(shù)據(jù)的同步。我們的特征查詢依賴于阿里云 TableStore 的能力，每次的特征查詢也都在 100 毫秒左右，所以性能還是比較有保障的。

Q8：Flink 計算完成后，實時特征查詢可能缺失嗎？

A8：是有可能缺失的。因為現(xiàn)在是監(jiān)聽 Binlog 的方式實時寫入的，如果在業(yè)務(wù)高峰期，特別是在有些跑批業(yè)務(wù)場景的這個情況下，可能 Binlog 的數(shù)據(jù)量非常大，那我們整個實時數(shù)據(jù)的采集耗時可能比平時要更長。比如說這個用戶在授信過程后馬上進行支用的話，他的一些授信的數(shù)據(jù)還沒有完全及時地寫到在線查詢引擎，可能這一次的實時查詢就會有缺失的情況。

Q9：特征計時計算場景下長窗口特征進行計算時會不會存在效率問題，然后是如何解決的？

A9：我們現(xiàn)在的存儲其實還是基于用戶維度的存儲方式，主鍵是用戶的 userID ，那我們會通過 table store 的 range 查詢的方式，把用戶相關(guān)的所有數(shù)據(jù)都查詢出來。

其實在金融場景，不像電商或者內(nèi)容查詢的業(yè)務(wù)場景，一個用戶的交易數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)并不太多，其實不會存在有太大的效率問題。

Q10：特征的維度如何界定？會有一些少見的數(shù)據(jù)作為維度嗎？比如優(yōu)惠券 ID 等。

A10：優(yōu)惠券 ID 等可能在營銷場景有不同的維度和特征。在風控業(yè)務(wù)場景，特征維度基本上基于人維度的，比如用戶身份證、手機號，還有用戶這個組件的維度，比較少見基于這種優(yōu)惠券 ID 維度的特征。

Q11：有深度網(wǎng)絡(luò)方面的特征提取嗎？

A11：現(xiàn)在還沒有這方面的探索。

Q12：在實際應(yīng)用中， Flink 最大的計算時間窗口有多大，是否超過 48 小時？

A12：這個會有超過的，最大窗口的范圍會在三天。但是實時特征場景，窗口基本上不會太大，一般是分鐘級別。對實時性要求不高的一些特征場景，我們可以支持在 3 天的窗口。這個比較耗費資源，這種情況會比較少。

Q13：請問目前上線的實時模型占比多嗎？然后遇到過什么問題嗎？

A13：如果相對于整個特征體系來說的話，是不多的。但是我們的模型覆蓋了整個金融業(yè)務(wù)領(lǐng)域，營銷場景其實也有，具體數(shù)量可能不太好透露。

現(xiàn)在我們遇到的問題主要是特征的開發(fā)衍生和實際的線上化的特征應(yīng)用是由兩個團隊去開發(fā)，之間的實現(xiàn)會有些不一致的情況。在模型開發(fā)的時候，它依賴的是離線的特征挖掘。那在生產(chǎn)時候我們是用實時特征的來去作為模型的入?yún)⒆兞浚瑪?shù)據(jù)會有所差異，對于模型的 PSI 穩(wěn)定性就會有一些影響。

Q14：線上線下的一致性如何解決？

A14：這是個非常大的話題，現(xiàn)在比較流行的流批一體化的方案也是在嘗試解決這個問題。從我的理解來說，首先 lambda 架構(gòu)可能要做一些調(diào)整，通過數(shù)據(jù)湖的方式來實現(xiàn)離線實時的同一份存儲。引擎方面要統(tǒng)一和存儲方面要統(tǒng)一，當然這個成本會比較大。最后就是特征口徑的開發(fā)，在特征挖掘開發(fā)的時候的口徑直接應(yīng)用到生產(chǎn)中，具于統(tǒng)一的口徑進行生成應(yīng)用，那這樣才能達到和之前特征開發(fā)口徑一致。

Q15：實時特征如果獲取不到或者返回很慢，線上模型或者決策引擎怎么處理？

A15：這個是會經(jīng)常碰到的一些問題。比如說模型和決策引擎依賴特征是三方的特征，那在三方不可用的情況下，我們需要去怎么處理。這種情況要看我們對這個特征的依賴情況，如果是強依賴，那我們可能等待這個實時特征能夠成功獲取，然后再跑真正的模型和策略。如果是弱依賴，那在模型的開發(fā)的時候，就會考慮這種情況，會用其他的特征或者其他的方式進行處理。那決策引擎同樣也是如此，可以定制不同的決策規(guī)則來規(guī)避這種情況。