数据仓库详细介绍（七.监控告警） - 《数仓架构》

1. 前言

在前边的章节，我们设计完存储模型，开发了 ETL 任务，并且配置好流程依赖，然后上调度系统，至此我们的数据仓库基本搭建完成，而且所有流程任务都可以自动化运转了。

随着公司上线的数据处理任务越来越多，我们可以安排专门的运维人员定时监控任务执行情况，定时去检查终端应用，尽最大可能的发现问题（比如源数据迟到、数据量突增、异常数据或者开发考虑不周、有人修改代码且测试不充分、服务器异常、调度宕机等等），并且赶在业务使用前解决掉。

不过技术人嘛，这种全靠人肉去监控的方法总感觉太低端，而且心里很不踏实。所以，就需要上一套工具，来监控 ETL 运行情况、稽核数据质量，并根据监控稽核结果及时的发出告警或者通知。

涉及到技术层面，我们必须做一下几点工作：

综上所属，除了正常的 ETL 任务流程和调度系统外，我还需要再有三大模块：ETL运行情况监控、数据质量稽核、告警通知系统。

另外，我最近在规划一套数据质量监控+告警通知系统，现在只是设计了表结构，其它的代码+页面都还没有，有兴趣的可以一起参与进来。
https://code.aliyun.com/lipengbo123/dqc

首先，整个 ETL 流程任务是经过充分测试后才会上线的，所以理论上讲，只要整体流程，能在规定的时间内运行结束且不报错，一切就 OK。

所以，监控的首要目的就是做好 ETL 运行情况的监控。每一步关键节点都要记录日志，并且标明层级。

大致分为三部分：

下图中的流程，事实上当时我们处理监控 ETL 执行情况外，还做了 ODS 层数据抽取完整性校验，和数据库存储空间使用情况检查。

我们当时使用了 Kettle 做为 ETL 工具，当然使用其它工具、 Shell 脚本，又或者调度工具方法都是类似的。

第一层 ETL，每一步节点都会判断成功还是失败，失败则直接记录失败日志然后结束任务。

第二层 ETL。第一层里的 JOB_DW 任务节点下钻后的第二层任务。当第二层里的任意一个节点失败，状态都会回传到上层，然后触发上一层任务流程的终止。

再往下层，方法类似，我们就不做多余介绍了。

这个参考第四部分：告警通知系统设计

除了告警通知，我们还需要有系统页面，方便事后的分析和查看。

报表01：最外层 ETL 任务
如果有错误，需要标成红色，并且显示错误信息，报表 02 同理

报表02：报表下转后的明细 ETL 任务。

这个其实也可以通过数据质量稽核，配置检查点实现

这个是当时 Oracle 数据库的统计，当空间占用达到80%时候需要告警

在某些情况下，就算 ETL 运行正常也不能保证整体数据就正常，比如源端数据迟到或缺失、ETL代码被人错误的修改、调度未执行等等。

所以，我们需要对重要或者关键节点上的数据，做好稽核校验。

我们之前项目上，通过 Oracle 存储过程 + Oracle job 实现过一版，大致思路就是通过比对两条 SQL 的查询结果来校验，但缺陷是待校验的数据必须存在于数据库里。

另外，我刚毕业时候，公司有一个网页版的工具（CData），现在想想拿来做数据质量稽核会更合适一些。

配置数据源，可以是各种数据库。
配置比对规则。
1. 指定数据源。
2. 指定表，或者自己写查询 SQL。
3. 字段映射，映射的时候可以配置简单的转换，需要区分维度和指标。
4. 设定阈值，比如指标差异多少算作异常。
根据配置的调度时机执行校验。
执行日志实时展示，事实上是一张报表，可以下钻，报错的会重点标红，正常的标绿。