关于大数据:数据质量漫谈

简介：数据品质问题无处不在，本文尝试找到一种办法，可能尽可能的发现数据品质问题并解决之。

作者 | 茂才
起源 | 阿里技术公众号

一 概述

1 数据品质问题无处不在

基本上每个用数据的同学，都遇到过以下相似的问题。

• 表没有按时产出，影响上游，重大的甚至可能影响线上成果。
• 打点缺失，看了报表才发现数据对不上。
• 数据统计进去，uv 大于 pv，很难堪。
• 数据产出暴增，原本 1000 万的数据变成了 3000 万。
• 字段外面的枚举值和正文外面的对不上，没人能解释。
• 某些维度缺失，没法做进一步的数据分析。
• 做了一通剖析，发现后果很离谱，一点点向前剖析，发现打点有问题。
• ……

以上都是数据品质的问题。本文尝试找到一种办法，可能尽可能的发现数据品质问题并解决之。

2 数据规范

谈到数据品质，就必须理解评估数据品质的维度。DAMA UK 提出了数据品质的六个外围维度，见图 1。

注：DAMA International（国内数据管理协会）成立于 1980 年，是一个由技术和业务业余人员组成的国际性数据管理业余协会，作为一个非营利的机构，独立于任何厂商，旨在世界范畴内推广并促成数据管理畛域的概念和最佳实际，为数字经济打下实践和实际根底。寰球会员近万人，在世界 48 个国家成立有分会。

图 1 数据品质维度

• 完整性 Completeness：完整性是指数据信息信息是否存在缺失的情况，常见数据表中行的缺失，字段的缺失，码值的缺失。比方尽管整体 pv 是正确的，但在某个维度下，只有局部打点，这就是存在完整性的问题。不残缺的数据所能借鉴的价值就会大大降低，也是数据品质问题最为根底和常见的问题。常见统计 sql：count(not null) / count(*)
• 有效性 Validity：有效性个别指范畴有效性、日期有效性、模式有效性等次要体现在数据记录的标准和数据是否合乎逻辑。标准指的是，一项数据存在它特定的格局，如：手机号码肯定是 11 位的数字；逻辑指的是，多项数据间存在着固定的逻辑关系，如：PV 肯定是大于等于 UV 的。
• 准确性 Accuracy：准确性是指数据记录的信息是否存在异样或谬误。最为常见的数据准确性谬误就如乱码。其次，异样的大或者小的数据也是不符合条件的数据。准确性可能存在于个别记录，也可能存在于整个数据集，例如数量级记录谬误。这类谬误则能够应用最大值和最小值的统计量去审核。
• 及时性 Timeliness：及时性是指数据从开始解决到能够查看的工夫距离。及时性对于数据分析自身的影响并不大，但如果数据建设的工夫过长，就无奈及时进行数据分析，可能导致剖析得出的论断失去了借鉴意义。比方：实时业务大盘数据，及时反映业务要害指标的状况，裸露业务指标的异样稳定，机动响应非凡突发状况都须要数据的及时更新和产出。某些状况下，数据并不是单纯为了剖析用而是线上策略用，数据没有及时产出会影响线上成果。
• 一致性 Consistency：一致性是指雷同含意信息在多业务多场景是否具备一致性，个别状况下是指多源数据的数据模型不统一，例如：命名不统一、数据结构不统一、束缚规定不统一。数据实体不统一，例如：数据编码不统一、命名及含意不统一、分类档次不统一、生命周期不统一等。
• 唯一性 Uniqueness：在数据集中数据不反复的水平。惟一数据条数，和总数据条数的百分比。比方 count(distinct business key) / count(*)，个别用来验证主键唯一性。

3 数据的生命周期

图 2 数据生命周期

• 数据接入：接入上游表输出或者其它数据源的数据。
• 数据加工：编写 sql 生成指标数据表。
• 数据产出：定时调度工作生成数据表。
• 数据利用：上游数据分析、报表等利用数据。

