本篇是《你了解你的数据吗》的第五篇,在前面的几篇文章中,我们聊到了数据接入量、数据的坑、数据核心维度分布、数据口径和数据质量监控。本篇将引入一个新的概念:数据血缘分析 ,或者叫血统分析。
那么什么是数据血缘分析呢?在这里我们不给出它的严谨的定义,仅从感觉上来解释一下这个东西。
数据血缘,我们可以大致理解为是一个表的生成过程。它依赖了哪些表,怎么生成的。同时加上它依赖的表又是怎么生成的。
下面举个栗子来解释一下。
现在假设你是一只数据开发工程师,为了满足一次业务需求,,然后为了生成这张表,可能是处于程序逻辑清晰或者性能优化的考虑,你会使用很多份数据表,也会通过 MR、Spark 或者 Hive 来生产很多中间表。
如下图,是你将花费时间来实现的整个数据流。
过了一段时间后,业务侧的感觉你提供的数据中有个字段总是不太对劲,其实就是怀疑你的数据出问题!需要你来追踪一下这个字段的来源。
首先你从 Table X 中找到了异常的字段,然后定位到了它来源于 Table I,再从 Table I 定位到了它来源于 Table G, 再从 Table G 追溯到了 Table D,最终发现是某几天的来源数据有异常。
或者说,你从 Table X 定位到了异常的字段原来来自于其它小伙伴处理的表 Table J,然后继续向前回溯,找到了这张表在处理过程中的某一个步出现了问题。
上面的过程是数据血缘分析的过程。
咋一看,其实感觉数据血缘分析并没有什么用,其实就我个人感觉来看,其实的确没什么用,特别是在你的业务规模比较小并且数据合作不频繁的情况下,基本不需要数据血缘分析。但是当遇到了下面一些场景的时候,数据血缘绝对能帮你提高很高的效率。
其实总的说来,数据血缘能帮你更好地理解自己的数据!
实现的话不打算在这里多聊,因为数据血缘一般是和元数据管理紧紧绑定起来的,在设计元数据管理系统的时候应该要考虑到数据血缘的内容。关于元数据系统的设计可以参考这篇博客《别人家的元数据系统是怎么设计的》。
这里随便提一句,数据血缘的管理可以考虑使用图数据来实现,用图数据的好处是更容易展现表之间的关系。比如说下面两个需求点,用关系型数据库写 Sql 的话会很麻烦,但是用图数据库的话逻辑就十分简单。
补充: 有朋友会问,数据的关系从哪来?这个其实途径很多,最简单的方式可以从所有的 Hive Sql 中解析出来关系对,也可以从其它的代码或者调度系统中解析。具体实现可以根据业务场景来实现。
居士个人理解,数据血缘关系是理解数据的一个十分重要的点,它能让你快速清晰地理解你所关注的数据的生成路径。
然后关于本文,闲扯的比较多,而且不是特别严谨。居士希望能帮助没怎么听过数据血缘的童鞋熟悉一下这个概念,至于深入的挖掘点,可以再多交流。