將實時計算和深度學習相結合，可解決某種特定的業務場景。本次將分享基於tensorflow和flink構建攜程的實時智能檢測平臺。
今天分享的主要內容分爲四個部分：
-
Background
-
What is Prophet
-
AI and Real Time
-
Challenges and Future
一、背景介紹
每個公司都會有監控平臺，大部分的監控平臺都是根據規則告警做監控指標的預警，規則告警一般都是根據統計學的方式，例如，某個指標的同比、環比的上升或下降，這就需要設置閾值或者一個衡量的百分比。因此，會出現很多問題：
-
規則告警會出現複雜的配置
-
規則告警的效果比較差
-
規則維護成本比較高
除了以上問題，攜程還有一些其他的問題，公司級別的監控系統有三個，根據不同的業務場景會構建相應的監控平臺，在公司內部大大小小的監控平臺會有十多個，在每個監控平臺構建配置對用戶而言是非常繁瑣的，根據以上的問題，攜程構建了實時平臺Prophet。
二、什麼是Prophet？
Prophet是一站式異常檢測解決方案，主要的靈感來源是來自Facebook的Prophet，但是所做的內容是有很多區別的。
1、Prophet一站式異常檢測解決方案包括
-
基於時序類型的數據
-
以監控平臺爲接入對象，不是以用戶爲目標，將規則告警全部下線，應用智能告警代替
-
採用深度學習的算法來實現異常的智能告警
-
基於實時計算的引擎實現異常的實時預警
2、Prophet的系統架構
-
底層爲Hadoop底層。YARN作爲資源調度引擎，主要運行Flink作業任務，HDFS主要是存儲Tensorflow訓練的模型。
-
中間層是引擎層。數據要實時必須要存儲在消息隊列當中，使用的是kafka，想要實現實時的異常預警使用的是flink的計算引擎，深度學習的訓練引擎使用的是tensorflow，還會基於時間序列的數據庫存儲數據。
-
上層是對外提供服務的平臺層。Clog的作用是採集作業日誌，Muise是實時計算平臺，Qconfig是提供作業中需要的配置項，Hickwall簡單的監控告警平臺。
3、Flink
當前有很多實時計算引擎，選擇Flink作爲計算引擎有以下原因：
-
高效的狀態管理，在異常檢測中需要很多的狀態信息需要存儲，Flink自帶的state backends能夠很好的存儲中間狀態
-
提供豐富的窗口，比如滾動窗口、滑動窗口以及其他窗口，攜程使用的是滑動窗口，後續會進一步講解
-
支持多種時間語義，一般使用的是Event Time
-
不同級別的容錯語義。
4、Prophet的操作流程
對於用戶而言需要做什麼事情？對於用戶而言是無感知的，並不需要在攜程監控平臺配置監控指標，用戶只需要在常用的監控的平臺配置監控告警，選擇智能告警就可以。後續的所有工作都是智能監控平臺與智能告警平臺進行交互。
用戶配置監控平臺的指標，監控平臺會把用戶的配置指標同步到Prophet平臺，接收到新的指標就會進行模型訓練，使用tensorflow訓練模型，實時數據導入到kafka中，對於歷史數據，如果用戶能夠提供接口就會使用，沒有就會使用消息隊列中積累的數據集進行訓練，訓練完成就會上傳至HDFS，更新配置，在配置中心會傳到Flink，需要對應的加載模型，推送的實時數據會保存到時序數據庫中，因爲在後面的異常檢測中會需要用到。
中間是模型訓練的過程，當模型訓練完成，Flink的作業監聽到配置發生更新，嘗試加載新的模型，實時的消費kafka中的數據，最終產生一個預測結果，異常的告警結果都會寫回到Kafka，各個監控平臺都會消費消息，獲取各自監控平臺的告警消息。整個過程對用戶都無感知的。
三、智能化與實時化
1、智能化挑戰
-
負樣本少，異常發生頻率低
-
業務指標類型多，訂單、支付等
-
業務指標形態多，週期波動、穩定、非週期
針對以上問題嘗試使用了很多種深度學習的算法，如下：
RNN和LSTM需要給每個指標訓練一個模型，基於這個模型預測當前數據集的走向，拿預測數據集和當前的數據集進行比對，進行異常檢測。每個指標都需要訓練一個模型，需要消耗比較大的資源，好處就是準確率比較高。
DNN模型，一個模型可以搞定所有業務場景，問題是特徵的提取會比較複雜，需要提取特徵不同頻率的指標，對於這個特徵需要用戶對大量數據進行標註，判定那種情況歸屬爲異常，這種情況比較複雜。
2、模型訓練的流程
攜程的業務基本兩個星期更新一個版本，每個業務指標每兩週都會嘗試訓練一次，模型的訓練數據也是兩週一次。
數據預處理。比如空值或null值，在數據中會有很多的異常區間，因此需要根據之前的預測值把這些異常區間的異常值進行替換；還有需要把節假日的數據進行替換，節假日的情況會比較複雜，會有相對用的應對方式，這個模型主要是平日的數據的訓練週期。
提取特徵。提取不同時序的特徵，或者是頻率特徵，然後訓練一個分類模型，判斷這個特徵是一個什麼類型的指標，比如說週期或者非週期，針對不同的指標會使用不同的模型。
3、模型的動態加載
模型訓練完成上傳，通知到配置中心，Flink作業收到信息，會從HDFS中拉取模型，爲了將每一個模型均勻的分佈在每個Task Manager中，所有的監控指標會根據id均勻的分佈在Task Manager。
4、數據實時消費與預測
要做一個實時的異常檢測，從kafka消息隊列中消費一個當前的實時數據，Flink Event Time+滑動窗口，監控的時間粒度很多種，例如選取分鐘的力度，選取十分鐘，Flink作業中會開一個窗口，長度爲10個時間點，當數據積累到十分鐘就可以進行數據的實時預測，會使用前面的五個數據來預測下一個數據，採用平滑的方式依次向後移動，從而獲得五個實際值和預測值的對比。
然而在實際情況下並非這樣簡單。現實情況下會出現很多的數據缺失，這些數據有可能再也不能消費，比如說由於網絡抖動的原因再也找回這些數據。需要對這些確實的數據進行插補，使用均值或者標準差替換缺失數據。如果在一個區間內的數據是異常值，需要使用上一批次訓練出來的預測值，將異常數據進行替換，作爲模型的輸入，得到一個新的預測值。
5、實時異常檢測
① 基於異常類型與敏感度判斷。不同指標會有不同的異常類型，有的是下降的異常，有的是上升的異常。其次會有一個敏感度，分爲中高低，對於高敏感度異常，發生簡單抖動就會認爲會有一個異常，對於中敏感度連續出現這樣的抖動纔會認爲是異常。
② 基於預測集與實際集的偏差判斷。判斷爲某個區間爲異常區間，需要同上週期的同一時間做對比，如果偏差較大，則認爲這是一個異常區間。
③ 基於歷史同期數據均值與標準差判斷。潛在異常還需與歷史週期數據比較來最終確認是否存在異常。
上面所說的技術都能夠應用於這樣的場景：
常見問題：對於用戶來說，監控指標太多，監控的維度也比較多。比如一個指標可能有 max、min 等不同的統計方式，監控指標的數量就會比較多。其次，用戶能力有限，很難每日查看監控告警。
異常原因：發生異常的原因一般會是技術性問題。如發佈新版本上線時可能存在的 bug 導致業務出現下跌。少數的情況是由於外部因素的影響，比如調用外部鏈接或者服務，外部服務宕掉導致自己的服務出現問題。
解決方案：用戶爲 Prophet 提供的檢測結果進行標註，選擇檢測結果的正確性。用戶的標註數據會用到 Prophet 以後的模型訓練中用於優化數據集。
6、節假日場景
節假日場景的問題如下：
① 不同業務間上漲或下跌的趨勢不同。比如攜程的機票或者火車票基本在節前會上升到一定量，到節假期的期間會逐漸下降；對於酒店，節假期間會上升很多。因此不同業務的趨勢是不一樣的。
② 上漲幅度大，容易產生漏報。針對圖中上升較大的部分可能會產生漏報，例如上週最高的訂單量爲1000單，但是本週作爲節假日最高訂單量爲2000單，下降50%也會和上週持平，這樣模型可能會檢測不到。
③ 下跌幅度大，容易產生誤報。上週爲1000單，這周跌到500單，這是個正常值，但是繼續下跌就會產生誤報。
④ 小業務活動多，波動劇烈。
針對節假日場景出現的問題，攜程也做了很多的應對準備。維護每年的節假日信息表。程序會自動判斷距離下個節假日還有一週的時候，自動提取某個指標過去兩年內的不同節假日的數據，然後統計跟當前時段的數值的相似度，使用當前數據擬合過去的數據。基於當前和歷史的數據訓練一個新的模型。
當前基本覆蓋了攜程的所有的業務線。覆蓋了大部分重要的業務指標，把公司級別的系統監控平臺都已經接入，可以覆蓋95%的異常，報警的準備率達到75%。每個數據過來都會觸發數據的實時消費和預測，告警的延遲是毫秒級別的，告警的數量較以前下降十倍左右。
上面的效果對比基於2019年4月-5月的數據。左邊的Prophet的命中達到90%，規則告警只達到74%。
上圖是告警數量的對比。Prophet的告警數量比規則降低了5倍到10倍左右。
四、挑戰與展望
1、遭遇挑戰
-
資源消耗大，單指標單模型，模型數量等同於指標數量
-
節假日影響大，業務指標節假日趨勢不同告警準確性受影響
-
無法適用於全部場景，波動劇烈的非週期性指標hold不住，比如遇到大促、活動等。
對於上面的遇到的挑戰，我們陸陸續續進行了改進。
2、未來展望
① 在通用模型中，並沒用着重分析DNN模型的應用，前面的所有流程和處理的邏輯都是針對LSTM。DNN模型可以一個模型通用於各個監控指標的，準確率相對LSTM要低，但是是能夠涵蓋一個比較多的場景。對於重要的指標，比如訂單、支付等重要的業務指標，使用LSTM，對於其它而言可以使用DNN模型。
② 節假日算法上線，採用節假日對齊方式依據上個節假日的數據加權作爲訓練數據，當前節假日算法已經運行半年多。
③ 覆蓋全部監控平臺，接入更多的監控平臺與指標當前已經覆蓋了70%-80%的監控平臺。
④ Flink作業會有一些性能的指標，未來打算用智能告警做一個自我監測的平臺，自我預警，從而帶來更好的效果。