八、数据仓库详细介绍（监控告警）

1. 前言

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

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

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

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

1. ETL 计算逻辑、流程控制准确合理。（这个有 ETL 开发人员保证，测试人员把关。当然了很多时候开发测试都是同一个人，责任重大但谁让你是高级开发呢？）。

2. ETL 任务流程在规定的时间点能够被调起来。（这个有调度系统保证，另外再配上监控告警系统，超时未启动触发告警）。

1. 对于时效性 SLA 有要求的任务，需要添加超时告警。（这个调度系统可能会有，没有的话监控告警系统有也行，超时未完成触发告警）。

2. 稽核校验系统，根据检查点规则配置的校验时间启动校验，发现问题触发报警。（当然，有时候会在任务执行完成后，直接启动关联的数据质量稽核校验）。

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

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

https://code.aliyun.com/lipengbo123/dqc

2. ETL 运行情况监控

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

因此我们首先要做的就是 ETL 运行情况的监控。每一步关键节点都记录日志并且标明所属层级。

2.1 大致流程介绍

大致分为三部分：

1. ETL 任务执行过程中，记录详细的 ETL 运行日志

2. 分析  ETL 运行日志，汇总关键信息到监控结果日志表。

1. 发现异常直接调用告警通知模块触达告警，或者将告警通知信息写入告警记录表。

下图中的流程源自于多年前的项目交付文档，我们除了监控 ETL 执行情况外，还做了 ODS 层数据抽取完整性校验和数据库存储空间使用情况检查。

2.2 记录运行日志的方法介绍

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

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

第二层 ETL。第一层里的 JOB_DW 任务节点下钻后的第二层任务。当第二层里的任意一个节点失败都会记录失败日志同时终止任务，同时该错误会向上层传递直至最外层任务。

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

2.3 表结构设计

2.3.1 流水线运行日志 T_BAS_ETL_LOG

2.3.2 ETL监控结果汇总信息T_ETL_RST_COLLECTINFO

2.3.2 通知告警记录表

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

2.4 报表展示设计

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

2.4.1 ETL运行情况日志

报表01：最外层 ETL 任务

如果有错误，需要标成红色，并且显示错误信息，报表 02 同理

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

2.4.2 数据抽取完整性日志

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

2.4.3 数据库空间存储日志

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

3. 数据质量稽核

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

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

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

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

3.1 大致流程如下

1. 配置数据源，可以是各种数据库。

2. 配置比对规则。

1. 1. 指定数据源。

   2. 指定表，或者自己写查询 SQL。

   3. 字段映射，映射的时候可以配置简单的转换，需要区分维度和指标。

   4. 设定阈值，比如指标差异多少算作异常。

1. 根据配置的调度时机执行校验。

2. 执行日志实时展示，事实上是一张报表，可以下钻，报错的会重点标红，正常的标绿。

3.2 表结构设计

3.2.1 检查点配置表 dqc_check_config

3.2.2 数据源配置表 dqc_check_config_datasource

3.2.3 校验结果数据 dqc_check_result

3.2.4 规则执行日志 dqc_check_log

4. 告警通知系统

ETL 运行情况监控或者数据质量稽核发现问题后，需要触发告警通知。

4.1 实现方法

1. 封装成一个服务对外开放 API 接口，ETL 运行情况监控或者数据质量稽核发现问题后实时调用该 API 触发告警/通知。传入参数如下：触达方式（邮件/短信/电话/微信/钉钉）、通知组、消息内容。

2. 写入告警信息表，告警通知系统另起一个调度任务对该表定时轮询。

4.2 三种用途

1. 确保监控和稽核任务发现问题后能够自动触发告警，以便运维人员能够及时处理。

2. 没有收到告警并不能代表无错误，可能是监控或者稽核任务没有执行，最稳妥的办法就是一切 OK 的时候也发一条完成通知消息。

1. 每日的分析简报也可以通过该系统推送消息。比如运营日报、监控日报。

4.3 表结构设计

4.3.1 数据质量-告警通知组 dqc_notify_group

4.3.2 数据质量-告警通知触达对象 dqc_notify_object

4.3.3 数据质量-告警通知日志 dqc_notify_log