在下面任何一个环节中，都可能呈现数据品质的问题，晋升数据品质须要从数据接入、数据加工、数据产出、数据利用、成果跟踪等全流程进行把控，全局观很重要，不拘一点，能力看的更全面。

二 如何解决数据品质问题

数据品质是数据的生命线，没有高质量的数据，所有数据分析、数据挖掘、数据利用的成果都会大打折扣，甚至呈现齐全谬误的论断，或者导致资损。然而数据品质问题却是宽泛存在的，且治理的难度很大，因为数据的生产、加工、流转、利用波及到业务经营、生产零碎、数据系统、数据产品等上下游链路几十个环节，每个环节都可能引入数据品质问题。

团体很多 BU 都有成体系的解决数据品质的计划，团体也有很多工具来解决数据品质问题。本文不具体介绍此类工具的应用，次要聚焦在数据开发过程中因为数据研发同学经验不足而导致的数据品质问题。

图 3 数据品质解决办法

如图 3 所示，我认为有三种办法能够在肯定水平上解决数据品质的问题。

数据探查

• 发现完整性、一致性、有效性、准确性、关联性等问题
• 解决的数据接入和数据产出阶段的问题

开发标准

• 发现数据及时性、数据一致性、数据准确性等问题
• 解决数据产出阶段的问题

数据监控

• 防止一致性、准确性等问题
• 解决数据生产阶段的问题

1 数据探查

数据探查的定义个别为：数据探查是摸索源数据的过程，用来了解数据结构、数据内容、数据关系以及为数据工程辨认可能存在的问题。

数据探查不止用在数据品质畛域，数仓开发、数据迁徙等都须要对源数据进行数据探查。数据仓库的所有数据根底都是源数据（ODS），在开发数仓之前，须要对源数据进行探查，能力保障产出的数据仓库的准确性。

题库业务的数据短少打点，数据建设次要基于业务架构的一些两头表和后果表，在开发后期，没有意识到数据探查的重要性，导致数据的准确性有重大问题，数据研发呈现了大量的返工景象。

dataworks 提供了数据探查的性能，能够统计根本信息、数据分布、topN、直方图等。但我试了几次始终是探查中，易用性还不是太好。

图 4 数据探查根本办法

上图是数据探查的一些基本功能。

本局部介绍数据探查的一些常见办法，不成体系，只是开发过程中遇到的问题，供参考。

表探查

1）数据总量探查

数据总量摸索是对 ods 的总体数据有初步认知，能够通过数据地图的分区信息确认，也能够通过写 sql 计算。

数据总量探查时要探查每日增量数据总量、全量数据总量（如有须要）。

个别状况下，数据总量探查后果要与业务方或者上游数据提供方确认是否合乎预期。

2）数据产出工夫和生命周期探查

在做数据探查时，须要探查数据产出工夫和生命周期，对后续的任务调度和补数据有肯定的帮忙。

列探查

1）数据分布探查

数据分布探查是数据探查中最重要的局部，能够探测不同维度下数据的散布状况。个别状况下，有如下写法。

SELECT  result         
,COUNT(*)
FROM    xxx.table_name
WHERE dt = 'xxxxx'
GROUP BY result ;

2）枚举值探查

枚举值探查是下面数据分布探查的一种特例，探查某些维度的枚举值是否正当。个别状况下 sql 如下。

SELECT  DISTINCT result
FROM    xxx.table_name
WHERE dt = 'xxxxx' ;

这种探查，能够探查出很多问题，比方上游生成某枚举值只有 0 和 1，但探查的时候探查出为空等。

3）惟一值探查

某些状况下，上游生成某些字段惟一（不肯定是主键），也须要对此类情况探查，不然做 join 时容易呈现数据收缩问题。探查 sql 个别如下。

SELECT  COUNT(item_id)         
,COUNT(DISTINCT item_id)
FROM    xxx.table_name
WHERE   dt = 'xxxxx' ;

4）极值 & 异样值探查

对于某些数值类的值，必要状况下能够做一下极值探查，比方求最大值、最小值、平均值。这样能够尽快发现源数据中的脏数据。

