数据治理之元数据管理实践
转载本文需注明出处:EAWorld,违者必究。
引言:
数字转型对不同的人意味着不同的东西,这取决于你的行业和你的业务性质。然而,所有的解释都有一个共同的主线,数据和数据治理的重要性。近年来,大家都在谈论数据逐步或已经成为企业的核心资产,数据驱动企业业务开展已经在不同的行业和企业中发挥着巨大的作用,那么作为企业的核心资产数据,如何进行管理是不同企业在进行全面数字化转型需要考虑的一个重要事情。
关于元数据概念的文章网上有不少,本文主要探讨一般的企业如何开展元数据管理工作。这里分享两个主题元数据是什么、如何实现元数据管理。
元数据是什么
元数据最简单的定义是描述数据的数据。这里有两个关键点,一个是数据,一个是描述数据。企业中一般的可进行管理的数据如下表:
和元数据管理相关的另一个重要概念是元模型,要实现企业元数据管理,需要定义一个符合存储企业数据现状的元数据模型,且这个模型有不同粒度和层次的元模型,有了层次和粒度的划分,未来元数据进行批量管理后就可以灵活的从不同维度进行元数据分析,如企业的数据地图、数据血统都是基于此实现的。
我们试着把企业找中的技术元数据、业务元数据、操作元数据、管理元数据进行元模型的梳理,如下图所示:
将以上梳理出的信息通过UML建模处理就得到了元模型,在元模型中有包、类、属性、继承、关系。创建元模型的时候也可以参考CWM,CWM定义了一套完整的元模型体系结构,但它是用于数据仓库构建和应用的元数据建模。
如何实现元数据管理
下面分析下企业的元数据如何管理,从元数据管理什么、元数据怎么管理、元数据管理的难点、元数据管理的实践这四个方面描述。
一、元数据管理什么
从多年的实施经验看,国内企业进行元数据管理的方向有三个,一个是基于数据平台进行元数据管理,由于大数据平台的兴起,目前逐步开始针对Hadoop环境进行元数据管理;二是基于企业数据整体管理规划开展对元数据的管理,也是企业数据资产管理的基础;三是元数据作为某个平台的组件进行此平台特有的元数据管理,它作为一个中介或中转互通平台各组件间的数据。
基于数据平台的元数据管理相对成熟,也是业界最早进行元数据管理的切入点或者说是数据平台建设的必备。
在此业务场景下,从技术维度讲:元数据管理围绕着数据平台内的源系统、数据平台、数据集市、数据应用中,数据模型,数据库、表、字段、报表(指标存储字段)、字段和字段间的数据关系进行管理。从业务维度讲:管理指标的定义包括指标的业务维度,技术维度和管理维度三方面的数据、字段的中文描述、表的加工策略、表的生命周期信息、表或字段的安全等级。从应用维度讲:实现数据平台模型变更管理、变更影响分析、数据血统分析、高阶数据地图、调度作业异常影响范围。
企业级数据管理,在企业整体数据管理背景下的元数据管理是数据管理的基础,除了要管理在数据平台元数据管理场景下的所有元数据外,核心是要解决元数据管理和数据标准、数据质量、数据安全、数据生命周期、数据服务的贯通问题,进行数据描述层面的信息融合。在此场景下,元数据管理的着力点是字段或信息项,其他的管理维度或信息都可以基于字段或信息项进行扩展或外延。企业级的数据管理涉及的内容很多,但基于字段或信息项的扩展其结构是稳定的,它是一个支点。否则在纷繁复杂的数据管理业务中会迷茫和痛苦。下图是基于信息项的各管理对象间数据关系,示例的说明了基于字段或信息项为管理核心和外延的定位。
最后是基于某个大型的平台的元数据管理,这种场景出现在应用型的产品架构中,一般企业数据管理中不会涉及这个问题,这里就不展开介绍了。
二、元数据怎么管理
元数据管理要符合企业数据现状,要能支撑企业数据人员分析数据的需要,元数据是企业数据资产的最原始词典,我们需要从这本词典中获取到准确的数据信息,准确、便捷、深度、广度是元数据管理努力的方向。
要实现企业元数据管理需从两个方面考虑,一是盘点企业数据情况,搞清楚要管理哪些元数据以及这些元数据在什么地方,以何种形态存储,他们之间有有着怎样的联系。二是建模,这里的建模是建立元数据的模型及元模型,要抽象出企业的元模型,建立个元模型之间的逻辑关系。总结的讲盘点企业数据资产和建立企业元模型是元数据管理的两个基本步骤。下面我们展开的讲一下这两点:
企业数据资产盘点,首先要把元数据建设的定位定义清楚,短期解决什么问题,长期达到什么目的,基于短期目标要重点细化。举个例子要实现企业物理模型的全面管理,实现数据结构变更一体化管理这个短期目标,那么就需要盘点企业有多少应用系统,每个应用系统有多少个数据库,数据库的种类有什么,哪些是业务数据表,哪些是垃圾数据表,每个数据字段的含义是否完整,每个系统那个业务部门使用,哪些管理员进行运维,企业的数据变更是否有流程驱动等。将以上信息分为两大类,一类是数据模型本身的元数据信息,一类是支撑数据模型管理的元数据信息,这两类信息都是需要盘点的内容。
元数据建模,元数据建模是对企业要管理的元数据进行结构化、模型化。元模型的构建要一般要参考公共仓库元模型CWM,但也不能照搬CWM,否则构建的元模型太过臃肿,不够灵活。在构建元模型过程中不但要关心模型的结构更要关系模型间的关系,每个模型在元数据的世界里是一个独立的个体,个体和个体之间的关系赋予了模型间错综复杂的关系圈,这些关系的创建往后衍生会支撑数据图谱或知识图谱的构建。再拿数据资产盘点的例子来讲,我们要建立数据库元模型、表元模型、字段元模型、管理员元模型,其中库-表-字段是通过组合关系来构建的,而表-表、字段-字段是通过依赖关系来构建的。通过这样的关系构建就能将企业中的所有有交互的数据形成一个错综复杂庞大的数据关系网络,数据分析人员就可以基于这张网络进行各种信息的挖掘。
三、元数据管理中的难点
元数据管理是大数据平台建设的重要组成部分,是企业实现数据资产,资产服务化的重要基础,在数据管理大环境下和数据安全、数据质量、数据架构、数据模型等有着千丝万缕的关系。也是是业务和技术互通的桥梁。因此元数据建设的好坏会对企业整体数据以及管理带来重要的影响。
元数据管理的难点,个人认为有三个点。
首先是元数据识别,要确定要管理哪些元数据,按元数据的定义来看只要能描述数据的数据都能作为元数据进行管理,但从价值角度讲一定要找到对数据业务、数据运维、数据运营、数据创新带来帮助的元数据进行管理,避免眉毛鼻子一把抓。一般企业元数据建设都是围绕数据集中的数据平台进行全链路的源、数据平台、分析系统的元数据数据管理,围绕这条主线,进一步管理业务元数据和操作元数据。在建设过程中要围绕本企业数据管理问题域进行虚实结合的建设。
其次是元模型的构建,元模型其核心结构要稳定,因为元数据的建设不是一蹴而就的,需要慢慢的积累和演变,因此存储元数据的元模型结构一定要进行抽象出稳定的结构,比如:针对关系抽象出组合关系和依赖关系、针对模型要抽象出每一类型元数据父类或基类以方便其灵活扩展。
最后是元数据间的关系,从元数据应用的角度来看,光分析元数据的结构对数据分析人员和数据应用的价值还不是那么的突出。元数据管理的价值主要在其关系的丰富程度,举个不恰当的例子,犹如一个人如果其社会关系足够的丰富,那么其处理各种事情就游刃有余,元数据也类似数据分析和应用一定是从其关系中探寻出数据的价值进而指导业务或进行数据创新。从长期的实践中发现,基于信息项或字段的元数据关系构建是最稳定的。
四、元数据管理最佳实践
下面从多年的实践角度谈一谈元数据管理:
谋定而后动,元数据管理是一盘棋,需要进行管理设计,如基于规范和制度的设计,元模型的设计、实施的设计,推广的设计,每一环节想一想再动。
选好价值点,元数据管理是纷繁复杂的,它是对企业数据现状的一种抽象、整合和展现,其管理是复杂和不容易的,其价值有可能是隐形的、不容易察觉的,它是一项承上启下,贯通业务和技术的基础性管理工作,因此选好不同时期其管理的价值点,逐步影响企业的方方面面。
选好工具,元数据管理可借助管理工具使管理工作变的相对快速和简单一些,如元数据的采集、元数据存储、数据血统、数据地图、元数据整合等都可以通过元数据工具来实现。
关于作者:王鹏,现任普元大数据产品线总经理,2009年进入国内数据治理领域,先后主导或参与金融、运营商、制造、政府、航空,物流等行业的数据治理解决方案的编写,以及相关落地项目的实施。
关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
窥探比特币核心机制如何运转
比特币真的很酷。当然,有人在想它是否是一种有用的技术,无论我们目前是否处于加密货币泡沫中,或者它目前面临的治理问题是否会得到解决......但在纯粹的技术层面上,神秘的Satoshi Nakamoto创造了令人印象深刻的技术。 不幸的是,虽然有很多资源可以对比特币的工作原理给出高级解释,我强烈推荐的一个这样的视频资源Anders Brownworth的blockchain visual 101,但是底层信息比较少。在我看来,如果你查看10000英尺的视图,那么你可以正确地理解这一点。 作为一个新手来说,我发现自己渴望了解比特币如何运作的机制。幸运的是,由于比特币本质上是去中心化的并且是对等的,所以任何人都能够开发符合协议的客户端。为了更好地了解比特币的运作方式,我决定编写自己的小玩具比特币客户端,该客户端能够向比特币区块链发布交易。 这篇文章介绍了创建一个最低限度可行的比特币客户端的过程,该客户端可以创建一个交易并将其提交给比特币点对点网络,以便它包含在区块链中。如果你只是阅读原始代码,请随时查看我的Github repo。 地址生成 要成为比特币网络的一部分,必须有一个地址,你可以从...
- 下一篇
马蜂窝消息总线——面向业务的消息服务设计
引言 马蜂窝消息总线于 2017 年 11 月份上线,截至目前,已经被电商、酒店、大交通、社区等多个技术团队投入到生产环境的使用中。 近一年时间里,消息总线经历过几次比较重要的功能迭代,承担了 PHP 在线服务异步、削峰、解耦的大部分任务。 这篇文章的目的主要是和大家交流下马蜂窝消息总线的设计原因、实现原理以及未来规划,希望能和有潜在需求的研发同学一起探讨。 我们为什么需要消息总线? 在消息总线上线前,马蜂窝大部分业务中的异步需求是通过 Redis 队列来实现。随着消息量增加,经常会出现消息积压、不同消息之间互相影响的问题。为解决这些问题,电商研发团队开始规划和设计消息总线。 为什么会有消息总线,而不是让业务系统直接用 PHP 或者其他语言对接 RabbitMQ,Kafka 这样的消息系统? 「消息总线和直接使用消息系列有什么实际的区别?」,这是很多研发同学一开始不太理解的地方。假如只是为了用一个性能更好的消息系统代替 Redis,确实并不需要消息总线的这个角色。 但当我们从实际业务角度出发,对公司整体技术架构和开发场景的梳理时,发现如果直接让业务系统对接消息系统,并不是一个很好的方...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- 2048小游戏-低调大师作品
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2全家桶,快速入门学习开发网站教程