元数据采集 hbase 元数据采集与血缘分析

转载

mob6454cc79ab13 2024-01-25 22:21:36

文章标签 元数据采集 hbase 数据库元数据数据元模型 文章分类 Hbase 数据库

一、元数据定义

元数据是用来描述数据的数据。它可理解为比一般意义的数据范畴更加广泛的数据，不再仅仅表示数据的类型、名称、值等信息，它可以进一步提供数据的上下文描述信息，比如数据的所属域、取值范围、数据间的关系、业务规则，甚至是数据的来源。

元数据可以帮助DW管理员和DW开发人员非常方便地找到他们所关心的数据。

元数据相当于数据的DNA，它可以告诉你，有用的数据在哪里，能提供一份数据结构定义和元素的详细示意图，数据来龙去脉、关系，使应用开发过程更有效，提供数据的参照性、引用性、血缘分析、影响分析、变化分析……

例如：元数据是传染病所有病例的“目录”，这个“目录”包含感染病例姓名、编号、所患传染病名称、就医时间、出现症状时间等信息，有了它，管理员就能快速查找病例。

按照不同领域和功能，元数据一般来说可分为：技术元数据、业务元数据、操作元数据、管理元数据。

1、技术元数据

技术元数据是用于开发和日常管理数据仓库时用的数据。它作为数据的结构化，能够方便计算机、数据库对数据进行识别、存储、传输和交换。

对开发人员来说，它有助于明确数据的存储、结构，为应用开发和系统集成打牢基础；对业务人员来说，它有助于理清数据关系，从而能够更加快速地找到想要的数据，进而对数据的来源和去向进行分析，支持数据血缘追溯和影响分析。

常见的技术元数据：

物理数据库表名称、列名称、字段长度、字段类型、约束信息、数据依赖关系等；
数据存储类型、位置、数据存储文件格式或数据压缩类型等；
字段级血缘关系、SQL脚本信息、ETL抽取加载转换信息、接口程序等；
调度依赖关系、进度和数据更新频率等。

2、业务元数据

业务元数据描述的对象，是数据的业务含义、业务规则等。通过对业务元数据的明确，人们对它的理解和使用会变得更加容易。元数据使得数据的二义性不复存在，人们对数据含义能够产生一致的认知，避免了“自说自话”的情况，进而为数据分析和应用提供支撑。

常见的业务元数据：

业务定义、业务术语解释等；
业务指标名称、计算口径、衍生指标等；
业务规则引擎的规则、数据质量检测规则、数据挖掘算法等；
数据的安全或敏感级别等。

3、操作元数据

操作元数据描述了数据的操作属性，比如管理部门、管理责任人等。数据操作属性的明确，有助于将数据管理责任落实到部门和个人，是数据安全管理的基础条件。

常见的操作元数据：

数据所有者、使用者等；
数据的访问方式、访问时间、访问限制等；
数据访问权限、组和角色等；
数据处理作业的结果、系统执行日志等；
数据备份、归档人、归档时间等。

4、管理元数据

管理元数据包含了数据管理的信息在其中，例如：表的业务属主、表的技术负责人。

常见的管理元数据：

数据的来源；
数据的功用；
数据的负责人；
数据的价值体现等。

元数据既然是一种数据，就需要某种具体的语法和语义规则，来对元数据的值进行规范。元数据语法是指构建元数据的字段或元素过程应该遵守的规则。一般建议的规则是“主语-谓词-对象”的三元组，或者是“类-属性-值”的三元组。

示例：比如 40 这个数字，它在特定场景下，有如下的元数据：

元数据	数据类型	数据内容
业务元数据	数据值	40
	单位	℃
	指标	体温
	统计时间	2022年
	区域范围	全国
	人群范围	登革热患者发热期24H内平均体温
	阈值	35-50
技术元数据	数据库类型	MySQL
	数据库链接	jdbc:mysql://xxxxxx
	数据库名	xxx
	表名	data_diseases
	主键	ID
操作元数据	创建人	张三
	创建时间	2022-10-22 09:30:00
	修改时间	2022-10-22 10:30:00
管理元数据	数据权限	公开
管理元数据	安全等级	安全

在表格中，“40”是实体数据，而业务元数据、技术元数据、操作元数据、管理元数据，分别从各自的角度描述了“40”这个数字，通过它们，我们可以了解到：登革热患者发热期24H内平均体温为“40℃”，这条数据的存储在“MySQL”的“xxx”库“data_diseases”表中，数据创建人是“张三”等。

