本次演講將為大家介紹攜程實時智能異常檢測平臺——Prophet。到目前為止，Prophet基本覆蓋了攜程所有業務線，監控指標的數量達到10K+，覆蓋了攜程所有訂單、支付等重要的業務指標。Prophet將時間序列的數據作為數據輸入，以監控平臺作為接入對象，以智能告警實現異常的告警功能，並基於Flink實時計算引擎來實現異常的實時預警，提供一站式異常檢測解決方案。

演講嘉賓簡介：潘國慶，攜程大數據研發經理。

以下內容根據演講視頻以及PPT整理而成。
https://developer.aliyun.com/live/1790

本次分享主要圍繞以下四個方面：

• 背景介紹
• Prophet
• 智能化與實時化
• 挑戰與展望

一、背景介紹

規則告警帶來的問題

大部分監控平臺是基於規則告警實現監控指標的預警。規則告警一般基於統計學，如某個指標同比、環比連續上升或下降到一定閾值進行告警。規則告警需要用戶較為熟悉業務指標的形態，從而才能較為準確的配置告警閾值，這樣帶來的問題是配置規則告警非常繁瑣、告警效果也比較差，需要大量人力物力來維護規則告警。當一個告警產生時，也需要耗費許多人力驗證告警是否正確並確認是否需要重新調整閾值。在攜程，規則告警還涉及了其它問題，比如攜程光公司級別的監控平臺就有三個，每個業務部門還會根據自己的業務需求或業務場景構建自己的監控平臺。攜程內部有十幾個不同規模的監控平臺，在每一個監控平臺都配置監控指標對於用戶是非常繁瑣的。

二、Prophet

針對規則告警存在的以上幾種問題，攜程構建了自己的實時智能異常檢測平臺——Prophet。攜程構建Prophet的靈感源於FaceBook的Prophet，但實現上有別於FaceBook的Prophet。

1.一站式異常檢測解決方案

首先，Prophet以時間序列類型的數據作為數據輸入。其次，Prophet以監控平臺作為接入對象，以去規則化為目標。基於深度學習算法實現異常的智能檢測，基於實時計算引擎實現異常的實時檢測，提供了統一的異常檢測解決方案。

2.Prophet系統架構

• 底層：Hadoop底層。YARN作為統一資源調度的引擎，主要用於運行Flink的作業。HDFS主要用於存儲訓練好的TensorFlow模型。
• 引擎層：首先數據必須實時存在於消息隊列當中，Prophet使用的是Kafka。此外，Prophet使用Flink計算引擎實現實時異常預警，使用TensorFlow作為深度學習模型的訓練引擎。同時Prophet基於時序數據庫存儲歷史數據。
• 平臺層：最上層是對外提供服務的平臺層Prophet。Clog用於採集作業日誌。Muise是實時計算平臺。Qconfig用於存儲作業中需要用到的配置項。Hickwall用於作業的監控告警。

3.Why Flink？

目前主流的實時計算引擎有Flink、Storm和SparkStreaming等多種，攜程選擇Flink作為Prophet平臺的實時計算引擎的原因主要是Flink具備以下四點特徵：

• 高效的狀態管理：異常檢測的過程中有許多狀態信息需要存儲。使用Flink自帶的State Backend可以很好地存儲中間狀態信息。
• 豐富的窗口支持：窗口包含滾動窗口、滑動窗口以及其他窗口。Prophet基於滑動窗口進行數據處理。
• 支持多種時間語義：Prophet基於Event Time。
• 支持不同級別的容錯語義：Prophet至少需要做到At Least Once或Exactly Once的級別。

4.Prophet操作流程

用戶只需要在自己常用的監控平臺上選擇配置智能告警，後續所有流程都是由監控平臺和Prophet智能告警平臺對接完成。監控平臺所需要做的包含兩件事，首先將用戶配置的監控指標同步到Prophet平臺， 其次監控平臺需將用戶配置的監控指標數據實時的推送到Kafka消息隊列中。

Prophet在接受到新的監控指標後，便開始嘗試使用Tensorflow訓練模型。模型訓練需要歷史數據，平臺可以按照約定好的規範提供歷史數據查詢接口，Prophet通過接口獲取歷史數據並進行模型訓練、如果沒有接口，Prophet基於消息隊列中的數據來積累訓練數據集。模型訓練完成後，將其上傳到HDFS，Prophet會更新配置中心中的配置通知Flink有新訓練好的模型可以加載。所有實時推送到Kafka裡面的監控指標的數值，會同步的落到Prophet的時序數據庫中，在異常檢測的過程中需要用到這些指標數值。當模型訓練完成後，Flink的作業一旦監聽到配置發生了更新，就開始嘗試加載新模型，實時消費Kafka裡面的指標數據，最終產出檢測結果以及異常告警會回寫至Kafka，各個監控平臺會從Kafka獲取自己監控平臺的那一部分告警數據。整套Prophet操作流程對於用戶是無感知的，用戶只需要配置告警，極大的提供了便捷性。

