基于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未来展望

加入血缘的监控和报警

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