DataPipeline王睿：業務異常實時自動化檢測 — 基於人工智慧的系統實戰

大家好，先自我介紹一下，我是王睿。之前在Facebook/Instagram擔任AI技術負責人，現在DataPipeline任Head of AI，負責研發企業級業務異常檢測產品，旨在幫助企業一站式解決業務自動化監控和異常檢測問題。 今天主要從以下四方面跟大家分享構建該產品的思路和實戰。

一、為什麼需要人工智慧業務異常檢測系統

企業會因為業務異常無法得到及時解決而遭受較大的損失，比如某知名網際網路企業，將原價為50元的優惠券以18元賣出，導致使用者在短時間內大量瘋搶，損失慘重。 同樣，在金融、零售、電商領域因為IT系統的bug或人工原因導致的業務異常也給企業造成了不可估量的經濟損失。

然而，在業務異常出現時，企業往往在幾天甚至幾個星期之後才會發現。 以某公司為例，其主營業務為線上借貸，有次放款率突然增加，此時距離出現問題已經過去十幾個小時 。 後果是將錢款借給了許多不具備借貸資質的人，導致回款率和營收大幅下降。

為此，隨著企業業務的持續高速增長以及資訊化的全面普及，業務人員需要對業務變化有一個全面實時地掌控。 這時，IT運維人員會關心伺服器和網路的執行；產品負責人 會關心使用者訪問，點選率和使用者體驗等； 業務負責人則關心業務的核心KPI，如銷售額。 這些指標猶如一個人的心跳、血壓、體溫，反映企業業務的健康狀況。

如何能快速準確地從業務指標中識別異常，發現問題根因，並及時解決對企業而言就顯得尤為重要。

目前針對這塊，不同企業採取的方法各異。 傳統的業務監控方法往往是手工生成報表每天檢視，對於比較重要且實時性要求較高的指標，會人工設定閾值，當指標跨過閾值時報警。 對於已知週期性的指標一般會用類似同比環比的方法。

隨著企業業務量和業務種類的不斷提升，人工的監控也隨之增多。 而這種基於人工的方法則會顯示出幾大不足：

1. 大量業務指標沒有被實時監控。 以電商為例，若只監控總銷售額，採用人工方法很容易實現。但是，一旦某些地區或品類的銷售額出現異常，只看總銷售額指標則很難發現問題。

例如某零售企業，其酸奶的銷售額在某地區較之前有所下降，原因是酸奶的庫存出現了週轉問題。由於一直售賣過期酸奶，導致接到大量使用者舉報。針對該情況，若只監控總銷售額很難發現問題，這時需要監控品類和地區兩個維度更細粒度的指標。而監控多個維度的指標，指標監控的數量會成倍增長，顯然是人工無法勝任的。

2. 告警洪流。 當業務出現問題時，往往報警的接收人員會收到大量告警，使得他們被告警洪流淹沒，很難精準定位問題根因。除了告警的準確率低以外， 還由於業務指標之間具有很強的相關性，主要體現在兩個方面：

首先是指標之間的鏈路關係。 比如在電商零售領域，當伺服器錯誤增高時導致使用者訪問下降，從而導致下游的訂單減少。 另外是指標的多維度特性，例如當訂單下降時，往往多個產品線，多個地區訂單量同時下降。 因此當業務出現問題時，往往是多個相關的指標一起告警，形成告警洪流。

3. 誤報漏報。 作為業務負責人，既不想在業務出現問題的最後一刻才知道，也不想在凌晨三點被一個假警報叫醒。 而多次的誤報會導致“狼來了”的效應，當真正的問題出現時，告警卻往往容易被接收人員忽略掉。

4. 人工維護成本。 隨著業務的不斷變化，大量的告警閾值和規則需要人工調整，而這顯然跟不上業務的變化速度和監控指標不斷增多的節奏。

