京東物流實時風控實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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