你了解你的数据吗（元婴篇）

0x00 前言

本篇是《你了解你的数据吗》的第五篇，在前面的几篇文章中，我们聊到了数据接入量、数据的坑、数据核心维度分布、数据口径和数据质量监控。本篇将引入一个新的概念：数据血缘分析 ，或者叫血统分析。

0x01 血缘分析

那么什么是数据血缘分析呢？在这里我们不给出它的严谨的定义，仅从感觉上来解释一下这个东西。

数据血缘，我们可以大致理解为是一个表的生成过程。它依赖了哪些表，怎么生成的。同时加上它依赖的表又是怎么生成的。

觉个栗子

下面举个栗子来解释一下。

现在假设你是一只数据开发工程师，为了满足一次业务需求，，然后为了生成这张表，可能是处于程序逻辑清晰或者性能优化的考虑，你会使用很多份数据表，也会通过 MR、Spark 或者 Hive 来生产很多中间表。

如下图，是你将花费时间来实现的整个数据流。

• 其中 Table X 是最终给到业务侧的表。
• 蓝色的 Table A-E，是原始数据。
• 黄色的 Table F-I 是你计算出来的中间表。这些表都是你自己写程序要处理的表。
• 然后你为了懒省事，嗯，应该说本着不重复开发的原则，你还要用到同事小伙伴处理的表，Table J 就是别人处理过的结果表。

[图片上传失败...(image-59d781-1517131923676)]

过了一段时间后，业务侧的感觉你提供的数据中有个字段总是不太对劲，其实就是怀疑你的数据出问题！需要你来追踪一下这个字段的来源。

首先你从 Table X 中找到了异常的字段，然后定位到了它来源于 Table I，再从 Table I 定位到了它来源于 Table G， 再从 Table G 追溯到了 Table D，最终发现是某几天的来源数据有异常。

或者说，你从 Table X 定位到了异常的字段原来来自于其它小伙伴处理的表 Table J，然后继续向前回溯，找到了这张表在处理过程中的某一个步出现了问题。

上面的过程是数据血缘分析的过程。

0x02 数据血缘分析有什么用？？？

咋一看，其实感觉数据血缘分析并没有什么用，其实就我个人感觉来看，其实的确没什么用，特别是在你的业务规模比较小并且数据合作不频繁的情况下，基本不需要数据血缘分析。但是当遇到了下面一些场景的时候，数据血缘绝对能帮你提高很高的效率。

1. 问题定位。上面的例子，假设你用到了别人的数据，数据血缘分析能快速帮你定位到问题。
2. 理解数据。如果你想用其它的数据源，首先要能理解它，不然数据口径能给你带来很大的麻烦。
3. 修改某份数据的时候能评估影响的范围大小。比如说现在你的小伙伴要调整自己开发的 Table J，这时候如果他不知道有谁在依赖这张表，冒然修改的话会带来毁灭性的伤害，但是有数据血缘分析的时候，至少能知道谁在使用这份数据。

其实总的说来，数据血缘能帮你更好地理解自己的数据！

0x03 关于实现

实现的话不打算在这里多聊，因为数据血缘一般是和元数据管理紧紧绑定起来的，在设计元数据管理系统的时候应该要考虑到数据血缘的内容。关于元数据系统的设计可以参考这篇博客《别人家的元数据系统是怎么设计的》。

这里随便提一句，数据血缘的管理可以考虑使用图数据来实现，用图数据的好处是更容易展现表之间的关系。比如说下面两个需求点，用关系型数据库写 Sql 的话会很麻烦，但是用图数据库的话逻辑就十分简单。

• 找到一张表依赖的所有的表和生成路径。
• 找到依赖于某张表的所有表，和它们的生成路径。

补充： 有朋友会问，数据的关系从哪来？这个其实途径很多，最简单的方式可以从所有的 Hive Sql 中解析出来关系对，也可以从其它的代码或者调度系统中解析。具体实现可以根据业务场景来实现。

0xFF 总结

居士个人理解，数据血缘关系是理解数据的一个十分重要的点，它能让你快速清晰地理解你所关注的数据的生成路径。

然后关于本文，闲扯的比较多，而且不是特别严谨。居士希望能帮助没怎么听过数据血缘的童鞋熟悉一下这个概念，至于深入的挖掘点，可以再多交流。