二、元数据管理

元数据管理是对元数据的创建、存储、整合、控制的一整套流程，它能够帮助开发和业务人员快速了解数据上下游关系、数据本身含义，减少数据研究的时间成本，提高工作效率。

元数据管理需要提供元数据精准定位查找、元数据分类和建模、血缘关系和影响分析的功能，方便数据的跟踪和回溯，最终对外提供应用及展现。

元数据管理一般包括元模型管理、元数据审核、元数据维护、元数据版本管理、元数据变更管理、元数据血缘分析、元数据影响分析等功能。

2.1元模型管理

元模型管理即基于元数据平台构建符合CWM规范的元数据仓库，实现元模型统一、集中化管理，提供元模型的查询、增加、修改、删除、元数据关系管理、权限设置等功能，支持概念模型、逻辑模型、物理模型的采集和管理，让用户直观地了解已有元模型的分类、统计、使用情况、变更追溯，以及每个元模型的生命周期管理。同时，支持应用开发的模型管理。

支持元模型的全生命周期管理。元模型生命周期中有三个状态，分别是：设计态、测试态和生产态。

设计态的元数据模型，通常由ERWin、PowerDesigner的等设计工具产生。
测试态的元数据模型，通常是关系型数据，如Oracle、DB2、MySQL、Teradata等；或非关系型数据库，如MongoDB、HBase、Hive、Hadoop等。
生产态的元数据模型，本质上与测试态元数据差异不大。

通过元数据平台对应用开发三种状态的统一管理和对比分析，能够有效降低元数据变更带来的风险，为下游ODS、DW的数据应用提供支撑。

2.2元数据审核

元数据审核主要是审核采集到元数据仓库但还未正式发布到数据资源目录中的元数据。审核过程中支持对数据进行有效性验证并修复一些问题，例如缺乏语义描述、缺少字段、类型错误、编码缺失或不可识别的字符编码等。

2.3元数据维护

元数据维护就是对信息对象的基本信息、属性、被依赖关系、依赖关系、组合关系等元数据的新增、修改、删除、查询、发布等操作,支持根据元数据字典创建数据目录，打印目录结构，根据目录发现、查找元数据，查看元数据的内容。元数据维护是最基本的元数据管理功能之一，技术人员和业务人员都会使用这个功能查看元数据的基本信息。

2.4元数据版本管理

在元数据处于一个相对完整、稳定的时期，或者处于一个里程碑结束时期，可以对元数据定版以发布一个基线版本，以便日后对存异的或错误的元数据进行追溯、检查和恢复。

2.5元数据变更管理

元数据管理提供元数据监控功能，一旦监控到元数据发生变更，就在第一时间通知用户，用户可根据指引进一步在系统中查询到变更的具体内容及相关的影响分析。

2.6元数据血缘分析

元数据血缘关系就是指数据从产生到最终消亡，数据之间形成的一种关系。一般元数据血缘关系有以下明显特征：

归属性。一般来说，特定的数据归属特定的团队或者个人
多源性。同一个数据可以有多个来源（多个父亲）。一个数据可以是多个数据经过加工而生成的，而且这种加工过程可以是多个。
可追溯性。数据的血缘关系，体现了数据的生命周期，体现了数据从产生到消亡的整个过程，具备可追溯性。
层次性。数据的血缘关系是有层次的。对数据的分类、归纳、总结等对数据进行的描述信息又形成了新的数据，不同程度的描述信息形成了数据的层次。提供对数据异常原因进行定位

元数据血缘分析就是对元数据之间的血缘关系进行分析，来对元数据进行溯源、价值评估、归档/销毁参考等。

数据溯源：

数据的血缘关系，体现了数据的来龙去脉，血缘分析能帮助业务人员追踪数据的来源，追踪数据处理过程，对数据产生原因的分析帮助很大，尤其是异常值分析。

例如：业务部门的小A想要对某传染病的变化趋势做一下分析，走了很长的流程才把数据借到，可是当他打开数据，却发现自己很难理解这些数据的意义，系统里的“变化趋势值”到底是怎么定义计算出来的？用的什么模型计算的？模型合不合理？为了完成任务，只能打电话一个个去询问，大大影响了工作效率。有了血缘分析，小A情况就不同了，他可以轻松拿到“变化趋势值”的整个计算过程以及所用到的所有数据、模型、参数。