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

一个散步者的梦

于 2024-07-28 22:59:50 发布

阅读量327

点赞数 13

分类专栏： HIVE Spark 文章标签：延时告警离线数仓

本文链接：https://blog.csdn.net/me_to_007/article/details/140753460

版权

HIVE 同时被 2 个专栏收录

8 篇文章 0 订阅

订阅专栏

Spark

7 篇文章 1 订阅

订阅专栏

简介

作业延时告警，通常来说有两种方式：
其一，当作业到目标时间点还没完成触发告警；这类情况，对于目标作业而言，延时已经触发了，风险相对较大；有的是监控接口延时（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；

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