因此我們需要一套自動化的智慧業務監控和異常檢測系統，透過對指標變化規律的學習，自動掌握指標資料正常和異常的表現模式，從而全面，實時地監控企業業務不同層面，不同維度的各項指標。 這就是為什麼我們需要搭建基於人工智慧演算法的業務異常檢測系統的原因。

                                                          二、搭建該系統的挑戰和設計理念

人工智慧演算法在異常檢測領域已經被研究了幾十年，但是搭建這樣的系統卻並非易事。 主要的挑戰有以下幾點：

第一，對於異常的定義較為模糊 且各種資料指標的表現形式千差萬別。比如IT的CPU異常與銷售額異常不同，因此試圖用一種通用的演算法檢測不同型別指標的異常往往準確率很低。因為某一類資料的異常表現形式放在另一類資料指標中可能就不會被認為是異常。 另外，在未來發生的異常很多時候是過去並未見過的。

這直接導致了第二個難點，即很難獲取標註資料。 不僅很難標註一個資料的變化是否是異常， 且異常出現的頻率較低，很難像傳統機器學習問題那樣獲得很多正負樣本。

第三，對該演算法和系統的實時性和可擴充套件性要求很高。 如果不能實時監控大量指標，發現異常並告警，這個系統將失去其意義。

為解決上述痛點，同時考慮到種種挑戰，DataPipeline在設計該系統前確定了幾點設計原則：

1. 無（半）監督機器學習演算法為主

雖然目標是將資料分類為正常或異常，但由於異常的定義模糊，很難獲取標註資料，我們主要採取無監督的機器學習演算法。 當然，對於給使用者傳送的告警，系統需要可以收集使用者的反饋，然後用在提升演算法的準確性上。 綜合來講，這是一種半監督學習的方法。

2. 演算法跟業務解耦

人工智慧演算法的優勢在於解放人工，做到自動化，因此演算法需要跟業務儘可能解耦。 演算法可以透過對於指標歷史資料本身模式（如週期性）的學習來建模。 而不同業務指標資料的表現形式各異，總體上時序資料的表現型別是有限的，因此我們需要演算法具備根據不同表現形式選擇不同模型的能力。

3. 異常相關性學習和根因分析

上面講到的一個很大的痛點是告警洪流。當業務出現問題時，業務人員往往被淹沒在大量告警中，很難快速準確地定位問題。因此我們需要學習監控指標之間的相關性，當業務出現問題時給使用者一個彙總的告警，這樣不僅能避免告警洪流，還能讓使用者一目瞭然地看到反映問題的相關指標，從而更快找到問題根因。從產品角度而言，這也是一個成熟的業務異常檢測系統中很重要的組成部分，即根因分析。我們不僅希望及時地反應業務問題，也希望能縮小發現問題到解決問題的時間和成本。

4. 演算法的擴充套件性和實時性

演算法和整個系統需要做到對億級資料指標的秒級實時響應。 因此我們主要考慮應用輕量級並且支援線上學習（Online Learning）的演算法模型。 近些年深度學習在異常檢測領域的應用逐漸成熟，其相較於傳統的統計模型演算法具有更強的泛化能力。 但這些演算法的訓練成本較大，因此需要對實時性要求更高的指標系統進行取捨。

三、DataPipeline的演算法實現思路

基於以上設計原則，DataPipeline提出瞭解決問題的幾個步驟：

1. 接入資料

首先利用DataPipeline自身的資料整合能力，從不同資料來源中接入實時的資料流或批式的資料集並進行預處理，形成多個指標的時序資料。

2. 正常表現的建模

進而對每個單一的指標時序資料學習其正常表現模式，擬合模型，並自動生成置信區間。 如下圖，深藍色部分為資料本身，淺藍色部分為自動生成的置信區間，紅色部分為異常。

3. 異常的檢測和過濾

對於新的資料點，一旦其跨過置信區間系統便認定為異常。 接著對於每個識別出的異常進行打分和過濾。

