转载自 https://blog.csdn.net/YcoeXu/article/details/114242239

数据治理（一）血缘关系
一、概念
数据血缘也称为数据血统或谱系，是来描述数据的来源和派生关系。数据来源是数据科学的关键，也是被公认为数据信任的核心的部分。说白了就是这个数据是怎么来的，经过了哪些过程或阶段，从哪些表，哪些字段计算得来的。

（桑基图是血缘关系的一种表达图表，图表使用ECharts绘制。公司安全要求，对一些业务信息进行模糊处理）

血缘关系按某个表为中心又分为两个方向，当前表依赖到的是上游；当前表被依赖到的是下游。

1. 上游依赖
上游依赖表达的是当前表直接或间接依赖到哪些表

例子：有一天，一个业务员发现他上个月的绩效数据不对的，那么这个问题提交到数仓开发的时候，数仓开发会怎样去查找这个问题呢？

数仓开发首先会找到这个报表指标用的是哪个表-字段，再找到这个表的数据创建脚本，认真查了一遍指标的计算逻辑。确认当前表-字段的计算逻辑没问题后，会往上查找这个表直接依赖到的表-字段。再继续用同样的方法确认这些表-字段，如此一层层定位问题…

（这个是经纪人宽表的上游依赖图。用树形图可以清晰展示依赖关系，但它不能表达环状的依赖，直接使用ant-design的树形控件）

2. 下游依赖
下游依赖表达的是当前表被哪些表直接或间接依赖。

例子：某个表能不能下线？

首先要检查的就是这个表有没有被依赖到。如果有，那肯定是不能直接下线的（至少需要将下线下游的表）；如果没有，也还需要再进一步确认下这个表还有没有被使用。没下游依赖并不代表没被使用！

（这个是经纪人宽表的下游依赖图，报表的依赖没有在这里显现，但可以在表的详情里面查看到）

二、为什么需要建立血缘关系
问这个问题，其实应该先问：数据要不要治理？这跟开一个公司，员工要不要管理一样，答案是肯定的。只是治理到什么程度而已。

刚开始搭建大数据平台时，是比较忽视数据治理的。几个开发，几十个表，用个Excel或文档就可以搞定的事。但随着迭代的继续，表越来越多；随着人员的变更，会越来越难以管理。指标难找、不知道已经存在这个指标…于是重复开发指标，然后就出现了各种指标/数据不一致的问题。烟囱式的开发也很容易带来这些问题。企业数仓发展到这个阶段，就需要考虑多人协作，统一的标准，解决数据一致性等问题了。数据治理就是解决这类问题的基础，它可以说是发展到一定阶段必定会演化出来的系统。

数据治理，应该系统性地去思考解决这些问题，统筹地去考虑如何限制和落地定制的规范，而不只是用几个文档或Excel展示。数据治理的基础是采集各种信息，将其分类归整好，然后定制出一个合理的规则进行执行监督。各种信息中血缘关系是核心，从数据怎么来，怎样分布的，怎么使用，怎样结束。这就形成了数据治理里面的数据地图、数据质量、数据生命周期等一系列模块。后续会有相关的文章单独讲解数据治理…

另外，血缘关系也是指标的派生关系、指标数据的影响因子，通过这个关系，对于指标数据异常的智能发现提供了最直接的溯源依据。比如平台经纪人的活跃指标突然下降，程序可以通过这个指标的上游关系自动的回溯，快速找到出现异常的最源头表-字段。这样对数据异常的排查难度会大大降低。

三、Apache Atlas？
1. 表级别的血缘关系
如果只是到表级别，这个实现比较简单，像hive tool就自带了一个工具类可以直接获得：

2. 字段级别的血缘关系
到表级别显然是不够的，我们需要更细粒度的，到字段级别的血缘关系。选择并不多，Apache Atlas名气很大，可以提供血缘关系和元数据管理功能。

（来自：https://atlas.apache.org/#/Architecture）

