內容來源：本文內容由阿里雲實時計算，流計算團隊提供。IT 大咖說作為獨家合作方，經授權發佈。
閱讀字數：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.總結
上面給出了一個準實時異常檢測系統的概念性設計，業務邏輯雖然簡單，但整個系統本身是非常完整且具有良好擴展性的，所以可以在這個基礎上進一步去完善。
後面我會再介紹近實時的異常檢測系統，即實時性要求不那麼高，要求在秒級的異常檢測系統，在近實時異常檢測系統中，流計算會發揮更大的作用。
以上為今天的分享內容，謝謝大家！此外，對實時計算業務感興趣的同學可以關注如下活動：
流計算團隊將於8月30日13:40-17:45在杭州夢想小鎮舉辦阿里雲流計算杭州峰會，聚焦實時大數據處理。流計算專家首次現場手把手教學——‘十分鐘教你搭建雙11成交大屏’。
詳情請複製：http://t.cn/RFGZau7 查看。
閱讀更多 IT大咖說 的文章