对于异样值也要探查一下，比方 0、null、空字符串等。

列间探查

1）关联字段探查

通常状况下，一张表中不同字段间接有关联关系。比方曝光字段和曝光时长之间有关联关系，有曝光的肯定有曝光时长，或者曝光时长大于 0 的状况下肯定有曝光。

或者 uv 肯定大于 pv，这种办法能够对 dws 表进行验证。

表间探查

1）join 条件探查

此种状况属于跨表探查。不同的表在做 join 时，除了探查 join 条件是否胜利，还须要探查 join 失去的数量是否合乎预期。

在题库业务中，呈现过因为零碎 bug，上游表的 join 条件中，有 3% 左右的数据 join 不上，但因为后期没有做此方面的数据探查，导致用了很久才发现此问题。

还有一种状况是业务上两张表必须 join 上，比方生产表所有的用户都应该呈现在用户表，或者所有内容都应该呈现在内容维表等。

个别 sql 如下：

SELECT  count(DISTINCT a.itemid)
FROM    xxx.yyy_log a
LEFT JOIN (
SELECT  itemid               
FROM    xxx.zzzz               
WHERE   ds = '20210916'           
 ) b
ON a.itemid = b.itemid
WHERE   a.dt = '20210916'
AND     b.itemid IS NULL ;

业务探查

1）过滤条件不对

在某些状况下，须要从海量数据中，通过某些过滤条件捞出所需数据。比方客户端打点的标准是统一的，不同的端的用户日志都在一张表中，如果只剖析某种数据，须要对数据进行过滤。

此过滤条件个别由业务方同学提供，在数据探查阶段要先做条件过滤，与业务方同学沟通过滤之后的数据是否合乎预期。

2）业务上数据反复问题

属于表唯一性探查。此问题与惟一值的景象相似，都是数据有反复。

不同之后在于，某些状况下，尽管数据提供方称了某些列惟一，但在某些业务场景下，数据就是不惟一的。比方题库的某业务中，业务方开始说不同线索失去的 q_id 不统一，然而 q_id 来自 url，在业务上 url 的确存在反复的状况，所以 q_id 有反复的状况。

但在另一种数据反复的问题往往不是业务如此，而是零碎 bug 导致的。比方某种业务中，一本书实践上解决完之后不应该再次解决，但零碎的 bug 导致呈现一本书被解决屡次的状况。

对于第一种状况，咱们在建模时要思考业务复杂性；而第二种状况，咱们要做的是找到无效的数据，去掉脏数据。

3）数据漏斗问题

数据链路中数据漏斗是很要害的数据，在做初步数据探查时，也须要关注数据漏斗。每一层数据抛弃的数量（比例）都要和业务方确认。

比方某一个入库流的解决数据数量和入库数量比照，或者入库数量和入索引数量等，如果比例呈现了很大的问题，须要找上游业务方修改。

4）业务上数据分布不合理

“刷子用户”的发现就是一种常见的数据分布不合理，比方某个 user 的一天的 pv 在 5000 以上，咱们大概率狐疑是刷子用户，要把这些用户从统计中剔除，并要找到数据上游过滤掉相似用户。

个别 sql 如下：

SELECT  userid         
,count(*) AS cnt
FROM    xxx.yyyy_log
WHERE   dt = '20210913'
GROUP BY userid
HAVING  cnt > 5000 ;

2 数据开发标准

下面形容了很多数据探查问题，如果认真的做了数据探查，能够防止很多数据品质问题。本局部形容在数据开发环节中开发同学因为教训等起因导致的数据品质问题。

SQL 编写问题

1）笛卡尔积导致数据收缩

此问题往往产生在没有对 join 条件进行唯一性查看的状况下。因为左边数据不惟一，产生笛卡尔积，导致数据收缩。如果是某些超大表，除了数据后果不对之外，会产生计算和存储的节约。

还有一种状况，在繁多分区中数据是惟一的，但 join 时没有写分区条件，导致多个分区同时计算，呈现数据爆炸。

