携程实时智能检测平台建设实践

  • 时间:
  • 浏览:1
  • 来源:uu快3规律_uu快3下载地址_窍门

Prophet基本覆盖了携程所有业务线。即携程的重要业务指标基本都将会在使用监控智能告警。业务类型富含7种。监控指标的数量达到10K+,覆盖了携程所有订单、支付等重要的业务指标,覆盖了大每种服务的重要的业务指标。接入平台在10+左右,基本接入了携程公司所有系统级别的监控平台,在陆续接入各个业务部门自己的监控平台。Prophet平台不能覆盖95%左右的异常,准确报警率达到75%。将会每个数据同步到Prophet便触发数据实时消费、预测以及告警,告警延迟达到ms级别。告警数量也下降了十倍左右。

针对规则告警所处的以上几种什么的问题,携程构建了自己的实时智能异常检测平台——Prophet。携程构建Prophet的灵感源于FaceBook的Prophet,但实现上有别于FaceBook的Prophet。

在做智能检测以后还会遇到或多或少挑战。

模型训练完成后,Flink作业不能 动态加载模型。但实际场景下,不将会每训练另另有另好几条 模型便重启一次Flink作业。就是我Prophet平台将模型训练完成后上传到HDFS,通知配置中心,就是我我Flink作业开使从HDFS上拉取模型。为了使每个模型均匀分布在不同的Task Manager上方,所有监控指标会根据五种id做keyBy,均匀分布在不同的Task Manager上。每个Task Manager只加载自己每种的模型,以此降低资源消耗。

Prophet在接受到新的监控指标后,便开使尝试使用Tensorflow训练模型。模型训练不能 历史数据,平台都不能 按照约定好的规范提供历史数据查询接口,Prophet通过接口获取历史数据并进行模型训练、将会必须 接口,Prophet基于消息队列中的数据来积累训练数据集。模型训练完成后,将其上传到HDFS,Prophet会更新配置中心中的配置通知Flink有新训练好的模型都不能 加载。所有实时推送到Kafka上方的监控指标的数值,会同步的落到Prophet的时序数据库中,在异常检测的过程中不能 用到那些指标数值。当模型训练完成后,Flink的作业一旦监听到配置所处了更新,就开使尝试加载新模型,实时消费Kafka上方的指标数据,最终产出检测结果以及异常告警会回写至Kafka,各个监控平台会从Kafka获取自己监控平台的那一每种告警数据。整套Prophet操作流程对于用户是无感知的,用户只不能 配置告警,极大的提供了便捷性。

将会携程做旅游方向的业务,节假日期间什么的问题较为突出。不类似型的业务在节假日的表现是不同的。类似携程的机票、火车票基本是在节前上升到多量,到假期期间将会大伙出游,该买的票将会购买完成,机票等业务订单量会下降就是我。而酒店等业务在节假期间会上升就是我。不类似型业务的趋势不同,上升幅度较大的业务容易产生漏报,对于下跌幅度较大的业务,容易产生误报。

大每种监控平台是基于规则告警实现监控指标的预警。规则告警一般基于统计学,如某个指标同比、环比连续上升或下降到一定阈值进行告警。规则告警不能 用户较为熟悉业务指标的价值形式,从而不能较为准确的配置告警阈值,以后带来的什么的问题是配置规则告警非常繁琐、告警效果也比较差,不能 多量人力物力来维护规则告警。当另另有另好几条 告警产生时,就是我需要 耗费大伙力验证告警有无正确并确认有无不能 重新调整阈值。在携程,规则告警还涉及了其它什么的问题,比如携程光公司级别的监控平台都在另另有另好几条 ,每个业务部门还会根据自己的业务需求或业务场景构建自己的监控平台。携程内部有十几条不同规模的监控平台,在每另另有另好几条 监控平台都配置监控指标对于用户是非常繁琐的。

实际场景下往往会经常出现意想必须的状况。类似上述10分钟的场景中只获得了9条数据,缺少第另另有另好几条 时刻的数据, Prophet会使用均值标准差补齐此类缺失数据。另外将会在上另另有另好几条 时刻检测到第6、7、8、9、10时间区间是异常区间,所处了下跌将会上升。必须 此区间的数据被认为是不正常的,必须作为模型输入。此时不能 用上一批次模型预测出的第6时刻的值替换原始的第六个时间粒度的值。第2、3、4、5、6这六个时刻值中第4是插补而来的,第6是时间区间训练出来的预测预测值替换掉了异常值。以插补替换以后的值作为模型输入,得到新的预测值7。再依次进行预测。上方过程中异常区间第6、7、8、9、10时刻的预测值不能 作为另另有另好几条 状况来存储到Flink StateBackend,后续窗口会使用到那些预测值。

