数仓--Theory--数仓元数据及管理

需要进行对比学习，弄清楚是hive元数据还是数仓元数据，两者有很大的区别，存储位置也是不一样的

Hive元数据

• 元数据包括：表名、表所属的数据库（默认是default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录、表的映射关系等；
• 默认存储在自带的derby数据库中，推荐使用MySQL存储Metastore；

数仓元数据

好好的体会一下数仓元数据的内容，注意和hive元数据进行对比学习
元数据概念

• 狭义的解释是用来描述数据的数据；
• 广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息、数据都可以叫作元数据；

元数据定义

• 按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。

技术元数据

存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据

• 数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
• 业务系统、数据仓库和数据集市的体系结构和模式；
• 汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；
• 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。

业务元数据

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

• 企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。
• 多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。
• 业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。

总结

• 搭建数据仓库中最容易缺失的就是对元数据的管理，很少有数据仓库团队具备完整的元数据，当然搭建数据仓库的工程师本身就是活的元数据，但无论是为了用数据的人还是数据仓库自身的团队着想，元数据都不可或缺。一方面元数据为数据需求方提供了完整的数据仓库使用文档，帮助他们能自主地快速获取数据，另一方面数据仓库团队成员可以从日常的数据解释中解脱出来，无论是对后期的不断迭代更新和维护还是培训新的员工，都非常有好处，元数据可以让数据仓库的应用和维护更加高效。

元数据作用

• 与其说数据仓库是软件开发项目，还不如说是系统集成项目，因为它的主要工作是把所需的数据仓库工具集成在一起，完成数据的抽取、转换和加载，OLAP分析和数据挖掘等；元数据在数据仓库中起到了承上启下得作用。

具体表现如下：

1.元数据是进行数据集成所必需的

• 数据仓库最大的特点就是它的集成性。这一特点不仅体现在它所包含的数据上，还体现在实施数据仓库项目的过程当中。一方面，从各个数据源中抽取的数据要按照一定的模式存入数据仓库中，这些数据源与数据仓库中数据的对应关系及转换规则都要存储在元数据知识库中；另一方面，在数据仓库项目实施过程中，直接建立数据仓库往往费时、费力，因此在实践当中，人们可能会按照统一的数据模型，首先建设数据集市，然后在各个数据集市的基础上再建设数据仓库。不过，当数据集市数量增多时很容易形成“蜘蛛网”现象，而元数据管理是解决“蜘蛛网”的关键。如果在建立数据集市的过程中，注意了元数据管理，在集成到数据仓库中时就会比较顺利；相反，如果在建设数据集市的过程中忽视了元数据管理，那么最后的集成过程就会很困难，甚至不可能实现。

2.元数据定义的语义层可以帮助用户理解数据仓库中的数据

• 最终用户不可能象数据仓库系统管理员或开发人员那样熟悉数据库技术，因此迫切需要有一个“翻译”，能够使他们清晰地理解数据仓库中数据的含意。元数据可以实现业务模型与数据模型之间的映射，因而可以把数据以用户需要的方式“翻译”出来，从而帮助最终用户理解和使用数据。

3.元数据是保证数据质量的关键

• 数据仓库或数据集市建立好以后，使用者在使用的时候，常常会产生对数据的怀疑。这些怀疑往往是由于底层的数据对于用户来说是不“透明”的，使用者很自然地对结果产生怀疑。而借助元数据管理系统，最终的使用者对各个数据的来龙去脉以及数据抽取和转换的规则都会很方便地得到，这样他们自然会对数据具有信心；当然也可便捷地发现数据所存在的质量问题。甚至国外有学者还在元数据模型的基础上引入质量维，从更高的角度上来解决这一问题。

4.元数据可以支持需求变化

• 随着信息技术的发展和企业职能的变化，企业的需求也在不断地改变。如何构造一个随着需求改变而平滑变化的软件系统，是软件工程领域中的一个重要问题。传统的信息系统往往是通过文档来适应需求变化，但是仅仅依靠文档还是远远不够的。成功的元数据管理系统可以把整个业务的工作流、数据流和信息流有效地管理起来，使得系统不依赖特定的开发人员，从而提高系统的可扩展性。

元数据管理现状

• 由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。

与元数据相关的数据仓库工具大致可分为四类：

1. 数据抽取工具;
   把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、Pentaho的开源ETL产品Kettle、ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。
2. 前端展现工具：
   包括OLAP分析、报表和商业智能工具等，如Cognos的PowerPlay、Business Objects的BO，以及国内厂商帆软的FineBI／FineReport等。它们通过把关系表映射成与业务相关的事实和维来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
3. 建模工具：
   为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
4. 元数据存储工具：
   元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间。这些工具包括微软的Repository，Ardent的MetaStage和Sybase的WCC等。

5.元数据管理工具：

• 目前国内的元数据管理工具大概有三类。一是像IBM、CA等公司都提供的专门工具，比如IBM收购Ascential得到的MetaStage，CA的DecisionBase都是如此；二是像DAG的MetaCenter，开源产品Pentaho Metadata，它们不依托于某项BI产品，是一种第三方的元数据管理工具；三是像普元、石竹这样的集成商也有自己的元数据管理工具：普元MetaCube、新炬网络元数据管理系统、石竹MetaOne等。
• 专门的元数据管理工具，对自家产品兼容较好，一旦涉及跨系统管理，就不尽如人意了。从国内的实际应用来看，DAG的MetaCenter这一工具使用最多，目前所看到的在电信、金融领域建设的元数据管理项目基本上都是应用了这一产品。
• 我从互联网上搜索了几乎所有的元数据厂家：Pentaho开源的MetaData产品，支持源码下载试用，可以进行集成开发；普元MetaCube下载后，配置麻烦，目前为止还没有调通；其他公司产品均不提供下载试用。

