1.背景介紹
異常檢測可以定義為“基於行動者（人或機器）的行為是否正常作出決策”，這項技術可以應用於非常多的行業中，比如金融場景中做交易檢測、貸款檢測；工業場景中做生產線預警；安防場景做***檢測等等。

根據業務要求的不同，流計算在其中扮演著不同的角色：既可以做線上的欺詐檢測，也可以做決策後近實時的結果分析、全域性預警與規則調整等。

本文先介紹一種準實時的異常檢測系統。

所謂準實時，即要求延遲在100ms以內。比如一家銀行要做一個實時的交易檢測，判斷每筆交易是否是正常交易：如果使用者的使用者名稱和密碼被盜取，系統能夠在盜取者發起交易的瞬間檢測到風險來決定是否凍結這筆交易。

這種場景對實時性的要求非常高，否則會阻礙使用者正常交易，所以叫做準實時系統。

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

2.系統架構與模組綜述
為了解決這個問題，我們設計如下的系統架構：

線上系統，完成線上檢測功能，可以是web服務的形式：
針對單條事件進行檢測
根據全域性上下文進行檢測，比如全域性黑名單
根據使用者畫像或近期一段時間的資訊進行檢測，比如最近20次交易時間與地點
kafka，把事件與檢測的結果及其原因傳送到下游
flink近實時處理
近實時的更新使用者的屬性，比如最近的交易時間&地點；

彙總統計全域性的檢測狀態，並做同期對比，比如某條規則的攔截率突然發生較大變化、全域性通過率突然增高或降低等等；

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.總結
上面給出了一個準實時異常檢測系統的概念性設計，業務邏輯雖然簡單，但整個系統本身是非常完整且具有良好擴充套件性的，所以可以在這個基礎上進一步去完善。
歡迎工作一到五年的Java工程師朋友們加入Java架構開發： 855835163
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！