大型資料/異常檢測的實用DevOps

引言

在異常檢測中，資料的性質是一個關鍵問題。資料可以有不同的型別，例如：二進位制、分類或連續型。在DICE中，我們主要處理連續型資料，儘管也可能存在分類或二進位制值。大多數指標資料都與計算資源消耗、執行時間等相關。也可能存在表示特定作業狀態的分類資料例項，甚至以布林值形式存在的二進位制資料。這使得建立用於執行異常檢測的資料整合為ADT的一個極其重要的方面，因為一些異常檢測方法不適用於分類或二進位制屬性。

需要注意的是，大多數（如果不是全部）異常檢測技術和工具都處理點資料，這意味著不假設資料例項之間存在任何關係。在某些情況下，這個假設是不成立的，因為資料例項之間可能存在空間、時間甚至順序關係。事實上，這就是我們在DICE環境下基於ADT的假設。

所有異常檢測技術將使用的資料都從監控平臺（DMon）查詢。這意味著一些基本的統計運算（如聚合、中位數等）已經可以整合到DMon查詢中。在某些情況下，這可以減少執行異常檢測的資料集大小。

在任何問題域中檢測異常的一個極其重要的方面是定義所提出的方法或工具可以處理的異常型別。在接下來的段落中，我們將簡要定義與DICE環境相關的異常分類。

首先，我們有點異常，這是最簡單的異常型別，由相對於其餘資料可以被認為是異常的資料例項表示。由於這種異常型別易於定義和檢查，因此大部分研究工作將針對發現它們。我們的目的是調查這些型別的異常並將它們包含在DICE ADT中。然而，由於市場上已經存在許多現有的解決方案，因此這並不是ADT的主要重點，而是使用ELK堆疊中的Watcher解決方案來檢測點異常。與DICE相關的一種更有趣的異常型別是所謂的上下文異常。這些異常僅在特定上下文中被認為是異常，否則不會。上下文是資料集結構的結果。因此，它必須作為問題表述的一部分進行指定。

在定義上下文時，我們考慮上下文屬性，這些屬性由每個例項的鄰居表示，以及描述值本身的行為屬性。簡而言之，異常行為是使用指定上下文內行為屬性的值來確定的。

最後一種異常型別稱為集體異常。當一系列相關的資料例項相對於整個資料集而言是異常時，就會出現這些異常。換句話說，單個數據實例本身並不異常。通常，集體異常與序列資料相關，並且只有在資料例項相關時才會出現。

動機

在應用程式的開發階段，效能瓶頸以及意外或未記錄的行為很常見。簡單的監控解決方案不是一個可行的解決方案，因為指標通常需要對底層平臺架構的專業知識。在DevOps環境中尤其如此。DICE異常檢測工具包含監督和無監督方法，能夠標記不需要的應用程式行為。

無監督方法在新開發的應用程式的初始階段很有用。在這種情況下，開發人員很難確定特定的效能配置檔案對於應用程式來說是否正常。另一方面，監督方法可以被開發人員用來檢測應用程式版本之間的上下文異常。與無監督方法相比，這需要一個訓練集，以便它們可以被訓練來檢測不同的異常例項。

現有解決方案

目前正在使用各種各樣的異常檢測方法。根據它們的訓練方式，可以將它們分成兩個不同的類別。首先是監督方法中使用的方法。從本質上講，這些可以被認為是分類問題，其目標是訓練一個能夠輸出關於任何給定資料例項異常性的假設的分類器。這些分類器可以被訓練來區分給定特徵空間中的正常和異常資料例項。這些方法不假設事件資料的生成分佈，它們純粹是資料驅動的。因此，資料的質量極其重要。

對於監督學習方法，應用程式資料例項中的標記異常是先決條件。在某些情況下，誤報頻率很高。這可以透過全面的驗證/測試來緩解。驗證和測試的計算複雜性可能很大，並代表著一個重大挑戰，ADT工具已將此考慮在內。用於監督異常檢測的方法包括但不限於：神經網路、神經樹、ART1、徑向基函式、SVM、關聯規則和基於深度學習的技術。在無監督異常檢測方法中，基本假設是正常資料例項在資料中被分組到一個簇中，而異常不屬於任何簇。這個假設用於大多數基於聚類的方案，例如：DBSCAN、ROCK、SNN FindOut、WaveCluster。K-Means、SOM、期望最大化（EM）演算法所基於的第二個假設是正常資料例項屬於大型且密集的簇，而異常則屬於小型且稀疏的簇。不難看出，每種無監督或基於聚類的方法的有效性很大程度上取決於各個演算法在捕獲正常資料例項結構方面的有效性。

需要注意的是，這些型別的方法並非設計用於異常檢測。異常檢測往往是基於聚類技術的產物。此外，在基於聚類技術的情況下，計算複雜性可能是一個嚴重問題，並且仔細選擇使用的距離度量是一個關鍵因素。

工具的工作原理

ADT由一系列相互連線的元件組成，這些元件由一個簡單的命令列介面控制。此介面僅用於工具的初始版本。未來版本將提供更友好的使用者介面。本節的體系結構圖中顯示了完整的體系結構。總共有8個元件構成ADT。通用體系結構旨在包含在需求交付物期間確定的每個主要功能和需求。

