- 站点信息
- 问题反馈
- 邮箱：[email protected]
- 吐槽一下
关注微信
©2020-2025 ioDraw All rights reserved,
Privacy Policy
<>项目场景：
今天上午一位做数据的同事找到我，问我有没有“数据稽核”相关的经验可供借鉴。
客户的需求是这样的:
* 每天从业务系统抽取数据到数据平台，每个表的数据量过亿
* 要求针对这两部分数据每天进行稽核，精确到字段，以保证“数据质量”，并针对差异数据形成相关报表。
针对上述场景，形成解决方案。
<>问题描述
看完需求，分析有以下几个难点需要考虑：
1、数据量大，如何保证效率
2、“字段”级稽核，工作量大，如何保证效率
3、规定了稽核频率，比对工作必须在当天完成
<>方案分析：
传统情况下，会有2种解决方案：
1、数据同步过来之后，写sql稽核
2、写程序实现，针对每条数据，根据主键查询、逐个字段比较
是否可行呢？
第一种不用说了，肯定跑不出来啊！
无论什么库，单表超过100w数据就不建议关联查询了。
而且任何时候都要遵循一个原则：业务逻辑的实现一定不要放在数据库中进行。
第二种方案相对靠谱一些，可以出结果，但是实现方式太“丑陋”了。而且要在一天之内出结果，免不了需要并行计算，这就需要大量的计算资源。
所以这2种方案都不是最佳方案，也没有任何亮点。
<>解决方案：
<>1.数据导出时做分组、摘要
在数据导出时，一般情况下都是按批次导出的，导出的数据量可配置。
在此基础上结合数据的特点进行分组(可以1个批次1组，也可以1个批次多个组)。
比如每组1w条数据，这1w条数据必须是按照主键或某个索引连续的序列。
然后针对这1w条数据做哈希，这里以md5为例（也可以选择其他靠谱的摘要算法）。
以分组键的范围作为key，md5值作为value，将其存储在k-v型的数据库中(如redis)。
例如：
key:1-10000, value:md5-xxxxxxxxx key:10001-20000, value:md5-yyyyyyyyy ………………
最终，这1亿条记录生成了1w个md5值。
<>2.数据导如时也做分组、摘要
在数据导入时，也需要按照这种形式组织数据，进行哈希，将key-value存入redis中。（当然，也可以在这里直接执行步骤3）
<>3.数据比对
这时源端和目的端都有1w条md5值，可以根据key值读取value进行比对:
* 哈希值一致的，说明这个区间内的数据没有问题。
* 哈希值不一致时，才需要抽取出来进行细致分析。这时由于数据量少了很多，就可以写sql或者其他方式进一步锁定差异。
<>4.分组粒度要可控
分组的粒度要可配置，根据每日的稽核结果，灵活调整这个值。
比如，按1w条数据分组，第一天比对1w条md5中只有1条md5不一致，那么这个分组粒度就是可以接受的。
如果有10条甚至20条不一致，说明同步的某个环节可能存在问题导致数据质量差，那么就需要调整分组粒度。
下一次稽核可以调整成1000条每组，使得稽核程序能够更精确的定位到差异数据的范围，降低后续比对的时间。
<>总结
在数据同步过程中，大部分数据都是没有问题的。采用这种将数据“打包”的方式进行批量比对，简单高效，可以将比对结果输出限制在分钟级。
当然，这种方式还有优化的空间：
* 可以将步骤1中生成的1w个md5值再进行分组，如每10个一组，这时一个组代表的数据量是10w。
* 对每一组数据的10个value进行md5，得到md5-2(这里的2可以理解为层级)，那么redis中又会有1000个md5-2。
*
按照这种分组方式递归下去，1000个md5-2会得到100个md5-3(代表100w数据)、10个md5-4(代表1000w数据)、1个md5-5(代表1亿数据)。
* 在比较时，先比对md5-5，在比较md5-4…逐级向下。
这种方式会不会让客户眼前一亮？
你有什么好方法呢？大家来说一说。