大型数据/异常检测的实用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。