首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

一种预测后置应用延迟的方法与实现

各省移动公司经营分析数据处理,程序多,关系复杂,形成了一个非常庞大又相互缠结的集群。大量程序或并发或依赖的运行,在某个环节出现故障延迟时,对后置造成多大范围的影响、多深的影响是未知数。对数据运营工作带来了很大的挑战。本文重点研究并解决数据库生产和运维过程中的问题预测,并给出了解决方案。

引言

现阶段移动经分的数据流大致分为数据接口、数据处理、数据分发、数据应用四个层级,每个层级内有数量庞大的运行程序,按照实际业务需求分成很多小层级,形成后置程序依赖前置程序的关系。而且每个程序的前置程序数量不固定,大于等于一个,就这形成了极其庞大且相互缠结的程序集群。

图一 部分应用关系示意图

如图一所示,程序间的依赖关系非常繁杂。每天凌晨开始,大量数据(大于100T)流经这些程序时,偶尔会有个别程序发生运行延迟。发生延迟程序会对后置造成多大范围的影响、多深的影响是未知数,这就为运维人员的防灾减灾工作带来困难。

现有脚本和手工查证的方式不便,而且因为速度太慢,当查证出后置延迟应用时往往已错过了时效性。因为前后置关系复杂,即使让有丰富经验的工作人员操作此流程,也不能缩短这个时间,也不能达到理想的效果。

目标与成果

本次研究目标包括

一、一种预测后置应用是否延迟的方法,重点解决数据库生产和运维过程中的问题预测问题,实现从“发现问题-找原因-处理问题”,转变为“发现波动-提出预警-启动预案-消灭问题”问题。

1、研究一种结合数据和机器学习方法,进行自动预测的方法,以数据监控和算法预测代替人工,大幅降低数据生产过程中出现的后置应用延时等问题;

2、研究方法实践中所需要的方法论,包括采用的算法分析、模型构建、参数调整和模型调优等。

二、研究一种数据库内生产调度优化的方法,重点解决数据库内前后置应用配置不合理的问题,实现理论和经验调度向数据化、智能化调度的转变。

1、研究一种结合数据和机器学习方法,判定程序启动时间是否合理的判别方法,以历史运行数据为基础,以模型判定为依据,大幅降低由于调度导致后置程序延迟和前后置依赖不合理的问题,解决长期困扰运维人员的数据生产程序的基础配置问题;

2、研究方法实践中所需要的方法论,包括采用的算法分析、模型构建、参数调整和模型调优等。

技术方案

本方法分为三个步骤实现:扫描程序、预测模型、优化模型,如图二所示。

图二 预测后置应用的流程

3.1步骤一:扫描程序,如图二(1)

为了得到当前应用的运行情况和应用的历史信息,参见图二中扫描程序的流程图,具体步骤如下

3.1.1数据采集

从当日应用运行记录中提取应用的运行信息,包含数据接口、数据处理、数据分发、数据应用等层级的全量数据。运行数据经过数据清洗、数据匹配得到应用名、是否重要、是否延迟、是否完成、结束时间、延迟时间、标杆时间等信息。其中每个应用的标杆时间来自最近一段时间段内的统计值,如下图三所示,x轴为最近一段时间内某个应用的历史结束时间间隔记录,y轴为次数。

图三 某个应用的结束时间分布图

如上图所示,应用的历史完成时间符合泊松分布:

泊松分布的期望和方差均为λ,特征函数为

泊松分布的参数λ是单位时间(或单位面积)内随机事件的平均发生率。 泊松分布适合于描述单位时间内随机事件发生的次数。

3.1.2数据处理

对来自不同层级的数据进行处理,得到数据格式一致的数据集。如有些数据接口的应用名得加上前缀,完成状态采用统一的编号格式,结束时间使用同一种格式。

这里采用简单的六西格玛计算。对于每一个前置应用程序,连续60天的完成情况可以构成一个简单时间序列,可以反映一定时间内的数据生产完成情况。那么这个时间序列的均值μ反映该程序的平均完成情况;时间序列的σ反映程序完成情况的波动性。从生产角度来说,为了控制的严格程度,往往需要生产的及时性控制在更小的范围内,因此,我们设定t

3.1.3数据保存

把应用的属性,如:是否重要、是否延迟、是否完成、结束时间、延迟时间、标杆时间等信息,提取出来后放入一个对象中。以应用名为键(key),应用对象为值(value)统一保存。

3.1.4历史数据统计

