阳江城乡建设部网站首页,广东工厂网站建设,linux有wordpress,wordpress文章模板代码元数据管理实践数据血缘
什么是元数据#xff1f;元数据MetaData狭义的解释是用来描述数据的数据#xff0c;广义的来看#xff0c;除了业务逻辑直接读写处理的那些业务数据#xff0c;所有其它用来维持整个系统运转所需的信息#xff0f;数据都可以叫作元数据。比如…元数据管理实践数据血缘
什么是元数据元数据MetaData狭义的解释是用来描述数据的数据广义的来看除了业务逻辑直接读写处理的那些业务数据所有其它用来维持整个系统运转所需的信息数据都可以叫作元数据。比如数据表格的Schema信息任务的血缘关系用户和脚本任务的权限映射关系信息等等。
管理这些附加MetaData信息的目的一方面是为了让用户能够更高效的挖掘和使用数据另一方面是为了让平台管理人员能更加有效的做好系统的维护管理工作。
出发点很好但通常这些元数据信息是散落在平台的各个系统各种流程之中的而它们的管理也可能或多或少可以通过各种子系统自身的工具方案或流程逻辑来实现。那么我们所说的元数据管理平台又是用来做什么的是不是所有的信息都应该或者有必要收集到一个系统中来进行统一管理呢具体又有哪些数据应该被纳入到元数据管理平台的管理范围之中呢下面我们就来探讨一下相关的内容。
一、元数据管理平台管什么
数据治理的第一步就是收集信息很明显没有数据就无从分析也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集至于收集哪些信息取决于业务的需求和我们需要解决的目标问题。
信息收集再多如果不能发挥作用那也就只是浪费存储空间而已。所以元数据管理平台还需要考虑如何以恰当的形式对这些元数据信息进行展示进一步的如何将这些元数据信息通过服务的形式提供给周边上下游系统使用真正帮助大数据平台完成质量管理的闭环工作。
应该收集那些信息虽然没有绝对的标准但是对大数据开发平台来说常见的元数据信息包括 数据的表结构Schema信息 数据的空间存储读写记录权限归属和其它各类统计信息 数据的血缘关系信息 数据的业务属性信息
下面我们针对这四项内容再具体展开讨论一下
1.1 数据的表结构Schema信息
数据的表结构信息这个很容易理解了狭义的元数据信息通常多半指的就是这部分内容了它也的确属于元数据信息管理系统中最重要的一块内容。
不过无论是SQL还是NoSQL的数据存储组件多半自身都有管理和查询表格Schema的能力这也很好理解如果没有这些能力的话这些系统自身就没法良好的运转下去了不是。比如Hive自身的表结构信息本来就存储在外部DB数据库中Hive也提供类似 show tabledescribe table之类的语法对这些信息进行查询。那么我们为什么还要多此一举再开发一个元数据管理系统对这些信息进行管理呢
这么做可能的理由很多需要集中管理可以是其中一个理由但更重要的理由是因为本质上这些系统自身的元数据信息管理手段通常都是为了满足系统自身的功能运转而设计的。也就是说它们并不是为了数据质量管理的目的而存在的由于需求定位不同所以无论从功能形态还是从交互手段的角度来说它们通常也就无法直接满足数据质量管理的需求。
举个很简单的例子比如我想知道表结构的历史变迁记录很显然多数系统自身是不会设计这样的功能的。而且一些功能就算有周边上下游的其它业务系统往往也不适合直接从该系统中获取这类信息因为如果那样做的话系统的安全性和相互直接的依赖耦合往往都会是个问题。
所以收集表结构信息不光是简单的信息汇总更重要的是从平台管理和业务需求的角度出发来考虑如何整理和归纳数据方便系统集成实现最终的业务价值。
1.2 数据的存储空间读写记录权限归属和其它各类统计信息
这类信息可能包括但不限于数据占据了多少底层存储空间最近是否有过修改都有谁在什么时候使用过这些数据谁有权限管理和查阅这些数据等等。此外还可以包括类似昨天新增了多少个表格删除了多少表格创建了多少分区之类的统计信息。
在正常的工作流程中多数人可能不需要也不会去关心这类信息。但是落到数据质量管理这个话题上时这些信息对于系统和业务的优化数据的安全管控问题的排查等工作来说又往往都是不可或缺的重要信息所以通常这类信息也可以从Audit审计的角度来归类看待。
与表结构信息类似对于这类Audit审计类信息的采集和管理通常具体的底层数据存储管理组件自身的功能也无法直接满足我们的需求需要通过专门的元数据管理平台中统一进行采集加工和管理。
1.3 数据的血缘关系信息
血缘信息或者叫做Lineage的血统信息是什么简单的说就是数据之间的上下游来源去向关系数据从哪里来到哪里去。知道这个信息有什么用呢用途很广举个最简单的例子来说如果一个数据有问题你可以根据血缘关系往上游排查看看到底在哪个环节出了问题。此外我们也可以通过数据的血缘关系建立起生产这些数据的任务之间的依赖关系进而辅助调度系统的工作调度或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。
分析数据的血缘关系看起来简单但真的要做起来并不容易因为数据的来源多种多样加工数据的手段所使用的计算框架可能也各不相同此外也不是所有的系统天生都具备获取相关信息的能力。而针对不同的系统血缘关系具体能够分析到的粒度可能也不一样有些能做到表级别有些甚至可以做到字段级别。
以hive表为例通过分析hive脚本的执行计划是可以做到相对精确的定位出字段级别的数据血缘关系的。而如果是一个MapReduce任务生成的数据从外部来看可能就只能通过分析MR任务输出的Log日志信息来粗略判断目录级别的读写关系从而间接推导数据的血缘依赖关系了。
1.4 数据的业务属性信息
前面三类信息一定程度上都可以通过技术手段从底层系统自身所拥有的信息中获取得到又或着可以通过一定的流程二次加工分析得到。与之相反数据的业务属性信息通常与底层系统自身的运行逻辑无关多半就需要通过其他手段从外部获取了。
那么业务属性信息都有哪些呢最常见的比如一张数据表的统计口径信息这张表干什么用的各个字段的具体统计方式业务描述业务标签脚本逻辑的历史变迁记录变迁原因等等此外你也可能会关心对应的数据表格是由谁负责开发的具体数据的业务部门归属等等。
上述信息如果全部需要依靠数据开发者的自觉填写不是不行但是显然不太靠谱。毕竟对于多数同学来说对于完成数据开发工作核心链路以外的工作量很自然的反应就是能不做就不做越省事越好。如果没有流程体系的规范如果没有产生实际的价值那么相关信息的填写很容易就会成为一个负担或者是流于形式。
所以尽管这部分信息往往需要通过外部手段人工录入但是还是需要尽量考虑和流程进行整合让它们成为业务开发必不可少的环节。比如一部分信息的采集可以通过整体数据平台的开发流程规范嵌入到对应数据的开发过程中进行例如历史变迁记录可以在修改任务脚本或者表格schema时强制要求填写业务负责人信息可以通过当前开发人员的业务线和开发群组归属关系自动进行映射填充字段统计方式信息尽可能通过标准的维度指标管理体系进行规范定义。
总体来说数据的业务属性信息必然首先是为业务服务的因此它的采集和展示也就需要尽可能的和业务环境相融合只有这样才能真正发挥这部分元数据信息的作用。
1.5 元数据分类
数据治理元数据管理 、数据血缘
技术元数据包括英文字段字段名称、字段长度、数据库表结构等。
业务元数据包括中文意思业务名称、业务定义、业务描述等。
技术元数据为开发和管理数据仓库的IT 人员使用它描述了与数据仓库开发、管理和维护相关的数据包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。
业务元数据为管理层和业务分析人员服务从业务角度描述数据包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
1.5.1 业务元数据
业务元数据主要描述 ”数据”背后的业务含义从业务角度描述业务领域的相关概念、关系——包括业务术语和业务规则。
业务人员更多关注的是与“客户”、“结算日期”、“销售金额”等相关的内容这些内容很难从技术元数据中体现出来。 业务元数据使用业务名称、定义、描述等信息表示企业环境中的各种属性和概念从一定程度上讲所有数据背后的业务上下文都可以看成是业务元数据。
业务元数据能让用户更好地理解和使用企业环境中的数据比如用户通过查看业务元数据就可以清晰地理解各指标的含义指标的计算方法等信息。
业务元数据广泛存在于企业环境中业务元数据的来源主要有 ERP企业ERP系统中存储着大量的业务元数据比如说财务计算公式、过程逻辑、业务规则等。 报表报表的表头也是一种业务元数据特别是那些包含合计、平均数等带有总结性质的列报表中的一些计算公式等。 表格与报表类似EXCEL的表头和公式也是很重要的业务元数据。与报表不同的是大多数表格中会有单独一列“描述”有些表格中还会有一列代码和代码描述这些都是很有用的业务元数据。 文件文件中到处都是业务元数据比如标题、作者、修改时间等文件内容中的业务元数据的获取相对比较困难涉及到机器学习等技术。 BI工具BI中经常会用到的操作就是“钻取”操作向上和向下钻取中通常定义了企业的各种分类结构例如产品等级和组织结构等级等这些都是很重要的业务元数据。 数据仓库数据仓库中也有业务元数据存在比如说构建数据仓库之前通常需要做大量调研来研究如何集成多个数据源这些如数据仓库构建过程相关的文件中存在着大量的业务元数据。
下图是两个具体的例子
某建筑公司的一张报表我们可以看到报表中包含了报表名称、填报时间、制表人和报表表头名称等这些都是高价值的业务元数据某公司新员工入职申请表和报表类似申请表名称、姓名、性别等申请表各栏名称都是业务元数据。
目前大部分企业只关注到了技术元数据忽略了对业务元数据的管理。技术元数据缺少业务含义很难被技术人员之外的人所理解比如可能用“rec_temp_fld_a”表示某个字段用“236IN_TAB”表示数据库中的某张表在不被理解的情况下很难给企业业务带来收益。业务元数据能代表数据背后的业务含义企业在对技术元数据管理的同时需要注重业务元数据的管理。
主题定义每段 ETL、表背后的归属业务主题。
业务描述每段代码实现的具体业务逻辑。
标准指标类似于 BI 中的语义层、数仓中的一致性事实将分析中的指标进行规范化。
标准维度同标准指标对分析的各维度定义实现规范化、标准化。
业务元数据在实际业务中需要不断的进行维护且与业务方进行沟通确认。
1.5.2 技术元数据
指技术细节相关的概念、关系和规则包括对数据结构、数据处理方面的描述。以及数据仓库、ETL、前端展现等技术细节的信息。
数据仓库中的技术元数据一般包含以下 4 大系统数据源元数据ETL 元数据数据仓库元数据BI 元数据。
数据源元数据
例如数据源的 IP、端口、数据库类型数据获取的方式数据存储的结构原数据各列的定义及 key 指对应的值。
ETL 元数据
根据 ETL 目的的不同可以分为两类数据清洗元数据数据处理元数据。
数据清洗元数据
数据清洗主要目的是为了解决掉脏数据及规范数据格式
因此此处元数据主要为各表各列的正确数据规则默认数据类型的正确规则。
数据处理元数据
数据处理例如常见的表输入表输出非结构化数据结构化特殊字段的拆分等。
源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
数据仓库元数据
数据仓库结构的描述包括仓库模式、视图、维、层次结构及数据集市的位置和内容
业务系统、数据仓库和数据集市的体系结构和模式等。
BI 元数据
汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。
1.6 元数据管理
1.元数据自动采集、动态感知版本差异标记
2.元数据血缘、影响、全链路关系自动探索图形化展现 1.7 元数据管理平台架构
元数据管理平台从应用层面可以分类元数据采集服务应用开发支持服务元数据访问服务、元数据管理服务和元数据分析服务。 1.7.1 元数据采集服务
在数据治理项目中通常涉及到的元数据还包括数据源的元数据数据加工处理过程的元数据数据仓库或数据主题库的元数据数据应用层的元数据数据接口服务的元数据等等。元数据采集服务提供各类适配器满足以上各类元数据的采集并将元数据整合处理后统一存储于中央元数据仓库实现元数据的统一管理。这个过程中数据采集适配器十分重要元数据采集要能够适配各种DB、各类ETL、各类DW和Report产品同时还需要适配各类结构化或半结构化数据源。目前市场上的主流元数据产品还没有哪一家能做到“万能适配”都需要在实际应用过程中做或多或少的定制化开发。
1.7.2 元模型驱动的设计与开发
通过元数据管理平台实现对应用的逻辑模型、物理模型、UI模型等各类元模型管理支撑应用的设计和开发。应用开发的元模型有三个状态分别是设计态的元数据模型通常由ERWin、PowerDesigner的等设计工具产生。测试态的元数据模型通常是关系型数据Oracle、DB2、Mysql、Teradata等或非关系型数据库MongDB、HBase、Hive、Hadoop等。生产态的元模型本质上与测试态元数据差异不大。通过元数据平台对应用开发三种状态的统一管理和对比分析能够有效降低元数据变更带来的风险为下游ODS、DW的数据应用提供支撑。另外基于元数据的MDD代码生成服务可以通过模型元数据完成业务对象元数据到UI元数据的关联和转换自动生成相关代码表单界面减少了开发人员的设计和编码量提升应用和服务的开发效率。 1.7.3 元数据管理服务
市场上主流的元数据管理产品基本都包括元数据查询、元模型管理、元数据维护、元数据版本管理、元数据对比分析、元数据适配器、元数据同步管理、元数据生命周期管理等功能。此类功能各家产品大同小异
1.7.4 元数据访问服务
元数据访问服务是元数据管理软件提供的元数据访问的接口服务一般支持REST或Webservice等接口协议。通过元数据访问服务支持企业元数据的共享是企业数据治理的基础。
1.7.5 元数据分析服务即元数据管理的意义 1、血缘分析是告诉你数据来自哪里都经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系追根溯源快速地定位到问题数据的来源和加工过程减少数据问题排查分析的时间和难度。这个功能常用于数据分析发现数据问题时快速定位和找到数据问题的原因。
血缘分析是一种技术手段用于对数据处理过程的全面追踪从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。元数据对象之间的关系特指表示这些元数据对象的数据流输入输出关系。
在元数据管理系统成型后我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。
2、影响分析是告诉你数据都去了哪里经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系向下追踪快速找到都哪些应用或数据库使用了这个数据从而避免或降低数据问题带来的更大的影响。这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用应用的影响分析。
在开发中我们经常会遇到以下问题如果我要改动某个表、ETL会造成怎样的影响
如果没有元数据那我们可能需要遍历所有的脚本、数据。才能得到想要的答案而如果有成熟的元数据管理那我们就可以直接得到答案节省大量时间。
3、冷热度分析是告诉你哪些数据是企业常用数据哪些数据属于“僵死数据”。其价值在于让数据活跃程度可视化让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度以便更好的驾驭数据激活或处置“僵死数据”从而为实现数据的自助式分析提供支撑。
4、关联度分析是告诉你数据和其他数据的关系以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况形成一张实体和所参与处理过程的网络从而进一步了解该实体的重要程度如表与ETL 程序、表与分析应用、表与其他表的关联情况等。本功能可以用来支撑需求变更的影响评估。
5、数据资产地图是告诉你有哪些数据在哪里可以找到这些数据能用这些数据干什么。通过元数据可以对企业数据进行完整的梳理、采集和整合从而形成企业完整的数据资产地图。数据资产地图支持以拓扑图的形式进行可视化展示各类元数据和数据处理过程通过不同层次的图形展现粒度控制满足业务上不同应用场景的数据查询和辅助分析需要。
1.7.6 ETL 自动化管理
在数仓中很大一部分 ETL 都是枯燥重复的步骤。
例如源系统-ODS 层的表输入——表输出。
又比如 ODS-DWSQL 输入——数据清洗——数据处理——表输出。
以上的规则其实就属于一部分元数据。
那理论上完全可以实现写好固定脚本然后通过前端选择——或 api 接口。
进而对重复的 ETL 实现自动化管理降低 ETL 开发的时间成本。
1.7.7 数据安全管理
在阿里推崇的数据中台中一切数据接口指标都会从数据仓库中出口。因此理论上我们只需在此处的元数据中对管理元数据的权限进行配置即可实现全公司的数据安全管理。
二、元数据管理相关系统方案介绍
元数据血缘技术调研 2.1 Apache Atlas
社区中开源的元数据管理系统方案常见的比如Hortonworks主推的Apache Atlas它的基本架构思想如下图所示 Atlas的架构方案应该说相当典型基本上这类系统大致都会由元数据的收集存储和查询展示三部分核心组件组成。此外还会有一个管理后台对整体元数据的采集流程以及元数据格式定义和服务的部署等各项内容进行配置管理。
对应到Atlas的实现上Atlas通过各种hook/bridge插件来采集几种数据源的元数据信息通过一套自定义的Type 体系来定义元数据信息的格式通过搜索引擎对元数据进行全文索引和条件检索除了自带的UI控制台意外Atlas还可以通过Rest API的形式对外提供服务。
Atlas的整体设计侧重于数据血缘关系的采集以及表格维度的基本信息和业务属性信息的管理。为了这个目的Atlas设计了一套通用的Type体系来描述这些信息。主要的Type基础类型包括DataSet和Process前者用来描述各种数据源本身后者用来描述一个数据处理的流程比如一个ETL任务。
Atlas现有的Bridge实现从数据源的角度来看主要覆盖了HiveHBaseHDFS和Kafka此外还有适配于Sqoop, Storm和Falcon的Bridge不过这三者更多的是从Process的角度入手最后落地的数据源还是上述四种数据源。
具体Bridge的实现多半是通过上述底层存储计算引擎各自流程中的Hook机制来实现的比如Hive SQL的Post Execute HookHBase的Coprocessor等而采集到的数据则通过Kafka消息队列传输给Atlas Server或者其它订阅者进行消费。
在业务信息管理方面Atlas通过用户自定义Type 属性信息的方式让用户可以实现数据的业务信息填写或者对数据打标签等操作便于后续对数据进行定向过滤检索。
最后Atlas可以和Ranger配套使用允许Ranger通过Atlas中用户自定义的数据标签的形式来对数据进行动态授权管理工作相对于基于路径或者表名/文件名的形式进行静态授权的方式这种基于标签的方式有时候可以更加灵活的处理一些特定场景下的权限管理工作。
总体而言Atlas的实现从结构原理的角度来说还算是比较合理的但从现阶段来看Atlas的具体实现还比较粗糙很多功能也是处于可用但并不完善的状态。此外Atlas在数据审计环节做的工作也不多与整体数据业务流程的集成应用方面的能力也很有限。Atlas项目本身很长时间也都处于Incubator状态因此还需要大家一起多努力来帮助它的改进。
2.1.1 表级别的血缘关系
如果只是到表级别这个实现比较简单像hive tool就自带了一个工具类可以直接获得 2.2 DataHub
2.3 整体对比
1、没有哪一款开源产品能直接达到我们的需求必须得针对或多或少的改造、扩展才行
2、Atlas的UI感觉其实是比较简单的如果要做二次开发感觉是最容易的(只用它的数据模型和API不用它的页面UI)
3、Atlas通过hook的方式可以实时收集元数据这是它的优势但是针对我们的场景hive表的元数据其实是在动态变化的用这种方式可能反而不太好
4、Datahub感觉是整体比较完整的一个产品支持的数据源也很多设计上是支持自定义扩展的重点是产品交互设计等能否达到我们的要求后期又要做多少修改
2.4 总结和问题
想把整个链路的数据血缘打通避免不了自己去针对某个链路进行数据解析和采集所以必须选择一款扩展性强的产品 首先应该搞清楚一个问题我们究竟想要做成一个怎样的产品
是一个仅仅供内部使用主要为了解决日常痛点交互体验差一点也可以容忍
还是想做成一个成熟的可以商业化的产品
具体的方案设计应该结合产品需求以及研发能力来综合考虑
大概有三种做法
1、完全自研
能做到最大的灵活性和体验产品高度适配业务但是有较高的研发成本投入要求高
2、使用开源产品扩展功能
产品体验受限于开源产品本身有些功能能否实现也主要看开源产品本身是否支持扩展
3、基于开源产品做二次开发
产品设计还是不能和开源产品相差太远不然就没有太大意义了。
而且对开发的能力要求是比较高的需要深入了解开源产品的架构设计和编码实现 可以结合1、2、3比如后端部分使用开源前端UI交互自己开发
个人觉得比较可行的方案
1、后端存储选用AtlasUI完全自己开发血缘这块交互比较复杂的可以拷贝代码复用Atlas不支持的元数据和血缘的采集也自己开发扩展
2、前后端都使用datahub做少量二次开发不支持的元数据和血缘的采集自己开发扩展
三、数据血缘
数据治理一自研血缘关系
3.1 数据血缘的作用与表现形式
2022数据血缘关系详解
3.1.1 数据血缘的作用
开篇的场景中的案例是数据血缘的两个典型的作用总结成一句话就是数据血缘可以帮助数据生产者以及消费者更好地对数据进行追根溯源提升数据运维、数据治理的效率。
(1)提升数据问题排查效率
数据从生产到赋能业务应用经过很多的处理环节业务端报表或数据应用服务异常时需要第一时间定位问题排查修复。
如果靠一层一层的人肉翻代码效率非常低下一方面数据开发人力花费在排查上另一方面定位问题时间越长业务影响和损失越大基于血缘数据加以可视化的展现形式可以直观地发现数据生产链路以及各个环节有无异常。
(2)有助于优化数据资产成本
随着业务地发展数据不断增长任务、数据表只增不减会不断膨胀大数据资源成本。很多时候不是不愿意做数据、服务治理二是不敢。
也就是不知道对应的服务有哪些业务在使用缺少治理的依据与其直接下线带来业务影响倒不如一直维持现状。构建全面准确的全链路数据血缘就可以找出数据下游应用方做好沟通和信息同步长期没有调用的服务及时做下线处理节省数据成本。
(3)提升数据产品及应用体验
数据部门经常被业务Diss数据是不是有问题长此以往会降低业务对数据准确度的信任搞数据的天天被打上数据不准的标签还是很无奈的。
在数据产出任务层面对数据质量的准确性、一致性、及时性、完整性等维度进行监控覆盖触发报警机制后利用数据血缘关系对下游应用进行通知提醒。业务看到后至少知道数据部门在处理问题了不会利用错的数据做错误的决策或者形成每次都是业务先发现问题的认知。
(4)方便确认数据处理逻辑
业务部门在使用数据时有时候需要确认数据口径和加工逻辑是什么是否符合自己的需求通过血缘的可视化展示可以方便业务部门查看数据的处理过程。
3.1.2 血缘的表现形式
每个数据表、字段、指标都可以认为是一个数据实体而生产它的上游以及使用它的下游都是对应的数据实体之间的关系因此在血缘数据的可视化展示时主要采用可以直观表示数据生产链路的形态每个节点需要包含以下要素
当前节点信息名称、类型、状态
上游关系、上游名称、类型、状态
下游关系、上游名称、类型、状态 3.2 字段血缘分析的意义
通过元数据以企业全局视角对企业各业务域的数据资产进行盘点实现企业数据资源的统一梳理和盘查有助于发现分布在不同系统、位置或个人电脑的数据让隐匿的数据显性化。数据地图包括了数据资源的基本信息存储位置信息、数据结构信息、各数据之间关系信息数据和人之间的关系信息数据使用情况信息等使数据资源信息详细、统一、透明降低“找数据”的沟通成本为数据的使用和大数据挖掘提供支撑。
数仓经常会碰到的两类问题
1、两个数据报表进行对比结果差异很大需要人工核对分析指标的维度信息比如从头分析数据指标从哪里来处理条件是什么最后才能分析出问题原因 ——数据回溯问题
2、基础数据表因某种原因需要修改字段需要评估其对数仓的影响费时费力然后在做方案 —— 影响分析问题
追根溯源发现数据问题本质
企业在做数据分析的时候数据分析结果不正确原因可能是数据分析过程出现数据问题也可能是数据源本身就有问题还可能是数据在加工处理过程中出现了数据问题……。通过元数据血缘分析能够快速定位数据来源和加工处理过程能够帮助数据分析人员快速定位数据问题。另外通过元数据血缘关系分析可以理解不同数据指标间的关系分析产生指标的数据源头波动情况带来的影响。
模型驱动敏捷开发
基于元数据模型的数据应用规划、设计和开发是企业数据应用的一个高级阶段。当企业元数据管理达到一定水平实现自动化管理的时候企业中各类数据实体模型、数据关系模型、数据服务模型、数据应用模型的元数据统一在元数据平台进行管理并自动更新数据间的关联关系。基于元数据、可扩展的MDA才是快速满足企业数据应用个性化定制需求的最好解决方案。通过将大量的业务进行模型抽象使用元数据进行业务描述并通过相应的模型驱动引擎在运行时驱动使用高度抽象的领域业务模型作为构件完成代码转换动态生成相关代码降低开发成本应对复杂需求变更。
这两类问题都属于数据血缘分析问题数据血缘分析还有其它的积极意义比如
问题定位分析
类似于影响分析当程序运行出错时可以方便找到问题的节点并判断出问题的原因以及后续的影响
指标波动分析
当某个指标出现较大的波动时可进行溯源分析判断是由哪条数据发生变化所导致的
数据体检
判定系统和数据的健康情况是否存在大量的冗余数据、无效数据、无来源数据、重复计算、系统资源浪费等问题
数据评估
通过血缘分析和元数据可以从数据的集中度、分布、冗余度、数据热度、重要性等多角度进行评估分析从而初步判断数据的价值
3.3 构建血缘的方案
方案一只收集SQL事后分析。
当SQL执行结束收集SQL到DB或者Kafka。
优点当计算引擎和工具不多的时候语法相对兼容的时候用Hive自带的LineageLogger重新解析SQL可以获得表和字段级别的关系。
缺点重放SQL的时候可能元数据发生改变比如临时表可能被Drop没有临时自定义函数UDF或者SQL解析失败。
方案二运行时分析SQL并收集。
当SQL执行结束后立即分析Lineage异步发送到Kafka。
优点运行时的状态和信息是最准确的不会有SQL解析语法错误。
缺点需要针对各个引擎和工具开发解析模块解析速度需要足够快。
3.4 携程方案
携程采用了方案二运行时分析SQL并收集分析结果到Kafka。由于开源方案在现阶段不满足需求则自行开发。
由于当时缺少血缘关系对数据治理难度较大表级别的血缘解析难度较低表的数量远小于字段的数量早期先快速实现了表级别版本。
在16-17年实现和上线了第一个版本收集常用的工具和引擎的表级别的血缘关系T1构建关系。
在19年迭代了第二个版本支持解析HiveSparkPresto多个查询引擎和DataX传输工具的字段级别血缘关系近实时构建关系。
3.4.1 第一个版本-表级别血缘关系
针对Hive引擎开发了一个Hook实现ExecuteWithHookContext接口从HookContext可以获得执行计划输入表输出表等丰富信息异步发送到Kafka部署的时候在hive.exec.post.hooks添加插件即可。
在17年引入Spark2后大部分Hive作业迁移到Spark引擎上这时候针对Spark SQL CLI快速开发一个类似Hive Hook机制收集表级别的血缘关系。
传输工具DataX作为一个异构数据源同步的工具单独对其开发了收集插件。
在经过解析处理后将数据写到图数据库Neo4j提供元数据系统展示和REST API服务落地成Hive关系表供用户查询和治理使用。 在元数据系统上可以查看一张表多层级的上下游血缘关系在关系边上会有任务ID等一些属性。 随着计算引擎的增加业务的增长表级别的血缘关系已经不满足需求。
覆盖面不足缺少Spark ThriftServer , Presto引擎缺少即席查询平台报表平台等。
关系不够实时期望写入表后可以快速查询到关系用户可以直观查看输入和输出数据质量系统调度系统可以根据任务ID查询到输出表对表执行质量校验任务。
图数据库Neo4j社区版为单机版本存储数量有限稳定性欠佳当时使用的版本较低对边不能使用索引(3.5支持)这使得想从关系搜索到关联的上下游较为麻烦。
3.4.2 第二版本-字段级别血缘关系
之前实现的第一个版本对于细粒度的治理和追踪还不够不仅缺少对字段级别的血缘关系也不支持采集各个系统的埋点信息和自定义扩展属性难以追踪完整链路来源并且关系是T1不够实时。
针对各个计算引擎和传输工具DataX开发不同的解析插件将解析好的血缘数据发送到Kafka实时消费Kafka把关系数据写到分布式图数据JanusGraph。 阿里开源的Druid是一个 JDBC 组件库包含数据库连接池、SQL Parser 等组件。通过重写MySqlASTVisitor、SQLServerASTVisitor来解析MySQL / SQLServer的查询SQL获得列级别的关系。
计算引擎统一格式收集输入表、输出表输入字段、输出字段流转的表达式等一些信息。 3.5 自研血缘关系
数据治理一自研血缘关系
数据血缘也称为数据血统或谱系是来描述数据的来源和派生关系。数据来源是数据科学的关键也是被公认为数据信任的核心的部分。说白了就是这个数据是怎么来的经过了哪些过程或阶段从哪些表哪些字段计算得来的。
桑基图是血缘关系的一种表达图表图表使用ECharts绘制。
附录A
A.1 数据血缘相关案例
携程数据血缘构建及应用搜狐 Hive SQL 血缘关系解析与应用顺丰 基于 Hook 机制实现数据血缘系统字节跳动数据血缘图谱升级方案设计与实现