4. 關聯多個異常並自動報警

對檢測出的多個異常，演算法自動進行相關性學習，將其關聯起來。 最後生成一個彙總的告警，傳送給使用者。

下面重點解釋對單一資料的正常表現建模，異常檢測和關聯多個指標異常的具體技術實現。

1. 單一數 據的正常表現 建模

在過去數十年裡，許多不同型別的演算法被研究和開發來嘗試解決這一問題。 其中有較為傳統的基於統計模型的演算法，也有許多基於時序資料的分析方法，而近年來大熱的深度學習模型也被證明在時序資料預測和異常檢測上有較高的準確性。

這些演算法一般遵循這樣一個步驟：先對歷史資料進行建模，學習資料正常表現的規律。對新來的資料點，根據資料點偏離正常表現模型的程度來判定是否為異常。

比如最簡單的演算法模型是高斯分佈，假設該指標資料符合高斯分佈，就可以透過歷史資料點估計出高斯分佈的mean和期望（均數）μ和標準差σ，進而對新的資料點判定，如果偏離期望多於三個標準差則該資料點不能被模型解釋的機率為99.7%，我們就可以判定其為異常。然而 實際情況是，大部分資料都無法簡單地表現為高斯分佈。

因此，首先我們需要根據資料本身來自動選擇最適合的演算法模型。 這也是很多開源的異常檢測演算法直接被拿來使用往往得不到滿意效果的一個原因，因為他們一般假設資料的底層表現是平穩的（Stationary），並且資料是規則取樣的（Regular Sampling），若使用不適合的演算法模型對資料建模會得到非常不好的效果，甚至完全無法使用。 因此DataPipeline開發了一個演算法，可以自動根據資料的表現形式選擇最合適的演算法進行擬合。 最常用的演算法可以分為基於統計模型的演算法和深度學習的演算法。

• 統計模型演算法

除了上面提到的高斯分佈，比較常用的模型有基於指數平滑（Exponential Smoothing）的模型，實際是對過去的資料進行平均來預測未來的資料，只是給時間上更靠近當下的資料點更大的權重。 比較經典的有Holt-Winters，ARIMA等，這些還可以將週期性的規律考慮進去。

• 深度學習演算法

對於不符合規則取樣和不表現為Staionary的資料，深度學習演算法的效果更好。 LSTM（Long Short-Term Memory）是最常用的演算法，而當下許多最新的演算法都是基於LSTM上的變種。 然而深度學習演算法很難做到實時訓練，即模型隨新的資料點實時更新，而且當監控資料量大的時候非常耗費CPU。

演算法自動選擇出最合適的模型後，系統便可根據歷史資料擬合模型，估計出模型引數，進而針對每個資料點給出預測。對於實際資料點和預測資料點的差異（error）我們可以用高斯分佈來模擬，利用高斯模型計算出一個置信區間，當新資料的error偏離置信區間過大時將其判斷為異常。

2. 週期性學習

許多指標資料都表現出明顯的週期性，而週期性學習對異常檢測的準確性至關重要。 最常見的自動學習週期性方法是自相關學習（Autocorrelation）。簡言之， 該演算法是將資料向過去平移一個時間差（Lag），然後計算平移後的資料和原來資料的統計相關性。如果某一個Lag平移後的資料和原資料相關性很大，則認為該Lag就是資料的週期性。 此演算法的主要問題是計算量較大，因為要對多個Lag進行計算。

鑑於上面提到的實時性和可擴充套件要求，DataPipeline對該演算法用Subsampling的方法進行最佳化，降低了計算複雜度。

3. 相關性學習

之前提到為解決告警洪流問題，我們需要一個演算法可以自動化計算指標間的相關性，在多個異常同時出現時，可以將反映同個業務問題的異常關聯在一起，給使用者一個彙總的告警。針對 這類問題，一般傳統的方法是採取多變數分析（Multivariate Analysis），即將所有時序資料當成互相有關聯的多變數一起建模，然後在整體層面檢測異常。該 方法的主要問題是很難規模化，且當出現異常時檢測結果的解釋性較差。

