海量数据的稽核方案

海量数据的稽核方案,第1张

项目场景:

今天上午一位做数据的同事找到我,问我有没有“数据稽核”相关的经验可供借鉴。

客户的需求是这样的:

  • 每天从业务系统抽取数据到数据平台,每个表的数据量过亿
  • 要求针对这两部分数据每天进行稽核,精确到字段,以保证“数据质量”,并针对差异数据形成相关报表。

针对上述场景,形成解决方案。


问题描述

看完需求,分析有以下几个难点需要考虑:
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…逐级向下。

这种方式会不会让客户眼前一亮?

你有什么好方法呢?大家来说一说。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/langs/720264.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-25
下一篇 2022-04-25

发表评论

登录后才能评论

评论列表(0条)

保存