什么是大数据血缘？

更多内容可以关注公众号：测试帮日记

今天跟一个测试同事聊天：

我：最近忙什么项目呢？
他：在测大数据血缘
我：啥？
他：血缘啊
我：啥血缘？
他：大数据血缘啊
我：血缘是啥？
他：就是数据血缘啊
我：...

看看，天就是这么被聊死的，我忍不住内心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 语法而已。