京東物流實時風控實踐

摘要：本文整理自京東風控資料產品組架構師周文躍，在 FFA 2022 實時風控專場的分享。本篇內容主要分為六個部分：

1. 京東物流業務介紹

2. 物流風控場景概括

3. 物流風控平臺建設

4. Flink 賦能

5. 技術挑戰

6. 未來規劃

Tips：點選「閱讀原文」檢視原文影片&演講 ppt

01

京東物流業務介紹

京東集團在 2007 年開始自建物流，是國內領先的以技術驅動的供應鏈解決方案及物流供應商，一體化的供應鏈物流是我們的核心賽道。

02

物流風控場景概括

京東物流風控場景主要概括為兩種，一種是貨品安全，如貨物丟失、破損等。另一種是交易風險，主要包括財務支出的一些風控場景。這兩種場景主要體現在銷售、倉儲、運力、計重和終端。最後的防損風控屬於事後風控，任何有防損訴求的風控都會被歸納到防損風控中。

其中銷售風控的主體是商家。從准入、運營、財務、理賠各個環節進行風險管控。為了解決長期以來受不良客戶擾亂市場的困擾，我們整合內部資源，透過風險商家模型和企業、法人知識圖譜的搭建，對風險行為進行精準識別、分析、預警及處置。

倉儲風控的主體是 sku。從單一人工舉報發現渠道，增加了利用資料發現渠道，擴充了發現風險線索的範圍，持續輸出風險線索，支援運營人員日常發現風險，及時核查並規避風險。

運力風控的主體是車輛。透過事前供應商招採，事中運營結算，事後防損稽核的方式，將已經完結的任務中可能存在的風險進行識別，及時扣減不合理的費用，降低公司的損失。

計重風控主要是指運單稱重量方。透過預定的規則，針對特定的運單重新進行稱重量方。這麼做是為了避免某些主觀上的偷重漏重，或者因為作業規範、裝置等問題導致的收入損失。

終端風控防控的物件是人。透過預測畫像最佳化業務流程，從下單到配送針對性的進行風險規避。

防損風控是利用大資料分析、演算法策略構建的大量損耗模型，並透過調查預審、案件平臺等業務系統識別出應收、丟損、異常等風險資訊形成案件。督導防損調查人員及時調查處置。

03

物流風控平臺建設

整個風控技術架構主要包含來源層、採集層、處理層、儲存層、應用層。資料來源於業務資料、財務資料、物聯網資料、外部資料。透過批、流、資料匯入的方式，經過資料探勘、機器學習、搜尋引擎、演算法服務，最終對外提供服務，服務包括資料服務、特徵服務、標籤服務、畫像服務。

在進行具體的風控平臺搭建之前，我們先了解一下風控的定義。風險控制存在四個基本方法，風險迴避、損失控制、風險轉移、風險保留。

京東物流主要集中在損失控制上，包含事前、事中、事後三個方面。

1. 事前：預防性風控，透過外部資料、歷史規律、演算法預測來挖掘出現風險的機率，並按照預定的預防措施和保護性措施，降低損失的機率。

2. 事中：阻斷性風控，主要是在流程進行中，系統根據相關規則監控，在出現實際損失前啟動攔截流程，降低損失的金額。

3. 事後：處置性風控，主要圍繞風險處置及覆盤來做的，屬於挽損性質。

瞭解了風控的定義，我們再來分享一下平臺的建設思路。

1. 中臺服務，對外提供能力，儘量不直接操作生產流程。過多的嵌入到生產流程，會影響到生產的效率。

2. 風控平臺接收各方資料來源，對各場景進行風險識別、打標並落庫，建立風險庫。風控模型的搭建是一個長期的不斷迭代最佳化的過程。

3. 風控平臺提供可配置的風控識別能力，使用者可以自己選擇風險識別型別，根據自身需求配置引數。這樣做是為了擴大風控模型的應用範圍，提升投入產出比。

4. 風控平臺提供標準化接入方式，無論訊息還是查詢介面，只要滿足需求，都可以接入並使用。一個成熟的平臺必然是標準化的，透過接入流程化，風控平臺的技術人員只需專注於模型的識別效率提升即可。

