当前位置：首页 > news >正文

数仓作业延时告警-基于关键路径预推

news 文章来源：https://blog.csdn.net/me_to_007/article/details/140753460 2024/9/20 8:03:14

简介

作业延时告警，通常来说有两种方式：
其一，当作业到目标时间点还没完成触发告警；这类情况，对于目标作业而言，延时已经触发了，风险相对较大；有的是监控接口延时（raw层），这里可能会出现接口延时，但是对于下游目标作业并没有延时影响；
其二，当前置作业完成已经晚于最晚时效，目标作业预触发告警；因为是前置预警，所以有一定的时间提前做好风险处理；

这里主要介绍第二种预警的思路，构思源自项目管理中的关键路径；
关键路径相关请访问：百度百科：关键路径）；

前提假定条件：数仓为周期调度作业分配了足够的资源，作业计算pending等待时间极短；

这里澄清下量化的期望：量化的目的是为了减少不确定性，而不是消除不确定；只要减少不确定带来的收益大于投入就是好的；对于不确定的地方也欢迎大家提出意见&优化方案；

量化相关或可阅读：《数据化决策》；作者：道格拉斯·W. 哈伯德（美国）

应用环境：离线数仓，yarn调度+hive亦或sparksql引擎计算

作业示例图

在这里插入图片描述
在数仓中，可能会存在这几类情况：

同一个作业出现在多个依赖路径中，比如上截图的A作业；
作业与作业之间有设置不依赖，这类依赖关系在计算中应做剔除；
不同周期作业依赖，这类情况在特定时间节点做特殊处理；比如日频率作业依赖月频率作业，一般的调度依赖机制，t月周期日频作业依赖t-1月周期任务，即7月日频作业等月频6月周期跑完开始执行；

考虑到数仓作业跑批时长具有一定的波动性，可能存在作业异常，作业跑批时长取近n周期中位数（中位数对异常兼容较好）；邻近相对更能代表当前集群情况，邻近取的周期数不应过多；这里按日频：近7日；月频：近3月；周频：近3周；小时：近24小时；

月频不太好把控，取周期数少可能命中特殊情况不具有代表性，取的周期过多，过早时间集群和作业配置可能会有变更，中位数不能代表最近情况；

数据准备

这里主要依赖如下几块数据：
1.集群作业跑批时长数据，用来估算每个作业跑批时长（这里取中位数，防异常），大概样式如下：

在这里插入图片描述
一般完成时间指的是基于当前集群概况，作业一般能在这个时间完成；

2.调度作业的依赖关系，大概样式如下：
在这里插入图片描述

计算流程

对于集群每一个非根节点（目标）作业结合作业依赖与跑批时长数据写一个递归程序计算上游作业节点最晚完成时效要求；

在这里插入图片描述

比如计算G作业前置作业依赖，G作业一般（这里取中位）在16点跑批完，作业跑批时长在2个小时，
那么G作业最晚需在14:00开始跑批
G作业依赖于E、B、A三个作业，根据E、B、A三个作业的运行时长可得出，E最晚需在13点跑批，B最晚需在13:00跑批，A最晚需在13:00跑批；
B作业依赖于A，所以为保障G作业在16:00完成，A作业最晚需在12:00点开始；
这里作业A处在两条依赖路线，兼容取最长路线（关键路径），在计算体现为在递归计算上游依赖最晚开始时间时，如一个作业重复出现，新计算的开始时间若早于之前的开始时间，则取最早的开始时间；

最后得出，作业G如需16:00完成，前置依赖最晚开始时间要求为：
A：12:00
B：13:00
E：13:00

延时预估取最大延时差，如果A在14:00完成（延时1个小时），E在16:00点完成（延时2个小时），那么目标G作业最终为18:00点完成，延时2个小时；前置依赖延时最大时间；（这里需要拉取已经跑批记录，取最大延时时长）

同理，计算作业D的前置依赖最晚开始时间，作业D跑批2小时，需在12:00完成，那么作业D需在10:00开始，前置依赖A需在9:00开始跑批；

同时满足作业D和作业G的目标时效，作业A在两个作业中都有依赖，则取最早时效，最晚开始时间为9:00；

脚本逻辑对每一个目标时效作业上游依赖时效计算写一个递归逻辑即可，逐层查找计算上游依赖时效要求，直到没有上游结束（查到根节点）；如果链路重复遇到一个作业，最晚开始时间取最早的时间，该重复出现作业不再重复计算上游作业时效要求；

数据输出

数据输出每一个作业以及其前置依赖最晚开始时效要求，如上依赖截图输出为：
在这里插入图片描述

目标时效设置

以上计算先给出的是作业一般完成时效，是基于当前集群概况作业大多数能完成的时间，即当前可行的时效；考虑到跑批时效不稳定，实际设定目标可以稍往后延长些许时间，比如1个小时；

这里可以结合目标作业完成时间波动来看，比如覆盖85%以上作业完成时间，再结合业务情况在这个基础上酌情往后延长时间；比如85%的作业实例在下午16:00点完成，这里可以设置到16:30这样；具体可由业务和技术共同商定；

有的业务时效要求不敏感的，比如一般目标作业下午14:00完成，业务方期望17:00完成就行，那么期望时效也可以适当往后延延，比如到16:00，同时预留时间去排查问题；（优先排查处理那些紧迫的需要）

如果对时效敏感，目标作业时效要求高，则可以优化关键路径上的作业，缩短作业跑批时长，作业优化相关可参考早前写的：sparksql优化以及hive和sparksql优化方向

这里需要注意的是，作业依赖链路中的关键路径并不是一成不变的，可能会随着作业优化时效变短而发生变更；

在设定期望时效后，相应的前置依赖时效根据计算得出时间差相应调整即可；比如期望G作业17:00完成，则前置作业A最晚在13:00开始执行即可；（完成时间跟A作业最晚开始时间相差4个小时）

告警方式

这块可提单平台开发一个接口（一般公司规模起来都会有），邮箱或者短信推送，监控脚本可根据实际需要一小时扫描一次作业运行情况或者其他时间间隔；一旦触发告警，脚本通过该接口将信息推送出来；

简介