干货 | 携程数据血缘构建及应用

作者简介

 

cxzl25，携程软件技术专家，关注大数据领域生态建设，对分布式计算和存储、调度等方面有浓厚兴趣。

一、前言

Data lineage includes the data origin, what happens to it and where it moves over time. Data lineage gives visibility while greatly simplifying the ability to trace errors back to the root cause in a data analytics process. ──百科Data lineage

大数据时代，数据的来源极其广泛，各种类型的数据在快速产生，数据也是爆发性增长。从数据的产生，通过加工融合流转产生新的数据，到最终消亡，数据之间的关联关系可以称之为数据血缘关系。

数据血缘是元数据管理、数据治理、数据质量的重要一环，追踪数据的来源、处理、出处，对数据价值评估提供依据，描述源数据流程、表、报表、即席查询之间的流向关系，表与表的依赖关系、表与离线ETL任务，调度平台，计算引擎之间的依赖关系。数据仓库是构建在Hive之上，而Hive的原始数据往往来自于生产DB，也会把计算结果导出到外部存储，异构数据源的表之间是有血缘关系的。

数据血缘用途：

• 追踪数据溯源：当数据发生异常，帮助追踪到异常发生的原因；影响面分析，追踪数据的来源，追踪数据处理过程。

• 评估数据价值：从数据受众、更新量级、更新频次等几个方面给数据价值的评估提供依据。

• 生命周期：直观地得到数据整个生命周期，为数据治理提供依据。

• 安全管控：对源头打上敏感等级标签后，传递敏感等级标签到下游。

本文介绍携程数据血缘如何构建及应用场景。第一版T+1构建Hive引擎的表级别的血缘关系，第二版近实时构建Hive，Spark，Presto多个查询引擎和DataX传输工具的字段级别血缘关系。

二、构建血缘的方案

2.1 收集方式

方案一：只收集SQL，事后分析。

当SQL执行结束，收集SQL到DB或者Kafka。

优点：当计算引擎和工具不多的时候，语法相对兼容的时候，用Hive自带的LineageLogger重新解析SQL可以获得表和字段级别的关系。

缺点：重放SQL的时候可能元数据发生改变，比如临时表可能被Drop，没有临时自定义函数UDF，或者SQL解析失败。

方案二：运行时分析SQL并收集。

当SQL执行结束后立即分析Lineage，异步发送到Kafka。

优点：运行时的状态和信息是最准确的，不会有SQL解析语法错误。

缺点：需要针对各个引擎和工具开发解析模块，解析速度需要足够快。

2.2 开源方案

Apache Atlas

Apache Atlas是Hadoop社区为解决Hadoop生态系统的元数据治理问题而产生的开源项目，它为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。官方插件支持HBase、Hive、Sqoop、Storm、Storm、Kafka、Falcon组件。

Hook在运行时采集血缘数据，发送到Kafka。Atlas消费Kafka数据，将关系写到图数据库JanusGraph，并提供REST API。

其中Hive Hook支持表和列级别血缘，Spark需要使用GitHub的hortonworks-spark/spark-atlas-connector，不支持列级别，Presto则不支持。

Linkedin DataHub

WhereHows项目已于2018年重新被LinkedIn公司设计为DataHub项目。它从不同的源系统中采集元数据，并进行标准化和建模，从而作为元数据仓库完成血缘分析。

社区提供了一个Demo，演示地址：https://demo.datahubproject.io/

与Airflow集成较好，支持数据集级别血缘，字段级别在2021Q3的Roadmap。