Apache Atlas支持的大数据组件很多：Hive / Sqoop / Falcon / Storm / HBase …也提供了接入Hook和接口的接入方式。底层存储使用HBase，使用Solr实现索引，存储之上用JanusGraph将其转换成图数据。

（来自：https://atlas.apache.org/#/ClassificationPropagation，还是挺炫酷）

我们第一版的数据血缘关系就是基于Apache Atlas搭建，使用它的元数据扩展功能扩展了中文名、标签等字段。但是在使用的过程，也遇到了很多问题，主要是复合查询的支持不够和性能问题，这主要是由它的底层索引架构和存储介质决定的。

四、自研duo-lineage
1. 为什么要重复造轮子
之前我就写了几个duo系列的产品了（duo-doc / duo-graphql / duo-schedule …），名字不重要，重要的是为什么我们要重新造一个轮子？

数据治理是一整套的方案，不仅仅是采集血缘关系。在规划这一套治理方案过程中，越来越觉得数据血缘信息的重要性，很有必要将它前置在执行脚本之前（Apache Atlas在执行阶段通过Hive Hook的方式采集的血缘关系，属于被动式采集，数据有点滞后）完成数据血缘的提取。以配合治理方案前期的规范验证和脚本依赖自动发现，为发布系统和智能调度系统提供数据。

（DwOps流程图，会在后续的文章里更多介绍）
详见：https://www.processon.com/view/link/5fed67095653bb21c1b1acaf

前置数据血缘解析，在脚本入库后自动触发脚本解析，同时对制定的一些规范进行验证，比如命名是否规范，分层是否合理，是否跨层依赖等。没有规范的限制，开发人员为了省事不去构建中间统计表，有可能出现ADM层的指标直接查ODS数据，这对数仓结构和性能来说是个灾难性的。

数据血缘关系同时也是脚本调度依赖关系。目前业内的调度系统oozie / airflow / azkaban…都得人工去配置依赖，容易出错。前置数据血缘解析可以实现自动的调度依赖配置，让调度的配置工作自动完成，最大限度地减少人工操作失误的可能性。

数据治理是一整套的方案，理念是通过程序去落地规范，完善数据采集。让治理工作不依赖人工维护（人是不可靠的），成为一个闭环，这样才能保证数据治理平台信息的准确性和关联性，避免形成信息孤岛。将DevOps的理念引入到大数据领域，将开发流程、发布系统、智能调度与数据治理方案整合成一套完整的系统，为数仓保驾护航。

为了实现这个宏大的想法，在数据血缘这一层面依赖Apache Atlas是实现不了的，所以我们重新造了一个轮子…

2. 技术选型
数据的产生方式很多，Shell、ETL、代码+SQL混合实现的spark，甚至纯scala/java代码实现。我们没办法实现所有数据血缘的采集。只能将采集范围最小化，收缩到两大类：Sqoop脚本和SQL（可能是Hive SQL、Spark SQL、Flink SQL…统称为SQL了）。

Sqoop的脚本其实最终也是转换成SQL，所以不再过多阐述，大的方向就是SQL化。（数据治理理念：所有数据处理必须可治理，SQL化更方便治理）

确定了SQL化治理，那么构建血缘关系的关键就是解析SQL生成AST（抽象语法树），再进行一步解析血缘关系。那么AST的解析就成了关键，当前可用的方案挺多的

Alibaba Druid：它是一个数据库连接池，里面带了一个SQLParser，可以解析SQL为AST。

优点：依赖简单，解析出来的AST简单，对Hive SQL的支持还不错，目前确实还有些语法不支持，但最近的版本在Hive SQL的支持在逐渐增强

缺点：AST解析工具只是它的副业 [哭笑]，另外有些不支持的语法需要额外处理

queryparser：uber开源，实现了hive、presto、vertica、teradata、pg等解析器。

优点：定制化很高，对语法支持好

缺点：使用haskell编写，学习成本比较高

hive：hive内置的解析器，依赖的包太重

