数仓的元数据管理和上下游约定

数仓的元数据管理和上下游约定

数仓元数据管理

一、元数据定义

元数据(Meta Data)狭义的来说可以理解为描述数据的数据,广义的来看是除了业务逻辑直接读写处理外的业务数据,所有用来维持整个系统运转所需的信息及数据都可以叫作元数据。

如何理解上面这句话呢?我告诉你小头儿子的信息,如果你没见过动画片你肯定是不能理解的,但是如果按照下面的文字进行描述呢?

小头儿子是一个高150cm的男孩子,重100斤,出生在2008年,现在13岁,爸爸的名字是小头爸爸,现在在上中学。

上文在描述小头儿子,那么是怎样描述的?从身高,体重,性别,家庭关系,年龄等。这些描述的信息可以理解为元数据。

同理,现在我告诉你一个数字175,看到这个你除了可以确定他具备一定的度量意义外,还是有很多疑问,无法立即,比如度量的什么,谁度量的等等问题,但是如果按照下面这些信息度量呢?

数据类型 数据内容
数据值 175
单位 cm
指标 平均身高
统计时间 2020年
区域范围 全国
人群范围 成年男性
范围 80-260
数据库类型 Mysql
数据库链接 jdbc:mysql://127.0.0.1:3306/info
表名 human_stat
字段 height_avg
创建人 李四
创建时间 2020-10-01
修改时间 2020-10-01
数据权限 公开
安全等级 安全
质量等级 极高

这样是不是就很清楚了?175 的意思是:2020 年统计的全国成年男性平均身高,该值的合理范围是 80-260cm,数据目前存在 MySQL中,访问连接是 jdbc:mysql://127.0.0.1:3306/info,由国家统计局的李四在 2020 年 10 月 1 日创建,数据目前是公开的,很安全,质量经过多重确认无误的。

上表在描述 175 这个数据,用了哪些描述项呢?单位、指标、统计时间、统计范围、合理范围、数据库、表、字段、创建人、创建时间、数据权限、质量等级等等。这些都是在描述 175 这个数据。我们把描述 175 这个数据的其他数据称之为“元数据”。

二、元数据类型

元数据可分为技术元数据、业务元数据和管理过程元数据等几类。

  1. 技术元数据
    为开发和管理数据仓库的 IT 人员使用,它描述了与数据仓库开发、管理和维护相关的数据,包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等;如表结构、文件路径/格式。

  2. 业务元数据
    为管理层和业务分析人员服务,从业务角度描述数据,包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等,帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用;如责任人、归属的业务、血缘关系。

  3. 管理过程元数据
    指描述管理领域相关的概念、关系和规则的数据,主要包括管理流程、人员组织、角色职责等信息;如表每天的行数、大小、更新时间。

针对元数据的类型上更容易理解,对上述例子中的元数据类型,进行归类划分:

业务元数据

数据类型 数据内容
数据值 175
单位 cm
指标 平均身高
统计时间 2020年
区域范围 全国
人群范围 成年男性
范围 80-260

技术元数据

数据类型 数据内容
数据库类型 Mysql
数据库链接 jdbc:mysql://127.0.0.1:3306/info
表名 human_stat
字段 height_avg

管理过程元数据

数据类型 数据内容
创建人 李四
创建时间 2020-10-01
修改时间 2020-10-01
数据权限 公开
安全等级 安全
质量等级 极高

三、元数据功能

  1. 血缘分析

“表”是元数据系统的后台逻辑核心,数据仓库是构建在 Hive 之上,而 Hive 的原始数据往往来自于生产系统,也可能会把计算结果导出到外部存储,所以我们认为 Hive 表、mysql 表、hbase 表、BI 报表都是“表”,这些“表”间关系是一个 DAG,也就是血缘关系。

血缘关系案例

有了血缘关系,优化可视化展示,可以让用户清楚看到一张表的上下游,更方便地查找表。基于血缘关系可以做很多事情,例如:

  • 结合表的更新时间,还可以找到调度 DAG 的关键路径,协助定位性能瓶颈;
  • 当表出现变更时,可以通知下游责任人,以及自动对下游任务做 SQL 的静态检查;
  • 辅助生命周期管理,找到没有被使用的表/字段;
  • 辅助维护字段的一致性,如注释、校验规则复用。
  1. 影响分析
    向下追溯元数据对象对下游的影响。影响分析可以让您轻松应对变更可能产生的影响,自动识别与其相关的依赖项和潜在的影响还可以跟踪所有对象及其依赖关系,最后我们还提供数据全生命周期的可视化显示。例如,如果您的某一信息系统中准备将“销售额”从包含税费更改为不包括税费,则SE-DWA将自动显示所有使用了“销售金额”字段,以便您可以确定有哪些工作需要完成,并且建议您在更改前完成该工作。

  2. 同步检查
    检查源表到目标表的数据结构是否发生变更。

  3. 指标一致性分析
    定期分析指标定义是否和实际情况一致。

  4. 实体关联查询
    事实表与维度表的代理键自动关联

四、元数据应用

  1. ETL自动化管理:使用元数据信息自动生成物理模型,ETL程序脚本,任务依赖关系和调度程序。
  2. 数据质量管理:使用数据质量规则元数据进行数据质量测量。数据质量根据设定的规则帮助您过滤出有问题的数据,并智能分析数据质量缺陷。
  3. 数据安全管理:的安全性会更进一步,可以限制特定的组成员只可以访问表中特定的数据。
  4. 数据标准管理:使用元数据信息生成标准的维度模型。
  5. 数据接口管理:使用元数据信息进行接口统一管理。多种数据源接入,并提供多种插件对接最流行的源系统。应该可以简单方便获取数据。
  6. 项目文档管理:使用元数据可以自动、方便的生成的健壮全面的项目文档,其以帮助您应对各种对于数据合规性要求。读取元数据模型,并生成pdf格式的描述文件。生成文档您查看每个对象的名称、设置、描述和代码。
  7. 数据语义管理:业务用户在自助服务分析中面临的挑战他们不了解数据仓库从而无法正确解释数据,使用元数据可以语义层建模,使用易于业务用户理解的描述来转换数据。

五、总结

由上可见,元数据(Meta Data),不仅记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。元数据把数据仓库系统中各个松散的组件联系起来,组成了一个整体数据仓库解决方案。

构建数据仓库的主要步骤之一是 ETL。此时元数据将发挥重要的作用,它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。

用户在使用数据仓库时,通过元数据访问数据,明确数据项的含义以及定制报表。数据仓库的规模及其复杂性离不开正确的元数据管理,包括增加或移除外部数据源,改变数据清洗方法,控制出错的查询以及安排备份等。

数据仓库上下游以及上下游约定

基于数据仓库的特性和定位,数仓强依赖于上游的业务系统,下游的报表、可视化平台又强依赖于数仓。

一、数仓的上游约定

数据仓库最重要的数据源主要来源于业务系统,故而数据需要不断的从业务系统导入数仓中。由此上游业务系统的变动,将会非常直接的影响下游。所以制定严谨的上游约定是极其重要的。

常见约定形式如下:

  • 表结构变更
  • 表字段的枚举值定义变化
  • create_time和update_time,业务数据与数仓系统的数据同步,对新增和修改的触发tongue,一般依托于这两个字段
  • is_delete 和 is_valid的定义规约

二、数仓的下游约定

对数仓来说,下游系统一般为接口,报表、可视化平台等使用。所以针对数仓平台的优化改动,都需要及时沟通同步。

评论