春宇
元数据管理这个大家谈的比较多，做起来的比较少，而且很多人对元数据的一些概念也不是很清楚，我先描述一下元数据的内容，也就是元数据都要管哪些东西。
元数据管理是我最爱谈及的话题之一，因为本人商业智能相关的绝世武功一直都没学好，而绝世武功的目录一直都背的不错。而元数据，真的很像绝世武功的目录。
不知道谁定义的元数据，和数据仓库商业智能等等长篇大论的定义迥然不同，它简直简短得不能再简短：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 PublicJr.
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各个领域均扮演极其重要的角色。可以说元数据管理是数据质量，以及信息治理的基础。如下经典，请铭记于心：数据不会自己管理自己。而我们需要通过元数据去管理他们。
BusinessMetadata
那么什么是BusinessMetadata？
广义来讲，所有用于描述业务各种逻辑的信息都可称为Business Metadata。这包括但不仅仅限于如下信息：
商业术语：BusinessGlossary, 包括名词和详细定义
术语分类：Taxonomies，对于上述的商业术语的逻辑归类，可构成Glossary Tree
业务规则：BusinessRule
业务流程：BusinessProcess，包括Activity, Input,Output, Supplier, Consumer, 等等
首先，商业术语（Business Glossary）, 提醒大家注意，这里的Metamodel，也就是装载 商业术语 元数据的框架。
接下来，术语分类
还有，业务规则
这些其实也是：
TechnologyMetadata
接下来什么是TechnologyMetadata？
广义来讲，所有在计算机系统中的各类数据的描述均可称为Technology Metadata。以BI系统为例，这包括但不仅仅限于如下信息：
系统：System
接口：Interface
实体/表：Entity/Table
属性/字段：Attribute/Column
数据转换：DataTransforming
......
# TechnologyMetadata是我们讲解的重点
Technology各个工具以及平台的情况：
1. DataRepository
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的InfosphereFacttrack具备此类功能，但也只可记录简单的Mapping信息，对于在ETL程序中的复杂实现还是无能为力。还好Infosphere系列能够记录数据血缘。
Informatica等工具未曾尝试，当下未知。
数据质量规则
Datastage,Informatica均支持数据质量管理，定义数据质量规则集合
3. Report &Analytics
语义层
Business Object的Universe
Cognos的FrameworkModel
OBIEE的语义层
将物理模型翻译成最终使用者容易理解的商业模型，屏蔽复杂的关联关系逻辑，增加维度的定义以及维度之间的关系等。
OperationalMetadata
接下来：OperationalMetadata指的是在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. 数据难于追溯
没有数据血缘的追溯，当修改一张基表时，根本无法获知其下游影响了多少表, ETLJob以及报表。而报表中某一个项目数据出错，也很难判断在什么环节数据出了问题。
9. 系统难于优化
如果没有Operational Metadata，很难对系统的运行状况作精准的分析并做出有效的优化措施。
元数据管理的策略，通常是需要建立元数据仓库，这个一般都是依托于某些元数据管理工具，我也只用过IBM的infosphere套系，原则上来说，所有的data about data都应该进metadata repository，包括服务器，文件，web service, etl jobs, 业务术语列集，也包括报表，
同时ETL 工具还能够捕获一些日常operation的log，也可以整合的元数据库里，再有就是对data的profling分析，比如row counts, null的比例，字符的pattern，与其他表的关联关系（假如你没有建外键的话，自动根据名字匹配，你也可以手动指定）等等。
infosphere套系有几个产品都可以做为元数据管理工具来使用，我相信informatica之类的也差不多，一个是蓝图工具，包括blueprint director和infospheredata architect。blueprint director这种东西我没见过其他公司有，大概就是画各个系统数据架构蓝图的东西。还有就是infospheredata architect，这个和erwin ,powerdeisnger是一样的东西。再有就是infosphereanalyzer，这种的就是data profling的分析工具，查看当前系统现状的，但这种东西非常耗费系统资源，我们都不能在PRD环境直接跑。此外还有fasttract，这个是做data mapping的，做ETL用的，还有asset magement，这个是用来导入各种元数据基本信息的，比如cognos 报表，BO语义层，也可以导入pdm等等，再就是workbench，有不少功能，还能做datalineage分析，内容比较繁杂，基本上思路就是用一个库去存储上面我说的各类信息，尤其对于数据血缘这种分析，大企业非常需要，当一个表的结构发生变化，我能知道下游有多少应用受到影响。
好了，元数据的内容很宽泛，暂时先讲到这。
