乐趣区

关于大数据:基于done文件的数据监控理论

1 问题

除了像 Alibaba 的 Dataworks 外,很难有另外的公司可能把数据调度,数据监控,数据血统,元数据管理等作为一体化的平台了,包含我司在内的一些厂,往往把这些建设独立开来,由不同的团队负责,其中数据平台调度性能是绝大多数公司都有的根底平台,然而调度的性能水平就各不同了,上面的问题当作抛砖引玉,指出在生产环境中常遇到的问题,如果后续有 产出,前面尽量开源一些代码进去,贴到本博客最初面。

监控从大的层面来说有两种,一种是监控用来拦挡的,即有依赖的 一种只是用来报警和剖析的

因为依赖接入源较多,以下问题常有产生:

1.1 数据延时产出,数据产出空分区,数据品质可能有问题(条数,工夫戳不对)

个别处理过程:破费工夫 30m+ 解决 - 延时问题→ 去易创上找依赖图,确认是哪个上游产出表没有产出 -> 复制表名 -> 去数据地图外面找负责人 -> 个别会拉群跟进 –> 等解决完 –> 同步或者不同步 / 关注方→同步产出好了

1.2 应用方有意识应用到谬误数据,破费工夫 60m + 解决 - 空分区问题

处理过程:须要对最终的产出标签的散布等进行品质监控,临时没有 -> 如果发现当前 -> 复制表名 -> 去数据地图外面找负责人 -> 个别会拉群跟进 –> 等解决完 –> 同步或者不同步 / 关注方→回溯数据 -> 告诉应用方数据问题

1.3 应用方先意识应用到谬误数据

破费工夫 60m + 数据品质问题 (条数,工夫戳)→ 个别只有等标签应用方发现能力意识到 -> 问题复现 -> 复制表名 -> 去数据地图外面找负责人 -> 个别会拉群跟进 –> 等解决完→同步或者不同步 / 关注方→同步产出好了

1.4 数据延时产出问题

有一些例行的,必须在每天 xx 点产出的数据,如果没有生成好,就要人为去挨个找上游负责人去找问题,与 1.1.3 中的问题相似,都是要手动找上游。

2 解决思路

基于以上问题,咱们发现这些问题,都是监控不欠缺,欠缺的监控应该是怎么样的呢?

在已知问题内,只有给表或者数据的标签散布加了监控,那么当呈现问题时候,能够主动告诉到数据应用方,数据公布方,当问题抛出来给某人当前,他能够抉择,将此次报警置为解决中,后续在 xx 工夫内解决好,如果解决不好持续报警,然而报警范畴可能更大,比方给负责人经理电话,邮件,短信,拉群艾特等。这样有另外一个益处是数据的 sla 在肯定水平上保障了,能够过起初查问题,或者在将来的“某些非凡场合”应用到。

需要如上,那么设计

监控独立于调度零碎,与调度零碎惟一的交互是 done 文件,调度在 done 文件产出后才继续执行。

1.2.0 为什么基于 done 文件呢?

工作依赖,对于工作依赖来说,为了对数据源的品质检测,就要对每个工作进行配置工作检测依赖,会有两个问题,其一是工作检测脚本会更扩散,其二,检测逻辑很多是相似的,也会造成脚本冗余

表依赖,检测地位是表的分区,那么当数据品质检测通过后,生成一个表的分区,最终就是相似 dt=xxxx/rule=check_t1_count.done 相似这样 通过 add partition 来增加

文件依赖,跟表依赖类似之处就是生成一个 done 文件,区别之处在于能够间接通过服务来调用生成 done,较不便所以选文件依赖

1.2.1 done 文件由一个惟一的表名 + 工作 id.done 组成

1.2.2 单点报警 + 多层解决报警,如果 A 表怎么样,B 表怎么样,就报警给谁,具体有产出延时,失败报警

3 设计开发

1. 工作信息

2. 报警信息

3. 表信息

4. 监控逻辑表

5. 监控与报警关联表

6. 监控与表信息与工作信息的关联表

基于 SpringBoot 的后盾零碎

次要开发,等后续再分享,????????????????????????????????????????????????????

4 将来瞻望

退出血统的监控和报警

吴邪,小三爷,混迹于后盾,大数据,人工智能畛域的小菜鸟。
更多请关注

退出移动版