三、智能化與實時化

1.智能化挑戰

在做智能檢測之前還會遇到一些挑戰。

• 負樣本少
  ：生產環境中發生異常的概率比較小。攜程在很多年的時間僅積累了大概幾千條負樣本數據。
• 業務指標類型多：業務指標類型繁多，有訂單、支付等業務類型的指標，也有服務類型的指標，如請求數、響應延時等，以及硬件設施類型的指標，如CPU、內存、硬盤等各種指標。
• 業務指標形態多：正因為有不同類型的業務指標，業務指標的形態也各不相同。攜程將業務指標形態歸納為三部分。一是週期波動相對平穩的指標，第二是穩定的，不會劇烈波動的指標，第三是上下波動幅度非常劇烈、呈現不穩定的形態的指標。

2.深度學習算法選擇

針對以上三點問題，攜程嘗試了RNN，LSTM和DNN等多種深度學習算法。

• RNN：RNN的優點是適合時間序列類型的數據，而缺點是存在梯度消失問題。
• LSTM模型：LSTM的優點是解決了梯度消失的問題。RNN和LSTM深度學習算法需要先給每個指標訓練一個模型，然後輸入當前的數據集，基於模型來預測當前數據集的走向。然後再比對預測數據集和當前數據集進行異常檢測。這種方式帶來的好處是檢測精度高，但是單指標單模型也帶來更多的資源消耗。
• DNN：DNN的優點是單個模型能夠覆蓋所有異常檢測的場景。但是特徵提取會非常複雜，需要提取不同頻域的特徵，需要大量用戶標註數據。

3.離線模型訓練

攜程一般兩週發一次版本，每個業務指標都是每兩週嘗試訓練一次，模型輸入的訓練數據也取兩週的數據集。在使用歷史數據之前需要做數據預處理，比如歷史數據中可能存在null值，需要使用均值標準差將其補齊。其次歷史數據區間裡面肯定會有一些異常區間，需要用一些預測值替換異常區間的異常值。另外由於節假日期間數據較為複雜，需要替換節假日期間的異常值。對歷史數據的數據集做數據預處理之後，開始提取其不同時序的特徵或者頻率的特徵。然後通過一個分類模型分類出指標是平穩的、非週期的還是週期型的。不同類型的指標需要不同的模型進行訓練。

4.模型動態加載

模型訓練完成後，Flink作業需要動態加載模型。但實際場景下，不可能每訓練一個模型便重啟一次Flink作業。所以Prophet平臺將模型訓練完成後上傳到HDFS，通知配置中心，然後Flink作業開始從HDFS上拉取模型。為了使每個模型均勻分佈在不同的Task Manager上面，所有監控指標會根據本身id做keyBy，均勻分佈在不同的Task Manager上。每個Task Manager只加載自己部分的模型，以此降低資源消耗。

5.數據實時消費與預測

模型加載完成後需要做實時異常檢測。首先從Kafka消息隊列中消費實時數據。Prophet目前基於Flink Event Time+滑動窗口。監控指標的時間粒度可以分為很多種，如1分鐘一個點、5分鐘一個點、10分鐘一個點等等。例如基於1分鐘一個點的場景來看，在Flink作業中開一個窗口，其長度是十個時間粒度，即十分鐘。當積累到十條數據時，用前五個數據預測下一個數據，即通過第1、2、3、4、5五個時刻的數據去預測第六個時刻的數據，然後用第2、3、4、5、6時刻的數據預測第七個時刻的數據。最終獲得第6、7、8、9、10五個時刻的預測值和實際值。再利用預測值與實際值進行對比。以上是數據無異常的理想場景下的情況。

6.數據插補與替換

實際場景下往往會出現意想不到的情況。例如上述10分鐘的場景中只獲得了9條數據，缺少第4個時刻的數據， Prophet會使用均值標準差補齊此類缺失數據。另外如果在上一個時刻檢測到第6、7、8、9、10時間區間是異常區間，發生了下跌或者上升。那麼此區間的數據被認為是不正常的，不能作為模型輸入。此時需要用上一批次模型預測出的第6時刻的值替換原始的第六個時間粒度的值。第2、3、4、5、6這五個時刻值中第4是插補而來的，第6是時間區間訓練出來的預測預測值替換掉了異常值。以插補替換之後的值作為模型輸入，得到新的預測值7。再依次進行預測。中間過程中異常區間第6、7、8、9、10時刻的預測值需要作為一個狀態來存儲到Flink StateBackend，後續窗口會使用到這些預測值。

7.實時異常檢測

實時異常檢測主要可以從以下幾個方面進行判斷：

