由两个实例看元数据管理

设计BI系统，免不了要跟元数据打交道，但有时候人们感觉不到它的存在。比如要了解数据库结构的时候，并不需要从系统表中去查看，可能只需要一个文档、一个命令或者通过数据库治理工具辅助查看即可；但假如要开发一种查询器，以供半业务半技术人员使用，让他们基于业务术语拖拖拽拽拼凑成SQL提交查询，这样的查询器就必然要去访问元数据了。
是什么？
元数据究竟是什么？用”描述数据的数据”(Data About Data)来定义确实是非常精简的，不过作为一种迭代式的定义，似乎并不够准确。从名称上理解，元数据也是数据，那么描述元数据的数据是什么？元元数据？如此迭代下去，就没完没了了。
用打比方的方法来辅助这个定义可能更加清楚一点。将元数据治理想象成是一个客户治理系统。企业为了更好地服务客户（其实是如何从客户身上赚取更多的利润），需要将客户治理起来，搞好客户关系。同样的道理，元数据治理系统也是为了更好地利用数据。客户有生命周期，比如什么时候被企业服务，什么时候脱离企业服务，处于什么状态等等；数据也是如此，什么时间产生，什么时间被什么人使用，状态的变迁等等。
在数据仓库中，元数据的概念被强化了，在每个数据仓库项目的总体架构图中，几乎都有”元数据治理”模块来横贯其他模块。显然，这表示它是一种基础模块，可以服务于诸如OLAP、ETL等其他模块。但实际上，却很少见一个完成了的数据仓库项目中有独立的元数据部分。大多项目，元数据都是分散在各种BI工具中。
这些分散的元数据是不一致的，例如对一张表的结构定义，可能出现在ER设计工具中，当然也会在数据库的数据字典中，还有可能在ETL工具的源、目标定义中。如此多的重复定义，当然会发生数据不一致现象，却也正好为元数据治理工具留下广阔空间，它们的作用就是集中治理这些分散的元数据，就像数据仓库一样，从不同的源采集数据，有ETL，也有清洗，甚至重新建模。
谁做过？
对于一些大型企业来说，尽管有时候还不能确定建立元数据治理系统的作用，但这方面的需求还是有的。例如中国移动就有吉林、湖北两个省公司高调宣传自己的元数据治理项目，这算是一种积极的尝试，也在为整个业界的元数据治理应用起到了推动作用。假如从宣传文字看，都是冠冕堂皇一个味道，没什么意思，但另外一家D省公司和这些先行者一份对比报告，却显得颇为有趣。
D省公司其实也有元数据治理的内容，只是尚未形成系统，这份报告就围绕着组织架构、建设时间、项目投资、系统功能等方面与吉林移动元数据系统展开了比较。从架构和投资上的比较很简单：吉林移动的元数据治理系统从建设时间稍晚一些，但是当作一个项目来建设，而D省则是夹杂在经营分析系统中一起建设，因此在组织结构上肯定不同；项目投资上，吉林移动投资了几百万，而D省公司由于并未单独立项，所在在报告就显示分文未花。
最重要的差别还是在系统功能上。吉林元数据作为一个项目提供了应用且易用的前端；而D省公司的元数据治理偏重于后台，提供系统监控、治理和优化等技术上的应用，都是面向技术人员，对业务元数据考虑较少，几乎没有提供给业务人员使用的界面。
不管两省公司的比较结果如何，从总体来看，两公司的元数据治理都还缺乏深入的应用，例如数据质量治理、影响分析、血统分析等，大都是在强调元数据治理的平台性。所谓平台，就是搭好了台子，上面唱什么戏就不管。至于这个平台是不是能够支持人家唱戏，是不是平整，目前还没有什么东西来衡量。
怎么样？
总的来说，元数据治理还是一个不成熟的领域。具体原因有业务和技术两个方面。
从业务上看，很多人对于建立一个元数据治理、交换平台的目的并不明确，也没有人知道集中这些元数据究竟给企业带来多大价值。
从目前国内企业所处的阶段看，建立这样一个平台并不能产生多少价值。即便是在平台的建设初衷和谁来使用这个平台等问题上，也有多种说法。例如有人说这是企业数据标准的前提，也有人认为是企业数据集成的基础，可以使系统变得可扩展。这些听起来确实有道理，但也太过空洞。假如追问下去，这些说法都经不起推敲。比如建立企业数据标准又是为了什么目的？数据集成又是为了什么目的？
这样追问并不是要否定数据标准或是数据集成，而是说其目的都不够直接。你可以将元数据治理作为企业的基础设施来做，就像城市修路、造林一样，是为了一个宏大的目标，可以造福广大群众。但是对于一般的企业来说，在整个IT系统体系不够成熟的时候，奢谈什么基础设施无疑有些过于超前。做元数据治理本身没问题，要害是你要给谁用？功能是什么？假如有人要求做数据质量控制、性能优化或者系统监控、灵活报表查询等等，这些都可以直接做，可假如你站在云端里面说 “我要建立企业的数据标准”，那么，还是先撇开元数据，先看看如何解决不同部门的沟通鸿沟以及工作习惯问题吧。
从技术上看，统一的元数据标准尚未真正建立起来。
一般元数据治理工具大多提供的是元数据交换功能，基于某种标准，从其他BI工具（诸如ER建模工具、数据仓库、ETL工具、OLAP工具等）中抽取元数据到集中的库中，目前既成事实的元数据标准是CWM（Common Warehouse Model）。
但问题是，这类工具涉及到与众多工具的交互，即便是它遵从某一标准，假如其他工具不遵循，问题依然不能解决。例如DAG（Data Advantage Group）公司的Metacenter，应该算是元数据治理工具领域的佼佼者，但其功能也非常有限。它在项目组里面应用，确实可以从Oracle、Essbase等产品中提取元数据，对于ER建模工具，可以从ERWin中提取表的设计信息，有内嵌的抽取模块。但在另一方面，却没有对PowerDesigner的抽取模块，问题是，项目里面就是用PowerDesigner设计ER模型。由此，这类工具假如不能完全集中所有的元数据，整个数据仓库中数据流就出现断层，所谓一致性分析、血统分析也就无法建立起来。
目前，将数据看作企业的信息资产这种观念已经逐渐被接受且重视。业务人员想去了解数据的渴望，治理人员对数据质量的要求，都将使得元数据提供更多实际的应用并起到越来重要的作用。