数据开发流程常出现的数据质量问题

问题背景

最近语兴从同事视角以及自身视角发现我们部门其中大多数问题集中在数据质量，让业务失去数据信心，虽然我们有开发流程，前期也会和业务对接，但最后业务方还是能发现好几个数据BUG,反复赶工，因此语兴复盘了一下导致数据质量问题发生的情况。

（1）没有数据产品经理对接业务。

（2）口径一直对不齐，没有明确口径。

（3）测试前指标看上去没问题，但上线后出现问题很多（没搞清楚底层数据情况）。

（4）因为需求过多，历史bug工单太多导致没时间仔细code review。

（5）源头数据质量就有问题，但业务方总以为是数仓的问题。

问题拆解

没有数据产品经理对接业务

正常开发流程中都是需要数据产品/数据分析来对接业务的，好处在于

（1）能帮数据开发省去很多对接业务时间以及开会时间，很多无用的会数据开发可不参与，由数据产品直接去对接，从而留下较多时间投入开发。

（2）能比数据开发更懂业务流程，作为数据开发如果需要懂业务流程仍然需要对接业务及对接后端搞清楚数据表才可，因此一个需求进度就会很长，哪怕是加字段需求都需要了解全部项目背景，很费心（当然如果有充足时间还是可以了解下，但在互联网数仓中没有太多时间去了解这么全面）

（3）没有uat测试（uat测试是指后段系统上线后产品再去测试看看整体系统是否有问题），因此数仓也需要uat，需要从开发角度看到更细节的问题，如果直接对接业务就会出现很多bug，这时数据产品用处就很大了，能提前拦截不必要bug，提升业务用数信心。

口径一直对不齐，没有明确口径

口径对不齐也是数据质量常出问题的情况，可能是一开始对接需求时，业务方没讲清，最后交付数据出现问题，也可能是对接需求中业务频繁改，业务也不知道他最后到底看哪个口径，或者说业务也不清楚到底要分析哪些指标，对于这种情况一定要让业务方先想好，同时让数据产品拍定最后方案（这里又强调了数据产品重要性），如后续更改需要走下期迭代，这也就是语兴常在简历中提到的统一指标口径的关键。

测试前指标看上去没问题，但上线后出现问题很多（没搞清楚底层数据情况）

这个问题很多数据开发同学都会遇到，明明在上线发布之前指标验证都是正确的，为什么过了一段时间数据又不对了，对于这种只能说明细数据还有一些细节没搞清楚，例如一些type值，或者要去除的数据没去除导致指标不对，这种情况还是要熟悉明细数据，只到问清楚后端所有枚举信息，并与业务确认要包含哪些枚举，不需要哪些数据，在开发指标前把明细数据理清，同时在开发好后观察指标1-2天（如果是不着急交付）

因为需求过多，历史bug工单太多导致没时间仔细code review

我敢肯定目前80%以上公司都没有完整的数据上线前规范，很多同学都是面向业务去开发，更不用提数仓分层穿透这些问题，本质在于没有时间开发，对！本质就在于没有时间去做需求，甚至平时还要处理历史线上bug，去开一些无用的会，因此草草了事发布被业务发现问题也是常出现的情况，我们先讲一下完整的数据仓库上线发布前完整流程：

（1）代码是否能跑通：首先需要在开发环境先去跑通代码，确保代码是是没问题的。

（2）数据探查：上线之前先进行数据探查可以通过工具去看，也可以通过sql查询去看数据分布看最大值、最小值、空值、最大字符串长度、去重前后行数等等。

（3）数据比对：如果是加字段需求，除了需要去探查指标，其次还需要去看一下加了这个字段后对之前指标的影响，比如加了这个字段导致数据膨胀，因此需要再做一下数据比对，可以先把数据跑到开发环境的库中，例如现在开发环境是101个字段，线上是100个字段，加了这一个字段后，可以用开发环境的表和线上的表去比对，看一下之前的数据能否一致，这里有工具是最好的能直接检验，如果没工具可以抽几百条数据去看一下之前100个字段的数据是否一致，如不一致需要看一下具体情况。

