数据仓库详细介绍（九.数据质量）流程与工具
2023-03-30 13:26 浏览量：369
本篇，首先会参考阿里云文档给大家讲解下数据质量管理流程（阿里云的文章写得不太好理解，我又根据个人理解做了许多加工），然后大致介绍下数据质量管理工具设计思路。
0x01 数据质量管理流程
数据质量管理是通过划分数据资产等级和分析元数据的应用链路，对不同资产等级的数据采取相对应的质量管理方式。
数据质量管理流程图如下：
数据资产等级定义
包含两部分内容：
数据资产等级的定义
根据资产等级分析数据处理链路
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 点以后才开始执行，计算前一天的数据。这些任务大多在深夜运行，要确保数据按时产出，需要考虑任务的执行优先级以及任务执行失败或时间过长时的报警问题。
降低您的配置成本。
杜绝无效报警。
自动覆盖所有重要任务。
任务优先级。根据业务的资产等级，确定任务的优先级，对于优先级高的任务优先调度并占用计算资源，确保高等级业务的准时产出。
任务报警。任务报警和优先级类似，任务执行过程中，可能出错或延迟，为了保障最重要数据（即资产等级高的数据）产出，需要立即处理出错并介入处理延迟。
数据质量衡量
在了解了以上保障数据仓库数据质量的方案后，我们还需要进一步学习如何制定一套标准度量方案，以及判断质量监控方案是否合适业务需求以及如何改进。
例如，针对每一个数据质量事件，必须分析原因和处理过程，制定后续同类事件预防方案。将严重的数据质量事件升级为故障，并对故障进行定义、等级划分、处理和总结。
0x02 数据质量管理工具设计思路
看到这里，我们再来回忆下以上的数据质量管理流程。
首先，进行数据资产等级定义。我们需要定义好最终应用以及对应的数据加工任务的重要性等级。
其次，进行关键节点控制。我们需要监控好源端的数据质量以及关键内容的变动，同时要把控好代码提交和任务的上线运行变更等环节，发现问题及时处理。
再次，进行数据风险点监控。我们使用 DQC 工具对核心风险点进行检查，同时监控好 SLA（最晚出数时间），发新问题及时告警触发后续处理。
最后，进行数据质量衡量。主要是对以上行为进行复盘，及时发现问题并纠正。
以上提到的环节，我们可以通过提高参与者的技术能力以及重视程度来尽可能的保障数据质量，但如果有条件还是希望能够采用技术手段（比如使用任务流程监控、数据稽核校验、告警通知等）去完成。
元数据管理工具
记录好数据存储模型、表/字段的词根库命名规则、ETL 任务流、数据资产等级、数据血缘、指标定义（口径）、ETL 运行日志、数据质量稽核规则及稽核日志等等关键元数据。
数据仓库详细介绍（八.元数据）
开发保障类工具
预设规则，可以在新增或变更时候启动检查，也可以定期自动化的触发，去检查数据存储模型质量、ETL 代码质量、各种数据应用的使用热度等等。
结合数据资产等级和数据血缘，及时发现设计和实施过程中的数据质量隐患以及影响程度。
ETL 过程检查工具
ETL 代码规范得到保障的前提下，我们通过浏览 ETL 运行日志发现问题，然后根据影响程度去触发告警或通知，同时考虑是否暂停后续任务。
源端变更识别工具
数据部门在公司有一定话语权话语权的情况下，建议跟源端系统把流程固化下来，源端的表结构变更、字段使用规则变更，需要通知到数据方并且要有一定的提前量否则会根据影响程度问责。另外数据方也要提前告知端系统，自己用到了哪些数据。有时候源端直接处理的成本和效果会比数据端好很多。
源端解决不了或者不给解决的就只能及时发现然后触发告警，但这通常都会有滞后性，建议还是要事先往上“闹一闹”的，这个锅不应该有咱背且有时候咱也背不动啊。
使用工具的话，最简单的方法，我们可以在稽核校验工具里配置规则，比如在业务系统压力小的时候，或者固定的上线发版日，检查源端重要表的可访问性、空值率、数据分布等等，发现问题及时触发告警通知。
来源：数据社
