“提升数据质量：数据开发中的常见错误与修正策略“

保证数据准确性不仅是数据中台&数仓开发中最核心的事情，也是数据相关从业者最关心的问题，以下方法非常有通用性借鉴意义。

以我自己在数据中台做数仓开发的实际工作过程中遇到的为例，经常会遇到指标数据不准确的问题，产品和业务经常会时不时的抛出一张截图，用质问的语气问这是怎么回事，内涵意思就是数据怎么又不准了，要你们开发干什么用的，此时我们心中一万匹马略过，数据不准一定不是我们的问题，是不是上游又改什么东西了，我们什么都没动，是不是后端或者前端动什么东西了，肯定不关我们的事，唉，行吧行吧，我给你排查一下，别着急（别叫了）.....

排查数据不准确的问题时间长了发现会有几个规律，总结：

T0级要做的事情首先就是明确问题

问清楚业务或产品发现的问题具体是什么，让他们具体的指出来，是数据异常过大和历史平均差距有点多，还是他们凭感觉评估出来的，要出示证据，和明细数据手工汇总之后作对比，不要上来就盲目自己排查，效率会高很多。

其次就是逐步排查在哪儿出现问题了。

一、检查数据出口数据是否一致

首先在Mysql库中查询一下各个数据出口的数值和前端展示的数据是否一致

说下我们的数据链路：数据中台——>后端——>前端——>app，我们的app相当于一个移动端的bi数据看板。

业务背景就拿电商举例吧。

我们在dataworks数仓中开发好某个指标例如复购率之后，会把指标数据推送到Mysql宽表、API接口、redis缓存这三个地方，供后端查询处理直至展示到app页面上。对于最新的数据我们是习惯把近30天的数据存储到redis中，这样可以保证数据查询的一个速度和时效性，对于历史数据，有些特定场景需要借助于接口才能实现逻辑，比如我们要把所有的店铺数据都关联到维表中最新的店长名下，最新的店长需要取最新分区的数据进行关联，而整体数据量比较大，不能做成全量表，这种前提之下，通过接口查询最新维表店长数据和历史店铺数据进行关联得以实现，后端直接掉我们的接口即可。

然后接下来就是对比前端展示的指标数值是否和我数据库里的数值一样，是否和接口调出来的数值一样，以及是否和redis缓存数值一样，通过这步可以判断出来问题是不是出现在我数据侧。如果不是那就大声的怼回去！

二、检查自己的相关代码是否有过修改

如果出现了mysql表或者接口、redis中的数值某个地方出现了错误，进一步排查相关的代码逻辑，近期有没有过修改，因为我们这是多个人开发，每个人可能对同一个表做不同的需求开发，可能会有冲突和信息差，所以无论这个指标是不是自己开发的，都要第一时间检查版本修改情况以及代码逻辑问题。有可能自己上个版本修改的代码在某个场景中如月初或者新出现的情况中产生了冲突，逻辑不适配了，是很常见的情况，就需要根据新出现的业务场景进行代码适配，增加通用性。

三、具体排查代码逻辑问题

代码逻辑问题大致分几种：

1、数据翻倍问题

出现数据异常过大通常可能是由于数据翻倍导致，看异常值是否正好和历史均值成倍数关系。一般是在新加字段的过程中left join新表的时候，一条关联出了多条数据导致。例如左表主表是一个店铺一天的销售金额为一条数据，右表一个店铺对应两个标签位有两条数据，此时关联之后一个店铺变成了两条数据，销售金额再汇总的时候就会翻倍。我们一般碰到数据翻倍问题只需排查下副表一般是右表的数据，关联字段是否不唯一，如果副表唯一的话，主表即使有很多条数据关联之后也不会翻倍。排查时可以单独分段跑每一段的代码分步进行排查，必要时把其他的代码注释掉，不然有的代码太多不容易精准判断。还可以count条数比对，比较直观，单个表关联之前的数据条数和关联之后的条数差多少

count (*)

2、精度&小数点问题

比如业务方手动算出一个月A店铺的复购率是25.77%，我们给出的指标值是25.78%。偶尔会差个0.01%，而且不是大面积的数据错误，基本上是由于double双精度浮点类型导致，有些特定业务场景人数不一定是整数，需要乘以0.9或者0.8等系数折算出小数来进行相关店铺的考核。相关字段是double，在进行sql计算的过程中，就会出现精度的缺失

比如：0.1+0.2+0.3 = 0.6 ，这个在sql中用sum逐步乘以系数再汇总出来可能是0.59999999，这点就比较坑了。

解决办法之一可以通过把分子（新客人数）、分母（老客人数）计算出来之后都保留1位小数（和系数保持一致），然后再进行相除得到复购率，但是这样有个弊端就是业务口径之后改系数的话保留几位小数，这里也需要同步处理。

round('新客人数' , 1) / round('老客人数' , 1)

另一种就是如果说mysql表中的字段类型是double，也可能出现精度的缺失，可以改成decimal(20,8)，这时有可能把数据纠正到和真实值一样。

alter table A modify column '字段B' decimal(20,8)

3、字段取错

在新加字段时，由于表的注释不清晰产品给的口径不清晰亦或是自己的马虎大意，可能会导致字段取错，这个可以单独跑一下新加的代码逻辑，和明细表数据比对一下，再和产品确认一下字段即可。

4、指标公式写错

比如：某指标公式计算方式为：(1-A) / B，写代码时写成了（1+A）/ B 或者 A/B 等等，是非常常见的事情

5、数据同步时导入语句写错

我们使用的datax同步工具，从数仓——>Mysql，同步数据时可以设置相应的导入语句

delete from table where month = '${bizmonth}'  and index_code = '123456' 

在导入前进行数据库的删除操作时，有可能表名没改导致删错表，从而影响其他表数据，也有可能日期范围错误，还有可能指标名称写错等等，都是一些小的注意点，另外同步的字段没有做同名映射，导致同步数据错误，也是很常见的，需要检查好细节。

使用脚本同步数据的，比较麻烦一些，可以使用网页对比工具对比下字段是否一致，或者使用excel高亮重复项筛选错误。

6、单位错误

有些从业务系统抽过来的销售额数值单位不仅有分，还可能有美元、其他国家本位币，这时候就需要我们注意一下，使用汇率或者相应的对应倍数进行手动转换。

SUM( CASE WHEN type RLIKE '**' THEN amount ELSE NULL END) / 100 AS amount --销售额，底层单位是分，转换成元

7、逻辑陷阱

有些求类似城市销售额排名的需求，需要用到rank函数开窗，需要注意asc正序还是desc倒序。像不良率、不合格率等负面指标通常使用asc，销售额等通常使用desc倒序。

rank() over(partition by '城市' order by '销售额' desc) rank() over(partition by '城市' order by '不合格率' asc)

以上是几种排查数据异常，保证数据准确性的方法，希望能够给大家带来帮助，也欢迎各位小伙伴们一起补充！