关于数仓监控体系优化的实践

这次和大家分享的是属于数仓任务监控体系中特别细节的一个点。

额，我觉得我特别擅长从细节处思考，主要也是因为我接触到的事情确确实实都是特别具体的、需要立刻去解决的、特别个性化、特别的贴合业务的事情。

在数仓侧处理比较多的任务监控有两种类型：运行监控和质量监控。

运行监控包括：执行失败监控、执行耗时过长监控、到规定时间未执行成功监控、执行成功通知等；

质量监控就更多了，也更个性化，比如：表行数监控、主键重复值监控、空值监控、指标波动监控等。

这次遇到的问题是属于运行监控类型中，任务设计层面。

该怎么描述这个场景呢？先给看一张图：

这个是数据多维分析和快速查询的场景，数据在数仓层加工生成到hive表之后，再抽取到clickhouse，然后由clickhouse支撑配制各种指标。

clickhouse中基本是已经计算好的指标，维度一致的指标可以从不同模型中随意组合，这样能够避免再从hive层重复计算。

不同的业务侧可以列出他们各自关心的核心指标，我们给做仪表盘 或者 每天给发邮件 或者 每天给核心群推送数据。

这些指标大多是横跨多个模型，并且有的还有可能是跨部门的模型，也就说模型的任务是维护在不同同学的手里。

当前的监控方案，是基于一个个表或者说是一个个任务来监控的(就像图片上那样)，大家各自维护自己的任务，这样当需要推送的核心任务变多时，就会遇到一些问题：

1. 任务owner及值班同学得知道这个任务的重要程度，也得知道这个任务是支撑了哪块的数据推送 ----这个不靠谱；
2. 由于1的原因，某个任务延迟，值班同学很纳闷，这个任务会影响哪些核心看板 or 核心推送 or 核心实验指标组呢？
3. 需设置的监控多，容易漏掉；
4. 因为3中设置的监控多，带来的问题就是报警多；
5. 如果推送数据依赖了其他部门的模型，某天会发现，咦？我们的底表都运行成功了，为啥数据还没推送？再往下排查才发现是另一个部门同学的数据延迟了；
6. 大家各自设置各自的监控，风格不一致
7. ......

上面这些问题，主要原因是我们的监控对象是中间的节点，而不是最终节点。

我们应该改变监控对象，把【为某个核心表 or 某个核心任务设置监控】改成【为最终某个业务重点关心的数据结果设置基线监控】，如果下图：

为这三个节点 【A1业务核心群指标推送节点】、【A2业务核心群指标推送节点】、【A3业务核心群指标推送节点】做整个链路的基线监控，最终只为这三个节点负责。

这样，我们值班同学看到报警后，立刻就知道：噢，A业务群的推送有延迟风险，主要是因为某某个任务可能延迟，应该通知负责A业务的同学去周知这个事情。

我们值班计划应该是为链路的最终点做值班，要为数据最终有没有推送负责，而不是说，我们负责的hive表产出了，就ok了，后面的事情我们就不关心了。

所以，这样改进的优势也很明显，如果够细心，加了运行成功的通知后，每天都能看到核心结果数据的就绪情况：

可能有点子乱，但也都是自己思考和改进的结果，😂😂😂，如果有遇到相同情况的朋友，可以看看啦~~

在最需要努力的时候，都别辜负了一个最好的自己。