将实时计算和深度学习相结合，可解决某种特定的业务场景。本次将分享基于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作业会有一些性能的指标，未来打算用智能告警做一个自我监测的平台，自我预警，从而带来更好的效果。

告警数下降10倍，携程实时智能检测平台实践相关推荐

监控指标10K+！携程实时智能检测平台实践
摘要:本文将介绍携程实时智能异常检测平台--Prophet.到目前为止,Prophet 基本覆盖了携程所有业务线,监控指标的数量达到 10K+,覆盖了携程所有订单.支付等重要的业务指标.Prophet ...
携程实时用户数据采集与分析系统
本文由携程技术中心投递,ID:ctriptech.作者:王小波,携程技术中心框架研发部高级工程师,主要负责用户行为数据采集系统及相关数据产品研发设计工作. 一.携程实时用户数据采集系统设计实践随着移 ...
携程实时计算平台架构与实践丨DataPipeline
文 | 潘国庆携程大数据平台实时计算平台负责人本文主要从携程大数据平台概况.架构设计及实现.在实现当中踩坑及填坑的过程.实时计算领域详细的应用场景,以及未来规划五个方面阐述携程实时计算平台架构与实 ...
查询时长下降10倍！网易有数 BI 物化视图设计要点与内部实践
原文:查询时长下降10倍!网易有数 BI 物化视图设计要点与内部实践|数据库|sql|网易_新浪新闻导读众所周知,BI 工具因其灵活的使用方式和便捷的结果展示,已成为生产运营和辅助管理决策的重要工具 ...
张向宁：窄告将让中国营销成本下降10倍
2005年4月8日,"第二届中国搜索力经济高峰论坛"在厦门国际会展中心举行.中国网络分众广告第一人.窄告运营方天下互联公司总裁张向宁再出惊人之语:"窄告将让中国营销成本至 ...
携程Hadoop跨机房架构实践
陈昱康,携程架构师,对分布式计算和存储.调度.查询引擎.在线离线混部.高并发等方面有浓厚兴趣. 本文将分享携程Hadoop跨机房架构实践,包含Hadoop在携程的发展情况,整个跨机房项目的背景,我们跨 ...
订单失效怎么做的_此招一出，数据库压力降低90%，携程机票订单缓存系统实践...
本文转自 | 携程技术作者简介 Chaplin,携程资深PMO,平时喜欢解决系统相关的问题,包括但不限于分布式/大数据量/性能/体验等,不畏复杂但更喜欢简单.本文旨在分享携程机票后服务订单处理团队, ...
订单失效怎么做的_数据库压力降低90%，携程机票订单缓存系统实践
本文旨在分享携程机票后服务订单处理团队,在构建机票订单缓存系统过程中的一些思考总结,希望能给大家一些启发或帮助.通篇分为以下七大部分:背景,瓶颈,选型,架构,方案,优化,总结,文章概要如下图: 一.背 ...
携程运维自动化平台，上万服务器变更也可以很轻松
讲师简介胡俊雅:携程资深技术支持工程师个人简介:携程技术保障中心资深技术支持工程师,负责公司 SaltStack.StackStorm 等运维平台管理,运维自动化工具开发. 给大家分享的主题是基于 ...

告警数下降10倍，携程实时智能检测平台实践