大数据数据血缘是什么，跟数据质量有什么关系？

数据血缘、数据质量、数据地图这三个，我个人感觉其实不太必要管它们的关系，这都是一些概念而已，如果你都知道了他们三个是干什么了，就知道关系了。

这里，我感觉可以重点理解几个两个概念：

元数据管理数据质量管理

数据地图应该算是元数据管理的一部分，其实只是换了一个名字而已，总的来讲都是管理元数据的，然后数据血缘也属于元数据管理的一部分。

然后数据质量管理主要是对数据质量方面的把控，比如说某天的数据丢失？数据的同比环比不正常等。

详细内容不是一句话说清的，我给你几篇文章参考，之前写博客的时候写过自己的理解，不一定完全正确，可以辅助理解。

google的16年出的关于元数据管理的论文，我读后写的博客：别人家的元数据系统是怎么设计的

数据质量监控的文章：数据质量监控

血缘分析的文章，今天刚出炉的：你了解你的数据吗（元婴篇）

下面节选一部分血缘分析正文：

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

觉个栗子

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

现在假设你是一只数据开发工程师，为了满足一次业务需求，，然后为了生成这张表，可能是处于程序逻辑清晰或者性能优化的考虑，你会使用很多份数据表，也会通过 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，然后继续向前回溯，找到了这张表在处理过程中的某一个步出现了问题。

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

写在最后，最后无耻地推荐一下自己的博客：木东居士的茶水间

目前里面最多的是关于大数据和数据仓库相关的内容，有两三个系列性的博客：

Data Warehouse in Action你了解 你的数据吗