精华内容
下载资源
问答
  • 聊一聊数据仓库中的元数据管理系统
    万次阅读
    2017-08-18 14:33:18

    原文地址


    一、元数据的定义

    按照传统的定义,元数据(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文件流的方式进行交换。

    原文地址



    更多相关内容
  • 数据管理系统设计

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

    元数据管理系统设计

    在这里插入图片描述

    1. 数据表管理模块

    数据表信息维护需要如下信息:

    • 表的元数据信息(引擎、字段等)

    • 表类型(维表或事实表)

    • 表的使用情况(是否被模型使用)

    • 表对应的ETL

    • 描述信息

    • 表的所有人

    • 表的建表语句

    2. 模型管理模块

    模型分为 数据表模型 和 SQL模型

    2.1 数据表模型管理

    在这里插入图片描述
    需要维护如下信息:

    • 事实表名称(必填)

    • 备注信息

    关联配置

    • 主数据表(表名)
    • 关联方式(join、left join、semi join)
    • 关联表
    • 关联字段(关联字段,关联关系(=,<,>))
    • 关联限制(限制字段,限制关系,限制值)
    • 模型ER图(绘制表关系图)

    模型详情

    • 数据表
    • 字段名称
    • 字段类型
    • 字段描述
    • 是否使用
    • 维度信息

    2.2 SQL模型

    在这里插入图片描述

    • 数据主题(业务用途)
    • 查询引擎(查询工具)
    • SQL语句

    模型详情

    • 字段名称
    • 字段类型
    • 字段描述
    • 维度信息
    • 是否使用

    3. 维度管理模块

    • 维度名称
    • 业务定义
    • 业务分类
    • 维表
    • 是否是日期维
    • 对应code
    • 对应name
    • 绑定维表(如果有维表)

    4. 指标管理模块

    包括基础信息管理、技术信息管理、关联指标管理、关联应用管理

    核心部分是指标与模型的绑定关系,通过使用演进形成了当前系统两类绑定关系:绑定物理模型和构建虚拟模型。

    1. 绑定物理模型是指标与模型管理中的物理模型字段绑定,并配置对应的计算公式,或还包含一些额外的高级配置,如二次计算、模型过滤条件等;
    2. 创建虚拟模型是通过已有指标和其对应的物理模型,具体步骤首先配置已有指标的计算方式或指标维度的过滤,然后选择指标已绑定的物理模型,形成一个虚拟模型,虚拟模型的分析维度就是所选指标基础模型的公共维度。

    基础信息管理(业务维护)

    • 指标名称
    • 业务分类
    • 统计频率
    • 精度
    • 单位
    • 指标类型
    • 指标定义
    • 计算逻辑
    • 分析方法
    • 影响因素
    • 分析维度

    技术信息管理(技术维护)

    • 指标名称(必填)
    • 数据类型

    模型信息

    • 模型名称
    • 筛选指标
    • 公共引擎
    • 查询引擎

    基础指标信息

    • 基础指标
    • 业务线/主题
    • 指标代码
    • 数据模型
    • 支持维度

    • 计算公式
    • 分析维度
    • 场景描述

    基础模型信息

    • 数据模型名称
    • 查询引擎
    • 绑定字段
    • 计算公式
    • 操作人
    • 操作时间
    • 支持维度

    5. 应用管理

    应用管理由数据应用、外部应用、数据地图三大模块组成,它们构成了对外服务的主体,记录了外部应用与平台内管理的指标、维度、模型和表的关联关系,也提供数据查询展示、应用层ETL生产的能力。而且数据开发人员从底层向上观察,可以追踪数据最终的所有流向;业务分析人员从顶层向下观察,可以看到构成服务的所有数据来源。

    5.1 数据应用模块

    数据应用模块是记录生成每个服务所需的指标、维度和数据模型的关系。每次服务中可以包含多个指标,这些指标可以来源于多个数据模型,不过不同的数据模型中需要包含公共维度,因为是通过这些公共维度将不同模型关联起来。

    数据应用中构建的服务可以发布成查询服务、应用层ETL生产服务、对外API数据接口服务、通用报表配置服务,来满足业务的不同需求

    需要信息:

    • 应用名称
    • 查询引擎

    统计指标列表

    • 统计指标
    • 指标代码
    • 数据模型
    • 支持维度

    • 分析维度列表

    where条件

    • 逻辑运算
    • 过滤字段
    • 是否为动态参数
    • 比较运算
    • 操作

    • 备注

    需要功能:

    • 生成SQL
    • 执行查询

    5.2 外部应用模块

    外部应用模块管理外部应用和应用内的模块,以及这些模块订阅的对应数据应用,目标是实现API接口调用的权限管理和数据最终流向的记录。

    具体的实现上模块

    首先创建对应的外部应用,记录:

    • 对应的外部应用
    • 记录外部应用的名称
    • URL
      -APPKEY等信息

    然后由对应应用的负责人创建模块,记录:

    • 模块名称
    • URL
    • moduleKey等信息。

    这些信息完善后,由对应的数据应用赋权给对应的模块,建立起数据应用与外部应用的联系。最后在外部应用调用平台对外API接口时,进行权限管理。

    5.3 数据地图

    数据地图功能是追查数据的流向,可以从数据表、模型、指标、数据应用、外部应用任意节点查看上游数据来源和下游数据去向

    展开全文
  • 大数据平台-元数据管理系统解析

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

    什么是元数据?在前面的集成开发环境建设相关文章中,我们也提到过,元数据MetaData狭义的解释是用来描述数据的数据,广义的来看,除了业务逻辑直接读写处理的那些业务数据,所有其它用来维持整个系统运转所需的信息/数据都可以叫作元数据。比如数据表格的Schema信息,任务的血缘关系,用户和脚本/任务的权限映射关系信息等等。

    管理这些附加MetaData信息的目的,一方面是为了让用户能够更高效的挖掘和使用数据,另一方面是为了让平台管理人员能更加有效的做好系统的维护管理工作。

    出发点很好,但通常这些元数据信息是散落在平台的各个系统,各种流程之中的,而它们的管理也可能或多或少可以通过各种子系统自身的工具,方案或流程逻辑来实现。那么我们所说的元数据管理平台又是用来做什么的?是不是所有的信息都应该或者有必要收集到一个系统中来进行统一管理呢,具体又有哪些数据应该被纳入到元数据管理平台的管理范围之中呢?下面我们就来探讨一下相关的内容。

    元数据管理平台管什么

    数据治理的第一步,就是收集信息,很明显,没有数据就无从分析,也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集,至于收集哪些信息,取决于业务的需求和我们需要解决的目标问题。

    信息收集再多,如果不能发挥作用,那也就只是浪费存储空间而已。所以元数据管理平台还需要考虑如何以恰当的形式对这些元数据信息进行展示,进一步的,如何将这些元数据信息通过服务的形式提供给周边上下游系统使用,真正帮助大数据平台完成质量管理的闭环工作。

    应该收集那些信息,虽然没有绝对的标准,但是对大数据开发平台来说,常见的元数据信息包括:

    • 数据的表结构Schema信息
    • 数据的空间存储,读写记录,权限归属和其它各类统计信息
    • 数据的血缘关系信息
    • 数据的业务属性信息

    下面我们针对这四项内容再具体展开讨论一下

    数据的表结构Schema信息

    数据的表结构信息,这个很容易理解了,狭义的元数据信息通常多半指的就是这部分内容了,它也的确属于元数据信息管理系统中最重要的一块内容。

    不过,无论是SQL还是NoSQL的数据存储组件,多半自身都有管理和查询表格Schema的能力,这也很好理解如果没有这些能力的话,这些系统自身就没法良好的运转下去了不是。比如,Hive自身的表结构信息本来就存储在外部DB数据库中,Hive也提供类似 show table,describe table之类的语法对这些信息进行查询。那么我们为什么还要多此一举,再开发一个元数据管理系统对这些信息进行管理呢?

    这么做,可能的理由很多,需要集中管理可以是其中一个理由,但更重要的理由,是因为本质上,这些系统自身的元数据信息管理手段通常都是为了满足系统自身的功能运转而设计的。也就是说,它们并不是为了数据质量管理的目的而存在的,由于需求定位不同,所以无论从功能形态还是从交互手段的角度来说,它们通常也就无法直接满足数据质量管理的需求。

    举个很简单的例子,比如我想知道表结构的历史变迁记录,很显然多数系统自身是不会设计这样的功能的。而且一些功能就算有,周边上下游的其它业务系统往往也不适合直接从该系统中获取这类信息,因为如果那样做的话,系统的安全性和相互直接的依赖耦合往往都会是个问题。

    所以,收集表结构信息,不光是简单的信息汇总,更重要的是从平台管理和业务需求的角度出发来考虑,如何整理和归纳数据,方便系统集成,实现最终的业务价值。

    数据的存储空间,读写记录,权限归属和其它各类统计信息

    这类信息,可能包括但不限于:数据占据了多少底层存储空间,最近是否有过修改,都有谁在什么时候使用过这些数据,谁有权限管理和查阅这些数据等等。此外,还可以包括类似昨天新增了多少个表格,删除了多少表格,创建了多少分区之类的统计信息。

    在正常的工作流程中,多数人可能不需要也不会去关心这类信息。但是落到数据质量管理这个话题上时,这些信息对于系统和业务的优化,数据的安全管控,问题的排查等工作来说,又往往都是不可或缺的重要信息,所以通常这类信息也可以从Audit审计的角度来归类看待。

    与表结构信息类似,对于这类Audit审计类信息的采集和管理,通常具体的底层数据存储管理组件自身的功能也无法直接满足我们的需求,需要通过专门的元数据管理平台中统一进行采集,加工和管理。

    数据的血缘关系信息

    血缘信息或者叫做Lineage的血统信息是什么,简单的说就是数据之间的上下游来源去向关系,数据从哪里来到哪里去。知道这个信息有什么用呢?用途很广,举个最简单的例子来说,如果一个数据有问题,你可以根据血缘关系往上游排查,看看到底在哪个环节出了问题。此外我们也可以通过数据的血缘关系,建立起生产这些数据的任务之间的依赖关系,进而辅助调度系统的工作调度,或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。

    分析数据的血缘关系看起来简单,但真的要做起来,并不容易,因为数据的来源多种多样,加工数据的手段,所使用的计算框架可能也各不相同,此外也不是所有的系统天生都具备获取相关信息的能力。而针对不同的系统,血缘关系具体能够分析到的粒度可能也不一样,有些能做到表级别,有些甚至可以做到字段级别。

    以hive表为例,通过分析hive脚本的执行计划,是可以做到相对精确的定位出字段级别的数据血缘关系的。而如果是一个MapReduce任务生成的数据,从外部来看,可能就只能通过分析MR任务输出的Log日志信息来粗略判断目录级别的读写关系,从而间接推导数据的血缘依赖关系了。

    数据的业务属性信息

    前面三类信息,一定程度上都可以通过技术手段从底层系统自身所拥有的信息中获取得到,又或着可以通过一定的流程二次加工分析得到。与之相反,数据的业务属性信息,通常与底层系统自身的运行逻辑无关,多半就需要通过其他手段从外部获取了。

    那么,业务属性信息都有哪些呢?最常见的,比如,一张数据表的统计口径信息,这张表干什么用的,各个字段的具体统计方式,业务描述,业务标签,脚本逻辑的历史变迁记录,变迁原因等等,此外,你也可能会关心对应的数据表格是由谁负责开发的,具体数据的业务部门归属等等。

    上述信息如果全部需要依靠数据开发者的自觉填写,不是不行,但是显然不太靠谱。毕竟对于多数同学来说,对于完成数据开发工作核心链路以外的工作量,很自然的反应就是能不做就不做,越省事越好。如果没有流程体系的规范,如果没有产生实际的价值,那么相关信息的填写很容易就会成为一个负担或者是流于形式。

    所以,尽管这部分信息往往需要通过外部手段人工录入,但是还是需要尽量考虑和流程进行整合,让它们成为业务开发必不可少的环节。比如,一部分信息的采集,可以通过整体数据平台的开发流程规范,嵌入到对应数据的开发过程中进行,例如历史变迁记录可以在修改任务脚本或者表格schema时强制要求填写;业务负责人信息,可以通过当前开发人员的业务线和开发群组归属关系自动进行映射填充;字段统计方式信息,尽可能通过标准的维度指标管理体系进行规范定义。

    总体来说,数据的业务属性信息,必然首先是为业务服务的,因此它的采集和展示也就需要尽可能的和业务环境相融合,只有这样才能真正发挥这部分元数据信息的作用。

    元数据管理相关系统方案介绍

    Apache Atlas

    社区中开源的元数据管理系统方案,常见的比如Hortonworks主推的Apache Atlas,它的基本架构思想如下图所示

    Atlas的架构方案应该说相当典型,基本上这类系统大致都会由元数据的收集,存储和查询展示三部分核心组件组成。此外,还会有一个管理后台对整体元数据的采集流程以及元数据格式定义和服务的部署等各项内容进行配置管理。

    对应到Atlas的实现上,Atlas通过各种hook/bridge插件来采集几种数据源的元数据信息,通过一套自定义的Type 体系来定义元数据信息的格式,通过搜索引擎对元数据进行全文索引和条件检索,除了自带的UI控制台意外,Atlas还可以通过Rest API的形式对外提供服务。

    Atlas的整体设计侧重于数据血缘关系的采集以及表格维度的基本信息和业务属性信息的管理。为了这个目的,Atlas设计了一套通用的Type体系来描述这些信息。主要的Type基础类型包括DataSet和Process,前者用来描述各种数据源本身,后者用来描述一个数据处理的流程,比如一个ETL任务。

    Atlas现有的Bridge实现,从数据源的角度来看,主要覆盖了Hive,HBase,HDFS和Kafka,此外还有适配于Sqoop, Storm和Falcon的Bridge,不过这三者更多的是从Process的角度入手,最后落地的数据源还是上述四种数据源。

    具体Bridge的实现多半是通过上述底层存储,计算引擎各自流程中的Hook机制来实现的,比如Hive SQL的Post Execute Hook,HBase的Coprocessor等,而采集到的数据则通过Kafka消息队列传输给Atlas Server或者其它订阅者进行消费。

    在业务信息管理方面,Atlas通过用户自定义Type 属性信息的方式,让用户可以实现数据的业务信息填写或者对数据打标签等操作,便于后续对数据进行定向过滤检索。

    最后,Atlas可以和Ranger配套使用,允许Ranger通过Atlas中用户自定义的数据标签的形式来对数据进行动态授权管理工作,相对于基于路径或者表名/文件名的形式进行静态授权的方式,这种基于标签的方式,有时候可以更加灵活的处理一些特定场景下的权限管理工作。

    总体而言,Atlas的实现,从结构原理的角度来说,还算是比较合理的,但从现阶段来看,Atlas的具体实现还比较粗糙,很多功能也是处于可用但并不完善的状态。此外Atlas在数据审计环节做的工作也不多,与整体数据业务流程的集成应用方面的能力也很有限。Atlas项目本身很长时间也都处于Incubator状态,因此还需要大家一起多努力来帮助它的改进。

    Cloudera Navigator Data Management

    另外一个比较常见的解决方案是Cloudera CDH发行版中主推的Navigator,相比Atlas而言,Navigator的整体实现更加成熟一些,更像一个完整的解决方案,不过,Navigator并不是开源的,也难怪,毕竟要卖钱的的东西,也就更有动力去完善 ;)

    Navigator的产品定位是Data Management数据管理,本质上也是通过管理元数据来管理数据,但周边工具和配套设施相对完善,和Cloudera Manager管理后台的产品集成工作也做得比较彻底。相比Atlas来说,Navigator的整体组件架构也更加复杂一些。Navigator的大致组件架构如下图所示

    Navigator定位为数据管理,所以对数据的审计管理方面的工作也会做得更多一些,除了采集和管理Hive/Impala等表格的血缘信息,Navigator也可以配置采集包括HDFS的读写操作记录,Yarn/Spark/Pig等作业的运行统计数据在内的信息。Navigator同时还为用户提供了各种统计分析视图和查询管理工具来分析这些数据。

    从底层实现来看,Navigator同样通过Hook或着Plugin插件的形式从各种底层系统的运行过程中获取相关信息。但与Atlas不同的是,Navigator的元数据采集传输处理流程并没有把这些信息写入到消息队列中,而是主要通过这些插件写入到相关服务所在的本地Log文件中,然后由Cloudera Manager在每台服务节点上部署的Agent来读取,过滤,分析处理并传输这些信息给Audit Server。

    此外Navigator还通过独立的Metadata Server来收集和分析一些非Log来源的元数据信息,并统一对外提供元数据的配置管理服务。用户还可以通过配置Policy策略,让Metadata Server自动基于用户定义的规则,替用户完成数据的Tag标签打标工作,进而提升数据自动化自治管理的能力。

    总体而言,Navigator和Cloudera Manger的产品集成工作做得相对完善,如果你使用CDH发行版全家福套件来管理你的集群的话,使用Navigator应该是一个不错的选择。不过,如果是自主管理的集群或者自建的大数据开发平台,深度集成定制的Navigator就很难为你所用了,但无论如何,对于自主开发的元数据管理系统来说,Navigator的整体设计思想也还是值得借鉴的。

    蘑菇街元数据管理系统实践

    蘑菇街大数据平台的元数据管理系统,大体的体系架构思想和上述系统也比较类似,不过,客观的说我们的系统的开发是一个伴随着整体开发平台的需求演进而渐进拓展的过程,所以从数据管理的角度来说,没有上述两个系统那么关注数据格式类型系统的普遍适用性。比如Schema这部分信息的管理,就主要侧重于表格类信息的管理,比如Hive,HBase等,而非完全通用的类型系统。但相对的,在对外服务方面,我们也会更加注重元数据管理系统和业务系统应用需求的关联,架构大同小异,下面主要简单介绍一下产品交互形态和一些特殊的功能特效设定等。

    如图所示,是我们的元数据管理系统的产品后台针对Hive表格元数据信息的部分查询界面,主要为用户提供表格的各种基础schema信息,业务标签信息,血缘关系信息,样本数据,以及底层存储容量星系,权限和读写修改记录等审计信息。

    除了表格元数据信息管理以外,我们的元数据管理系统主要的功能之一是“业务组”的管理,业务组的设计目标是贯穿整个大数据开发平台的,做为大数据开发平台上开发人员的自主管理单元组织形式。将所有的数据和任务的管理工作都下放到业务组内部由业务组管理员管理。

    从元数据管理系统的角度来说,业务组的管理,包括数据和任务与业务组的归属关系映射,业务组内角色的权限映射关系等,此外,为了适应业务的快速变化,也给用户提供的数据资产的归属关系转移等功能。

    总体来说,业务组的管理功能,更多的是需要和大数据开发平台的其它组件相结合,比如和集成开发平台IDE相结合,在开发平台中提供基于业务组的多租户开发环境管理功能,再比如与调度系统相结合,根据任务和数据的业务组归属信息,在任务调度时实施计算资源的配额管理等。

    最后,关于数据的血缘关系跟踪,再多说两句。在Atlas和navigator中,主要通过计算框架自身支持的运行时hook来获得数据相关元数据和血缘相关信息,比如hive的hook是在语法解析阶段,storm的hook是在topology submit阶段。

    这么做的优点是血缘的追踪分析是基于真实运行任务的信息进行分析的,如果插件部署全面,也不太会有遗漏问题,但是这种方式也有很多不太好解决的问题,比如

    • 如何更新一个历史上有依赖后来不再依赖的血缘关系
    • 对于一个还未运行的任务,不能提前获取血缘信息
    • 临时脚本或者错误的脚本逻辑对血缘关系数据的污染

    简单总结一下,就是基于运行时的信息来采集血缘关系,由于缺乏静态的业务信息辅助,如何甄别和更新血缘关系的生命周期和有效性会是一个棘手的问题,一定程度上也限制了应用的范围。

    我们的做法是,血缘信息的采集不是在运行时动进行的,而是在脚本保存时进行的。由于开发平台统一管理了所有用户的任务脚本,所以,我们可以对脚本进行静态的分析,加上脚本本身业务信息,执行情况和生命周期对开发平台是可知的。所以一定程度上能解决上述提到的几个问题。

    当然,这种方案也有自己的短板需要克服,比如:如果脚本管控不到位,血缘关系分析可能覆盖不全;血缘关系是基于最新的脚本的静态的逻辑关系,无法做到基于某一次真实的运行实例进行分析。不过,这些短板对我们来说从需求的角度来说都不是很核心的问题,又或者通过周边系统的配套建设可以在一定程度上加以解决克服的。


    常按扫描下面的二维码,关注“大数据务虚杂谈”,务虚,我是认真的 ;)

    展开全文
  • 数据管理系统

    千次阅读 2019-01-10 16:53:00
    建立元数据管理系统是解决上述问题的关键。那么,什么是元数据?简单来说,元数据就是描述数据的数据(data about data),扩展地说,元数据是指来自企业内外的所有物理数据和知识,包括企业所使用数据的结构、物理...

    面临的问题

    1. 各数据平台业务术语定义不一致,导致员工之间交流产生误会,降低沟通效率。
    2. 各数据平台指标数据来源、计算口径不一致,导致出现计算结果和取数偏差。
    3. 各数据平台数据没有统一的数据标准导致数据难以集成和统一。

    上述问题的由来,主要是不同业务线的数据分析人员、数据开发人员,以及不同的产品之间,缺乏有效的沟通,也没有一个统一的入口,来记录业务的发生和加工过程。再加上人员的流动,长时间积累之后就产生了这些问题。随处可见的数据不统一,难以提升的数据质量,难以完成的数据模型梳理等源源不断的基础性数据问题,限制了数据平台发展,导致数据应用不能快速展示效果。

    解决思路

    建立元数据管理系统是解决上述问题的关键。那么,什么是元数据?简单来说,元数据就是描述数据的数据(data about data),扩展地说,元数据是指来自企业内外的所有物理数据和知识,包括企业所使用数据的结构、物理数据的格式、技术和业务过程、数据的规则和约束,这些元数据可能存在于软件中,也可能存在于文档中,甚至只处于意识形态中而尚未整理出来。

    元数据管理

    1. 跟踪每一个数据元素的生命周期。为每一个数据元素提供生命周期信息,从数据源到最终的用户展现,包含了原始字段名,ETL处理,目标表定义和用户的表现定义(包含转换和导出的列)。
    2. 分析变更带来的影响可能带来的冲突和影响。对数据源字段的跟踪能够在数据源发生变更时分析对数据仓库带来的影响。例如数据源中的年份字段长度由2位变成4位、数据源中某些字段删除都会对数据仓库加载和转换脚本产生影响,但数据仓库中的对象应该保持稳定。
    3. 支持当前数据与历史数据的合并,处理和标识己经归档过期数据。
    4. 为更好的管理数据仓库提供依据,例如可以对哪些元数据需要保存进行分析、获得元数据发生了哪些变化,其频度如何,以及哪些元数据变化最频繁等数据,并通过辅助分析工具来产生决策支持信息。

    明确元数据管理范畴

    元数据主要可以分为技术元数据和业务元数据。

    1. 技术元数据是描述系统中技术领域相关概念、关系和规则的数据,主要包括对数据结构、数据处理方面的特征描述,覆盖系统数据源接口、数据仓库与数据集市存储、ETL、OLAP、数据封装和前端展现等全部数据处理环节。
    2. 业务元数据是描述系统中业务领域相关概念、关系和规则的数据,主要包括业务术语、信息分类、指标定义和业务规则等信息。 从元数据的层次结构上来说,目前阶段对L0、L1层元数据进行管理。从元数据的分析领域来说,主要对技术元数据和业务元数据进行管理。

    元数据获取

    在企业中很多元数据的管理是通过手工录入的方式人工整理的,在大数据时代,面对如此复杂的数据,人工已经完全不可能梳理清楚。企业需要从技术上提供各种自动化能力,实现对元数据的自动获取,包括自动元数据信息采集、自动服务信息采集与自动业务信息采集等这要求企业使用的数据管理工具支持一系列的适配器。比如各种数据库的适配器,各种ETL工具的适配器,脚本等等适配器。目前很多工具都采用导出XML,这种会缺少很多细节,而细节是数据资产的关键点,所以对于工具的采集最好采用直连的方式。

    管理核心元数据

    数据标准是元数据管理中很重要的内容,但是建立有效的数据标准并落地,是有一定难度的,传统的元数据管理的模式需要建立一套规范元数据模型,即使企业实际元数据模型中有上万个字段,也需要将每个字段于规范元数据模型进行比对,这种方式往往难以落地。 其实只需要在众多元数据中挑选出核心元数据,只管理这些核心元数据定义,依照核心元数据建立标准,就可以实现企业数据治理的目标,还能提升数据治理的效率。
                                                               元数据样例
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    随业务持续更新元数据标准
    对于企业来说,有很多元数据标准建立以后,往往只是一份文档,没有根据企业业务发展及时做出更新,时间长了就成为了摆设 。实际上,元数据标准是需要随着企业的业务变化而不断进行修订的,比如在企业拓展新业务的时候,需要在增加相应的标准进去,对于没有价值的标准,也要及时废弃。
     
     
     
     
     
     
     
     
     
    元数据仓库分层设计
     
     

    转载于:https://my.oschina.net/aubao/blog/2999808

    展开全文
  • 数据管理系统产品选型分析 1 概述 需要给目前数据仓库适用一套元数据管理系统,目的 减少人为的维护工作量、web页面协同工作(多人统一入口使用)、元数据权限管理等 1.1 应用背景 目前数据仓库没有专业的元...
  •     数据库技术是应数据管理任务...    在应用需求的推动下,在计算机硬件、软件发展的基础上,数据管理技术经历了人工管理、文件系统、数据库系统三个阶段。 数据管理三个阶段比较 人工...
  • 知识库管理系统(源码+数据

    热门讨论 2018-05-15 16:55:15
    知识库管理系统,包含源码和数据库。通过maven构建,使用git版本控制和团队合作,采用springmvc+mybatis框架,集成Lucene全文检索,openoffice转化office文档,ffmpeg处理视频文件,red5搭建流媒体服务,基于...
  • 10款精选的后台管理系统,收藏吧!

    万次阅读 多人点赞 2019-03-22 08:22:56
    此项目是 vue + element-ui 构建的后台管理系统,是后台项目node-elm的管理系统,所有的数据都是从服务器实时获取的真实数据,具有真实的注册、登陆、管理数据、权限验证等功能。 项目地址:...
  • 8大常用数据库管理系统简介

    万次阅读 2019-06-20 14:48:15
    转自:http://vps.zzidc.com/vpsjishu/817.html 数据库管理系统(Database Management System)是种操纵和管理数据库的大型软件,是用于建立、使用和维护数据库,简称DBMS。是企业进行数据管理及维护不可或...
  • 数据库管理系统(DataBase ...用户通过数据库管理系统访问数据库中表内的数据。 数据库服务器软件(数据库管理系统)=多个数据库 一个数据库=多张表 实体类与表的对应关系: java中的类对应数据...
  • 基于vue搭建的后台管理系统

    万次阅读 多人点赞 2018-07-16 15:21:28
    小编推荐:Fundebug专注于JavaScript、微信小程序、微信小游戏,Node.js和Java实时BUG监控。...此项目是 vue2.0 + element-ui + node+mongodb 构建的后台管理系统,所有的数据都是从服务器实时获取...
  • Java Web酒店管理系统源码 +mysql 数据库

    千次下载 热门讨论 2014-03-19 10:04:37
    酒店管理系统分为前台和后台两个部分,其中后台供管理员管理系统之用,包括客房类型设置模块、客房设置模块以及操作员设置三个子模块,具体的功能模块如下。 客房类型设置模块:该模块用来管理酒店的所有客房类型,...
  • spring+springmvc+mybatis搭建的一个酒店管理系统附带mysql数据库
  • 数据库管理系统

    千次阅读 2018-10-24 00:14:00
    数据库管理系统主要是实现对共享数据有效的组织、存储、管理和存取。围绕数据,数据库管理系统的功能为: 1、数据库定义和创建 创建数据库主要是用数据定义语言定义和创建数据库模式、外模式、内模式等数据库对象。...
  • 数据、数据库、数据库管理系统、数据库系统

    万次阅读 多人点赞 2018-07-19 21:34:56
    数据库管理系统——DBMS 数据库应用程序——DBAP 数据库(DataBase): 存放数据的仓库,这个仓库是在计算机存储设备上,而且数据是一定的格式存放的。数据库是具有统一的结构形式并存放于同一的存储介质内的...
  • 数据库系统的三种数据模型

    万次阅读 2019-04-26 20:01:28
    数据模型从抽象层次上描述了系统的静态特征、动态行为和约束条件,为数据库系统的信息表示与操作提供了一个抽象的框架。数据模型所描述的内容有三部分:数据结构、数据操作和数据约束。 数据结构:数据结构描述...
  • 图书租赁管理系统——数据流程图

    万次阅读 多人点赞 2016-10-08 14:35:54
    图书租赁管理系统——数据流程图
  • 数据结构实现学生信息管理系统功能

    万次阅读 多人点赞 2019-01-22 20:25:22
    学生信息管理系统 1、 学生信息录入:主要是录入学生班级信息和学生基本情况; 2、 学生信息查询:按指定系检索该系的学生信息,其中包括所有的学生信息; 3、 学生信息维护:维护学生、系别、课程、学生选课及...
  • 链接:https://pan.baidu.com/s/1Ankv_KXWDjNnACgiOqbtQQ 提取码:6wxd
  • 四大基本概念(1)数据--Data① 数据的定义② 数据的种类③ 数据的特点④ 数据举例(2)数据库--Database① 数据库的定义② 数据库的基本特征(3)数据库管理系统--DataBase Management System① 什么是DBMS?...
  • 数据库管理系统是对数据进行管理的大型系统软件,它是数据库系统的核心组成部分,用户在数据库系统中的一切操作,包括数据定义、查洵、更新(包括插入、删除和修改)及各种控制都是通过DBMS进行的。DBMS就是实现把用户...
  • 早期的计算机系统用于科学计算,处理的数据是正数、实数、浮点数等传统数学中的数据。 (2)数据库(DataBase,简称DB):数据库是长期储存在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型...
  • 数据库定义功能 数据组织、存储和管理 数据操纵功能 数据库的事物管理和运行管理 数据库的建立和维护功能
  • 教务管理系统 数据库设计

    千次下载 热门讨论 2011-12-25 21:52:54
    数据库原理课,设计了一个高校教务管理系统数据库,word文档,包括需求分析,ER图,具体的代码设计,SQL语句的数据库查询,创建视图
  • 一、数据流程图: 1. 顶层数据流程图: 2. 第一层数据流程图: 3. 第二层数据流程图: 3.1 挂号: 3.2 就诊: 3.3 取药: 二、 ER图 1. 挂号: 2.就诊 3.取药 4.总ER图 ...
  • 数据结构课程设计 - 通讯录管理系统

    万次阅读 多人点赞 2016-07-06 21:44:10
    本系统为简单的通讯录管理系统,运行系统时,将从文件中读取已有的数据内容记录在内存中,使用者可以对通讯录进行添加、删除、修改、浏览、查找等操作,每进行一项操作后将内存中的数据写入到文件中,同时并记录操作...
  • 1.数据(date): ...3.数据库管理系统(DateBase Management System, DBMS): 组织、存储、获取、维护数据的软件,也就是对数据进行增删改查等操作的软件。 个人理解:有一个软件,能够增删改查第2条数据库中
  • 基于图书管理系统的需求分析之数据流图

    万次阅读 多人点赞 2019-07-08 17:40:53
    基于图书管理系统的需求分析之数据流图 数据流图概述 根据图书管理系统要求可知,该系统整体流程如下: 系统管理员采购图书,添加图书相关信息(如:图书编号、书名、作者、备注等)形成图书信息表。系统管理员...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,924,497
精华内容 1,169,798
关键字:

数据管理系统

友情链接: 表格汉字转拼音.rar