因此，在DataPipeline，我們採用單變數分析對每個指標進行異常檢測，然後利用大規模聚類演算法將相關度較高的指標進行聚類（如上圖）。 這樣每個指標的機器學習和相關性學習兩部分可以各自規模化，使得整個系統計算效率更高。 而聚類演算法透過幾類特徵來進行計算：

• 異常表現的相似度

簡言之，如果兩個指標多次、同時出現異常，則認為兩者更相關。 我們可以生成一個異常表現的特徵向量，若在某個時間點該指標表現正常便設定為0，若表現異常則設定為異常的打分（演算法根據異常的嚴重程度自動打分）。

• 統計模型的相似度

即指標的數值是否有相似的模式。其中計 算兩個時序資料數值相似度最常見的演算法是Pearson Correlation Coefficient。

• 後設資料相似度和人工反饋

DataPipeline還根據後設資料的拓撲關係來判斷相關性。 比如同一個指標的多個維度生成的多個子指標會被認為更相關。 此外，使用者也可自己輸入一些資訊告訴系統哪些指標更相關。

四、DataPipeline的系統架構

若構建一套企業級業務監控和異常檢測系統應該具備哪些組成部分？ 下面為DataPipeline的一些思路。

1.  產品功能組成

從產品功能角度而言，該系統可以接入企業的各種業務系統（左邊），包括核心業務系統和各種已有系統，諸如資料分析，監控系統等。 挑戰是如何將多源異構的資料以一致的方式接入，且同時可以處理流式和批式資料。 DataPipeline已有的資料融合產品可以很好地實現這點。如果 企業自己搭建，則需要根據具體情況確定實現方式。

另外，針對中間的系統核心，我們將其設計成了一個跟業務完全解耦的黑盒。 右邊則是使用者互動UI，包括兩部分：第一是告警系統，可根據企業的報警需要接到企業交流app如釘釘、郵件，電話等。 第二是監控看板，可以看到監控的指標資料，搜尋不同指標和多維度展示。 另外，還可看到指標異常的彙總展示，根因展示等。 從看板上使用者可以根據展示出的異常進行反饋，表明這是正確的異常還是誤報，另外還可調整指標異常檢測的敏感度。 這些反饋和調整會返回到系統中。

2. 核心系統架構

核心系統主要分為線上處理和線下模型訓練兩部分。 線上部分處理實時的資料指標最新資料流，從模型儲存資料庫中讀入模型並存於記憶體中，對資料流中每一個資料指標進行實時的閾值計算、異常檢測和打分。 之後多個資料指標的異常檢測結果會被彙總到一個關聯性處理器，進行異常的關聯，最後將關聯好的異常指標組彙總，生成並觸發告警。 在處理實時指標資料時，處理器會將最新的指標資料和檢測出的異常分別寫入資料庫為線下訓練做準備。

線下部分會定時從資料指標的歷史資料庫中讀取資料並進行線下的模型訓練，這其中便包括上面提到的演算法自動選擇，週期性學習等。 也會定期利用使用者返回的反饋對模型進行評估，計算出誤報漏報率等。

總結

業務異常的不及時解決會給企業帶來巨大的經濟損失。 相對於傳統的人工生成報表和人工閾值的監控方法，基於人工智慧的業務異常檢測系統可以更自動化，更全面地監控業務各項指標並給出準確率更高，更有幫助性的報警和業務洞見。

而搭建這樣一套系統面臨業務資料表現形式多樣，告警過多準確率低下等挑戰。 伴隨著 企業級人工智慧業務異常檢測系統的出現，企業可以更高效、及時全面的掌控業務，從而實現業務和經濟效益的提升。