四、元数据管理标准

没有规矩不成方圆。元数据管理之所以困难，一个很重要的原因就是缺乏统一的标准。在这种情况下，各公司的元数据管理解决方案各不相同。近几年，随着元数据联盟MDC（Meta Data Coalition）的开放信息模型OIM（Open Information Model）和OMG组织的公共仓库模型CWM（Common Warehouse Model）标准的逐渐完善，以及MDC和OMG组织的合并，为数据仓库厂商提供了统一的标准，从而为元数据管理铺平了道路。

从元数据的发展历史不难看出，元数据管理主要有两种方法：

• 对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库。

• 对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后，通过建立标准的元数据交换格式，实现元数据的集成管理。

• 目前OMG家的CWM（Common Warehouse MetaModel）标准已成为元数据管理界的统一标准：

• OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：

• UML：它对CWM模型进行建模。

• MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。

• XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。

五、元数据管理功能

1. 数据地图

数据地图展现是以拓扑图的形式对数据系统的各类数据实体、数据处理过程元数据进行分层次的图形化展现，并通过不同层次的图形展现粒度控制，满足开发、运维或者业务上不同应用场景的图形查询和辅助分析需要。

2. 元数据分析

血缘分析

• 血缘分析（也称血统分析）是指从某一实体出发，往回追溯其处理过程，直到数据系统的数据源接口。对于不同类型的实体，其涉及的转换过程可能有不同类型，如：对于底层仓库实体，涉及的是ETL处理过程；而对于仓库汇总表，可能既涉及ETL处理过程，又涉及仓库汇总处理过程；而对于指标，则除了上面的处理过程，还涉及指标生成的处理过程。数据源接口实体由源系统提供，作为数据系统的数据输入，其它的数据实体都经过了一个或多个不同类型的处理过程。血缘分析正是提供了这样一种功能，可以让使用者根据需要了解不同的处理过程，每个处理过程具体做什么，需要什么样的输入，又产生什么样的输出。

影响分析

• 影响分析是指从某一实体出发，寻找依赖该实体的处理过程实体或其他实体。如果需要可以采用递归方式寻找所有的依赖过程实体或其他实体。该功能支持当某些实体发生变化或者需要修改时，评估实体影响范围。

实体关联分析

• 实体关联分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度。本功能可以用来支撑需求变更影响评估的应用。

实体差异分析

• 实体差异分析是对元数据的不同实体进行检查，用图形和表格的形式展现它们之间的差异，包括名字、属性及数据血缘和对系统其他部分影响的差异等,在数据系统中存在许多类似的实体。这些实体（如数据表）可能只有名字上或者是在属性中存在微小的差异，甚至有部分属性名字都相同，但处于不同的应用中。由于各种原因，这些微小的差异直接影响了数据统计结果，数据系统需要清楚了解这些差异。本功能有助于进一步统一统计口径，评估近似实体的差异

指标一致性分析

• 指标一致性分析是指用图形化的方式来分析比较两个指标的数据流图是否一致，从而了解指标计算过程是否一致。该功能是指标血缘分析的一种具体应用。指标一致性分析可以帮助用户清楚地了解到将要比较的两个指标在经营分析数据流图中各阶段所涉及的数据对象和转换关系是否一致，帮助用户更好地了解指标的来龙去脉，清楚理解分布在不同部门且名称相同的指标之间的差异，从而提高用户对指标值的信任。

3. 辅助应用优化

元数据对数据系统的数据、数据加工过程以及数据间的关系提供了准确的描述，利用血缘分析、影响分析和实体关联分析等元数据分析功能，可以识别与系统应用相关的技术资源，结合应用生命周期管理过程，辅助进行数据系统的应用优化.

4. 辅助安全管理

• 企业数据平台所存储的数据和提供的各类分析应用，涉及到公司经营方面的各类敏感信息。因此在数据系统建设过程中，须采用全面的安全管理机制和措施来保障系统的数据安全。
• 数据系统安全管理模块负责数据系统的数据敏感度、客户隐私信息和各环节审计日志记录管理，对数据系统的数据访问和功能使用进行有效监控。为实现数据系统对敏感数据和客户隐私信息的访问控制，进一步实现权限细化，安全管理模块应以元数据为依据，由元数据管理模块提供敏感数据定义和客户隐私信息定义，辅助安全管理模块完成相关安全管控操作。

5. 基于元数据的开发管理

数据系统项目开发的主要环节包括：需求分析、设计、开发、测试和上线。开发管理应用可以提供相应的功能，对以上各环节的工作流程、相关资源、规则约束、输入输出信息等提供管理和支持。

推荐学习文章：https://tech.youzan.com/youzan-metadata/ 有赞数据仓库元数据系统实践

参考博客 ： 聊一聊数据仓库中的元数据管理系统
元数据及数据仓库相关概念