概述
#多图慎入
元数据管理是我最爱谈及的话题之一，因为本人商业智能相关的绝世武功一直都没学好，而绝世武功的目录一直都背的不错。而元数据，真的很像绝世武功的目录。
不知道谁定义的元数据，和数据仓库商业智能等等长篇大论的定义迥然不同，它简直简短得不能再简短：The data about data。好吧，我第一次看见这定义时，真心还是不懂，谓之玄而又玄。待经过一些学习探索之后发现这定义还是很棒的，更准确的或许应该是The information abut data。
看上面的经典DIKW金字塔，Metadata发生于 Data 和 Information之间，它是用于描述Data的东西，Metadata + Data就构成了Information。还是不懂是不是？
给个例子： Rainbow 2011/07/06
如上两个，均是Data，单纯看他们，我们是无法猜出它们的含义的，但如果：
而这里，“名字”和 “生日”分别是用来描述Rainbow和 2011/07/06，它们使 Rainbow和2011/07/06具有了含义，从中我们获得的信息 “一个叫Rainbow的孩子，生日是2011年7月6日”。”名字“和”生日“就是元数据。
下面这张图很有趣，它以关系型数据库为例，解释了三个术语。
1. 数据，在图中就是Data Instance，这里给出一个人的名字以及他的相关信息：Mr. John Public Jr.
2. 模型：在图中对应Model，给出了在数据库模型中，为了描述上面的 人 的数据，构造了怎样的 元数据 模型：有三个实体，分别是Person，Name和Address。这Model对应的内容，就是我们今天的课题：元数据
3. 元模型：这个其实是我们今天要讲的重点，它是用来装 模型 的框架，因为是关系型数据库，因此元模型对应的内容就是 DataModel(数据模型）， LogicalEntity（逻辑实体）和Relationship（关系），其实还应该有Attribute（属性），Constraints（约束）等等关系型数据库中的概念。
而我们学习元数据，其实应该先去了解不同类型的元数据对应的元模型，而元模型作为元数据的框架再去填充元数据的内容。
接着说元数据，元数据按照功能主要分为三类：
1. Business Metadata
2. Technology Metadata
3. Operational Metadata
而对于BI系统而言，这三类元数据，横亘整个BI全部生命周期，且在DB，ETL，Report各个领域均扮演极其重要的角色。可以说元数据管理是数据质量，以及信息治理的基础。如下经典，请铭记于心：数据不会自己管理自己。而我们需要通过元数据去管理他们。
Business Metadata
那么什么是Business Metadata？
广义来讲，所有用于描述业务各种逻辑的信息都可称为Business Metadata。这包括但不仅仅限于如下信息：
商业术语：Business Glossary, 包括名词和详细定义
术语分类：Taxonomies，对于上述的商业术语的逻辑归类，可构成Glossary Tree
业务规则：Business Rule
业务流程：Business Process，包括Activity, Input, Output, Supplier, Consumer, 等等
首先，商业术语（Business Glossary）, 提醒大家注意，这里的Metamodel，也就是装载 商业术语 元数据的框架。
接下来，术语分类
还有，业务规则
这些其实也是：
Technology Metadata
接下来什么是Technology Metadata？
广义来讲，所有在计算机系统中的各类数据的描述均可称为Technology Metadata。以BI系统为例，这包括但不仅仅限于如下信息：
系统：System
接口：Interface
实体/表：Entity/Table
属性/字段：Attribute/Column
数据转换：Data Transforming
......
# Technology Metadata是我们讲解的重点
Technology各个工具以及平台的情况：
1. Data Repository
Data Modeling: Table/Column等详细信息
可使用工具如ERWIN，PowerDesigner, Infosphere Data Architect等等，几大主流数据建模工具之前的元数据可以项目export/import，会有少量问题但基本可以重用。
Oracle，DB2， MSSQLServer等均有自己的数据字典，可以反向生成为数据模型文件。数据库的数据字典不会记录如前面描述的详细的元数据信息，因此需要Designer在做Model的时候整理元数据，或以comment的形式保存至Data Model中，或自定义元数据模型将相关信息保存。而几大Data Model软件都以文件的方式保存(PD具有一定的Repository功能，但功能也不够丰富），因此如果我们要做元数据管理，也应该将Model的信息结构化的保存到Metadata Repository中。一些Matadata Repository也能够支持数据模型的导入。
2. ETL
数据转换规则
最常使用的还是EXCEL表，IBM的Infosphere Facttrack具备此类功能，但也只可记录简单的Mapping信息，对于在ETL程序中的复杂实现还是无能为力。还好Infosphere系列能够记录数据血缘。
Informatica等工具未曾尝试，当下未知。
数据质量规则
Datastage, Informatica均支持数据质量管理，定义数据质量规则集合
3. Report & Analytics
语义层
Business Object的Universe
Cognos的Framework Model
OBIEE的语义层
将物理模型翻译成最终使用者容易理解的商业模型，屏蔽复杂的关联关系逻辑，增加维度的定义以及维度之间的关系等。
Operational Metadata
接下来：Operational Metadata指的是在DB, ETL，Report等所有过程中，如日志、安全、审计、血缘等等信息。通常他们可以用来解答如下问题：
1. Job运行成功了还是失败了？有哪些出错或警告信息？
2. 上次Job中哪些数据库表，或者文件被读取/修改了？
3. XX Job在最近几次运行中读取多少条记录，修改多少条记录，引用多少条记录，平均速度如何？
4. XX Job什么时间开始，什么时间结束的？
5. Job运行在哪个服务器上？
6. 一共多少张报表上个星期发布了？
7. 多少个Schedule报表运行成功了？
8. 报表运行成功后发送了多少封邮件给不同用户？
9. XX报表的平均访问频率是多少？什么时间访问的最多？
...... Operational Meta种类繁多，在此不一一赘述，需结合实际项目应用做详细的规划。
不做元数据管理的危害
1. 系统难于理解
大公司林林总总的系统上千级别，而各个系统均只考虑当下不考虑未来，经年累月之后会发现系统无法理解。后面则会带来大量的项目风险，开发成本，时间成本，等等多种问题，也会造成很多有创意的新的idea没法办法展开。总之，后患无穷。
2. 信息无法整合
基于上面的问题，系统无法理解，当需要做信息整合时完全无从下手。
3. 知识无法传递
系统的知识保存在架构师的头脑中，或者上帝的头脑中，当精英人员流失会造成知识无法传递，系统无法更新升级也无法指导未来的信息集成。
4. 信息质量问题
元数据质量不高，几乎一定会带来后期的信息质量问题。同一含义的字段采用不同的名字，不同含义的字段采用相同名字，等等问题会带来大量数据不一致问题。
5. 阻碍企业发展
元数据以及数据质量问题甚至会影响到企业的发展，信息系统为企业提供有力的支撑，如果底层数据存在大量问题，很多企业的运行无法正常展开。可以想象如果Amazon如果数据质量不能支持精准的推荐，就不会有Amazon的今天。
6. 无法重用
Information as Service很大程度上需要对企业通盘的信息规划的考虑，完善的元数据是其基础。
7. 影响项目开发质量和效率
几乎要从头分析源系统的结构，并且没有可重用的元数据。会造成开发效率低下且开发质量没有办法保证。
8. 数据难于追溯
没有数据血缘的追溯，当修改一张基表时，根本无法获知其下游影响了多少表, ETL Job以及报表。而报表中某一个项目数据出错，也很难判断在什么环节数据出了问题。
9. 系统难于优化
如果没有Operational Metadata，很难对系统的运行状况作精准的分析并做出有效的优化措施。
未来会有下篇，如何规划以及实施元数据管理，敬请期待。
对BAO胖子原创文章感兴趣的朋友，请关注我的公众号。
22 个评论
BAO胖子 回复 rocky_wang
BAO胖子 回复 crazygoalie