5. 風控平臺儘量少的根據特定場景進行邏輯加工，不直接嵌入使用者的程式碼。這麼做也是為了擴大風控模型的應用範圍，做到以點破面。

風控資料庫包含規則庫、模型庫、知識圖譜，運用的資料庫型別也是市面上常見的關聯式資料庫、NoSQL 資料庫、搜尋引擎、圖資料庫等。現行的方案是 Flink 實時更新，實時模型和知識圖譜，Flink SQL 或者 Hive SQL 更新離線模型，同時兼顧資料回算。

從上圖可以看出實時和離線是相互獨立的。左上部分是實時風控，它包含事中和事後風控流程，主要根據生產活動所產生的日誌資訊、維度介面、預先設定的規則模型，進行風險指標計算。透過風險預警將風險結果反饋給生產方，同時對接風控大盤供領導決策。

中間部分是事中風控模型，運用的技術有實時也有離線。主要流程是生產系統主動發起是否需要風控、是否黑白名單、根據規則判斷是否命中風控。如果命中，生產系統會有相應的管控流程，會將管控的結果同步給財務系統，財務系統在閉環入倉形成一個迴圈。

最下部分是事後和事前風控流程，主要依據歷史資料和過往風險判斷的結果，根據一系列大資料手段對風控模型進行迭代最佳化，從資料中發現問題並形成案件，推送給調查預審、案件平臺等運營系統，同時督導防損調查人員進行防損調查。調查的結果，除了反饋給模型，還會同步給財務，從而挽回損失。

Flink 作為實時計算引擎，對接兩部分資料，分別是業務資料和規則資料。規則應用將變化的規則資料透過訊息的形式流入到計算引擎中。當 Flink 接收到實時生產訊息時，透過資料清洗、資料壓縮、資料封裝，和預先流入的規則資訊相結合，進行風險指標計算。計算結果儲存進實時模型中，並透過訊息或者介面的形式反饋給風控預警以及風控大盤。

04

Flink 賦能

我們最開始沒有事前和事中風控，屬於大資料風控，風險的判定比較滯後，嚴重影響到物流風控工作的推進。之後在我們初步涉及實時風控時，並沒有選擇實時計算引擎，而是採取 docker+多執行緒的方式，這就使得各個場景割裂，無法統一管理，且消費速度較慢。在資料洪峰到達時，資源利用率較低、擴容困難；在一些注重時效的事中風控中，命中率較低。

現在物流風控各環節，大規模推進事中風控，原有架構就已經無法滿足了。從運力事中風控開始逐步遷往 Flink 流式計算引擎，並開始搭建風控實時中臺模型，滿足業務場景對高吞吐、低延遲、高效能的要求，同時積極探索流批一體在風控場景下的應用。

先來簡單瞭解一下批處理和流處理的概念，流處理是透過 SDK、Storm、Flink 等流式計算引擎對資料進行逐條處理，並將處理結果儲存到資料庫中。批處理則是透過 Hive、Spark 對資料進行分層，按批處理，從 ODS 到 DWS，最終輸出結果對外服務。

我們理想的計算引擎應該是統一的，統一的資料來源、計算過程和服務。而 Flink 正是未來的統一計算引擎，它有著以下幾個特點：

1. 成熟的流批一體概念：統一的 shuffle 架構設計，並專門對序列化和記憶體複製進行了最佳化。

2. 生態相容：與 Hadoop yarn /Kubernetes 整合，並且支援單機模式執行。

3. 效能卓越：效能卓越的批處理和流處理支援。

4. 規模計算：作業可被分解成為上千的任務，分佈在叢集中併發執行。滿足我們對高效能、高時效的需求。

05

技術挑戰

這是計重風控、終端風控相關的部分資料鏈路，從倉到分揀再到配送，整個資料鏈路長，風險規則繁多。

今年雙十一大促時，單個拓撲的訊息總量達到百億級以上，因此我們面臨諸多的挑戰。

1. 業務複雜性：多業務條線、多生產環節；資料來源多，資料異構；資料生命週期長；資料複式波峰；業務迭代快。

