以實時風控場景爲例，阿里雲實時計算如何來作異常檢測？

內容來源：本文內容由阿里雲實時計算，流計算團隊提供。IT 大咖說（微信id：itdakashuo）做爲獨家合做方，經受權發佈。

閱讀字數：3102 | 8分鐘閱讀

前言

DT時代，數據是最重要的生產資料。互聯網的發展讓人們時刻在線，產生着數據，數據在線了，處理天然也應該在線，但傳統的離線大數據處理方式面對這一業務需求愈來愈力不從心。因而流計算技術應運而生，以其亞秒級延遲的處理能力迅速解決了大數據實時化的問題，在各個業務場景大放異彩：從實時ETL到實時數據倉庫的構建，從實時營銷到實時推薦，從互聯網到IoT，實時的處理能力漸漸成了大數據系統的標配。

目前實時計算擅長解決的幾個領域的應用場景：

• 實時BI：實時的網絡點擊PV、UV統計。

• 城市交通：統計交通卡口的平均5分鐘經過車流量。

• 工業大腦：水利大壩的壓力數據統計和展示。

• 實時風控：網絡支付涉及金融盜竊固定行爲規則的告警。

• 實時推薦：實時提取特徵變量，及時跟蹤用戶關注品類，預測用戶消費趨勢。

以「實時風控」的場景爲例，咱們具體談談，阿里雲實時計算如何來作異常檢測的。

1.背景介紹

異常檢測能夠定義爲「基於行動者（人或機器）的行爲是否正常做出決策」，這項技術能夠應用於很是多的行業中，好比金融場景中作交易檢測、貸款檢測；工業場景中作生產線預警；安防場景作入侵檢測等等。

根據業務要求的不一樣，流計算在其中扮演着不一樣的角色：既能夠作在線的欺詐檢測，也能夠作決策後近實時的結果分析、全局預警與規則調整等。

本文先介紹一種準實時的異常檢測系統。所謂準實時，即要求延遲在100ms之內。

好比一家銀行要作一個實時的交易檢測，判斷每筆交易是不是正常交易：若是用戶的用戶名和密碼被盜取，系統可以在盜取者發起交易的瞬間檢測到風險來決定是否凍結這筆交易。這種場景對實時性的要求很是高，不然會阻礙用戶正常交易，因此叫作準實時系統。

因爲行動者可能會根據系統的結果進行調整，因此規則也會更新，流計算和離線的處理用來研究規則是否須要更新以及規則如何更新。

2.系統架構與模塊綜述

爲了解決這個問題，咱們設計以下的系統架構：

在線系統，完成在線檢測功能，能夠是web服務的形式：

• 針對單條事件進行檢測

• 根據全局上下文進行檢測，好比全局黑名單

• 根據用戶畫像或近期一段時間的信息進行檢測，好比最近20次交易時間與地點

kafka，把事件與檢測的結果及其緣由發送到下游。

blink近實時處理：

• 彙總統計全局的檢測狀態，並作同期對比，好比某條規則的攔截率忽然發生較大變化、全局經過率忽然增高或下降等等；

• 近實時的更新用戶的屬性，好比最近的交易時間&地點；

maxcompute/hadoop存儲與離線分析，用於保留歷史記錄，並由業務&開發人員探索性的研究有沒有新的模式。

hbase，保存用戶畫像。

3.關鍵模塊

3.1 在線檢測系統

交易的異常檢測在本系統中實現，他能夠是一個web服務器，也能夠是嵌入到客戶端的系統。在本文中，咱們假設它是一個web服務器，其主要任務就是檢閱到來的事件並反饋贊成或拒絕。

針對每個進入的事件，能夠進行三個層次的檢測：

• 事件級檢測

只用該事件自己就能完成檢測，好比格式判斷或基本規則驗證（a屬性必須大於10小於30，b屬性不能爲空等等）

• 全局上下文檢測

在全局信息中的上下文中，好比存在一個全局的黑名單，判斷該用戶是否在黑名單中。或者某屬性大於或小雨全局的平均值等。

• 畫像內容檢測

針對該行動者自己的跨多條記錄分析，好比該用戶前100次交易都發生在杭州，而本次交易發生在北京且距上次交易只有10分鐘，那就有理由發出異常信號。

因此這個系統至少要保存三方面的東西，一方面是整個檢測的過程，一方面是進行判斷的規則，一方面是所需的全局數據，除此以外，根據須要決定是否把用戶畫像在本地作緩存。

3.2 kafka

kafka主要用來把檢測的事件、檢測的結果、拒絕或經過的緣由等數據發送到下游，供流計算和離線計算進行處理。

3.3 實時計算Flink近實時處理

在上面的系統中已經完成了異常檢測，並把決策發送到了kafka，接下來咱們須要使用這些數據針對當前的策略進行新一輪的防護性檢測。

即便已知的做弊行爲已經輸入到模型和規則庫中進行了標記，但總有「聰明人」嘗試欺詐。他們會學習如今的系統，猜想規則並做出調整，這些新的行爲極可能超出了咱們當前的理解。因此咱們須要一種系統來檢測總體系統的異常，發現新的規則。

也就說，咱們的目標不是檢測單個事件是否有問題，而是要檢測這些用來檢測事件的邏輯自己有沒有問題，因此必定要站在比事件更高的層面來看問題，若是在更高的層面發生變化，那麼有理由考慮對規則/邏輯進行調整。

具體來講，系統應該關注一些宏觀指標，好比總量，平均值，某個羣體的行爲等等。這些指標發生了變化每每表示某些規則已經失效。

舉幾個例子：

• 某條規則以前的攔截率是20%，忽然下降到了5%；

• 某天規則上線後，大量的正經常使用戶均被攔截掉了；

• 某我的在電子產品上的花費忽然增加了100倍，但同時其餘人也有不少相似的行爲，這可能具備某種說得通的解釋（好比Iphone上市）；

• 某人連續幾回行爲，單次都正常，但不該該有這麼屢次，好比一天內連續買了100次同一產品【開窗分析】；

• 識別某種組合多條正常行爲的組合，這種組合是異常的，好比用戶買菜刀是正常的，買車票是正常的，買繩子也是正常的，去加油站加油也是正常的，但短期內同時作這些事情就不是正常的。經過全局分析可以發現這種行爲的模式。

業務人員根據流計算產生的近實時結果可以及時發現規則有沒有問題，進而對規則做出調整。除此以外，流計算還能進行用戶畫像的實時更新更新，好比統計用戶過去10分鐘的幾回行爲，最近10次的登錄地點等等。

3.4 maxcompute/hadoop離線存儲於探索性分析

在這個環節中，能夠經過腳本、sql、或機器學習算法來進行探索性分析，發現新的模型，好比經過聚類算法把用戶進行聚類、對行爲打標後進行模型的訓練等等，或者週期性的從新計算用戶畫像。這裏和業務關係很大，很少過多描述。

3.5 hbase用戶畫像

hbase保存着流計算&離線計算產生的用戶畫像，供檢測系統使用。之因此選擇hbase主要是爲了知足實時查詢的需求。

4.總結

上面給出了一個準實時異常檢測系統的概念性設計，業務邏輯雖然簡單，但整個系統自己是很是完整且具備良好擴展性的，因此能夠在這個基礎上進一步去完善。

後面我會再介紹近實時的異常檢測系統，即實時性要求不那麼高，要求在秒級的異常檢測系統，在近實時異常檢測系統中，流計算會發揮更大的做用。