今天跟一个测试同事聊天:
我:最近忙什么项目呢?
他:在测大数据血缘
我:啥?
他:血缘啊
我:啥血缘?
他:大数据血缘啊
我:血缘是啥?
他:就是数据血缘啊
我:...
看看,天就是这么被聊死的,我忍不住内心OS(怪不得你秃顶还没女朋友)
我赶紧回来问问 google,分析了各路答案之后,可以总结成两句话:
通常我们会对原始数据进行多个步骤的各种加工,最后产生出新的数据,在这个过程中会产生很多表,这些数据表之间的链路关系就可称为大数据血缘。
大数据血缘测试,就是测试数据流转过程中的每个环节的数据质量。
同时,数据血缘还有几个同义词:
Data Lineage 数据血缘(数据血统) = Data Provenance 数据起源 = Data Pedigree 数据谱系
在现实世界中,我们每个个体都是祖先通过生育关系一代×××育而来,这样就形成了我们人类的各种血缘关系。
在数据信息时代,每时每刻都会产生庞大的数据,即我们通常说的大数据,对这些数据进行各种加工组合、转换,又会产生新的数据,这些数据之间就存在着天然的联系,我们把这些联系称为数据血缘关系。
直白点说,数据血缘就是指数据产生的链路关系,就是这个数据是怎么来的,经过了哪些过程和阶段。
下面举个通俗点的例子:
比如在淘宝网中,客户在淘宝网页中购买物品后,数据就被存到后台数据库表A中。我们希望查看某个月卖的最火的是哪些物品时,就需要对数据库中的原始数据进行加工汇总,形成一张中间表B来存储阶段处理的数据,若逻辑较复杂时,还要继续加工继续形成中间表。。。直到最后处理成我们前台展现使用的最终表,假设为C表。
那么A表是C表数据最初的来源,是C表数据的祖先。从A表数据到B表数据再到C表数据,这条链路就是C表的数据血缘。
在数据的处理过程中,从数据源头到最终的数据生成,每个环节都可能会导致我们出现数据质量的问题。比如我们数据源本身数据质量不高,在后续的处理环节中如果没有进行数据质量的检测和处理,那么这个数据信息最终流转到我们的目标表,它的数据质量也是不高的。也有可能在某个环节的数据处理中,我们对数据进行了一些不恰当的处理,导致后续环节的数据质量变得糟糕。
因此,对于数据的血缘关系,我们要确保每个环节都要注意数据质量的检测和处理,那么我们后续数据才会有优良的基因,即有很高的数据质量。
数据血缘的常见分析过程:
现在假设你是一名数据开发工程师,为了满足某个业务需求,需要生成最终表 X。
可能是出于程序逻辑清晰或者性能优化的考虑,你为了生成这张表,通过 MR、Spark 或者 Hive 来生成很多中间表。
如下图,是你将花费时间来实现的整个数据流,其中:
Table X 是最终给到业务侧的表
蓝色的 Table A-E,是原始数据
×××的 Table F-I ,是你计算出来的中间表,这些都是你自己写程序要处理的表
Table J ,是别人处理过的结果表,因为本着不重复开发的原则,你很可能要用到同事小伙伴处理的表
过了一段时间后,业务侧的感觉你提供的数据中有个字段总是不太对劲,其实就是怀疑你的数据出问题!需要你来追踪一下这个字段的来源。
首先你从 Table X 中找到了异常的字段,然后定位到了它来源于 Table I,再从 Table I 定位到了它来源于 Table G, 再从 Table G 追溯到了 Table D,最终发现是某几天的来源数据有异常。或者说,你从 Table X 定位到了异常的字段原来来自于其它小伙伴处理的表 Table J,然后继续向前回溯,找到了这张表在处理过程中的某一个步出现了问题。
上面的过程是数据血缘分析的过程。
到此,相信你已经大概明白血缘是啥了。
再啰嗦两句,其实数据血缘并不难,只是概念比较高大上而已,实际我们测试的时候跟普通的 sql 操作差不多,只是用到的语法是 hive、sqoop、pig 等组件相对应的语法,不是常见的 sql 语法而已。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。