元数据管理技术及应用现状

http://www.csai.cn　作者：佚名　来源：http://www.chinabi.net　2006 年 10 月 19 日　发表评论　进入社区

　　朋友老朱在最近惊喜地发现，在营业部的每周例会上，原先各部门针对每日用户数的

争吵声，现在逐渐销声匿迹了。原来，老朱所在的这家电信运营商，最近刚刚验收并启用了

一个元数据管理平台工具。通过这一平台，IT 部门可以在那些曾经引发激烈争吵的数字后

面加上详细的注解。这样，即便各部门得出的当日用户数数值不一样，也能在注解中清楚地

看到具体的差异在哪里。如此，自然再没有了吵来吵去的必要。

　　元数据，最常见的定义是：“关于数据的数据”。更准确一点说：元数据是描述流程、

信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义

（包括字典和分类法）以及操作特征（如活动指标和使用历史）。早在上世纪末，元数据的

概念和相关工具就已经出现，但限于当时的数据量还不够大，而元数据本身又包含太多的

内容，以至于它并未得到充分利用。而在今天看来，元数据正在成为解决诸多数据问题时必

须要抓住的一个“精髓”要素。

　　消弭争吵

　　在此前一年中，老朱所在的那家电信运营商，各部门之间经常就每日用户数这类问题

的指标数值不一致而吵得面红耳赤。其实，在其他电信公司或者其他行业中也都存在着类似

问题。简单来讲，这些公司通过各个时期的 IT 建设，形成了很多个独立分开的系统。以电信

运营商为例，就有计费系统、网络系统、OA 系统、财会系统和客服系统等等。在这些系统中，

存有不同的客户信息，具体体现就是不同格式的表。

　　两年前，公司的数据仓库项目建设完成，本以为这会大步提升 IT 系统的“智能性”，

没想到，基层的反映却是根本没法用。而其中的原因就在于，数据质量没法保证，也即：在

业务逻辑上并不准确，各部门对于指标的定义不能统一。
　　以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。

按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：

计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，

只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。

如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有

6000；市场部的系统显示却只有 4000；到了财务部门的系统中，显示仅有 3000 个。在这种

情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大

家对数据仓库系统本身的可信度也就打了折扣。

　　事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，

原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据

仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查

工作自然要求 IT 部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一

般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程

中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月

的时间也过去了。

　　元数据管理平台的建设就是为了避免继续出现类似问题。在元数据管理平台建成之后，

其一，可以实现对技术元数据的抽取,把相关的字段放到平台上来。在这个平台上，就能清

晰地看到这些表或字段之间的关联关系，有一个很清晰的视图。其二,还会把业务元数据抽

取出来，确定要做哪些应用，就把相关的指标、流程在平台上建立起来。把这些元数据抽取

出来后，用户可以通过平台很方便地修改数据仓库中的数据，调整业务中的统计指标等等。

其三，就是要把技术元数据和业务元数据两种数据对应起来。比如对于当日用户数来讲,它

在数据仓库中对应的都是哪些表，让技术元数据和业务元数据联系起来。这样，在把各种定

义统一之后，元数据管理平台就可以给出一个更为详细的指标。比如在数值之后做出注解，

注明具体开机的有多少，发生费用的又有多少。如此，老朱所在公司的争吵也就不复存在了。

　　第三 方工具的 魅力
　　虽然元数据至今尚未引起业界的广泛重视，但是与元数据相关的管理工具其实早就存

在，而专业的元数据管理工具则在 2000 年左右开始出现，比如像

IBM、CA、DAG、Informatica、BEA 等公司都有自己专门的元数据管理工具。

　　总起来看，目前国内的元数据管理工具大概有三类。一是像 IBM、CA 等公司都提供的

专门工具,比如 IBM 收购 Ascential 得到的 Metastage，CA 的 DecisionBase 都是如此；二是像

DAG 的 Metacenter，它不依托于某项 BI 产品，是一种第三方的元数据管理工具；三是像亚

信、石竹这样的集成商也在开发自己的元数据管理工具。

　　“各种元数据管理工具有很多。理论上讲，用户可以用其中一种管理其他系统中的数据，

比如选择数据仓库系统厂商提供的元数据管理工具来管理其他层面的元数据。但实际应用中

的管理效果如何呢？一般情况是，这些专门工具管理自己本系统的元数据尚可，一旦跨系

统管理，效果就不尽如人意了。” 亚信产品及解决方案咨询部总监薛森这样表示。

　　从国内的实际应用来看，DAG 的 Metacenter 这一工具使用最多，目前所看到的在电信、

金融领域建设的元数据管理项目基本上都是应用了这一产品。至于像 CA 等公司的工具，在

国内基本上没有成功案例。记者在对 CA 公司提出采访要求的时候，该公司在回复中则称没

有合适人员接受采访，看来像 CA 公司在元数据管理技术上似乎还比较滞后。

　　石竹商业智能软件部产品支持经理薛勇认为，Metacenter 能够为很多用户所采用，主

要因为这一产品的几项优势：一是它是第三方提供的工具。二是在技术上确有过人之处，可

以实现动态元数据管理，实时获取元数据。而其他非第三方工具可能对自己数据仓库中的数

据看得很快，但是对于其他系统就不行了。三是可以提供的应用多。比如像血统分析和影响

分析、表重要程度和表无关程度分析等都可以提供。

　　此外，还有两个产品使得 SOA 和元数据的紧密关系迅速凸显出来。首先是 IBM 的

