十、数据仓库详细介绍（数据质量）流程与工具

上篇我们主要介绍了以下三部分内容。

第一部分，介绍了五种常见的数据管理知识体系，数据质量在所有的知识体系中都有非常重要的地位，数据应用体现数据价值，数据质量为应用提供支撑。
第二部分，我们介绍了数据质量评判的五大标准，它为数据质量管理工作提供了参考依据、评定标准、量化理论支撑。
第三部分，我们介绍了四种数据质量保障体系，希望大家能够从多个不同维度去深度思考，然后结合自己的身份职位以及所处环境去制定行之有效的数据质量保障手段。

做为数据人必须对数据质量保持足够的重视。

如果你是公司高层，可以从制度管理业务等多个方面，协调各个相关部门去保证数据质量。
如果你是数据团队负责人，需要提高团队成员对于数据质量的重视程度，制定数据质量标准和规范，开发数据质量管理工具，使得相关工作能够更轻松有序的开展。
如果你是一线数据开发，至少得保证自己负责的部分内容的数据质量。接到任务后不要急于上手，先去看看上游依赖的数据数据质量是否可用，同时跟需求方确认好口径，最后才是考虑具体的实现逻辑。

本篇，首先会参考阿里云文档给大家讲解下数据质量管理流程（阿里云的文章写得不太好理解，我又根据个人理解做了许多加工），然后大致介绍下数据质量管理工具设计思路。

0x01 数据质量管理流程

数据质量管理是通过划分数据资产等级和分析元数据的应用链路，对不同资产等级的数据采取相对应的质量管理方式。

数据质量管理流程图如下：

原文内容可以翻阅阿里巴巴大数据之路，第 15 章数据质量部分。

也可以查看阿里云文档：https://help.aliyun.com/document_detail/114560.html

数据资产等级定义

包含两部分内容：

数据资产等级的定义
根据资产等级分析数据处理链路

1、数据资产等级的定义

根据数据质量不满足完整性、准确性、一致性、及时性时，对业务的影响程度划分数据的资产等级。通常，划分为5个性质的等级：

毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失等。标记为A1。
全局性质：数据直接或间接用于企业级业务、效果评估和重要决策等。标记为A2。

局部性质：数据直接或间接用于某些业务线的运营、报告等，如果出现问题会给业务线造成一定的影响或造成工作效率降低。标记为A3。
一般性质：数据主要用于日常数据分析，出现问题带来的影响极小。标记为A4。
未知性质：无法明确数据的应用场景。标记为Ax。

从上到下重要性依次降低，即重要程度为A1>A2>A3>A4>Ax。如果一份数据出现在多个应用场景汇总，则根据其最重要程度进行标记。

2、根据资产等级分析数据处理链路

定义数据资产等级后，您可以从数据流转链路开始进行数据资产等级打标，完成数据资产等级的确认，给不同的数据处理链路定义不同的重要程度。

源端业务系统产生的数据，通过同步工具进入数据数仓系统。数据在数仓中进行清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程过程，数据都存放在表中，流转链路大致如下图所示。

在数据流转链路上，您需要整理各个表对应的最终应用业务产品。根据这些应用业务产品的数据资产等级，结合数据的上下游血缘，将整个链路打上某一类资产等级的标签。

关键节点控制

1、源端系统变更检测

源端的问题最好能在源端解决掉，比如数据准确性、一致性、稳定性等等。

我们需要事先跟源端系统负责人沟通确认清楚数据使用规则，确保数据抽取和计算环节的数据准确性。

在线业务系统复杂多变，每次变更都会产生数据的变化。为保证数据质量，就需要考虑如何能将源端业务系统的变更，更高效地通知给数据仓库维护人员。

首先，我们可以从人员管理入手，制定流程规范，要求前端业务变更发版上线前必须通知下游下游数仓运维人员。

其次，我们可以使用工具自动捕捉每一次业务的变化。如果数仓直接使用的是业务系统的表可以检测表结构的变化、业务关键字段的空值率、数据量同环比的波动等等。如果数仓接入的是业务系统日志，可以在入库前做格式校验和数据量同环比波动分析。

2、模型设计评审

模型设计师、架构师、需求人员、业务人员、运维人员参与，对数仓模型进行评审，优秀的数据模型除了满足业务需求外，还需要在性能、成本、效率、质量等方面有不错的助力。良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

数据仓库详细介绍（四.建模）理论篇

3、代码提交核查

即在 SQL 提交前进行相关规则校验。有工具最好，如果没有可以人工代码 review。规则分类如下：

代码规范类规则。例如，表命名规范、生命周期设置及表注释等。
代码质量类规则。例如，分母为0提醒、NULL 值参与计算影响结果提醒及插入字段顺序错误等。
代码性能类规则。例如，分区裁剪失效、扫描大表提醒及重复计算检测等。

4、任务发布变更审查

为保障线上数据的准确性，每次变更都需要经过测试再发布到线上生产环境，上线后最好第一时间对相关应用和底层数据做检查。

在进行更新操作前，需要通知下游变更原因、变更逻辑、变更时间等信息。下游对此次变更没有异议后，再按照约定时间执行发布变更，这样可以将变更对下游的影响降到最低。

5、任务运行过程监控

ETL 运行过程每一步的执行情况都应该记录日志，如果有报错需要根据资产等级定义选择立即触发报警以及是否停止任务。

数据风险点监控

DQC Data Quality Center/Check 数据质量中心，还是数据质量检查？好吧，我们暂时叫它数据质量监控。我们在上一篇提到的五大数据质量评估标准，完整性、准确性、一致性、时效性、可访问性，DQC 通过配置质量检查规则，可以实现完整性、准确性、可访问性监控，从而间接实现了时效性监控。但是，一致性只能通过统一的模型设计和口径定义来保障。

SLA（Service Level Agreement）服务等级协议，它描述是双方的一种约定，是一种服务可用性的指标。SLA 提供的可用性越高，那么一年内停机的时间越小。SLA 是保证服务的可用性的。好吧，它的原始含义好像是跟运维相关的。在数据质量管理中，SLA 指的应该是最晚出数时间。

1、DQC 数据质量监控

通过配置 DQC 的数据质量校验规则，可以实现在数据处理过程中进行自动的数据质量监控。DQC 可以监控数据质量并报警，但它不对数据产出进行处理，需要报警接收人判断如何处理。

DQC 数据监控规则有强规则和弱规则：

强规则：一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）。
弱规则：只报警但不阻断任务的执行。

DQC 的工作流程如下图所示。

DQC 提供常用的规则模板，包括表行数较 N 天前波动率、表空间大小较 N 天前波动率、字段最大/最小/平均值相比 N 天前波动率、字段空值/唯一个数等。

DQC 的检查也可以通过运行 SQL 任务实现。该 SQL 任务嵌套在整体任务中，如果检查次数过多会影响整体的任务执行性能。因此，哪些数据需要配置 DQC 规则、应该配置什么规则，也需要根据数据资产等级来确定。例如 A1、A2 类数据监控率要达到 90% 以上，规则类型需要 3 种以上，而不重要的数据资产没有强制要求。

2、SLA 数据时效性监控

在确保数据准确性的前提下，您需要进一步让数据能够及时提供服务，否则数据的价值将大幅降低。确保数据及时性是保障数据质量的重要一环。为确保数据完整性，每天任务通常都是 0 点以后才开始执行，计算前一天的数据。这些任务大多在深夜运行，要确保数据按时产出，需要考虑任务的执行优先级以及任务执行失败或时间过长时的报警问题。