关于元数据(Metadata) -- 菜鸟篇

这个问题和工作相关，最近思考也比较多，可以发表些个人看法。但工作日浅，希望以后有更深的理解再做更新。

为什么要有元数据？

这个问题是我加入公司第一个疑问的问题，毕竟应用在三层或者MVC结构中最终要和数据库的交互，无论是结构化还是非结构化的数据源，都要转成SQL或者类似SQL的查询语言，对于一个技术人员而言，自然而然觉得用户的需求直接被转化为SQL语句是自然而然的事情。定义元数据感觉像是多此一举，而元数据和数据库表列的映射关系又非常复杂，实际上会增大开发的难度和工作量。

关于这个问题，我觉得元数据有两方面的价值：

1. 服务于业务

对大多数公司而言，业务和技术即使不是完全无关的两个领域，但至少有很多不重合的地方，要求业务人员直接写SQL去获取分析所需要的数据是非常困难的。虽然互联网行业的很多数据分析人员具有SQL相关的知识，但首先对于很多传统领域（比如制造，销售），具有相关技术的业务人员还比较少，另外即使是在互联网领域，当面对数据提取需要的数十行甚至上百行SQL，业务人员难免会焦头烂额于其中，思考这个Column_ID和DESC是什么含义，那几个表不同的列名会不会有相关性，等等。公司的分工要求是人尽其职的，如果业务人员花过多的时间在如何获取数据上而不是想获取什么数据上，对于数据分析的效率是有很大影响的。

元数据的好处在于它是一种高层抽象，你可以理解它为逻辑层，在这里我们可以使用业务人员更熟悉的术语而屏蔽具体实现的细节。比如数据仓库的维度模型，我们可以定义事实表，定义维度表，事实表和维度表下面隐藏着具体的物理表，业务人员只需要和事实维度打交道（在什么维度下获取什么事实，当然这只是泛泛而言），而事实维度的概念更容易表述（最基本的写个文档给股东看，股东或许对库存周转率还有兴趣，如果看到一顿column_name大概就无法交流下去了）

2. 扩展性

如1所言，元数据封装了底层实现。我认为扩展性一方面指的是数据源，比如异构数据源，业务人员不需要关于分析的数据是从数据库来还是Hadoop来，不需要关于底层的实现，元数据是一个接口，接口里面可能是key-value，可能是column，或者其它什么，我们不需要关心。另外一方面为底层的调优预留了空间。不可否认自动化生成的SQL有它的问题，但事实上由一个数据库的门外汉（我就是）写出来的SQL不会好到哪里去，甚至会因为不一致性和语法错误浪费更多的时间。元数据让业务人员只在上层搞（在这里多补充一聚，元数据系统在通过不断定义新的model来实现业务的灵活性），而把底层交给熟悉数据库的专业人员。

如何定义元数据？

这里可以参考Kimball的维度模型，比如最基本的元数据可以有事实(Fact)，维度(Dimension)，当然还可以有其它很多，比如对于报表领域，你可以定义report的概念来包含相关的事实与维度。推荐microstrategy的相关文档，当然各家都有各家自己的设计观念，即使简单说可能也要好长的篇幅了，希望以后有时间总结下。

如何才算好的元数据？

惭愧，这点等我了解清楚再补充。