共计 1545 个字符，预计需要花费 4 分钟才能阅读完成。
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 将来瞻望
退出血统的监控和报警
吴邪，小三爷，混迹于后盾，大数据，人工智能畛域的小菜鸟。
更多请关注