• 基於異常類型與敏感度判斷：不同的指標不同的異常類型，如上升異常，下跌異常。其次，不同指標敏感度不同，可以定義其為高敏感度、中敏感度、低敏感度。當高敏感度指標發生簡單的下降抖動時，認為是下跌異常。中敏感度指標可能連續下跌兩個點時會判斷異常。對於低敏感度指標，當下跌幅度較大時才會判斷為異常。
• 基於預測集與實際集的偏差判斷：如果預測結果和實際結果偏差較大，認定當前第6、7、8、9、10時刻區間是潛在的異常區間。
• 基於歷史同期數據均值與標準差判斷：同時需要與上週同期的時間進行對比，同一區間的數值偏差較大，則判斷為異常。當異常樣本較多時，可以用簡單的機器學習分類模型通過預測值和實際值做異常判斷。

8.常見場景

• 常見問題：對於用戶來說，監控指標太多，監控的維度也比較多。比如一個指標可能有max、min等不同的統計方式，監控指標的數量就會比較多。其次，用戶能力有限，很難每日查看監控告警。
• 異常原因：發生異常的原因一般會是技術性問題。如發佈新版本上線時可能存在的bug導致業務出現下跌。少數的情況是由於外部因素的影響，比如調用外部鏈接或者服務，外部服務宕掉導致自己的服務出現問題。
• 解決方案：用戶為Prophet提供的檢測結果進行標註，選擇檢測結果的正確性。用戶的標註數據會用到Prophet以後的模型訓練中用於優化數據集。

9.節假日場景

由於攜程做旅遊方向的業務，節假日期間問題較為突出。不同類型的業務在節假日的表現是不同的。例如攜程的機票、火車票基本是在節前上升到一定量，到假期期間由於人們出遊，該買的票已經購買完成，機票等業務訂單量會下降很多。而酒店等業務在節假期間會上升很多。不同類型業務的趨勢不同，上升幅度較大的業務容易產生漏報，對於下跌幅度較大的業務，容易產生誤報。

節假日應對手段：不同的場景會導致不同的問題，所以Prophet針對節假日場景做了一些特殊處理。首先，維護每年節假日信息表，程序一旦發現下一個節假日還有一個星期時，Prophet就會提取出過去兩年內的不同節假日期間的數據。然後計算前兩年的不同節假日和當前節假日數值的相似度來匹配。相當於以當前節假日的數據擬合過去節假日的數據，擬合到某個時間段時，就知道大概從某個時間開始到某個時間結束是和當前趨勢類似的。然後會用過去多個節假日的數據作為一個組合作為新模型的數據輸入去訓練數據集。不同節假日的佔比不同，通過一些方式計算出不同佔比值。最終相基於組合的數據集訓練出新的模型，新的模型可以比較好地預測出某一個指標或者某一個業務在節假期七天之內的趨勢。

10.平臺現狀

Prophet基本覆蓋了攜程所有業務線。即攜程的重要業務指標基本都已經在使用監控智能告警。業務類型包含7種。監控指標的數量達到10K+，覆蓋了攜程所有訂單、支付等重要的業務指標，覆蓋了大部分服務的重要的業務指標。接入平臺在10+左右，基本接入了攜程公司所有系統級別的監控平臺，在陸續接入各個業務部門自己的監控平臺。Prophet平臺能夠覆蓋95%左右的異常，準確報警率達到75%。因為每個數據同步到Prophet便觸發數據實時消費、預測以及告警，告警延遲達到ms級別。告警數量也下降了十倍左右。

四、挑戰與展望

1.挑戰

• 資源消耗大：如果採用LSTM模型，需要為每個指標訓練模型，單個Flink作業裡面都加載了約4K~5K的模型，無論訓練資源還是實時處理資源消耗都相對較大。
• 節假日影響：由於在業務指標在不同節假日的趨勢不同，告警準確性受到一定程度的影響。
• 智能告警無法適用於全部場景：有些機器的CPU的使用率可以直接設定閾值，達到95%時告警，非常方便簡單。但是如果用智能告警的方式擬合其趨勢，意義不大。另外節假日大促時，會發放門票、酒店優惠券等活動，其訂單量可能快速增長10倍到100倍。這種突發的快速增長在歷史數據也很難學習到。上述場景的數據智能告警比較難處理。

2.展望

針對上述問題，Prophet正陸續進行改進，希望通過下面幾種方式解決遇到的挑戰。

• 通用模型迫在眉睫：Prophet目前訓練了一個DNN模型，可以處理所有監控指標。DNN模型的準確率可能相較於LSTM模型會低一點，但能夠涵蓋較多場景。所以針對訂單、支付等重要的業務指標，可以使用LSTM算法模型，保證準確性，但對於相對不太重要的業務指標，可以使用DNN通用模型。
• 節假日算法上線：Prophet節假日算法已經在線上驗證半年，基本可以保證其準確性。
• 覆蓋攜程全部監控平臺：Prophet已經覆蓋了攜程70%~80%的監控平臺。大部分業務指標是在公司的系統監控級別，所以只要能覆蓋公司級別的監控系統，就可以覆蓋大部分重要的業務指標。後續，Prophet也將陸續接入更多業務部門的監控平臺。

閱讀更多 阿里云云棲號 的文章

關鍵字: 可以 HDFS 實時