模型加载完成后不能 做实时异常检测。首先从Kafka消息队列中消费实时数据。Prophet目前基于Flink Event Time+滑动窗口。监控指标的时间粒度都不能 分为就是我种,如1分钟另另有另好几条 点、5分钟另另有另好几条 点、10分钟另另有另好几条 点等等。类似基于1分钟另另有另好几条 点的场景来看,在Flink作业中开另另有另好几条 窗口,其长度是六个时间粒度,即十分钟。当积累到十条数据时,用前六个数据预测下另另有另好几条 数据,即通过第1、2、3、4、5六个时刻的数据去预测第六个时刻的数据,就是我我用第2、3、4、5、6时刻的数据预测第七个时刻的数据。最终获得第6、7、8、9、10六个时刻的预测值和实际值。再利用预测值与实际值进行对比。以上是数据无异常的理想场景下的状况。

本次分享主要围绕以下六个方面:

摘要:本次演讲将为大伙介绍携程实时智能异常检测平台——Prophet。到目前为止,Prophet基本覆盖了携程所有业务线,监控指标的数量达到10K+,覆盖了携程所有订单、支付等重要的业务指标。Prophet将时间序列的数据作为数据输入,以监控平台作为接入对象,以智能告警实现异常的告警功能,并基于Flink实时计算引擎来实现异常的实时预警,提供一站式异常检测补救方案。

针对上述什么的问题,Prophet正陆续进行改进,希望通过下面几种最好的土办法补救遇到的挑战。

节假日应对手段:不同的场景会原困不同的什么的问题,就是我Prophet针对节假日场景做了或多或少特殊补救。首先,维护每年节假日信息表,应用系统进程一旦发现下另另有另好几条 节假日还有另另有另好几条 星期时,Prophet就会提取出过去两年内的不同节假日期间的数据。就是我我计算前两年的不同节假日和当前节假日数值的类似度来匹配。大慨以当前节假日的数据拟合过去节假日的数据,拟合到某个时间段时,就知道大慨从某个时间开使到某个时间开使是和当前趋势类似的。然还会用过去多个节假日的数据作为另另有另好几条 组公司媒体合作 为新模型的数据输入去训练数据集。不同节假日的占比不同,通过或多或少最好的土办法计算出不同占比值。最终相基于组合的数据集训练出新的模型,新的模型都不能 比较好地预测出某另另有另好几条 指标将会某另另有另好几条 业务在节假期七天之内的趋势。

演讲嘉宾简介:潘国庆,携程大数据研发经理。

实时异常检测主要都不能 从以下几条方面进行判断:

携程一般两周发一次版本,每个业务指标都在每两周尝试训练一次,模型输入的训练数据也取两周的数据集。在使用历史数据以后不能 做数据预补救,比如历史数据中将会所处null值,不能 使用均值标准差将其补齐。其次历史数据区间上方肯定会有或多或少异常区间,不能 用或多或少预测值替换异常区间的异常值。另外将会节假日期间数据较为复杂,不能 替换节假日期间的异常值。对历史数据的数据集做数据预补救以后,开使提取其不共同序的价值形式将会频率的价值形式。就是我我通过另另有另好几条 分类模型分类出指标是平稳的、非周期的还是周期型的。不类似型的指标不能 不同的模型进行训练。

目前主流的实时计算引擎有Flink、Storm和SparkStreaming等多种,携程选折 Flink作为Prophet平台的实时计算引擎的原困主就是我我Flink具备以下四点价值形式:

首先,Prophet以时间序列类型的数据作为数据输入。其次,Prophet以监控平台作为接入对象,以去规则化为目标。基于厚度学习算法实现异常的智能检测,基于实时计算引擎实现异常的实时检测,提供了统一的异常检测补救方案。

以下内容根据演讲视频以及PPT收集而成。

https://developer.aliyun.com/live/1790

用户只不能 在自己常用的监控平台上选折 配置智能告警,后续所有流程都在由监控平台和Prophet智能告警平台对接完成。监控平台所不能 做的富含两件事,首先将用户配置的监控指标同步到Prophet平台, 其次监控平台需将用户配置的监控指标数据实时的推送到Kafka消息队列中。

针对以上三点什么的问题,携程尝试了RNN,LSTM和DNN等多种厚度学习算法。