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

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

一 概述

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_nameWHERE dt = 'xxxxx'GROUP BY result ;

2）枚举值探查

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

SELECT  DISTINCT resultFROM    xxx.table_nameWHERE dt = 'xxxxx' ;

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

3）惟一值探查

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

SELECT  COUNT(item_id)         ,COUNT(DISTINCT item_id)FROM    xxx.table_nameWHERE   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 aLEFT JOIN (SELECT  itemid               FROM    xxx.zzzz               WHERE   ds = '20210916'            ) bON a.itemid = b.itemidWHERE   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 cntFROM    xxx.yyyy_logWHERE   dt = '20210913'GROUP BY useridHAVING  cnt > 5000 ;

2 数据开发标准

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

SQL编写问题

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

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

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

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

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

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

SELECT  COUNT(*)FROM    xxx aLEFT JOIN yyy bON      a.id = b.item_idWHERE   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_pricefrom sale_detail_sj a join sale_detail bon 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(美团点评数据品质监控平台)

三 后记

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

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