一.元数据概述

(1)元数据定义

按照传统的定义,元数据( Metadata )是关于数据的数据。元数据打通了源数据、数据仓库、数据应用,记录了数据从产生到消费的全过程。

元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。在数据仓库系统中,元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据,用于指导其进行数据管理和开发工作,提高工作效率。

将元数据按用途的不同分为两类:技术元数据( Technical Metadata)和业务元数据( Business Metadata )

 

技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据。阿里巴巴常见的技术元数据有:

分布式计算系统存储元数据,如 MaxCo te 表、列、分区等信息。记录了表的表名。分区信息、责任人信息、文件大小、表类型,生命周期,以及列的字段名、字段类型、字段备注、是否是分区 段等信息。

 

分布式计算系统运行元数据,如 MaxCompute 上所有作业运行等信息:类似于 Hive Job 日志,包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间、最细粒度的 Instance(Max Compute MR 执行的最小单元)执行信息等。

 

数据开发平台中数据同步、计算任务、任务调度等信息,包括数据同步的输入输出表和字段,以及同步任务本身的节点信息:计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等,以及不同类型调度任务的运行日志等。

 

数据质量和运维相关元数据,如任务监控、运维报警、数据质量、故障等信息,包括任务监控运行日志、告警配置及运行日志、故障信息等。

 

业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读

懂”数据仓库中的数据。阿里巴巴常见的业务元数据有:

  •  OneData 元数据,如维度及属性、业务过程、指标等的规范化定义,用于更好地管理和使用数据。
  • 数据应用元数据,如数据报表、数据产品等的配置和运行元数据。

 

(2)元数据价值

元数据有重要的应用价值,是数据管理、数据内容、数据应用的基础,在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。例如在计算上可以利用元数据查找超长运行节点,对这些节点进行专项治理,保障基线产出时间。在数据内容方面为集团数据进行数据域、数据主题、业务属性等的提取和分析提供

数据素材。例如可以利用元数据构建知识图谱,给数据打标签,清楚地知道现在有哪些数据。在数据应用方面打通产品及应用链路,保障产品数据准确、及时产出。例如打通 Max Compute 和应用数据,明确数据资产等级,更有效地保障产品数据。

 

(3)统一元数据体系建设

元数据的质量直接影响到数据管理的准确性,如何把元数据建设好将起到至关重要的作用。元数据建设的目标是打通数据接入到加 ,再到数据消费整个链路,规范元数据体系与模型,提供统一 的元数据服务出口,保障元数据产出的稳定性和质量。

 

数据仓库元数据表结构 数据仓库元数据例子_数据仓库元数据表结构

 

首先梳理清楚元仓底层数据,对元数据做分类,如计算元数据、存储元数据、质量元数据等,减少数据重复建设,保障数据的唯一性。另外,要丰富表和字段使用说明,方便使用和理解。根据元仓底层数据构

建元仓中间层,依据 OneData 规范,建设元数据基础宽表,也就是元数据中间层,打通从数据产生到消费整个链路 ,不断丰富中间层数据,如MaxCompute 元数据、调度元数据、同步元数据、产品访问元数据、服

务元数据等。基于元数据中间层,对外提供标准统一的元数据服务出口,保障元数据产出的质量。丰富的元数据 中间层不仅能够为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持,形

成一套完整的 ROI 数据体系,而且为集团数据进行数据内容、数据域、数据主题、业务属性等的提取和分析提供了数据素材。

 

二.元数据应用

数据的真正价值在于数据驱动决策,通过数据指导运营。通过数据驱动的方法,我们能够判断趋势 ,从而展开有效行动,帮助自己发现问题,推动创新或解决方案的产生。这就是数据化运营。同样,对于元数

据,可以用于指导数据相关人员进行日常工作,实现数据化“运营”。比如对于数据使用者,可以通过元数据让其快速找到所需要的数据;对ETL 工程师,可以通过元数据指导其进行模型设计、任务优化和任

务下线等各种日常 TL 工作;对于运维工程师,可以通过元数据指导其进行整个集群的存储、计算和系统优化等运维工作。

 

(1)Data Profile

