必贝yo告诉你如何构建实时智能异常检测平台？
1．前言
随着互联网的迅速发展，各个公司都建立了自己的监控体系，用于提前发现问题降低损失，携程亦是如此。然而携程的监控体系存在以下三个问题：
§ 监控系统繁多
§ 监控告警配置复杂
§ 没有统一规范
首先携程目前光公司级别的监控系统就有三套，各个 BU 为了满足自己的业务监控需求也陆续开发了许多自己的监控系统。其次这些监控系统都是基于规则来判断是否存在异常，比如当满足同环比连续几个点上升或下降到用户配置的阈值时触发告警。最后是没有统一的规范，这里指的是两个规范，第一，没有统一的规则告警配置规范，不同的监控系统都带有不同的规则告警配置方式；第二，没有统一的异常判断规范，研发人员或 QA 人员都是根据自己对业务的理解，通过主观判断指标达到一定阀值时监控系统需要进行告警。
基于以上的三点问题给用户带来了诸多不便，首先是规则告警维护成本高，用户时常需要基于多个监控系统以不同的方式配置规则告警，而且还需要根据告警的情况持续调整阈值，导致一个规则告警从配置到最终能够产生较好的效果需要一个很长的周期。其次，基于规则告警往往表现不尽如人意，会导致准确率低、覆盖率低和时效性低的三低状况。用户很多情况下为了提高异常的覆盖率降低漏报的情况，不得不将规则告警的阀值设置的非常敏感，虽然这样能够覆盖更多的异常场景，却导致了大量的误报，规则告警的准确性也就大大折扣。
为了应对上述的诸多问题，携程打造了自己的实时智能异常检测平台 Prophet。简单概括，Prophet 是一个基于时序类型数据、以平台为接入对象、去规则化为目标的异常检测系统，基于深度学习算法实现异常的智能检测，基于实时计算引擎实现异常的实时检测，提供了统一的异常检测解决方案。接下来的文章会详细介绍我们是如何依次实现了异常的智能化、实时化检测以及平台的构建。
2． 智能化
2.1 深度学习算法选择
目前业界采用比较多的方式是引入统计分析的各种方法，框定一个滑动的样本集，对这个样本集进行一些数据处理和转化，经过归一化，去周期，去趋势，再将最新采集到的数据点经过同样的转换，和样本集的残差序列的统计量进行比较，比如距离、方差、移动平均、分位数等，超出一定的范围就判断为异常，或是综合各种离群点计算的方法来做个投票，多数算法认为异常则报异常。起初我们也借鉴了这种做法，却发现虽然可以不用维护告警规则了，但报警的质量并没有提升。
我们需要设计一套新的算法，降低报警总量到可以人工逐个处理的程度，同时不能以增加漏报真正的生产订单故障为代价，并且这套算法的设计还不能太复杂，影响到告警的实时性，最好还能做到算法即服务，有较强的可移植性，提供给其他的监控系统使用。自然而然的，基于神经网络的深度学习算法成为我们进一步探索的工具。
RNN 算法比较适合处理序列变化的数据，符合我们时序特征的场景，但是存在梯度消失和过拟合的现象。而他的改进版 LSTM 算法，能够通过控制传输状态来选择性地记住较重要的长期数据，能在更长的序列上有良好的表现，业界也有很多成功的应用。LSTM 算法的异常检测方式是基于指标的历史数据训练出模型并基于现有数据预测指标未来的走势，基于预测数据与现实数据各种偏差来判断指标是否有异常。这样好处在于每个指标都会训练一个自己的模型，能够达到很高的精度，但是也带来了一定的弊端，需要消耗较多的训练与检测资源。
DNN 算法的检测方式与 LSTM 的方式不同，我们基于小波变换算法提取监控指标不同频域的特征喂给 DNN 模型，直接输出是否存在异常。这种的好处在于一个 DNN 模型就能够满足所有异常检测场景的需求，但是相对的特征工程也要复杂很多，我们需要大量的人工标记数据来提高模型的精度。
最后无论是基于 LSTM 算法还是 DNN 算法实现的异常检测需要根据各自所需的不同场景来决定使用哪个。在携程，对于最重要的订单、支付类指标，我们都是采取 LSTM 算法，单个指标训练单个模型，对于其他一些非重要的指标可以使用 DNN 算法。
2.2 模型训练
选定好深度学习算法之后，我们也就开始尝试模型的训练。我们首先取得监控指标的历史数据对其进行清洗，其中需要对一些空值进行插补，节假日数据对于数据模型的影响很大，导致训练出来的数据有偏差，我们也选择性的剔除节假日期间的数据；如果历史数据中的某个区间数据是异常区间，我们也需要使用预测值替换异常区间的数值。
做完数据清洗之后，也就需要实现特征工程。我们使用了多尺度滑动窗口时序特征的方法，将一个滑动窗口内的数据和前 n 个周期做统计量上的对比，均值、方差、变化率等这些，这样基本上就可以把明显的周期性和平稳型数据给分离出来。剩下的时序中，有些是波动很大的随机序列，有的则是带有趋势的周期性序列，通过时序分析法把周期性去掉，再用频域分析尝试分解成频谱。对于带有明显频谱的，则归类为周期型时序，而频谱杂乱的，则归类为非周期性。
在做完特征提取与指标分类之后，我们也就根据指标的类型使用不同的算法进行模型训练。我们根据线上的人工标注数据持续性的优化我们的模型。我们经历过初期不停的调参和验证之后，我们将模型训练的频率设为了两周，我们每两周重新走下图中的整个流程，这个也是根据我们业务变更的频率所做的考虑。
3必贝yo云数据（www.bbeyo.com），作为国内基于大数据方面的数据积累、数据分析和标签归类人工智能AI技术驱动的大数据交易平台，支持海量数据的分布式采集、计算及处理，从而以机器学习推动数据交易发展，让数据价值最大化。互联网开放数据、企业内部数据接入，清洗、过滤、脱敏处理后再交易，以数据和算法规则等形态沉淀在数据交易平台，满足企业对数据分析、数据运营及精准营销等方面的需求。互联网开放数据、企业内部数据接入，清洗、过滤、脱敏处理后再交易，以数据和算法规则等形态沉垫，实现企业和政府的数字化转型。联系电话：0351-6106588，0351-6106599，公司邮箱[email protected]，
公司地址：太原市小店区东中环南段259号亲海国际1幢A座24层2422号，山西奇畅飞科技有限公司
4. Prophet
4.1 Prophet 系统架构
在讲述完如何实现智能化与实时化异常检测之后，相信大家对于 Prophet 已经有了一定的认知。下图展示了整个 Prophet 平台的系统架构，首先是最底层的 Hadoop 集群承担了分布式存储与资源调度的功能，HDFS 用来存储 Tensorflow 训练好的模型，所有 Flink 作业运行在 Yarn 集群上。中间层的消息队列承担了实时数据源的作用，所有指标的历史数据存储在时序数据库中，实时化与智能化检测依托于 Flink 与 Tensorflow 两套引擎实现。最上层的 Prophet 以平台的方式对外提供服务，Clog 用于日志存储与排障，Muise 是我们的实时计算平台，Qconfig 用于存储于监控指标相关的配置信息，最后 Hickwall 用于监控作业的各项指标。