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