2. 海量資料：大促多條線資料量爆發，對叢集產生了很大的壓力。

3. 大狀態：單次增量 state 達 40G，高峰是更是達到 100G 以上。

4. 高實時性：終端風控場景要求時效控制在 3 秒內（包含上下游網路差異）

5. 資料傾斜：資料來源上資料分佈不均勻。

6. 儲存壓力：儲存無法抗住 Flink 的寫入 QPS。

我們最先開始的是業務上的最佳化，對於資料傾斜問題，我們採用了感興趣列過濾，減少進入拓撲的資料數量，主要依靠 kafka 當前變更的值來進行資料過濾。反壓監控，最佳化邏輯或增加資源。根據業務具體條件，變更 keyby 欄位。

對於高實時性的問題，我們採取變更資料來源、減少途徑鏈路、前置計算、新增快取、剝離核心和非核心業務。減少資料鏈路的同時，儘可能降低拓撲的大小。

對於儲存的問題，我們進行壓縮合並，降低寫入頻率。將計算寫入分離，避免因為儲存問題影響叢集的正常執行。

因為每一個拓撲的資料量、計算邏輯都不相同，所以每個配置也不盡相同。要進行合理的配置需要了解 TM 的記憶體模型。從圖上所知，如果是容器化部署，那麼容器的記憶體大小就是總處理記憶體的大小。Flink 總記憶體的大小等於總處理記憶體減去元空間和記憶體超限的大小，這兩塊一般採用預設值即可。

Flink 總記憶體包含堆和非堆兩部分，框架堆記憶體和框架非堆記憶體也是採用預設值就可以，無需額外配置。任務堆記憶體等於 Flink 總記憶體減去其他記憶體配置的大小得出，也無需單獨配置。

這麼算下來，我們只需關注託管記憶體、任務堆外記憶體以及網路快取即可。託管記憶體如果使用 RocksDB 狀態後端，且狀態資料量較大或讀寫較頻繁，建議適當增加託管記憶體的大小。配置太小對叢集效能的影響是非常巨大的，可以配合 RocksDB 監控來決定。

任務堆外記憶體一般流作業很少用到，所以可以優先保障堆記憶體，降低該記憶體的大小。網路快取也是一般容易造成浪費的地方，整個拓撲需要的網路快取大小是由並行度以及上下游互動方式所決定，所以在拓撲啟動時，就會確定一個大小，且向上浮動不大。我們一般保留 50%~70%來預防後續並行度增加即可，優先保障任務堆記憶體。

先了解下狀態的寫入和讀取流程。寫入操作先寫入活動寫快取，寫滿以後轉換為只讀寫快取，再 flash 進磁碟形成 SST 索引檔案。讀取則是依次從活動寫快取、只讀寫快取、塊快取以及 SST 索引檔案中尋找目標資料。因此我們只需關注寫快取、塊快取以及 SST 索引檔案這三部分的記憶體大小即可。

一般情況，這三者的配置無需變更，若作業狀態特別重讀或重寫，可以適當進行調整，但優先保證託管記憶體的充足。還有一些其他建議調整的引數，比如啟用增量狀態同步、開啟壓縮清理、調整狀態非同步的執行緒數量，這個一般與容器的 CPU 個數保持一致即可。

狀態預定配置有四種，預設、機械磁碟、機械磁碟+記憶體、SSD。如果單個槽的狀態量達到 GB 級別，且託管記憶體充裕的情況下，設定為機械磁碟+記憶體的效能是最佳的，其他情況設定為機械磁碟即可。

還有一些其他最佳化，程式碼層面，使用元組、複用物件、資料去重、非同步呼叫等等。

部署層面上，並行度最佳化、鏈合併、拓撲分拆、計算和寫入分離、採用 child-first 的類載入機制避免版本衝突等等。

06

未來規劃

目前流批一體在風控場景上的應用還是比較薄弱的，舊版本的升級也是未來規劃中比較重要的一環。風險庫的建立還處於野蠻發展中，其中的規範制定也是迫在眉睫的事情。