首先，我們有資料聯結器元件，用於連線到DMon。它能夠查詢監控平臺並向其傳送新資料。這些資料可以是檢測到的異常或學習到的模型。對於每種型別的資料，資料聯結器在DMon中建立不同的索引。對於異常，它會建立一個格式為anomaly-UTC的索引，其中UTC代表Unix時間，類似於監控平臺處理指標及其索引的方式。這意味著索引每24小時輪換一次。

查詢監控平臺後，生成的資料集可以是JSON、CSV或RDF/XML。但是，在某些情況下，可能需要額外的格式化。這是由資料格式化元件完成的。它能夠規範化資料、從資料集中過濾不同的特徵甚至對資料進行視窗化。資料集可能需要或不需要的格式化型別高度依賴於所使用的異常檢測方法。特徵選擇元件用於減少資料集的維度。

並非資料集的所有特徵都需要用於訓練用於異常檢測的預測模型。因此，在某些情況下，擁有一個機制來允許僅選擇對異常檢測方法的效能有重大影響的特徵非常重要。目前，僅支援兩種型別的特徵選擇。第一個是主成分分析（來自Weka）和包裝器方法。

ADT架構

接下來的兩個元件用於訓練和驗證用於異常檢測的預測模型。對於訓練，使用者必須首先選擇所需的方法型別。然後將資料集拆分為訓練和驗證子集，然後用於交叉驗證。在此階段可以設定驗證與訓練大小的比率。與每種方法相關的引數也可以在此元件中設定。驗證由一個專門的元件處理，該元件最大程度地降低了模型過擬合的風險，並確保樣本外效能足夠。它透過使用交叉驗證並將當前模型的效能與過去的模型進行比較來做到這一點。

模型驗證完成後，模型匯出元件會將當前模型轉換為可序列化的載入形式。我們儘可能使用 PMML 格式，以確保與儘可能多的機器學習框架相容。這使得 ADT 在生產環境中的使用變得更加容易。目前並非所有模型都支援匯出為這種格式，特別是基於神經網路的模型不相容。生成的模型可以饋送到 DMon 中。事實上，DMon 的核心服務（特別是 Elasticsearch）在 Lambda 架構中扮演著服務層的角色。檢測到的異常和訓練好的模型都儲存在 DMon 中，可以直接從監控平臺查詢。從本質上講，這意味著 DICE 工具鏈中的其他工具只需要知道 DMon 端點，就可以檢視已檢測到的異常。

此外，訓練和驗證場景實際上是批處理層，而無監督方法和/或載入的預測模型是速度層。ADT 可以完成這兩種場景。這種整合是一個開放的挑戰，將在下一節中詳細介紹。

最後一個元件是異常檢測引擎。它負責檢測異常。需要注意的是，它能夠檢測異常，但無法將其傳遞給服務層（即 DMon）。它使用 dmon-connector 元件來完成此操作。異常檢測引擎還能夠處理無監督學習方法。從架構圖中我們可以看到，異常檢測引擎在某種程度上是模型選擇器的子元件，模型選擇器選擇預訓練的預測模型和無監督方法。

開放挑戰

目前，異常檢測工具依賴於最先進的分類和異常檢測技術。然而，隨著該領域的不斷發展，將需要整合新的演算法。工具的內部架構使得這種整合變得容易。此外，還需探索幾種處理極度不平衡資料集的方法。一些未來的改進/挑戰包括：

• 包含 SMOTE 和 ADASYN 等過取樣和欠取樣技術
• 分散式超引數最佳化（例如在 Spark 上執行）
• 貝葉斯超引數最佳化
• 堆疊和裝袋元學習演算法/方法
• 深度學習技術的應用
  • 目前，我們使用帶有 Tensorflow 後端的 Keras 庫來訓練神經網路。但是，還沒有測試過任何深度學習拓撲結構。

應用領域

由於與監控平臺（DMon）緊密整合，異常檢測工具可以應用於其支援的任何平臺和應用程式。對於基於 Storm 的 DIA，異常檢測工具查詢 DMon 獲取所有效能指標。這些指標可以按部署的 Storm 拓撲進行查詢。使用該工具的工作流程如下：

• 查詢資料
  • 聚合不同的資料來源（例如系統指標與 Storm 指標）
  • 過濾資料
• 指定要使用的異常檢測方法
  • 設定訓練或檢測模式（預訓練模型需要由使用者選擇）
  • 對於監督方法，使用者需要提供訓練資料集（包括目標值）
    • 如果未提供目標值，ADT 會將最後一列視為目標。

生成的異常儲存在 DMon 中的單獨索引中。因此，可以像在 DMon 中查詢和視覺化任何其他指標一樣查詢和視覺化異常。如前所述，由於與 DMon 的緊密整合以及 ADT 的指標無關性，將其應用於 DMon 和 DICE 支援的其他工具需要與 Storm 相同的步驟。

還值得一提的是，ADT 根據 DMon 中的結構構建訓練集和測試集。這意味著只要 DMon 對指標具有扁平化的表示，ADT 就可以使用它們。

結論

在 DICE 期間開發的異常檢測工具能夠使用監督和無監督方法。結合 DMon 監控平臺，它形成了一個 Lambda 架構，能夠檢測潛在異常並持續訓練新的預測模型（分類器和聚類器）。由於整合的預處理、訓練和驗證模組，它能夠成功檢測與效能相關的異常。

同樣重要的是要注意，異常檢測工具從本質上說是技術無關的。它不需要事先了解底層技術。它獲得的唯一上下文是訓練/驗證資料集中固有的上下文。這使得新手使用者能夠輕鬆地開發 DIA。