优点：Hive SQL完美支持（亲爹）

缺点：包依赖太重，解析出来的AST比较复杂

Antlr4：通用的高性能的语法分析器

优点：高性能，灵活，自己写几乎可以把控它的所有行为

缺点：太底层了，需要自己写解析规则，后续的维护成本也会很高，Alibaba Druid就是基于Antlr4实现的AST

…

综合各种情况，我们选择了 Alibaba Druid。

3. 实现
解析AST，无非就是遍历这棵树，解析出需要的数据再向上冒泡。实现原理挺简单的，但是还是有很多的细节需要处理的。处理流程如下图：

首先在输入时，如果是sqoop脚本，需要先解析脚本，将其转换成SQL。

其次就是对目前不支持的语法进行处理，比如注释掉，只要处理后不影响数据血缘就可以了。

接进来就是对各个解析出来的Statement进行处理，SQL的Statement有很多种，有用的就是Create Table / Insert / Select这三类。当然在执行过程中还需要对Drop Table进行处理，临时表可以看成是临时的变量，不会对整个过程有什么影响，所以在血缘关系中会隐藏掉，将它的血缘直接传递过去即可。

无论是哪种Statement生成的数据，最终都会落到QueryStatement上，对Query的解析才是重头戏。其中一个细节就是在语法树的处理顺序上。From是源头，所以需要先解析它。它可能多种源组成，比如：实体表、子查询、JOIN、甚至是由lateral view等抽象出来的。From节点可能解析出多个源头（一般会指定别名）然后交给Where节点进行筛选。Where / Group By / Sort By是对所有的字段起作用的，所在这些节点上出现的字段都归为全局依赖。

（项目模块截图，模块化设计，可以更好扩展）

hook是使用端插件，比如hive hook实现，用于上报执行过程的SQL，用于采集数据使用情况，超出了本文的内容，会在后续文章中介绍

lineage-api：dubbo客户端协议定义，是对外提供的协议包

lineage-server：dubbo服务端，对外暴露了dubbo和RESTful两类接口

定义了个简单的接口，解析的结果除了血缘关系数据外，还包含了一些脚本规范、错误、引入的jar包、变量等信息，主要是在DwOps发布系统中使用。为了确保项目质量，每类脚本都写了一组单元测试，确保每次迭代不会影响到核心功能。

（单元测试截图，右侧是到字段级别的血缘关系数据）

（关键表设计，只包含关键的字段，非全部字段）

表设计上，分为两大块，浅黄色部分是数据血缘的表，可以随时清空，从源码中重新构建。白色部分是数据字典的表，是平时维护的信息，不可再生。如此设计主要也是为了更好的迭代血缘关系，部分表可以比较无压力的删了重建。

4. 查询性能
吸取Apache Atlas的教训，在接口性能优化上做了精心设计，确保在所有的查询中可以瞬间返回数据。事实证明，仅此一项，大家都觉得这是一次成功的重造轮子

一张表完整的血缘关系可能会很复杂，关联上的表可达上百张，如果使用传统的存储/缓存（redis），这么多的查询也会消耗不少的时间。所以最好的选择是使用内存缓存！对于静态数据来说，其它实现不是很复杂。但是对于多节点部署的动态变更的数据，情况就复杂很多了。

我们使用了Hazelcast实现了内存缓存，具体使用可以查询官网。这里大概说下Hazelcast的能力：

分布式内存缓存，它的内置机制实现了数据变更时的同步，不需要我们额外去实现
实现了分布式队列。这个特性，本项目没有用到，但在duo-schedule中大量使用
实现了分布式锁，在更新血缘关系时使用到
系统启动时，从数据库中加载数据，将每张表的直接上游、下游关系数据保存到内存Map中。在查询血缘关系时，直接在内存里递归遍历依赖的表，构建完整的血缘关系图。注意这里需要特殊处理下循环依赖的表，避免出现死循环。

经过这一设计，表血缘关系响应几乎可以在10ms内返回。