首页 >>新闻中心

数据治理之元数据管理实践 2019-04-17

元数据是什么

元数据最简单的定义是描述数据的数据。这里有两个关键点,一个是数据,一个是描述数据。企业中一般的可进行管理的数据如下表:

image.png

和元数据管理相关的另一个重要概念是元模型要实现企业元数据管理,需要定义一个符合存储企业数据现状的元数据模型,且这个模型有不同粒度和层次的元模型,有了层次和粒度的划分,未来元数据进行批量管理后就可以灵活的从不同维度进行元数据分析,如企业的数据地图、数据血统都是基于此实现的。

image.png

我们试着把企业找中的技术元数据、业务元数据、操作元数据、管理元数据进行元模型的梳理,如下图所示:

image.png

将以上梳理出的信息通过UML建模处理就得到了元模型,在元模型中有包、类、属性、继承、关系。创建元模型的时候也可以参考CWM,CWM定义了一套完整的元模型体系结构,但它是用于数据仓库构建和应用的元数据建模。

如何实现元数据管理

下面分析下企业的元数据如何管理,从元数据管理什么、元数据怎么管理、元数据管理的难点、元数据管理的实践这四个方面描述。

一、      元数据管理什么 

从多年的实施经验看,国内企业进行元数据管理的方向有三个,一个是基于数据平台进行元数据管理,由于大数据平台的兴起,目前逐步开始针对Hadoop环境进行元数据管理;二是基于企业数据整体管理规划开展对元数据的管理,也是企业数据资产管理的基础;三是元数据作为某个平台的组件进行此平台特有的元数据管理,它作为一个中介或中转互通平台各组件间的数据。

基于数据平台的元数据管理相对成熟,也是业界最早进行元数据管理的切入点或者说是数据平台建设的必备。

在此业务场景下,从技术维度讲:元数据管理围绕着数据平台内的源系统、数据平台、数据集市、数据应用中,数据模型,数据库、表、字段、报表(指标存储字段)、字段和字段间的数据关系进行管理。从业务维度讲:管理指标的定义包括指标的业务维度,技术维度和管理维度三方面的数据、字段的中文描述、表的加工策略、表的生命周期信息、表或字段的安全等级。从应用维度讲:实现数据平台模型变更管理、变更影响分析、数据血统分析、高阶数据地图、调度作业异常影响范围。

企业级数据管理,在企业整体数据管理背景下的元数据管理是数据管理的基础,除了要管理在数据平台元数据管理场景下的所有元数据外,核心是要解决元数据管理和数据标准、数据质量、数据安全、数据生命周期、数据服务的贯通问题,进行数据描述层面的信息融合。在此场景下,元数据管理的着力点是字段或信息项,其他的管理维度或信息都可以基于字段或信息项进行扩展或外延。企业级的数据管理涉及的内容很多,但基于字段或信息项的扩展其结构是稳定的,它是一个支点。否则在纷繁复杂的数据管理业务中会迷茫和痛苦。下图是基于信息项的各管理对象间数据关系,示例的说明了基于字段或信息项为管理核心和外延的定位。

image.png

最后是基于某个大型的平台的元数据管理,这种场景出现在应用型的产品架构中,一般企业数据管理中不会涉及这个问题。

二、      元数据怎么管理

元数据管理要符合企业数据现状,要能支撑企业数据人员分析数据的需要,元数据是企业数据资产的最原始词典,我们需要从这本词典中获取到准确的数据信息,准确、便捷、深度、广度是元数据管理努力的方向。

要实现企业元数据管理需从两个方面考虑,一是盘点企业数据情况,搞清楚要管理哪些元数据以及这些元数据在什么地方,以何种形态存储,他们之间有有着怎样的联系。二是建模,这里的建模是建立元数据的模型及元模型,要抽象出企业的元模型,建立个元模型之间的逻辑关系。总结的讲盘点企业数据资产和建立企业元模型是元数据管理的两个基本步骤。下面我们展开的讲一下这两点:

企业数据资产盘点,首先要把元数据建设的定位定义清楚,短期解决什么问题,长期达到什么目的,基于短期目标要重点细化。举个例子要实现企业物理模型的全面管理,实现数据结构变更一体化管理这个短期目标,那么就需要盘点企业有多少应用系统,每个应用系统有多少个数据库,数据库的种类有什么,哪些是业务数据表,哪些是垃圾数据表,每个数据字段的含义是否完整,每个系统那个业务部门使用,哪些管理员进行运维,企业的数据变更是否有流程驱动等。将以上信息分为两大类,一类是数据模型本身的元数据信息,一类是支撑数据模型管理的元数据信息,这两类信息都是需要盘点的内容。

元数据建模,元数据建模是对企业要管理的元数据进行结构化、模型化。元模型的构建要一般要参考公共仓库元模型CWM,但也不能照搬CWM,否则构建的元模型太过臃肿,不够灵活。在构建元模型过程中不但要关心模型的结构更要关系模型间的关系,每个模型在元数据的世界里是一个独立的个体,个体和个体之间的关系赋予了模型间错综复杂的关系圈,这些关系的创建往后衍生会支撑数据图谱或知识图谱的构建。再拿数据资产盘点的例子来讲,我们要建立数据库元模型、表元模型、字段元模型、管理员元模型,其中库-表-字段是通过组合关系来构建的,而表-表、字段-字段是通过依赖关系来构建的。通过这样的关系构建就能将企业中的所有有交互的数据形成一个错综复杂庞大的数据关系网络,数据分析人员就可以基于这张网络进行各种信息的挖掘。

