精华内容
下载资源
问答
  • 产品是一款基于 WEB 方式的元数据管理工具,采用这个工具能够整合游离于企业各环 节的元数据资产,便于用户浏览及分析元数据。产品有助于帮助用户了解和管理信息和加工 处理过程的来源,也有助于用户理解信息与加工...
  • 元数据管理 技术规范

    2018-09-15 08:23:46
    元数据管理 技术规范 一、元数据概念 二、元数据管理体系 三、元数据管理功能 四、元数据管理应用 五、元数据变更流程
  • 元数据管理

    千次阅读 2019-05-06 09:56:32
    元数据管理 1、什么是元数据管理? 企业用户在创建了众多数据库信息时,需要一个查询功能可以及时高效地为用户查询数据库信息,如数据源、表以及视图等信息。DataPipeline(www.datapipeline.com)元数据管理功能...

    元数据管理
    1、什么是元数据管理?
    企业用户在创建了众多数据库信息时,需要一个查询功能可以及时高效地为用户查询数据库信息,如数据源、表以及视图等信息。DataPipeline(www.datapipeline.com)元数据管理功能可以为用户降低时间成本,提高查询效率。
    2、元数据管理能做到什么?
    元数据管理能带给用户的核心功能有:
    1、支持筛选查询已创建的数据源/表/视图信息。
    2、支持查看总览查询所有已创建的数据库信息。
    3、支持用户输入数据源名称/类型/负责人/创建人查询数据源信息。
    4、支持用户输入表名称、负责人、Comment查询表信息。
    5、支持用户输入视图名称、负责人、Comment查询视图信息。
    6、支持用户在搜索结果中对数据源和创建人进行筛选。
    7、支持查询数据源类型为MySQL、Oracle、SQL Server、PostgreSQL、FTP、S3数据源。
    8、支持用户在总览列表页进行搜索。
    3、如何使用元数据管理?
    元数据管理首页
    顶部显示搜索入口
    提示文案:请输入搜索关键词(如数据源、表、视图、字段、标签名称)
    搜索范围:
    数据源搜索范围:数据源名称、数据源类型、创建人、负责人、标签
    表搜索范围:表名称、负责人、Comment、标签
    视图搜索范围:视图名称、负责人、Comment、标签
    字段搜索范围:字段名称、标签、别名、描述

    展开全文
  • 数据治理系列2:元数据管理—企业数据治理的基础

    万次阅读 多人点赞 2019-05-13 20:11:04
    导读:元数据管理是对企业涉及的业务元数据、技术元数据、管理元数据进行盘点、集成和管理,按照科学、有效的机制对元数据进行管理,并面向开发人员、最终用户提供元数据服务,以满足用户的业务需求,对企业业务系统...

     

    导读:元数据管理是对企业涉及的业务元数据、技术元数据、管理元数据进行盘点、集成和管理,按照科学、有效的机制对元数据进行管理,并面向开发人员、最终用户提供元数据服务,以满足用户的业务需求,对企业业务系统和数据分析平台的开发、维护过程提供支持。元数据管理是企业数据治理的基础。

    认识元数据

    元数据(Metadata),元数据是关于数据的组织、数据域及其关系的信息,简言之,元数据就是描述数据的数据。这么说对于没有技术背景的人来说还是比较抽象的,我给大家举几个例子。

     

     

    在我之前写的一篇文章《关于“数据”的一些概念的整理和总结》中,有一个关于元数据的例子,歌曲《小芳》中有一段台词:“村里有个姑娘叫小芳,长得好看又善良” 这首耳熟能详的歌,我们分析一下,姓名:小芳、性别:姑娘(女)、长相:好看、性格:善良,住址:村里。这里面,小芳是被描述的对象也就是我们所谓的实体数据,而姓名、性别、长相、性格、住址就是描述“小芳”的元数据。

    再举个栗子:元数据就像“户口本”,户口本中除了有姓名、出生日期、住址、民族等信息外,还有家庭的血缘关系,父子关系、兄弟关系等。这些信息就构成了对这个人的详细描述,那这些信息就是描述这个人的元数据。

    再举个栗子:元数据好比“字典”,针对每个字都注音、含义、组词、举例等信息,同时也有关于字体结构、相关引用、出处等。另外,我们可以通过拼音、偏旁部首都能查到这个字。所有的这些信息都是对这个字的详细描述,那这些信息就是描述这个字的元数据。

    再举个栗子:元数据就如“地图”,通过这张“地图”能够找到你所处的地点,以及你从哪来来,到哪里去,途中都需要路过哪些地方……

    这下大家理解了吧,元数据是对数据的结构化描述,使得数据更容易理解、查找、管理和使用。

    元数据的分类

    根据数据的性质特点,业内一般将元数据划分为三类:业务元数据、技术元数据和管理元数据。

     

     

    业务元数据是描述数据的业务含义、业务规则等。通过明确业务元数据让人们更容易理解和使用业务元数据,元数据消除了数据二义性,让人们对数据有一致的认证,避免“各说自话”,进而为数据分析和应用提供支撑。常见的业务元数据包括:业务定义、业务术语、业务规则、业务指标等。

    技术元数据是对数据的结构化,方便计算机或数据库之间对数据进行识别、存储、传输和交换。技术元数据可以服务于开发人员,让开发人员对数据的存储、结构更明确,从而为应用的开发和系统的集成奠定基础。技术元数据也可服务于业务人员,通过元数据理清数据关系,让业务人员能够更快速的找到想要的数据,进而对数据的来源去向进行分析,支持数据血缘追溯和影响分析。常见的技术元数据包括:存储位置、数据模型、数据库表、字段长度、字段类型、ETL脚本、SQL脚本、接口程序、数据关系等。

    管理元数据描述了数据的管理属性,包括管理部门、管理责任人等,通过明确管理属性,有利于数据管理责任到部门和个人,是数据安全管理的基础。常见的管理元数据包括:数据所有者、数据质量定责、数据安全等级等。

     

    表:元数据分类实例

    元数据类型

    元数据描述

    元数据实例

     业务定义

     数据的含义

     客户的完整名称,并具有法律效力

     业务规则

    数据录入规则

     企业的营业执照、组织机构代码证书,统一社会信用代码证书等具有法律效力的证明文件中的中文名称全称

     

     识别规则

    企业的组织机构代码或者统一社会信用代码或者统一纳税号必须完全匹配,则认为是同一客户。

     

     质量规则

     客户名称为非空,并且与营业执照的中文名称一致

    存储位置

    数据的存储什么地方

    ERP系统

    数据库表

    存储数据的库表名称和路径

    ERP/Customers

    字段类型

    数据的技术类型

    字符型

    字段长度

    数据存储的最大长度

    [200]

    更新频率

    数据的更新频率

    每年更新一次

    管理部门

    数据责任部门

    客户管理部

    管理责任人

    数据责任部门

    客户管理部业务员

     

    元数据管理成熟度

    在实施元数据管理的过程中,可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次,并根据业务需要制定路线图实现元数据管理水平的提升。下图是元数据管理成熟度模型:

     

     

    元数据管理成熟度评估模型

    • L0: 初始状态

    元数据分散于日常的业务和职能管理中,由某个人或某一组人员在局部产生或获取,并在局部使用。在局部环境工作数月或数年后,人们使这些元数据以及对它的理解内在化,使对这种信息有习惯性的理解。这些元数据会永远保存在某个人那儿,一旦这个人调离,这些元数据将永远消失。

    • L1: 从属于业务系统

    在这个阶段,随着各个业务系统自动化构建完成,相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中,技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中,元数据之间互通互联困难,如果需要获取其他系统的元数据,除了调阅各种文档外,对分散在各种中间件和业务系统中的技术元数据需要一定的集成方式实现互通互联。

    • L2:元数据统一存储

    元数据依然在局部产生和获取,但会集中到中央存储库进行存储,业务元数据会手工录入到中央存储库中,技术元数据分散在文档中的部分也通过手工录入到中央存储库中,而散落在各个中间件和业务系统中的技术元数据则通过数据集成的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建,使得元数据在整个企业层面可被感知和搜索,极大地方便了企业获取和查找元数据。缺点是,元数据仍然在各业务系统上维护,然后更新到中央存储库,各业务竖井之间仍然使用不同的命名法,经常会造成相同的名字代表不同意义的事情,而同一件事情则使用了多个不同的名字,有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理,局部元数据更改后也不自动通知其他人。

    • L3: 元数据集中管理

    在 L2 的基础上做了改进,增强了元数据的集中控制,局部业务单元或开发小组如不事先通知其他人,将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互,仍然通过桥集成的方式进行,中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。

    • L4:元模型驱动管理

    在 L3 的基础上,通过构建元模型以及元元模型,优化各业务单元之间的各种冲突和各种副本,创建、管理和共享业务词汇表和分类系统(基于主题领域的层次结构)。业务词汇表(业务元数据)包含与企业相关的词汇、词汇业务含义以及词汇与信息资产(技术元数据)的关系,可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构,用以对业务术语归类。和其他中间件和应用系统的交换,通过基于 CWM 的适配器方式进行连接。

    • L5: 元数据管理自动化

    在 L5 元数据管理是高度自动化的,当逻辑层次元数据变更时,会被传播到物理层次,同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流,以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统(元模型),他们之间的关系可以通过知识本体进行推断,因此各个应用系统之间的数据格式的映射自动产生。

     

    元数据管理平台架构

    元数据管理平台从应用层面,可以分类:元数据采集服务,应用开发支持服务,元数据访问服务、元数据管理服务和元数据分析服务。

     

     

    元数据采集服务

    在数据治理项目中,通常涉及到的元数据还包括:数据源的元数据,数据加工处理过程的元数据,数据仓库或数据主题库的元数据,数据应用层的元数据,数据接口服务的元数据等等。元数据采集服务提供各类适配器满足以上各类元数据的采集,并将元数据整合处理后统一存储于中央元数据仓库,实现元数据的统一管理。这个过程中,数据采集适配器十分重要,元数据采集要能够适配各种DB、各类ETL、各类DW和Report产品,同时还需要适配各类结构化或半结构化数据源。目前市场上的主流元数据产品还没有哪一家能做到“万能适配”,都需要在实际应用过程中做或多或少的定制化开发。

    元模型驱动的设计与开发

    通过元数据管理平台实现对应用的逻辑模型、物理模型、UI模型等各类元模型管理,支撑应用的设计和开发。应用开发的元模型有三个状态,分别是:设计态的元数据模型,通常由ERWin、PowerDesigner的等设计工具产生。测试态的元数据模型,通常是关系型数据:Oracle、DB2、Mysql、Teradata等,或非关系型数据库:MongDB、HBase、Hive、Hadoop等。生产态的元模型,本质上与测试态元数据差异不大。通过元数据平台对应用开发三种状态的统一管理和对比分析,能够有效降低元数据变更带来的风险,为下游ODS、DW的数据应用提供支撑。另外,基于元数据的MDD(代码生成服务),可以通过模型(元数据)完成业务对象元数据到UI元数据的关联和转换,自动生成相关代码,表单界面,减少了开发人员的设计和编码量,提升应用和服务的开发效率。

     

    元数据管理服务

    市场上主流的元数据管理产品,基本都包括:元数据查询、元模型管理、元数据维护、元数据版本管理、元数据对比分析、元数据适配器、元数据同步管理、元数据生命周期管理等功能。此类功能,各家产品大同小异,此处不再赘述。

    元数据访问服务

    元数据访问服务是元数据管理软件提供的元数据访问的接口服务,一般支持REST或Webservice等接口协议。通过元数据访问服务支持企业元数据的共享,是企业数据治理的基础。

     

    元数据分析服务

     

    血缘分析:是告诉你数据来自哪里,都经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系,追根溯源,快速地定位到问题数据的来源和加工过程,减少数据问题排查分析的时间和难度。这个功能常用于数据分析发现数据问题时,快速定位和找到数据问题的原因。

     

    影响分析:是告诉你数据都去了哪里,经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系,向下追踪,快速找到都哪些应用或数据库使用了这个数据,从而避免或降低数据问题带来的更大的影响。这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用应用的影响分析。

     

    冷热度分析:是告诉你哪些数据是企业常用数据,哪些数据属于“僵死数据”。其价值在于让数据活跃程度可视化,让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度,以便更好的驾驭数据,激活或处置“僵死数据”,从而为实现数据的自助式分析提供支撑。

     

    关联度分析:是告诉你数据和其他数据的关系以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况,形成一张实体和所参与处理过程的网络,从而进一步了解该实体的重要程度,如:表与ETL 程序、表与分析应用、表与其他表的关联情况等。本功能可以用来支撑需求变更的影响评估。

     

    数据资产地图:是告诉你有哪些数据,在哪里可以找到这些数据,能用这些数据干什么。通过元数据可以对企业数据进行完整的梳理、采集和整合,从而形成企业完整的数据资产地图。数据资产地图支持以拓扑图的形式进行可视化展示各类元数据和数据处理过程,通过不同层次的图形展现粒度控制,满足业务上不同应用场景的数据查询和辅助分析需要。

     

    元数据管理价值

     

    一图在手,天下我有

    通过元数据以企业全局视角对企业各业务域的数据资产进行盘点,实现企业数据资源的统一梳理和盘查,有助于发现分布在不同系统、位置或个人电脑的数据,让隐匿的数据显性化。数据地图包括了数据资源的基本信息,存储位置信息、数据结构信息、各数据之间关系信息,数据和人之间的关系信息,数据使用情况信息等,使数据资源信息详细、统一、透明,降低“找数据”的沟通成本,为数据的使用和大数据挖掘提供支撑。

     

    追根溯源,发现数据问题本质

    企业在做数据分析的时候,数据分析结果不正确,原因可能是数据分析过程出现数据问题,也可能是数据源本身就有问题,还可能是数据在加工处理过程中出现了数据问题……。通过元数据血缘分析,能够快速定位数据来源和加工处理过程,能够帮助数据分析人员快速定位数据问题。另外,通过元数据血缘关系分析,可以理解不同数据指标间的关系,分析产生指标的数据源头波动情况带来的影响。

     

    模型驱动,敏捷开发

    基于元数据模型的数据应用规划、设计和开发是企业数据应用的一个高级阶段。当企业元数据管理达到一定水平(实现自动化管理的时候),企业中各类数据实体模型、数据关系模型、数据服务模型、数据应用模型的元数据统一在元数据平台进行管理,并自动更新数据间的关联关系。基于元数据、可扩展的MDA,才是快速满足企业数据应用个性化定制需求的最好解决方案。通过将大量的业务进行模型抽象,使用元数据进行业务描述,并通过相应的模型驱动引擎在运行时驱动,使用高度抽象的领域业务模型作为构件,完成代码转换,动态生成相关代码,降低开发成本,应对复杂需求变更。

     

     

    总结:

    元数据是企业数据资源的应用字典和操作指南,元数据管理有利于统一数据口径、标明数据方位、分析数据关系、管理数据变更,为企业级的数据战略规划、数据模型设计、数据标准管理、主数据管理、数据质量管理、数据安全管理以及数据的全生命周期管理提供支持,是企业实现数据自服务、推动企业数据化运营的可行路线。企业以元数据为抓手进行数据治理,帮助企业更好地对数据资产进行管理,理清数据之间的关系,实现精准高效的分析和决策。

    注:本文的首发平台为微信公众号:learning-bigdata(谈数据),如需要了解第一手数据治理相关内容,请关注微信公众号,CSDN微博不定期更新。

    欢迎转载,转载请注明,作者:石秀峰,公众号:learning-bigdata(谈数据)

     

    展开全文
  • 在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical ...

    原文地址

    一、元数据的定义

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

    技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据,它主要包括以下信息:

    数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据的定义,以及数据集市的位置和内容;
    业务系统、数据仓库和数据集市的体系结构和模式
    汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚集、汇总、预定义的查询与报告;
    由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全(用户授权和存取控制)。
    业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法以及公式和报表的信息;具体包括以下信息:

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

    二、元数据的作用

    与其说数据仓库是软件开发项目,还不如说是系统集成项目,因为它的主要工作是把所需的数据仓库工具集成在一起,完成数据的抽取、转换和加载,OLAP分析和数据挖掘等。如下图所示,它的典型结构由操作环境层、数据仓库层和业务层等组成。

    在这里插入图片描述

    其中,第一层(操作环境层)是指整个企业内有关业务的OLTP系统和一些外部数据源;第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层;第三层是为了完成对业务数据的分析而由各种工具组成的业务层。图中左边的部分是元数据管理,它起到了承上启下的作用,具体体现在以下几个方面:

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

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

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

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

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

    原文地址

    展开全文
  • 浅谈元数据管理之Atlas和Metacat

    千次阅读 2020-05-27 15:51:30
    元数据管理、血统采集、血统生命周期、数据地图、图数据库

    关键字:元数据管理、血统采集、血统生命周期、图数据库、数据地图

    元数据管理概述

    元数据是描述数据的数据(data about data),是指从信息资源中抽取出来用于描述其特征与内容的数据,从一般意义上来讲,元数据是指数据的类型、名称、和值等;在关系型数据库中,常常指数据表的属性、取值范围、数据来源,以及数据之间的关系等。
    元数据的管理有着十分重要的作用,它能够为数据用户提供完整的数据定义信息,减少数据冗余,有利于识别与查找数据。同时,能够追踪数据在数据库中发生的任何变化,帮助用户理解数据在整个血统生命周期的来龙去脉,实现简单高效地管理大数据系统中的海量数据,并且通过数据资源的有效追踪、发现、查找来挖掘大数据系统中数据的价值。
    在大数据治理活动中,元数据与元数据管理有以下要点。
    (1)数据管理
    数据管理要求能够追踪数据的整个生命周期,包括数据的来源、数据的修改与删除,并能够支持快速的检索。
    (2)元数据建模
    元数据建模通过结合标签与数据属性的方式来更好地理解数据及生命周期,从而实现对元数据的快速建模。
    (3)易于交互的解决方案
    通过建立统一的、贯穿Hadoop生态系统的元数据库,定义统一的元数据标准,为系统中不同组件的元数据信息进行交互提供基础。

    元数据管理工具Apache Atlas

    Apache Atlas是一个可伸缩和可扩展的元数据管理工具与大数据治理服务,其设计的目的是为了与其他大数据系统组件交换元数据,改变以往标准各异、各自为战的元数据管理方式,构建统一的元数据库与元数据定义标准,并且与Hadoop生态系统中各类组件相集成,建立统一、高效且可扩展的元数据管理平台。
    对于需要元数据驱动的企业级Hadoop系统来说,Apache Atlas提供了可扩展的管理方式,并且能够十分方便的支持对新的商业流程和数据资产进行建模。其内置的系统类型(Type System)允许Atlas与Hadoop大数据生态系统之内或之外的各种大数据组件进行元数据交换,这使得建立与平台无关的大数据管理系统成为可能。同时,面对不同系统之间的差异以及需求的一致性问题,Atlas都提供了十分有效的解决方案。
    Atlas能够在满足企业对Hadoop生态系统的预设要求的条件下,高效地与企业的平台的所有生态系统组件进行集成。同时,Atlas可以应用预先设定的模型在Hadoop中实现数据的可视化,提供易于操作的审计功能,并通过数据血统查询来丰富企业的各类商业元数据。它也能够让任何元数据消费者与其相互协作而不需要在两者之间构建分离的接口。另外,Atlas中的元数据的准确性和安全性由Apache Ranger来保证,Ranger能够在运行时阻止那些不具备权限的数据访问请求。

    Apache Atlas提供的大数据治理的核心治理服务

    1、元数据交换:允许从当前的组件导入已存在的元数据或模型到Atlas中,也允许导出元数据到下游系统中。
    2、数据血统采集:Atlas在平台层次上,针对Hadoop组件抓取数据血统信息,并根据数据血统间的关系构建数据的血统生命周期。
    3、数据血统生命周期可视化:通过Web服务将数据血统生命周期以可视化的方式展现给客户。
    4、快速数据建模:Atlas内置的类型系统允许通过继承已有类型的方式来自定义元数据结构,以满足新的商业场景的需求。
    5、丰富的API:提供了目前比较流行且灵活的方式,能够对Atlas服务、HDP组件、UI及外部组件及外部组件进行访问。

    Apache Atlas的主要特性

    1、数据分类
    (1)Atlas提供了导入或定义数据注释的功能,这些数据注释可以根据具体的商业业务分类来定义。通过这些分类后的数据注释,可以实现数据分类的功能。
    (2)Atlas提供了定义、添加注释以及自动获取数据集与基础元素之间关系的功能,这些基础元素包括数据源、数据目标及其衍生的过程。
    (3)向第三方系统导出元数据。
    2、集中审计
    (1)对于每一个访问数据的应用以及交互过程,Atlas会抓取其安全访问信息。
    (2)对于每一个执行的操作活动及其具体步骤,Atlas能够将这些操作信息抓取下来。
    3、搜索与数据血统
    (1)在Atlas中,用户可以预先定义访问路径,并通过这些路径来浏览数据分类与数据审计的信息。
    (2)用户利用Atlas全文搜索这一特性,可以快速与准确地定位相关数据及审计事件。
    (3)可视化的数据血统允许用户深入挖掘数据具体的来源、操作方式以及安全策略等整个数据血统生命周期中的各类信息。
    4、安全与策略引擎
    (1)基于数据分类的计划、属性和角色,Atlas使得数据管理策略间的关系更加合理化。
    (2)通过数据分类,Atlas也支持自定义策略以防止数据不适当的衍生
    (3)通过数据表项中的值或者属性,Atlas支持对数据表中的列或者行添加标签。

    Apache Atlas 架构

    Apache Atlas的各组成部分的架构图如下图所示。
    Atlas 架构图
    1、元数据源(Metadata Sources)
    Atlas支持与多种数据源相互整合,在未来会有更多的数据源被整合到Atlas之中。目前,导入与管理的数据源有Hive、Sqoop、Falcon、Storm和Hbase。
    这意味着:在Atlas中定义了原生的元数据模型来表示这些组件的各种对象;Atlas 中提供了相应的模块从这些组件中导入元数据对象,包括实时导入(HOOK)和批处理 (Batch)导入两种方式。
    2、应用简介(Apps)
    在Atlas的元数据库中存储着各种组件的元数据,这些元数据将被各式各样的应用所使用,以满足各种现实业务与大数据治理的需要。
    (1) Atlas管理界面:作为其中的一个应用是基于Web UI方式的,它允许管理员与数据科学家发现元数据信息和添加元数据注解。在诸多主要的功能中,Atlas提供了搜索接口与类SQL语言,这些特性在Atlas的架构中扮演着十分重要的角色,它们能够被用于查询Atlas中的元数据类型和对象。另外,该管理界面使用Atlas的REST API来构建它的功能。
    (2)基于各种策略的标签验证:对于整合了诸多Hadoop组件的Hadoop生态系统, Apache Ranger是一个高级安全解决方案。通过与Atlas整合,Ranger允许管理员自定义元数据的安全驱动策略来对大数据进行高效的治理。当元数据库中的元数据发生改变时,Atlas会以发送事件的方式通知Ranger。
    (3)商业业务分类:从各类元数据源中导入Atlas的元数据以最原始的形式存储在元数据库中,这些元数据还保留了许多技术特征。为了加强挖掘与治理大数据的能力,Atlas提供了一个商业业务分类接口,允许用户对其商业领域内的各种术语建立一个具有层次结构的术语集合,并将它们整合成能够被Atlas管理的元数据实体。商业业务分类这一应用,目前是作为Atlas管理界面的一部分而存在的,它通过REST API来与Atlas 集成。
    3、集成交互模块(Integration)
    Atlas提供了两种方式供用户管理元数据。
    (1)API : Atlas的所有功能都可以通过REST API的方式暴露给用户,以便用户可以对 Atlas中的类型和实体进行创建、更新和删除等操作。同时REST API也是Atlas中查询类型和实体的主要机制。
    (2)消息(Messaging)系统:除了 REST API,用户可以选择基于Kafka的消息接口来与Atlas集成。这种方式有利于与Atlas进行元数据对象的交换,也有利于其他应用对Atlas中的元数据事件进行获取和消费。当用户需要以一种松耦合的方式来集成Atlas时,消息系统接口变得尤为重要,因为它能提供更好的可扩展性和稳定性。在Atlas中,使用Kafka作为消息通知的服务器,从而使得上游不同组件的钩子(HOOK)能够与元数据事件的下游消费者进行交互。这些事件被Atlas的钩子所创建,并冠以不同的Kafka主题。
    4、核心(Core)模块
    在Atlas的架构中,其核心组成部分为其核心功能提供了最为重要的支持。
    (1)类型系统(Type System) : Apache Atlas允许用户根据自身需求来对元数据对象进行建模。这样的模型由被称为“类型”(Type)的概念组成,类型的实例被称为“实体” (Entity),实体能够呈现出元数据管理系统中实际元数据对象的具体内容。同时,Atlas中的这一建模特点允许系统管理员定义具有技术性质的元数据和具有商业性质的元数据,这也使得在Atlas的两个特性之间定义丰富的关系成为可能。
    (2)导入/导出(Ingest/Export) : Atlas中的导入模块允许将元数据添加到Atlas中,而导出模块将元数据的状态暴露出来,当状态发生改变时,便会生成相应的事件。下游的消费者组件会获取并消费这一事件,从而实时地对元数据的改变做出响应。
    (3)图引擎(Graph Engine):在Atlas内部,Atlas使用图模型(一种数据结构)来表示 元数据对象,这一表示方法的优势在于可以获得更好的灵活性,同时有利于在不同元数据 对象之间建立丰富的关系。图引擎负责对类型系统中的类型和实体进行转换,并与底层图 模型进行交互。除了管理图对象,图引擎也负责为元数据对象创建合适的索引,使得搜索 元数据变得更为高效。
    (4)Graph Engine:在内部,Atlas保留使用Graph模型管理的元数据对象。这种方法提供了极大的灵活性,并可以有效处理元数据对象之间的丰富关系。图引擎组件负责在Atlas类型系统的类型和实体以及基础图持久性模型之间进行转换。除了管理图形对象外,图形引擎还为元数据对象创建适当的索引,以便可以有效地搜索它们。Atlas使用JanusGraph(图数据库)存储元数据对象。默认情况下,Atlas使用独立的HBase实例作为JanusGraph(图数据库)的后备存储。为了为元数据存储提供HA,我们建议将Atlas配置为使用分布式HBase作为JanusGraph(图数据库)的后备存储。这样做意味着您可以从HBase提供的HA保证中受益。Atlas通过JanusGraph(图数据库)索引元数据以支持全文本搜索查询,为了为索引存储提供HA,官方建议将Atlas配置为使用Solr或Elasticsearch作为JanusGraph(图数据库)的后备索引存储,从而提高搜索的效率。

    Apache Altas的技术优势

    1、定义统一的元数据标准
    元数据的标准大致可以分为两类:一类是指元数据建模,即对将来的元数据的建模规范进行定义,使得元数据建模的标准在制定之后,所产生的元数据都以统一的方式建模和组织,从而保证了元数据管理的一致性。另一类是指元数据的交互,是对已有的元数据组织方式以及相互交互的格式加以规范定义,从而实现不同组件、不同系统之间的元数据交互。
    Apache Atlas核心中的Type System (类型系统)为定义统一的元数据标准提供了最重 要的支持。在Atlas的类型系统中定义了 3个概念,分别是类型、实体和属性。若将其与面向对象语言中的类、对象和属性类比,这3个概念就变得十分易于理解了。
    在类型系统中,类型是对某一类元数据的描述,定义了某一类元数据由哪些属性组成, 属性的属性值也需要定义为某一类型。在元数据管理的实际应用中,Atlas从数据源获取某一个元数据对象时,会根据其隶属的类型建立相应的实体,这个实体就是该元数据对象在 Atlas中的表示。
    在Atlas的类型系统中,元型可分为基本元型、集合元型、复合元型,所有的类型都 是基于这些元型来定义的。同时,Atlas中也提供了若干预置的类型,用户可以直接使用这些类型,或者通过继承的方式来复用这些类型。正是由于所有类型的背后都是统一的元型, 并且所有类型都是继承自某些预置的类型,这实际上就给元数据对象的建模定义了标准。 这样统一的规范和标准使得高效且可靠的元数据交换成为可能。
    2、高效的元数据获取与交换体系
    为了建立可扩展、松耦合的元数据管理体系,Apache Atlas支持多种元数据获取方式,并且针对大数据生态系统中的不同组件,其元数据的获取方式是相互独立的,这就满足了大数据系统高内聚和低耦合的要求。另外,Apache Atlas的元数据库是唯一的,统一的元数据库保证了元数据的一致性,减少了元数据交换过程中不必要的转换,使不同组件之间的元数据交换高效而稳定。
    Apache Atlas获取元数据包括Batch批处理和HOOK两种方式。对于通过Batch批处理的方式获取元数据。在该方式中,Atlas允许用户执行某一脚本获取相应组件的元数据信息,将该组件的元数据信息更新到元数据库中。即,当用户不执行获取元数据的脚本时,相应组件的数据变更不会导致Atlas元数据库中的信息变更;当用户执行获取元数据的脚本时,相应组件中若存在数据的变更,Atlas就会将其所有新增的元数据信息存入元数据库中。
    对于通过HOOK的方式获取元数据,针对每一种组件,都有相应的HOOK,用户可以根据自身需要针对不同组件对HOOK进行配置。当配置完成后,相应组件的HOOK会监听该组件的各种操作,一旦该组件的状态发生变化,HOOK会自动创建相应的元数据对象,并发送给Atlas 处理。
    使用Kafka作为消息通知系统(Notification)。即不同组件只需要与Kafka进行交互,再由Kafka将元数据对象封装成消息传递给Atlas。当向Atlas元数据管理系统中添加新的大数据组件时,只需要将遵循Kafka规范的HOOK添加到系统之中,即可让Atlas对这一新的组件进行管理,从而满足了元数据管理系统的高扩展性要求。
    3、允许针对不同商业对象进行元数据建模
    以往的元数据管理组件考虑了用户的诸多需求,为用户设计了诸多的元数据类型,但这种设计思想往往也限制了元数据管理组件的应用。因为不管元数据管理组件的设计者如何高明,也难以概括实际商业场景中涉及的所有元数据对象,因此在使用以往的元数据管理组件时,用户常常会遇到实际商业场景中的元数据对象与组件提供的建模模型不匹配的情况,只能选择近似的类型对实际场景中的元数据对象进行建模,这使得元数据的管理极为不便。
    但Apache Atlas有所不同,它提供了若干的预置类型,这些类型的背后也定义了统一且易于复用的元数据对象的元型,并且允许用户通过继承的方式来创建符合实际需求的元数据类型,这就极大地满足了用户对于不同商业对象进行建模的需求,解决了其他元数据管理组件难以匹配所有商业场景中元数据对象的难题。
    4、可视化的血统采集与血统生命周期
    Apache Atlas能够通过批处理或者HOOK的方式从元数据源获取元数据信息,前者需要用户手动运行脚本来执行,后者则会自动监听相应组件的各类操作。无论采取怎样的方 式,从各类组件获取的元数据对象是十分丰富与多样的,包括血统采集的数据源和采集方式,被采集血统的结构,血统的状态变化及其相应操作,以及数据最后被删除等各种元数据对象信息。这些信息都会被包装成相应的元数据类型,并生成对应的元数据实体,通过消息通知系统发送给Atlas并存储到元数据库中。
    但Atlas并不是简单地将这一系列的元数据信息直接存入元数据库中,而是将它们之间的关系也存入元数据库中(图数据库)。同时,为了更好地表示元数据之间的关系,Atlas在其Web UI 中提供了对于数据血统的可视化显示,能够为用户提供直观且明晰的数据地图及血统生命周期, 使得用户从一幅数据血统图中就能够了解数据从进入大数据系统开始,到中间经历的各种变化,到最后从大数据系统中消亡的整个数据血统生命周期(见下图)。
    数据血统图

    元数据管理工具Netflix Metadata

    Netflix公司的数据存储在Amazon S3、Druid、Elasticsearch、Redshift、Snowflake和 MySql 中。并且需要使用Spark、Presto、Pig和Hive消费、处理和生成数据集。因为数据源的多样性,为了确保数据平台能够横跨这些数据集成为一个“单一”的数据仓库,应用而生了Metacat。Metacat是一种元数据服务,方便发现、处理和管理数据。

    Metacat的目标

    1、元数据系统的联合视图(所有数据存储的元数据访问层)
    2、用于数据集元数据的统一API(各种计算引擎可以用来访问不同数据集的集中式服务)
    3、数据集的任意业务和用户元数据存储

    Metadata应用架构

    Metacat应用架构图
    1、数据源(Data Source):支持RDS、AMAZON REDSHIFT、HIVE、Druid、Snowflke
    2、计算引擎(Compute):支持Pig、HIVE、Spark、presto

    Metacat的架构图

    Metacat架构图
    Metacat是一种联合服务,提供统一的REST/Thrift接口来访问各种数据存储的元数据。元数据存储仍然是模式元数据的事实来源,所以Metacat没有保存这部分元数据。Metacat只保存业务相关和用户定义的元数据。它还将所有关于数据集的信息发布到Elasticsearch,以便进行全文搜索和发现。
    Metacat的功能可以分为以下几类:
    1、数据抽象和互操作性
    2、业务和用户定义的元数据存储
    3、数据发现
    4、数据变更审计和通知
    5、Hive Metastore优化

    数据抽象和互操作性

    Netflix使用多种查询引擎(如Pig、Spark、Presto和Hive)来处理和使用数据。通过引入通用的抽象层,不同的引擎可以交互访问这些数据集。例如:从Hive读取数据的Pig脚本能够从Hive列类型的表中读取数据,并转成Pig类型。在将数据从一个数据存储移动到另一个数据存储时,Metacat通过在目标数据存储中创建具有目标类型的表来简化这一过程。Metacat提供了一组预定义的数据类型,可将这些类型映射到各个数据存储中的数据类型。例如,我们的数据移动工具使用上述功能将数据从Hive移动到Redshift或Snowflake。
    Metacat的Thrift服务支持Hive的Thrift接口,便于与Spark和Presto集成。我们因此能够通过一个系统汇集所有的元数据变更,并发布有关这些变更的通知,实现基于数据驱动的ETL。当新数据到达时,Metacat可以通知相关作业开始工作。

    业务和用户定义的元数据

    Metacat也会保存数据集的业务和用户定义元数据。我们目前使用业务元数据来存储连接信息(例如RDS数据源)、配置信息、度量指标(Hive/S3分区和表)以及数据表的TTL(生存时间)等。顾名思义,用户定义的元数据是一种自由格式的元数据,可由用户根据自己的用途进行定义。
    业务元数据也可以大致分为逻辑元数据和物理元数据。有关逻辑结构(如表)的业务元数据被视为逻辑元数据。我们使用元数据进行数据分类和标准化我们的ETL处理流程。数据表的所有者可在业务元数据中提供数据表的审计信息。他们还可以为列提供默认值和验证规则,在写入数据时会用到这些。
    存储在表中或分区中的实际数据的元数据被视为物理元数据。我们的ETL处理在完成作业时会保存数据的度量标准,在稍后用于验证。相同的度量可用来分析数据的成本和空间。因为两个表可以指向相同的位置(如Hive),所以要能够区分逻辑元数据与物理元数据。两个表可以具有相同的物理元数据,但应该具有不同的逻辑元数据。

    数据发现

    作为数据的消费者,我们应该能够轻松发现和浏览各种数据集。Metacat将模式元数据和业务及用户定义的元数据发布到Elasticsearch,以便进行全文搜索。我们的Big Data Portal SQL编辑器因此能够实现SQL语句的自动建设和自动完成功能。将数据集组织为目录有助于消费者浏览信息,根据不同的主题使用标签对数据进行分类。我们还使用标签来识别表格,进行数据生命周期管理。

    数据变更通知和审计

    作为数据存储的中央网关,Metacat将捕获所有元数据变更和数据更新。我们还围绕数据表和分区变更开发了通知推送系统。目前,我们正在使用此机制将事件发布到我们自己的数据管道(Keystone),以更好地了解数据的使用情况和趋势。我们也将事件发布到Amazon SNS。我们正在将我们的数据平台架构发展为基于事件驱动的架构。将事件发布到SNS可以让我们数据平台中的其他系统对这些元数据或数据变更做出“反应”。例如,在删除数据表时,我们的S3数据仓库管理员服务可以订阅这些事件,并适当地清理S3上的数据。

    Hive Metastore优化

    由RDS支持的Hive Metastore在高负载下表现不佳。我们已经注意到,在使用元数据存储API写入和读取分区方面存在很多问题。为此,我们不再使用这些API。我们对Hive连接器(在读写分区时,该连接器直接与RDS通信)进行了改进。之前,添加数千个分区的Hive Metastore调用通常会超时,在重新实现后,这不再是个问题。

    Metacat 待增强的特性

    1、模式和元数据的版本控制,用于提供数据表的历史记录。例如,跟踪特定列的元数据变更,或查看表的大小随时间变化的趋势。能够查看过去某个时刻元数据的信息对于审计、调试以及重新处理和回滚来说都非常有用。
    2、为数据lineage服务提供数据表的上下文信息。例如,在Metacat中汇总数据表访问频率等元数据,并发布到数据lineage服务中,用于对数据表的关键性程度进行排序。
    3、增加对Elasticsearch和Kafka等数据存储的支持。
    4、可插拔的元数据验证。由于业务和用户定义的元数据是自由形式的,为了保持元数据的完整性,我们需要对其进行验证。Metacat应该有一个可插拔的架构,可在存储元数据之前执行验证策略

    Atlas和Metacat的主要区别

    1、血统采集(数据源):Atlas支持数据源有Hive、Sqoop、Falcon、Storm和Hbase。Metacat支持的数据源RDS、AMAZON REDSHIFT、HIVE、Druid、Snowflke。
    Atlas血统采集是从所支持的数据源进行导入元数据,而Metacat是直接获取相对应的所支持数据库的元数据。
    2、元数据管理的模式:Atlas需要按照统一元数据规则,对元数据进行配置导入。而Metacat是直接从所支持的数据源中获取各自的元数据,对源数据库的元数据进行相应的转换,以形成元数据系统的联合视图,从而达到查询引擎交互查询不同数据系统的目的。
    Atlas的Type System满足所支持的所有数据系统元数据标准,而且它允许我们通过继承它的预定义类型来实现符合我们自己需求的元数据类型。Metacat也可以根据业务需求定义自己的元数据,但它是直接在数据源的数据库中进行定义。
    3、血统的生命周期:Altas利用图数据库提供了UI界面,可直观的看到血统的生命周期。Metacat没有相应的UI界面,它将数据集组织为目录帮助消费者浏览信息,它使用标签来识别表格,进行血统的生命周期管理。
    4、图数据库:Atlas应用了JanusGraph作为源数据的图数据库,并用Hbase作为图数据库的后备存储,同时Atlas为实现通过图数据库索引元数据以支持全文本搜索查询,官网建议将Solr或Elasticsearch作为JanusGraph(图数据库)的后备索引存储,从而提高搜索的效率。Metacat将关于元数据的所有信息存储到Elasticsearch中。
    5、数据地图:Atlas所提供的UI界面不仅可以看到血统的生命周期,而且还可以确定目标数据是由那些来源数据所形成,同时也可以定位到各个来源数据所属的数据系统甚至可以定位到那个库的那个表。Altas同时支持数据字段的来源追踪。这对数据异常的追踪和定位提供了极大的方便。Metacat可以通过Elasticsearch查询元数据的相关信息,进行相应数据管理。
    6、数据状态的检测:Atlas中的导出模块,将元数据的状态暴露出来,一旦状态发生改变,将会生成相应的事件,下游的消费者会获取到相应的事件,并实时的作出元数据状态的响应。Metacat可以对所有元数据和数据的变更进行捕获,通过消息推送系统将事件推送到外部的数据管道,来了解数据的使用情况及趋势。
    7、组件的可扩展性:Atlas扩展新的大数据组件时,只需要将组件的HOOK按照kafka的规范添加到系统中即可,这样Atlas就可以对这一新的组件进行管理。Metacat扩展新的数据源时需要进行相应的开发,这也是Metacat未来待增强的特性之一。
    8、Hive Metastore:Atlas和Metacat支持的数据源都有Hive,但Atlas使用的是传统的Hive Metastore,而Metacat对传统的Hive Metastore进行了相应的改进,避免了添加数千个分区的Hive Metastore调用时会发生超时的问题。
    9、元数据的验证:Atlas通过集成Apache Ranger来保证元数据的准确性及安全性,并能够在运行时阻止那些没有权限的数据访问请求。Metacat对于可拔插的元数据验证架构还是其将来待增强的特性之一。

    如有不当之处,请不吝赐教。

    参考文献:《大数据治理与安全:从理论到开源实践》–刘驰等编著 2017.8
    参考博客:https://www.codercto.com/a/19908.html

    展开全文
  • 数据治理里面最关键的元数据管理,元数据打通数据源、数据仓库、数据应用,记录了数据从产生到消费的完整链路。它包含静态的表、列、分区信息(也就是MetaStore);动态的任务、表依赖映射关系;数据仓库的模型定义...
  • 一篇文章搞懂数据仓库:元数据分类、元数据管理

    千次阅读 多人点赞 2020-12-31 15:41:39
    业务元数据 描述 ”数据”背后的业务含义 主题定义:每段 ETL、表背后的归属业务主题。 业务描述:每段代码实现的具体业务逻辑。 标准指标:类似于 BI 中的语义层、数仓中的一致性事实;将分析中的指标进行规范化...
  • Atlas(1):前言-从元数据到元数据管理

    万次阅读 2021-01-08 20:07:37
    而数据治理的关键就在于元数据管理,我们要知道数据的来龙去脉,才能对数据进行全方位的管理,监控,洞察。 “元数据管理是企业数据治理的基础”,在数据治理战略实施的时候,这是我们经常会听到看到的一句话。但是...
  • 大数据平台-元数据管理系统解析

    万次阅读 多人点赞 2018-03-14 09:25:24
    什么是元数据?在前面的集成开发环境建设相关文章中,我们也提到过,元数据MetaData狭义的解释是用来描述数据的数据,广义的来看,除了业务逻辑直接读写处理的那些业务数据,所有其它用来维持整个系统运转所需的信息...
  • 数据仓库元数据管理

    千次阅读 2018-09-21 16:11:56
    数据仓库元数据管理元数据元数据分类技术元数据业务元数据系统管理功能 元数据 元数据(Meta Date),主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元...
  • 元数据管理系统产品选型分析 1 概述 需要给目前数据仓库适用一套元数据管理系统,目的 减少人为的维护工作量、web页面协同工作(多人统一入口使用)、元数据权限管理等 1.1 应用背景 目前数据仓库没有专业的...
  • 元数据管理系统设计

    千次阅读 2019-08-15 10:55:43
    文章目录元数据管理系统设计1. 数据表管理模块2. 模型管理模块2.1 数据表模型管理2.2 SQL模型3. 维度管理模块4. 指标管理模块 元数据管理系统设计 1. 数据表管理模块 数据表信息维护需要如下信息: 表的元数据...
  • 数据治理---Apache Atlas元数据管理

    千次阅读 2020-08-05 09:43:56
    采用Hadoop必须考虑数据管理的实际情况,元数据与数据治理成为企业级数据湖的重要部分。 为寻求数据治理的开源解决方案,Hortonworks 公司联合其他厂商与用户于2015年发起数据治理倡议,包括数据分类、集中策略引擎...
  • Curve技术解析之MDS元数据管理

    万次阅读 2020-11-18 20:52:03
    curve简介 curve是今年7月份开源的一个⾼性能、⾼可⽤、⾼可靠的分布式存储系统,...k8s上主要是想作为计算节点的数据⽬录,这个场景⽬前在灰度环境中测试验证中。 当前curve的整个项目已经完全开源到github,感兴
  • 元数据管理系统

    千次阅读 2019-01-10 16:53:00
    数据标准是元数据管理中很重要的内容,但是建立有效的数据标准并落地,是有一定难度的,传统的元数据管理的模式需要建立一套规范元数据模型,即使企业实际元数据模型中有上万个字段,也需要将每个字段于规范元数据...
  • 数据仓库建设之《元数据管理

    千次阅读 2019-01-23 11:34:42
    元数据管理作为大数据治理的核心,是有效管理这些数据的基础和前提,在信息化建设中发挥着重要的作用。如何理解、管理并发挥出元数据的价值,成为迫切的任务。 一、什么是元数据  元数据(Metadata)是关于数据的...
  • 元数据管理的核心功能及使用?

    千次阅读 2019-06-14 14:58:35
    1、什么是元数据管理? 企业用户在创建了众多数据库信息时,需要一个查询功能可以及时高效地为用户查询数据库信息,如数据源、表以及视图等信息。DataPipeline元数据管理功能可以为用户降低时间成本,提高查询效率。...
  • 目前,很多企业已经意识到,由于业务人员看不懂系统中存储的数据,所以难以通过大数据来提升业务创新能力,本文就来谈谈解决这个问题的方法——业务元数据管理。(同系列文章请点击王轩的文章《面向业务的企业元数据...
  • 元数据管理是数据治理非常重要的一个方向,元数据的一致性,可追溯性,是实现数据治理非常重要的一个环节。传统数据情况下,有过多种相对成熟的元数据管理工具,而大数据时代,基于hadoop,最为成熟的,与Hadoop...
  • 大数据平台的元数据管理

    千次阅读 2019-03-23 00:27:17
    2,大数据平台涉及的元数据——由大数据作业的业务逻辑直接读写处理的业务数据,都不是元数据,除此之外的数据都是元数据。例如数据表的schema信息、任务之间的血缘关系、任务的权限映射关系、数据的业务属性、数据...
  • Marquez,开源的元数据管理工具

    千次阅读 2020-07-06 18:56:03
    Marquez是一款开源的元数据服务,用于数据生态系统元数据的收集、汇总... 集中式元数据管理支持: 数据血缘(Data Lineage) 数据治理(Data governance) 数据健康检查(Data health) 数据发现+探索(Data...
  • 数据仓库(五)元数据管理

    万次阅读 多人点赞 2018-09-20 21:47:03
    概述 元数据通常定义为”关于数据的...元数据贯穿了数据仓库的整个生命周期,使用元数据驱动数据仓库的开发,使数据仓库自动化,可视化。  元数据类型   1.业务元数据  业务元数据指从业务角度描述业务...
  • 但是其实没有一个统一的概念说明元数据管理的边界应该是什么,所以大家的做法会有所不同,有些元数据管理还会把数据质量模块也加入进来,有些可能是独立出来一个监控数据质量的模块,当然大家的目的都是想实现数仓的...
  • 数仓学习笔记_hive元数据管理

    千次阅读 2019-05-24 15:00:18
    hive元数据管理 我们通常会使用MySQL管理hive的元数据,只要在hive-site.xml中写入库路径、连接驱动、用户名和密码即可。 但是在企业中,我们可以使用统一元数据管理:EMR 相较于MySQL,EMR有如下优点 EMR中的数据...
  • Atlas-元数据管理

    千次阅读 2019-05-18 18:55:42
    0. 当我们谈论数据治理/元数据管理的时候,我们究竟在讨论什么?谈到数据治理,自然离不开元数据。元数据(Metadata),用一句话定义就是:描述数据的数据。元数据打通了...
  • 经过这些年的发展,国内外厂商在元数据管理能力的建设上有了一定的经验积累,此篇文章分析了国内外市场现状,指出企业级元数据管理正吸引着越来越多的厂商关注,有望成为未来元数据管理的主流方向,提出了企业级...
  • kafka架构之zookeeper元数据管理

    千次阅读 2018-05-30 14:27:31
    kafka是如何通过zookeeper进行元数据管理的呢?首先我们来看一下安装好一个kafka集群之后,对应zookeeper会出现哪些目录?概括为一A一B四个C,如下图:首先在zookeeper的根目录下面会出现以下目录:admin ----/...
  • HDFS元数据管理机制

    千次阅读 2018-02-20 23:43:09
    一、元数据管理概述 HDFS 元数据,按类型分,主要包括以下几个部分: 1、文件、目录自身的属性信息,例如文件名,目录名,修改信息等。 2、文件记录的信息的存储相关的信息,例如存储块信息,分块情况,副本个数等...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 428,317
精华内容 171,326
关键字:

元数据管理