统计最近三个月内每个应用的平均运行时长和等待时长。运行时长指的是应用从开始执行到结束执行中间所耗费的时间。等待时长指的是应用众多前置中最晚结束的时间到本应用开始执行之间的间隔时长。

3.2步骤二:预测模型,如图二(2)

通过递归计算得到未执行应用的延迟可能性,参见图二中预测模型的流程图,具体步骤如下

3.2.1设置延迟阀值

设置初始延迟的阀值和范围,这里圈定数据接口、数据处理、数据分发、数据应用四个层级中的重要应用,阀值为延迟30分钟以上。如果此应用还没执行完成,则把当前时间代指应用的结束时间,在此基础上累加后置时间。以结束时间作为标记时间,即本分支推算到当前应用的标记。

3.2.2得到关系树

在血缘关系表(如下图四)中记录着应用的前后置关系,每条信息是一对一关系,但总体上是多对多关系,也就是说一个前置会对应多个后置,一个后置会有多个前置应用。逐个拿到2.1中判定的延迟应用名,在关系表中取得它的后置应用名。

图四 血缘关系表示例

3.2.3验证应用有效

验证后置应用是否有效,最近三个月是否有运行记录,如果没有的话则忽略此应用。

3.2.4查看是否已执行

查看后置应用当日是否已经执行过,如果已经执行过则更新标记时间,即本分支推算到当前应用的标记。直接把后置应用的结束时间覆盖标记时间。如果还未执行则跳至2.6

3.2.5查看是否已预测

查看后置应用是否已经预测过,因为一个前置有多个后置应用,意味着现在这个后置可能会出现在别的应用的后置中,所以有必要查看此后置应用是否已被预测。如果已经被预测过,则比较预测结束时候是否早于标记时间加上等待时长和运行时长,取更大的那个时间覆盖预测结束时间。这是因为应用得等待每个前置完成后才能开始执行。如果没有预测过,则跳至2.6

3.2.6预测应用

进入此环节的便是待预测的应用,累加标记时间、应用等待时长、运行时长,减去标杆时间得到预计延时长,如果为负数或0表示不会延迟。使用预计延时长通过线性拟合算法得到此后置的预计延时几率。但无法保证此后置应用没有再下一层的后置,所以需要从2.2开始使用递归算法,把此后置应用作为前置,运算它的下一层,即后置的后置。如果没有下一层则自动终止。

3.3步骤三:优化模型,如图二(3)

验证预测出的延时几率的可信度,参见图二中优化模型的流程图,具体步骤如下:

3.3.1关联预测

对比每个预测出来的结果和对应的前置的关联关系,即在历史记录中查看当前置们发生延迟时后置是否也会发生延迟,得到如下的关系表,其中1表示延迟,0表示未延迟

逻辑性的思维是指根据逻辑规则进行推理的过程;它先将信息化成概念,并用符号表示,然后,根据符号运算按串行模式进行逻辑推理;这一过程可以写成串行的指令,让计算机执行。然而,直观性的思维是将分布式存储的信息综合起来,结果是忽然间产生的想法或解决问题的办法。这种思维方式的根本之点在于以下两点:1.信息是通过神经元上的兴奋模式分布储在网络上;2.信息处理是通过神经元之间同时相互作用的动态过程来完成的。

结合BP网络结构,误差由输出展开至输入的过程如下:

输出层

误差展开至隐藏层

展开至输入层

本模型在输入层使用的节点数和前置数相同,设置两个隐藏层,输出层直接输出0和1用来代指后置应用是否会延迟。如下图五所示。

图五 BP神经网络节点

3.3.2更新延时几率

把关联预测加权成数值累加到应用的延时几率,得到此应用的总的延时几率,亦即

总的延时几率=p1*x1 + p2*x2 + p3*x3 + ... + pn*xn = ∑(pi*xi)

3.3.3保存结果

保存预测出的应用名和延时几率

3.3.4使用结果

延时几率大于50%的应用自动发送给运维管理人员,对这些应用进行重点观测或看情况进行重新调度。如果该延迟应用超过一定时间仍未完成则自动重新调度。

结论

本文提出预测后置应用延迟的方法,解决了当前、后置关系呈金字塔状的情况下的自动预测,现有的预测模型更多解决的是链式关系下的逐层排查问题。在算法方面,使用的是自行设计的基于业务的推演算法,顺着关系树逐个节点计算出预计完成时间,递归至整个关系树,得到每个未完成节点的总的延时概率。在应用成效上,预测结果的准确率经过验证达到94%以上。

本文供稿于

“上海移动潘钢,宋冰”

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181229G18PIL00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券