三、      元数据管理中的难点

元数据管理是大数据平台建设的重要组成部分,是企业实现数据资产,资产服务化的重要基础,在数据管理大环境下和数据安全、数据质量、数据架构、数据模型等有着千丝万缕的关系。也是是业务和技术互通的桥梁。因此元数据建设的好坏会对企业整体数据以及管理带来重要的影响。

元数据管理的难点,个人认为有三个点。

首先是元数据识别,要确定要管理哪些元数据,按元数据的定义来看只要能描述数据的数据都能作为元数据进行管理,但从价值角度讲一定要找到对数据业务、数据运维、数据运营、数据创新带来帮助的元数据进行管理,避免眉毛鼻子一把抓。一般企业元数据建设都是围绕数据集中的数据平台进行全链路的源、数据平台、分析系统的元数据数据管理,围绕这条主线,进一步管理业务元数据和操作元数据。在建设过程中要围绕本企业数据管理问题域进行虚实结合的建设。

其次是元模型的构建,元模型其核心结构要稳定,因为元数据的建设不是一蹴而就的,需要慢慢的积累和演变,因此存储元数据的元模型结构一定要进行抽象出稳定的结构,比如:针对关系抽象出组合关系和依赖关系、针对模型要抽象出每一类型元数据父类或基类以方便其灵活扩展。

最后是元数据间的关系,从元数据应用的角度来看,光分析元数据的结构对数据分析人员和数据应用的价值还不是那么的突出。元数据管理的价值主要在其关系的丰富程度,举个不恰当的例子,犹如一个人如果其社会关系足够的丰富,那么其处理各种事情就游刃有余,元数据也类似数据分析和应用一定是从其关系中探寻出数据的价值进而指导业务或进行数据创新。从长期的实践中发现,基于信息项或字段的元数据关系构建是最稳定的。

四、      元数据管理最佳实践

谋定而后动,元数据管理是一盘棋,需要进行管理设计,如基于规范和制度的设计,元模型的设计、实施的设计,推广的设计,每一环节想一想再动。

选好价值点,元数据管理是纷繁复杂的,它是对企业数据现状的一种抽象、整合和展现,其管理是复杂和不容易的,其价值有可能是隐形的、不容易察觉的,它是一项承上启下,贯通业务和技术的基础性管理工作,因此选好不同时期其管理的价值点,逐步影响企业的方方面面。

选好工具,元数据管理可借助管理工具使管理工作变的相对快速和简单一些,如元数据的采集、元数据存储、数据血统、数据地图、元数据整合等都可以通过元数据工具来实现。


 

二、Cable--新虚拟网络架构介绍

OpenStack架构中,Neutron作为虚拟网络模块,管理虚机的网络。随着容器技术的发展,越来越多的应用部署到Kubernetes等容器编排系统中,而Kubernetes也有自带的网络管理模块,如Flannel,Calico等。分别维护OpenStack、Kubernetes网络模块,不仅增加管理成本,且无法满足虚机和容器网络互通等需求。为了统一管理不同编排系统的网络模块,简化虚拟网络功能的开发流程,虚拟网络工作组实现了新的虚拟网络架构Cable。

背景简介

目前公司的虚拟网络架构有如下不足:

1 物理机、虚机和容器网络分开管理,无法达到直接互联互通。

2 Neutron agent里的DHCP、metadata采用集中式服务,健壮性不足。

3 vxlan实现时需要外部路由器的支持,较为复杂。

新的网络架构需要满足统一管理物理机、虚机和容器网络,实现直接互联互通;简化Neutron agent,分布式架构实现DHCP、metadata等功能;在虚拟网络层面实现vxlan;提供流量镜像等新功能。

方案实现

Cable整体框架图

image.png

为了满足上诉需求,Cable架构实现了如下两个关键点。

1虚拟数据平面

虚拟数据平面不再基于OVS,而是采用功能更为丰富虚拟路由器vrouter.ko。vrouter.ko是Juniper的虚拟网络架构OpenContrail中的开源数据模块。相比于OVS的简单数据包转发,vrouter.ko支持虚拟网络路由、vxlan、流表配置安全组、流表配置nat/snat、流量镜像等功能。丰富的数据平面功能,简化了网络功能模块的开发难度。

2自研管理平面

重新自研开发管理平面。管理平面统一管理OpenStack和Kubernetes网络模块;采用Kubernetes里的watch方式,主动监控平台资源变化情况,并执行相关操作;分布式实现DHCP;用vrouter.ko中的flow功能实现nat、安全组等。

与Openstack兼容

Cable需要考虑如何与现有的虚拟网络结构兼容,使得Neutron能够平滑过渡到新的架构上。所以在保持Neutron原有接口不变的基础上,将Neutron的db替换为etcd,并将DHCP-agent,metadata-agent,l3-agent替换为统一的cable-agent。将Neutron用Cable替代后,OpenStack的相关命令行和Restful API都没有变化,实现无缝切换,方便运维管理。

Cable代替Neutron后架构图

image.png

总结

新的虚拟网络架构,兼容了不同网络平面,简化了网络功能模块,使得网络更为健壮。目前Cable的整体架构已经基本开发完成,实现了DHCP、metadata和VLAN架构网络,后续将实现安全组、VXLAN等更多功能,并实现自动化部署,完善监控功能。