（4）抽样比对：通过的ods抽样数据和ads数据去比对看看是否一致，例如今天做了一个指标可以写一段sql从ods查这个指标再和我们开发好的ads比对，可以抽200条user_id去看是否一致，但这里数据只能保障200条是准的，不能保障100%指标是准确的，但我们也只能检测到这个情况。

（5）依赖检测：添加字段后还需要检测是否有新依赖加入，从而再去配置依赖。

（6）上线前code review：找另外同事或者mentor再次去检查代码情况，确保代码看上去没问题，依赖有配置，同时找出慢sql进行修改。

（7）上线后回补数据：如果是全量数据则跑t-1即可，如果是增量数据需要进行补数据，为了检测生产环境是否有访问表的权限，如果没有的话生产环境运行代码也会报错，同时也是为了刷新数据后续交付。

（8）数据UAT测试：上线发布后需要让数据产品接入，再去看一下指标是否有异常（空值、枚举值分布、一场值等）

（9）DQC/基线SLA配置：配置监控告警，防止每日问题数据向下游流出，保障每日任务正常运行。

这是完整的链路，语兴相信大家能完全遵守每一条是不太现实的，但还是需要自测一下，重点需要关注数据探查、抽样比对、依赖检查、上线回补数据、DQC/SLA配置，其实做到这些点已经能规避60%问题出现，剩下情况就需要看需求是否堆积，以及是否有数据分析/数据产品。

源头数据质量就有问题，但业务方总以为是数仓的问题。

其实这个问题跟数仓无关，但总是被业务扣帽子，就说你数据质量问题，但作为数据开发同学心里也苦，明明不是我的锅，但也没办法，既然出现了就要澄清及解决

（1）需要让后端出面解释，可以拉数据质量沟通群中，做出源头数据解释，同时数仓也需要截图证明ods接入的数据确实有问题，并发群里。

（2）可以做数据质量长期跟踪体系，之前b站讲过【数仓建设实践路线-第九讲-数据质量监测跟踪体系建设】 https://www.bilibili.com/video/BV1hz4y177hG/?share_source=copy_web&vd_source=8d8a1a27ec58db6da3b9a0f242dc0ee8

既解释了，又给业务方做出了改善的方向，最终保障了数仓中数据质量无问题。

补充内容：如何通过sql自测

create table mammut_user.yx_dq_test as 
1.首先看代码能不能跑通
select '1' as user_id, null as staus, 10000 as pay_amt,'xxxxxxx' as content
union all 
select '1' as user_id, '1' as staus, 20000 as pay_amt,'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' as content
union all 
select '2' as user_id, '2' as staus, 33333343 as pay_amt,'xzczxcasdsaeqwewqe' as content
union all 
select '3' as user_id, '4' as staus, 21344124 as pay_amt,'gfhfghtryrtyrtyrt' as content
union all 
select '4' as user_id, '6' as staus, 568674 as pay_amt,'uyiuyiuyiyuiyuiyui' as content

2.数据探查
2.1 全表扫描
select *
from mammut_user.yx_dq_test

2.2 重复数
select count(user_id)
      ,count(distinct user_id)
from mammut_user.yx_dq_test

2.3 如果是新建表则可以大概看一下同时看看枚举值分布 ，如果是加字段则需要看一下空值、最大长度、最大值
select * from mammut_user.yx_dq_test

--枚举分布
select count(user_id)
      ,staus
from mammut_user.yx_dq_test
group by staus

--最大长度/最大值
select max(length(content))
      ,max(pay_amt) 
      ,user_id
from mammut_user.yx_dq_test
group by user_id

--空值情况，可按照维度去看
select count(content)
      ,count(*)
      ,staus
from mammut_user.yx_dq_test
group by staus

2.3 如果是新开发的指标则可以抽样校验
--抽样比对
-- create table mammut_user.yx_dq_test_target as
select count(if(staus='1',user_id,null)) as xx_cnt
       ,user_id
from mammut_user.yx_dq_test
group by user_id

select * 
from mammut_user.yx_dq_test_target
where user_id in ()