这个问题很多同学在开发中遇到了屡次，肯定要留神。

2）join on where 程序导致后果谬误

此问题也是常见问题，因为写错了 on 和 where 的程序，导致后果不合乎预期。谬误 case 如下。

SELECT  COUNT(*)
FROM    xxx a
LEFT JOIN yyy b
ON      a.id = b.item_id
WHERE   a.dt = '${bizdate}'
AND     b.dt = '${bizdate}' ;

在下面的 sql 中，因为 b.dt 在 where 条件中，那么没有 join 上的数据会被过滤掉。

3）inner join 和 outer join 用错问题

此问题偶发，往往是开发同学没有了解业务或者 typo，导致后果不合乎预期。

写完 sql 肯定要查看，如果有可能请别的同学 review sql。

4）工夫分区加引号

个别状况下，分区都是 string 数据类型，但在写 sql 时，分区不写引号也能够查问出正确的数据，导致有些同学不习惯在分区上加引号。

但某些状况下，如果没有加引号，查问的数据是谬误的。所以肯定要在工夫分区上加引号。

5）表循环依赖问题

在开发时，偶然会呈现三个表相互依赖的问题，这种状况比拟少见，而且在数据开发阶段不容易发现，只有再提交工作之后才会发现。

要防止这种状况，须要明确一些开发标准。比方维表和明细表都要从 ods 表中查得，不能维表和明细表间接相互依赖。对于某些简单的逻辑，能够通过两头表的模式实现重用。

6）枚举值问题

在做 etl 时，须要把某些枚举值转化成字符串，比方 1 转成是、0 转成否等。

常见的写法是在 sql 中写 case when。

但对于某种始终增长的枚举值，这种办法不适合，否则减少一种编码就要改一次 sql，而且容易呈现 sql 收缩的问题。

举荐通过与码表 join 的办法解决此问题。

性能问题

1）join on where 程序的性能问题

下面提到过 join 的 on 和 where 执行程序的问题，这也关系到 join 的性能问题。因为是先 on 后 where，倡议先把数据量放大再做 join，这也能够晋升性能。

(1) 如果是对左表（a）字段过滤数据，则能够间接写在 where 前面，此时执行的程序是：先对 a 表的 where 条件过滤数据而后再 join b 表；

(2) 如果是对右表（b）字段过滤数据，则应该写在 on 条件前面或者独自写个子查问嵌套进去，这样能力实现先过滤 b 表数据再进行 join 操作；

如果间接把 b 表过滤条件放在 where 前面，执行程序是：先对 a 表数据过滤，而后和 b 表全副数据关联之后，在 reduce 阶段才会对 b 表过滤条件进行过滤数据，此时如果 b 表数据量很大的话，效率就会很低。因而对于应该在 map 阶段尽可能对右表进行数据过滤。

我个别对右表做一个子查问。

2）小维表 map join

在 Hive 中

若所有表中只有一张小表，那可在最大的表通过 Mapper 的时候将小表齐全放到内存中，Hive 能够在 map 端执行连贯过程，称为 map-side join，这是因为 Hive 能够和内存的小表逐个匹配，从而省略掉惯例连贯所需的 reduce 过程。即便对于很小的数据集，这个优化也显著地要快于惯例的连贯操作。其不仅缩小了 reduce 过程，而且有时还能够同时缩小 Map 过程的执行步骤。参考文末链接一。

在 MaxCompute 中

mapjoin 在 Map 阶段执行表连贯，而非等到 Reduce 阶段才执行表连贯，能够缩短大量数据传输工夫，晋升系统资源利用率，从而起到优化作业的作用。

在对大表和一个或多个小表执行 join 操作时，mapjoin 会将您指定的小表全副加载到执行 join 操作的程序的内存中，在 Map 阶段实现表连贯从而放慢 join 的执行速度。

文档中给的例子如下：