WebSphere 元数据服务器将于今年年底作为 IBM WebSphere 信息集成（WII）平台 Hawk 版

的组成部分正式上市。
　　WebSphere 元数据服务器将为 WII 平台中的产品提供元数据管理，并为其他 IBM 软件

品牌中的元数据项目提供通用的元数据服务基础设施。同在今年底，WebMethods 公司将在

12 月份发布的 Fabric 产品下一版本也融合了 Cerebra 公司的语义元数据管理功能，从而来

为 IT 部门提供了软件资源的单一视图。或许，只有当 SOA 战略充分认识到元数据管理的重

要性之后，企业信息资源的业务价值才能实现最大化。

　　元数据 管理工具 现状一览 表

　　应 用决定功 能

　　“这样一个平台不是仅仅把元数据抽取出来，我们把元数据管理平台定位为两个应用

层次。”亚信产品及解决方案咨询部总监薛森指出了目前元数据管理平台的两个主要应用层

次，即系统维护和应用分析。从系统维护来看，元数据管理平台使得数据仓库以及业务系统

中的各种修改变得省心省力。比如对数据库中表的修改，小的数据仓库模型的修改等等，都

可以通过元数据管理平台来实现。同时对数据仓库、OLAP、ETL 等各个层面进行修改。而在

以前，这些工作需要 DBA 自己来完成。

　　那时虽然也有一些工具，但是都分散在不同的系统中。一个 DBA 要完成全部修改必须

要求精通所有工具才能实现。而如果是多个 DBA 协作完成，同样需要通知所有人在数据仓

库、OLAP、前端展现、ETL 等系统中依次修改，耽误时间不说，修改是否准确也不能保证，

而业务在这个修改阶段也会陷于停滞。从应用分析上看，目前可见的应用主要有三类。

　　其一，作为即席查询工具做指标的管理，即通过基于元数据的指标管理，掌控各种指

标的异常波动情况。据薛森介绍，像亚信公司建设的吉林移动的元数据管理平台，现在就已

经开放了一些接口给业务人员。他们只需通过拖拽一些业务元数据就可以得到他们想要的东

西。比如，要找出某项业务的前十大用户，业务人员通过元数据平台提供的即席查询工具，

几次操作就可得到结果。而在过去，这需要业务人员首先提出请求，然后计费中心会制作一

个工单，再把工单传给集成厂商，厂商再把这个工单分解开来，让某人做 ETL 层，某人做

OLAP 层。等这些都做完，半个月的时间也就搭进去了。

　　当然，薛森也表示，目前这种应用接口还比较有限，因为如果每个业务人员都在用，

数据仓库就承受不住了。其二，血统分析和影响分析。血统分析是指，发现某报表中的指标

不正常就需要查出问题可能出在哪里。通过血统图就可以很快找出问题是在 BOSS 系统中，

还是在 ODS 层或者是 DW 层中。影响分析则和血统图相反，主要看在修改一个表之后，可

能会影响到上游的哪些数据。其三，表重要程度分析和表无关程度分析。主要就是针对现在

数据仓库提供的表的数量太多（上万个）。这些表中有的使用频率特别高，就需要加倍小心，

多做优化。通过元数据管理平台就可以列出不同重要程度的表。

　　据石竹商业智能软件部产品支持经理薛勇介绍，目前，像四川移动的元数据管理平台

上，以上三类应用基本上都已存在。但是，他也表示，目前针对元数据管理平台的应用大都

还在探索阶段。亚信薛森也认为，更重要的应用还在于更复杂的分析上。此外，据说目前国

内迄今为止最为全面的一个元数据管理平台项目正在中国银行总行抓紧实施，现在尚未开

始验收，其中还将出现哪些新的应用尚且不得而知。

　　编 看编想
　　不 够成熟， 但足够重 要！

　　“你在做元数据管理平台项目时，最大的工作量是花在哪里？”这是笔者对每位被访

者都会问的一个问题，而两位采访者不约而同提到的一点就是，整理元数据。事实上，这一

问题也正彰显着目前国内的元数据管理项目尚不够成熟。

　　“说不成熟，是因为数据不成熟。”薛森表示。作为企业，从一开始就没有完整的规划，

比如当初指标的含义，现在几乎都需要倒着往回推，要获得那些元数据自然就比较困难。薛

勇也认为，各部门都有各自的描述方式，比如对于男女，有的分成 F 和 M，有的分成 0 和

1。如果把这些整理出来，是个很麻烦的过程。而要克服这种困难，只能靠熬时间一点一点解

决。而像管理工具本身的不成熟也是一个方面。薛勇就认为，目前的元数据管理工具还不能

自动把不同系统元数据之间的关系自动映射出来，还需要人工去做。

　　此外，目前平台导入的元数据范围也还很有限。比如在电信企业中，大多仅仅导入了经

营分析系统的元数据。而像 BOSS 系统，动辄都有几千个业务控制点，导入元数据弄不好就

要影响业务。也正是因为顾及到这一点，所以目前的元数据管理平台只是选择了在经营分析

系统这样一个准实时的分析系统上做试点，然后再逐步推广。

　　总起来看，目前国内大型行业企业做元数据管理项目虽然不成熟，但是技术发展很快；

见效虽然不快，但是早晚要做，而且早做比晚做遇到的困难相对要少些。对于那些有条件的

大型行业用户，早点入手无疑更好一些。(CCW-CNW)