摘要：本文整理自眾安保險大資料平臺開發高階專家郭育波在 Flink Forward Asia 2021 行業實踐專場的演講。主要內容包括：
- 整體概況
- 智慧營銷應用
- 實時特徵應用
- 反欺詐應用
- 後期規劃
一、 整體概況
上圖是我們的實時計算整體架構圖，最下層是資料來源層，包括了來自於應用系統的業務資料、應用系統的訊息資料、使用者行為埋點資料以及應用日誌資料，這些資料都會經過 Flink 進入實時數倉。
實時數倉分為三層：
- 第一層是 ODS 層，資料經過 Flink 到 ODS 層後會關聯一張原始表，這個表是和資料來源一一對應的，然後會有一個檢視表對原始資料進行簡單的清洗加工；
- 之後，資料經過 Flink 下發到 DWD 層，DWD 層是基於主題域進行劃分的，我們現在劃分為使用者資料域、營銷資料域、信貸資料域和保險資料域等；
- 另外還有一部分是 DIM 層，包含使用者相關、產品相關和渠道相關等維表資料，DIM 層的資料會儲存到 HBase 中。
經過 DWD 層的資料清洗之後，資料下發到 DWS 層，DWS 層會對資料進行整合彙總，一般會有指標寬表和多維明細寬表。之後這些資料會進入 ADS 層，這一層包含多樣的 OLAP 資料儲存引擎。我們現在主要使用 ClickHouse 作為大盤實時報表的儲存引擎，還有 HBase 和阿里雲的 TableStore 為使用者標籤和特徵工程提供資料儲存服務，還有 ES 主要用於實時監控場景。
上圖是我們的實時計算平臺架構圖，整個實時計算平臺可以分為三個部分。第一部分是任務管理後臺，在任務管理模組裡面編輯和提交任務，任務編輯器同時支援 Flink SQL 和 Flink JAR 任務，提供了比較便利的 Flink SQL 編輯功能和除錯功能，也支援多種任務啟動策略，比如基於 checkpoint、offset、時間點和最早位置等，還支援定時和即時生成 checkpoint 功能。任務提交之後，會通過 Flink 客戶端將它提交到我們自建的 CDH 叢集裡。任務管理服務也會定時從 Yarn 獲取任務的實時狀態。
監控方面，Flink 會把指標日誌資料推送到 PushGateway，Prometheus 獲取 PushGateway 這些指標之後會在 Grafana 進行資料的視覺化展示。除了對任務異常的狀態監控之外，我們還會對資源使用率、訊息積壓等多種情況進行實時告警。此外 Flink 還支援了比較多的 connector，比如阿里雲的 ODPS、TableStore 和 Hologres，也內建了豐富的 UDF 並且支援使用者自定義 UDF。
上圖是我們實時計算平臺的任務編輯器，可以看到它支援 Flink SQL 和 Flink JAR 任務，SQL 任務支援 DML 和 DDL，它們可以一起在編輯器裡面進行整體任務提交，任務管理這塊同時也支援每一次變更的版本管理。此外，還支援比較多的高階任務配置功能，有 checkpoint 配置、訊息 Kafka 的並行度和狀態管理等。
二、智慧營銷應用
接下來，重點介紹一下 Flink 在智慧營銷應用場景的使用情況。
營銷平臺的架構圖的最下層也是資料來源層，包括金融業務資料、保險業務資料、使用者行為資料、第三方平臺的資料和運營結果資料。離線資料通過 ETL 的方式進入離線數倉，實時資料通過 Flink 的方式進入實時數倉。
實時離線數倉之上是標籤服務層，平臺有對離線/實時的標籤管理功能，同時我們也會對這些標籤進行治理管控，比如資料許可權的管控，此外，還有標籤資料的監控，能夠及時發現標籤資料的異常，準確掌握標籤使用情況的分析統計。
標籤層之上是標籤應用層，我們有營銷 AB 實驗室和流量 AB 實驗室，它們之間的差異在於，營銷 AB 主要居於客群進行營銷，無論是基於規則進行客群圈選的靜態客群還是通過 Flink 接入的實時客群，都會對這些客群進行流程化的營銷和智慧的觸達。而流量 AB 實驗室也是基於標籤的資料服務能力，用於 APP 端千人千面的個性化推薦。平臺還提供了客群畫像的分析功能，可以快速找到相似客群和客群的歷史營銷的資料效果情況，能夠更好地協助運營對於客群的甄選和營銷。
通過營銷 AB 和流量 AB 實驗之後，會有一個效果分析服務來進行實時效果回收，通過效果分析可以及時輔助運營團隊進行快速的策略調整。
目前，標籤總數已經達到 500 個以上，營銷任務執行數量每天會有 200 萬左右，流量 AB 每天會有 2000 萬以上的呼叫量，主要是給前端提供了資源位的個性化顯示和千人千面的業務場景。
上圖是智慧營銷平臺的資料流圖，左邊是資料來源，有來自於業務系統的業務資料，也有埋點、事件資料，這些資料經過 Kafka 到達實時數倉，經過實時數倉的加工後，一部分會變成實時標籤，被儲存在阿里雲的 TableStore，還有一部分會被加工成實時客群，同樣也會發到 Kafka，然後由營銷 AB 實驗室對這些實時客群進行智慧的營銷觸達。
另一部分離線數倉加工出來的標籤資料，我們使用 DataX 作為 ETL 的工具，將它們同步到 Hologres，Hologres 能夠無縫對接 ODPS，並利用其和 ODPS 關聯外表的加速能力，實現了百萬級別每秒的資料同步。運營人員可以在營銷平臺自助的進行客群圈選，利用 Hologres 的互動分析能力，可以支援複雜的客群的秒級生成。
整個營銷平臺的特徵可以總結為三點：
- 第一，實時畫像。通過定製標準化的實時事件、資料結構，利用 Flink 實時計算的能力，實現自動化的實時標籤接入；
- 第二，支援比較智慧的營銷策略。可以讓使用者直接在營銷平臺上進行元件化的營銷流程的配置，提供豐富的時間策略，還有各種智慧的營銷通道，同時也支援靈活的、多分支的業務流轉，使用一致性雜湊分流演算法進行使用者的 AB 實驗；
- 第三，實時分析。對營銷成效進行實時分析，我們也是使用 Flink 實現實時效果回收。通過漏斗的分析和業務指標的成效分析能力，能夠更好地賦能給營銷業務。
三、實時特徵應用
特徵工程主要服務於金融風控場景，比如決策引擎、反欺詐、風控模型服務等。特徵工程主要的目的是將原始資料轉換為更好的表述問題本質的過程。使用這些特徵可以提高我們對一些不可見事物預測的精度，金融業務場景就是使用這個特徵來提高對使用者風險的識別能力。
特徵工程是整個資料探勘模型裡最耗時也最重要的一步，它為金融業務全流程的風控提供了核心的資料支撐，主要分為三個部分：
- 首先是特徵挖掘，主要由風控策略和模型開發的團隊來完成，他們會根據業務指標進行資料的分析處理，然後再提取出有效的合規的特徵；
- 當特徵挖掘出來之後會給到開發團隊，特徵開發團隊根據這個特徵的來源會對接不同的資料來源，有些是來自三方的，有些是離線加工出來的，還有實時加工的，當然還有一些機器學習模型進行再次加工計算出來的特徵；
- 開發好的特徵會通過特徵中臺提供給線上的業務使用，同時也要保障整個特徵鏈路的穩定性。
特徵工程目前使用的 Flink 實時任務有一百個以上，產生了一萬個以上的特徵數量，每天會有 3000 萬以上的特徵呼叫。
金融風控特徵的核心指標，最重要的是合規。所有的特徵都是居於合規之上，之外還需要保證特徵加工的準確性、特徵數字的實時性、特徵計算的快速響應，還有整個平臺執行的高可用和穩定性。
基於這樣的指標要求，我們採用了 Flink 作為實時計算引擎，使用 HBase 和阿里雲的 TableStore 作為高效能的儲存引擎，然後通過微服務化的架構實現整體的服務化和平臺化。
特徵平臺的架構圖總體可以分為 5 大部分。上游系統有前臺系統、決策系統和保護系統。業務方所有的請求都會經過特徵閘道器，特徵閘道器會根據特徵的源資料進行鏈路編排，有些要呼叫三方資料，人行徵信資料，還有一些來自資料集市的資料。資料接入之後就會進入特徵資料的加工層，裡面有對三方資料的特徵加工服務，也有對金融實時特徵資料的計算；還有一些反欺詐的特徵計算服務，其中包含關係圖譜以及一些名單特徵的服務。
有些基礎的特徵通過這一層加工之後，就可以提供給上游的業務系統使用了，還有一些需要經過特徵組合服務進行再次加工。我們通過一個低程式碼編輯器來實現特徵的組合服務和風控模型服務，通過機器學習平臺來進行特徵的重新加工。
基礎服務層主要是做特徵的後臺管理和實時監控。實時特徵需要依賴實時計算平臺，離線特徵依賴離線排程平臺。
總結來說，特徵平臺是以微服務化構建的一個特徵服務體系，通過接入三方資料、徵信資料、內部資料、實時資料、離線資料進行特徵加工和服務，組合成的一套特徵計算的風控資料產品。
上圖可以很清晰地看到實時金融特徵資料的流向。資料主要來源於業務資料庫，有前臺、中臺等各個業務系統，通過 binlog 的方式傳送到 Kafka，資料中介軟體 blcs 能夠把 binlog 轉換到 Kafka。使用者行為的資料直接傳送到 Kafka，經過 Flink 進入到實時數倉，經過實時數倉的資料計算之後，會把多維明細資料寫入到 TableStore。
最早我們使用的是 HBase，後面出於穩定性的考慮，我們使用了 TableStore 進行了一個技術升級。最後考慮到特徵服務對穩定性的要求比較高，我們還是保留了兩個儲存，HBase 作為降級儲存來進行使用。
因為金融特徵是要求能夠描述使用者全生命週期的資料服務，所以不單要求實時的資料，還要求全量的離線資料。離線資料是通過 DataX 迴流到 HDFS，再使用 Spark 的離線計算能力迴流到線上儲存引擎 TableStore 裡。
現在，風控對於特徵的加工越來越要求精細化了，比如支用金額這樣簡單的一個特徵計算，就可能會要求包含半個小時、近 3 個小時、近 6 個小時、近一天、7 天、15 天、30 天等各種業務的視窗。如果使用實時計算會產生非常多的視窗，而且全量資料的計算也會造成Flink吞吐能力下降。所以我們的實時任務主要是做資料的清洗和簡單的整合，之後還是會把這些明細資料迴流到儲存引擎，然後通過應用系統的特徵計算引擎進行配置化的特徵加工。
風控特徵的場景還是比較固定的，基本上是從使用者身份證、使用者ID或者使用者手機號等維度來進行計算，所以我們就抽象了一套使用者實體關係關聯表，包含身份證、手機號、裝置指紋等使用者 ID 的 mapping 關係表，業務資料使用 userID 進行維表關聯儲存，通過實體關係加業務資料兩個維度來進行使用者明細資料的查詢。得益於 TableStore 提供的高效能點查能力，我們可以處理高併發的特徵計算。有些特徵不單使用到了實時資料，還會呼叫業務系統的介面來獲取資料，需要實時資料，介面資料進行聚合計算來完成，這樣導致無法在 Flink 中完成所有的特徵計算。所以 Flink 只是進行明細資料的加工和聚合，再由特徵計算引擎來實現特徵結果的計算。
現在我們的實時特徵計算主要是居於實時數倉 DWD 的資料結合特徵計算引擎實現的，DWD 的資料會迴流到阿里雲的 Tablestore，然後通過配置化的方式實現特徵的加工計算。為了節約查詢成本，我們的計算粒度都是居於特徵組的維度，一個特徵組只會查詢一次資料來源，特徵組和特徵是一對多的關係。
這裡簡單描述下特徵的計算過程：首先會根據特徵的查詢條件把相關的明細資料都掃描出來，然後根據特徵組下的具體的特徵配置比如時間粒度，維度使用自定義的統計函式進行特徵計算，而如果是多個資料來源需要 join 來計算的話，先把依賴的特徵因子計算完成後，再完成下一步的特徵計算。此外如果我們的自定義函式不能滿足計算的需求，系統也提供了居於 Groovy 指令碼進行特徵加工的方式。另外還有部分的特徵來源源是來自業務系統的介面，這樣只需要把第一步資料獲取從查詢 Tablestore 切換到呼叫介面即可，如果有其他的特徵資料來源也可以通過實現標準資料介面就可以完成，特徵的計算引擎不需要做任何調整。
四、反欺詐應用
上圖是實時反欺詐特徵應用的資料流圖，它和金融實時特徵服務的資料流圖有些類似的一面，但也存在一些差異。這裡的資料來源除了會使用業務資料外，更關注的是使用者行為資料和使用者裝置的資料。當然這些裝置資料和行為資料都是在使用者許可的前提下進行採集。這些資料經過 Kafka之後，也會進入 Flink 進行處理。反欺詐的資料主要是用一個圖資料庫來儲存使用者關係資料，對於需要歷史資料的複雜特徵計算，我們會在 Flink 裡面用 bitmap 作為狀態儲存，結合 timerService 進行資料清理，使用 Redis 進行特徵計算結果儲存。
GPS 的反欺詐特徵是使用 TableStore 的多元索引和 lbs 函式的能力來進行位置識別的特徵計算。反欺詐的關係圖譜和關係社群會通過資料視覺化的能力來提供給反欺詐人員進行個案調查。
我們把反欺詐特徵歸為 4 大類：
- 第一類是位置識別型別，主要是基於使用者的位置資訊，加上 GeoHash 的演算法，實現位置集聚特徵的資料計算。舉個例子，我們通過位置集聚特徵，發現了一些可疑使用者，然後再通過反欺詐調查檢視這些使用者的人臉識別的照片，發現了他們的背景很相似，都是在同一家公司進行業務申請。所有我們就可以結合位置類的特徵，加上影像識別的 AI 能力來更精準地定位類似的欺詐行為；
- 第二類是裝置關聯類，主要是通過關係圖譜來實現。通過獲取同一個裝置的關聯使用者的情況，可以比較快速地定位到一些羊毛黨和簡單的欺詐行為；
- 第三類是圖譜關係，比如使用者的登入、註冊、自用、授信等場景，我們會實時抓取使用者在這些場景的一些裝置指紋、手機號、聯絡人等資訊，來構造關係圖譜的鄰邊關係。然後通過這樣的鄰邊關係和使用者關聯的節點度數判斷是否關聯到一些黑灰名單使用者來進行風險的識別；
- 第四類是基於社群發現演算法實現的統計類的社群特徵，通過判斷社群的大小、社群裡面這使用者行為的表現，來提煉統計類的規則特徵。
上文提到比較多的關係圖譜特徵都是用圖計算引擎 (NebulaGraph) 來進行儲存的。我們測試過比較常用的是 janusgraph 和 orientdb，但是當資料量達到了一定數量級以上之後，就會出現一些不穩定的因素和情況，所以我們嘗試使用了圖計算引擎 ，發現它的穩定性相對來說比較高，因為它採用的是 shard-nothing 的分散式引擎儲存，能夠支援萬億級別的大規模的圖的計算。它主要分為三大部分來進行組合服務：
- graph 服務，主要負責圖實時計算；
- meta 服務，主要負責資料管理、schema 的操作和使用者許可權等等；
- storage 服務，主要負責資料儲存。
同時 Nubula 還採用了計算儲存分離的架構，無論是計算層還是儲存層都可以獨立進行克隆，同時它還支援傳遞計算，減少了資料的搬遷。無論是 meta 層還是 storage 層，都是通過 raft 協議來實現資料的最終一致性。
另外 NebulaGraph 也提供了比較豐富的客戶端的接入方式，支援 Java\Go\Python 等客戶端，同時也提供了 Flink connector 和 Spark connector，能夠很容易地和現在主流的大計算引擎整合。
關係圖譜的實現路徑分為 4 部分：首先是圖的資料來源。要想構建比較有價值的關係圖譜，一定要找到準確豐富的資料進行圖建模。我們的資料來源主要來自使用者資料，比如手機號、身份證、裝置資訊、聯絡人等相關資料都會同步到關係圖譜裡面，除了實時資料，這裡也會通過離線 Spark 任務清洗歷史資料。NebulaGraph 提供的查詢語言支援了豐富的圖函式，比如相鄰邊、最大路徑、最短路徑等。社群發現我們是通過 Spark Graph-X 來實現的，最後通過 API 的方式提供資料服務，進行圖資料庫的應用，我們現在有直接提供給決策引擎來進行圖資料特徵的服務，也有對反欺詐的一些資料服務，甚至之後可以考慮用於營銷的基於社群的推薦演算法。
五、後期規劃
未來，首先我們要夯實我們的實時計算平臺，實現實時資料的血緣關係的管理，還有嘗試 Flink + K8s 的方式實現資源的動態擴縮容。
其次，我們希望能夠基於 Flink + NubelaGraph 進行圖譜平臺化的建設，目前實時計算和離線計算是 Lambda 架構實現的，所以我們想借 Flink + Hologres 實現流批一體來嘗試解決這個問題。
最後，我們會嘗試在風控的反欺詐業務場景使用 Flink ML 來實現線上機器學習，提升模型開發效率，快速的實現模型的迭代,賦能智慧實時風控。
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～