select /*+ mapjoin(a) */
a.shop_name,
a.total_price,
b.total_price
from sale_detail_sj a join sale_detail b
on a.total_price < b.total_price or a.total_price + b.total_price < 500;

参考文末链接二。

3）超大维表 hash clustering

在互联网大数据场景中，一致性维表的数据量都比拟大，有的甚至到几亿甚至十亿的量级，在这个数据量级下做 join，会这种工作往往耗时十分长，有些工作甚至须要消耗一天的工夫能力产出。

在这种状况下，为了缩短执行工夫，通常能够调大 join 阶段的 instance 数目，减少 join 阶段的内存缩小 spill 等，然而 instance 的数目不能有限增长，否则会因为 shuffle 规模太大造成集群压力过大，另外内存的资源也是无限的，所以调整参数也只是就义资源换取工夫，治标不治本。

Hash clustering，简而言之，就是将数据提前进行 shuffle 和排序，在应用数据的过程中，读取数据后直接参与计算。这种模式非常适合产出后后续节点屡次依照雷同 key 进行 join 或者聚合的场景。

Hash clustering 是内置在 MaxCompute 中，不必显示的指定，很不便。

参考文末链接三。

4）数据歪斜问题

Hive/MaxCompute 在执行 MapReduce 工作时常常会碰到数据歪斜的问题，体现为一个或者几个 reduce 节点运行很慢，缩短了整个工作实现的工夫，这是因为某些 key 的条数比其余 key 多很多，这些 Key 所在的 reduce 节点所解决的数据量比其余节点就大很多，从而导致某几个节点迟迟运行不完。

常见的状况比方 join 的散布不平均，group by 的时候不平均等。

具体的解决办法能够参考文末链接四。

3 数据监控

提交数据工作后，如何能正确及时的监控工作也是十分重要的。在数据监控方面，团体提供了很多弱小的产品来解决问题，简略介绍如下。

数据及时性监控（摩萨德）

摩萨德监控是对工作运行状态的监控，包含工作运行出错、未按规定工夫运行。摩萨德是对工作的监控，因而特地适宜监控数据产出的实时性。比方某些表须要在几点产出，如果没有产出则报警等。以后摩萨德只能在 Dataworks 应用。

数据产出监控（DQC）

不同于摩萨德对工作的监控，DQC 监控是对表和字段的监控，是工作运行后触发监控条件从而触发报警。

数据品质核心（DQC，Data Quality Center）是团体推出的数据品质解决方案，它能够提供整个数据的生命周期内的全链路数据品质保障服务。通过 DQC，咱们可能在数据生产加工链路上监控业务数据的异样性，如有问题第一工夫发现，并主动阻断异样数据对上游的影响，保障数据的准确性。

DQC 能够做以下监控

• 数据产出行数稳定监控
• 业务主键唯一性监控
• 关键字段空值监控
• 汇总数据合理性监控

DQC 的流程如下：

• 用户进行规定配置
• 通过定时的调度工作触发查看工作执行
• 基于工作配置，获取样本数据
• 基于计算返回测验后果
• 调度依据测验后果，决定是否阻断干涉(强依赖、弱依赖)

不过 DQC 尽管很弱小，但其配置还是很繁琐的，而且要设置稳定规定，须要较长时间观测，表和字段多的时候配置工作特地大。有团队钻研了 Auto-DQC，能够自动化监控 DQC 配置。

其它数据品质监控平台

其它值得关注的数据品质监控平台包含

• Apache Griffin(Ebay 开源数据品质监控平台)
• Deequ(Amazon 开源数据品质监控平台)
• DataMan(美团点评数据品质监控平台)

三 后记

解决数据品质问题没有银弹，数据品质治理不单纯是一个概念，也不单纯是一项技术、也不单纯是一个零碎，更不单纯是一套治理流程，数据品质治理是一个集方法论、技术、业务和治理为一体的解决方案。本文简略总结了咱们以后遇到的数据品质问题和解决办法，也心愿与对数据品质敢趣味的同学多多交换。

原文链接
本文为阿里云原创内容，未经容许不得转载。