Data Profi le 的出现,很好地解决了在研发初期数据处理的繁杂困境,既节约了时间成本,同时也缩减了相当一部分人力资源。它的核心思路是为纷繁复杂的数据建立一个脉络清晰的血缘图谱。通过图计算、标签传播算法等技术 ,系统化、自动化地对计算与存储平台上的数据进行打标、整理、归档。形象地说, Data Profile 实际承担的是为数据“画像”的任务。

数据之间的个性化,除了应用场景的不同之外,实际上在数据的研发流程、保障登记、数据质量要求、安全 级、运维策略、告警设置上都会有 差异。根据这种差异化, Data Profile 开发出了四类标签,如图12.2 示。

数据仓库元数据表结构 数据仓库元数据例子_元数据_02

(2) 元数据门户

阿里巴巴基于元数据产出的最重要的产品是元数据门户。元数据门户致力 打造一站式 的数据管理平台、高效的 体化数据市场。包括“前台”和 “后台”,“前台”产品为数据地图,定位消费市场,实现检索数理解数据等“找数据”需求 “后台”产品为数据管理,定位于站式数据管理,实现成本管理、安全管理、质量管理等。

 

(3)应用链路分析

对于某个数据计算任务或表,其重要程度如何,是否还有下游在使用,是否可以下线;阿里巴巴有这么多数据产品,都依赖哪些MaxCompute 表,对这些 MaxCompute 表是否需要根据应用的重要程度进行资源 、运维保障……对于这些问题,我们都可以通过元数据血缘来分析产品及应用的链路,通过血缘链路可以清楚地统计到某个产品所用到的数据在计算、存储、质量上存在哪些问题,通过治理优化保障产品数据的稳定性。

通过应用链路分析,产出表级血缘、字段血缘和表的应用血缘。其中表级血缘主要有两种计算方式:一种是通过 MaxCompute 任务日志进行解析;一种是根据任务依赖进行解析。

 

其中难度最大的是表的应用血缘解析,其依赖不同的应用。按照应用和物理表的配置关系,可以分为配置型和无配置型。对于数据报表、集市等应用,其数据源直接或间接使用 MaxCompute 数据且有元数据配置依赖关系,通过配置元数据,可以获取 MaxCompute 物理表和具体的报表、集市等应用的血缘关系。对于生意参谋等数据产品,其数据摞通过数据同步方式同步至 MySQL HBase 等数据库,间接使用 MaxCompute数据且无配置产品和 MySQL HBase 等物理数据源的依赖关系,导致无

法通过配置元数据解析 MaxCompute 数据和数据产品的关系。主要通过统一的应用日志打点 SDK 来解决此问题,可以做到配置化、应用无痕化。

 

常见的应用链路分析应用主要有影响分析、重要性分析、下线分析、链路分析、寻根溯源、故障排查等。

 

(4)数据建模

传统的数据仓库建模一般采用经验建模的方式,效率较低且不准确。基于现有底层数据已经有下游使用的情况,我们可以通过下游所使用的元数据指导数据参考建模。通过元数据驱动的数据仓库模型建设,可以在 定程度上解决此问题,提高数据仓库建模的数据化指导,提升建模效率。

所使用的元数据主要有

  • 表的基础元数据,包括下游情况、查询次数、关联次数、聚合次数、产出时间等。
  • 表的关联关系元数据,包括关联表、关联类型、关联字段、关联次数等。
  • 表的字段的基础元数据,包括字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等。

其中查询指 SQL SELECT 关联指 SQL JOIN ,聚合指 SQL的GROUP BY 过滤指 SQL WHERE

 

(5)驱动 ETL 开发

通过元数据,指导 ETL 工作,提高 ETL 的效率。在“数据同步”中,我们提到了通过元数据驱动 键、批量高效数据同步的OneClick OneClick 覆盖的另 个场景是存量数据日常维护,其主要功能如图 12.3 中的“数据运维”部分所示。

数据仓库元数据表结构 数据仓库元数据例子_数据_03

 

我们可以通过 Data Profile 得到数据的下游任务依赖情况、最近被读写的次数、数据是否可再生、每天消耗的存储计算等,这些信息足以让我们判断数据是否可以下线;如果根据 些规则判断可以下线,则

会通过 OneClick 个数据下线的工作任务流,数据 Owner 可能只要点击提交按钮,删除数据、删除元数据、下线调度任务、下线 DQC监控等 系列操作就会自动在后台执行完成。