做品牌网站怎么样,织梦和wordpress哪个安全,wordpress文章发布添加项目,优化设计四年级上册语文答案简介
作业延时告警#xff0c;通常来说有两种方式#xff1a; 其一#xff0c;当作业到目标时间点还没完成触发告警#xff1b;这类情况#xff0c;对于目标作业而言#xff0c;延时已经触发了#xff0c;风险相对较大#xff1b;有的是监控接口延时#xff08;raw层…简介
作业延时告警通常来说有两种方式 其一当作业到目标时间点还没完成触发告警这类情况对于目标作业而言延时已经触发了风险相对较大有的是监控接口延时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完成前置依赖最晚开始时间要求为 A12:00 B13:00 E13: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个小时
告警方式
这块可提单平台开发一个接口一般公司规模起来都会有邮箱或者短信推送监控脚本可根据实际需要一小时扫描一次作业运行情况或者其他时间间隔一旦触发告警脚本通过该接口将信息推送出来
