深圳便宜建网站,互动吧网站模板,代替做网站推广,域名关键词排名查询简介#xff1a; 数据质量问题无处不在#xff0c;本文尝试找到一种方法#xff0c;能够尽可能的发现数据质量问题并解决之。 作者 | 茂才 来源 | 阿里技术公众号
一 概述
1 数据质量问题无处不在
基本上每个用数据的同学#xff0c;都遇到过以下类似的问题。
表没有按…简介 数据质量问题无处不在本文尝试找到一种方法能够尽可能的发现数据质量问题并解决之。 作者 | 茂才 来源 | 阿里技术公众号
一 概述
1 数据质量问题无处不在
基本上每个用数据的同学都遇到过以下类似的问题。
表没有按时产出影响下游严重的甚至可能影响线上效果。打点缺失看了报表才发现数据对不上。数据统计出来uv大于pv很尴尬。数据产出暴增本来1000万的数据变成了3000万。字段里面的枚举值和注释里面的对不上没人能解释。某些维度缺失没法做进一步的数据分析。做了一通分析发现结果很离谱一点点向前分析发现打点有问题。……
以上都是数据质量的问题。本文尝试找到一种方法能够尽可能的发现数据质量问题并解决之。
2 数据标准
谈到数据质量就必须了解评价数据质量的维度。DAMA UK 提出了数据质量的六个核心维度见图1。
注DAMA International 国际数据管理协会成立于1980年是一个由技术和业务专业人员组成的国际性数据管理专业协会作为一个非营利的机构独立于任何厂商旨在世界范围内推广并促进数据管理领域的概念和最佳实践为数字经济打下理论和实践基础。全球会员近万人在世界48个国家成立有分会。 图1 数据质量维度
完整性Completeness完整性是指数据信息信息是否存在缺失的状况常见数据表中行的缺失字段的缺失码值的缺失。比如虽然整体pv是正确的但在某个维度下只有部分打点这就是存在完整性的问题。不完整的数据所能借鉴的价值就会大大降低也是数据质量问题最为基础和常见的问题。常见统计sqlcount( 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表进行验证。
表间探查
1join条件探查
此种情况属于跨表探查。不同的表在做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时没有写分区条件导致多个分区同时计算出现数据爆炸。
这个问题很多同学在开发中遇到了多次一定要注意。
2join 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上的数据会被过滤掉。
3inner join和outer join用错问题
此问题偶发往往是开发同学没有理解业务或者typo导致结果不符合预期。
写完sql一定要检查如果有可能请别的同学review sql。
4时间分区加引号
一般情况下分区都是string数据类型但在写sql时分区不写引号也可以查询出正确的数据导致有些同学不习惯在分区上加引号。
但某些情况下如果没有加引号查询的数据是错误的。所以一定要在时间分区上加引号。
5表循环依赖问题
在开发时偶尔会出现三个表相互依赖的问题这种情况比较少见而且在数据开发阶段不容易发现只有再提交任务之后才会发现。
要避免这种情况需要明确一些开发规范。比如维表和明细表都要从ods表中查得不能维表和明细表直接互相依赖。对于某些复杂的逻辑可以通过中间表的形式实现重用。
6枚举值问题
在做etl时需要把某些枚举值转化成字符串比如1转成是、0转成否等。
常见的写法是在sql中写case when。
但对于某种一直增长的枚举值这种方法不合适否则增加一种编码就要改一次sql而且容易出现sql膨胀的问题。
推荐通过与码表join的方法解决此问题。
性能问题
1join 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监控是对表和字段的监控是任务运行后触发监控条件从而触发报警。
数据质量中心DQCData Quality Center是集团推出的数据质量解决方案它可以提供整个数据的生命周期内的全链路数据质量保障服务。通过DQC我们能够在数据生产加工链路上监控业务数据的异常性如有问题第一时间发现并自动阻断异常数据对下游的影响保障数据的准确性。
DQC可以做以下监控
数据产出行数波动监控业务主键唯一性监控关键字段空值监控汇总数据合理性监控
DQC的流程如下
用户进行规则配置通过定时的调度任务触发检查任务执行基于任务配置获取样本数据基于计算返回检验结果调度根据检验结果决定是否阻断干预(强依赖、弱依赖)
不过DQC虽然很强大但其配置还是很繁琐的而且要设置波动规则需要较长时间观测表和字段多的时候配置工作特别大。有团队研究了Auto-DQC可以自动化监控DQC配置。
其它数据质量监控平台
其它值得关注的数据质量监控平台包括
Apache Griffin(Ebay开源数据质量监控平台)Deequ(Amazon开源数据质量监控平台)DataMan(美团点评数据质量监控平台)
三 后记
解决数据质量问题没有银弹数据质量管理不单纯是一个概念也不单纯是一项技术、也不单纯是一个系统更不单纯是一套管理流程数据质量管理是一个集方法论、技术、业务和管理为一体的解决方案。本文简单总结了我们当前遇到的数据质量问题和处理方法也希望与对数据质量敢兴趣的同学多多交流。
原文链接
本文为阿里云原创内容未经允许不得转载。
