元数据与元数据平台
（一）元数据的定义
如果按照传统的定义，元数据是关于数据的数据，是为了描述数据的相关信息而存在的数据，例如记录数据的存储位置、模型定义、生命周期、血缘关系等信息。例如我们看一部电影，电影本身就是数据，那么元数据就是用来描述这部电影的数据。如下图所示：
在数据仓库体系中，元数据代表了一种统计数据从元数据、数据仓库到数据应用的全链路信息，记录了统计数据从产生到展示的全部过程。可以说，有了元数据，开发人员便可以方便的找到统计数据背后的计算逻辑与过程，用于指导开发工作并追踪数据问题，可以极大的提升工作的效率。元数据按照用途的不同可以分为两个部分：技术元数据和业务元数据。技术元数据是存储关于数据仓库体系建设细节的数据，常见的用如下几种：
-
存储信息：例如表名、字段名、字段备注、分区、责任人、文件大小、表类型、生命周期等；
-
运行信息：例如Hadoop上运行MR的Job信息、实例名称、输入输出、运行参数、执行时间、优先级等；再例如Hive上运行的SQL内容、查询表名、扫描文件大小等；
-
开发信息：例如数据开发方式、任务调度时间、上下游依赖、运行节点信息等；
-
质量信息：例如运行状态、报警信息、质量评分等。
业务元数据记录了从业务角度所关心的数据信息，通常面向产品及运营人员使用，因而记录的信息是十分简洁易的，主要包括：
-
数据信息：例如维度、字段涵义、安全等级、计算逻辑、指标定义等；
-
应用信息：例如展示平台、应用产品等。
（二）元数据存在的意义
在传统意义上，元数据有两方面的用处：
可以说，元数据有重要的应用价值，对于数据管理，提供诸如计算、存储、成本、质量、安全、模型等方面有重大的利用价值。阿里巴巴在OneData体系中，建设的相关平台是：数据地图。因为平台属于内部使用，因此不便于对外透露。但你可以设想一下，一个平台，拥有的数据表，在百万数量级，是一种怎样的体验。可以说，跨部门、跨平台之间的数据信息同步，基本上都是要数据地图平台来进行的，对于维护百万张临时表和几万张常用表来说，区分它们的安全级别、使用频率、重复性、数据质量等信息，真的需要一个团队去专门的维护。数据地图在整个数据体系中，承担的是一种管理者的角色，通过图形化的方式来展示数据信息，并标明数据计算中所必要的各种信息参数，不仅数据开发人员可以使用，对于产品和运营来说也是非常友好的。它包含的内容有如下几个部分：
-
快速的搜索定位：通过搜索引擎的方式来查找相关数据，支持精确查询、模糊查询、表名查询、字段查询、备注查询等方式；
-
标准化的图形展示：采用图形化的方式来组织页面逻辑，例如采用类似Wifi图标的形式来标注数据质量级别，肉眼可见的便捷，方便使用者所需要的关键信息；
-
积累历史数据信息：在很多场景下，历史数据是不需要重复计算的，直接拉取能够极大的避免重复开发。例如针对新用户的统计，可以拉取历史用户信息，和每日用户登录日志进行关联，用于生产每日新增用户；
-
直接关联分析工具：因为数据的信息直接存储在平台上，因而可以调用报表插件来快速看到直观的报表信息，不需要二次加工开发，很大的提升了开发的效率。
数据平台本身仍在不断的完善和开发中，更多的功能和更强的能力会被开发出来，以上提到的是其中的几个场景。
（三）元数据平台该如何搭建
标准的建设思路图如下：
其实根据数据团队规模的不同，并不一定要建设如此复杂和精确的元数据平台，对于中小型团队而言，能够满足技术元数据的相关指标已经足够，完整的元数据平台投入的人力物力不是一般的大，并且通常情况下针对跨部门、跨业务线的合作，这种平台的价值才能被真正的提现出来。首先要树立清楚自身的业务数据逻辑，例如在搜索统计中，针对CPM的统计有三种方式，分别为CPM1（搜索展现）、CPM2（广告展现）、CPM3（有广告的搜索展现），那么每一种的统计方式都要有定义，后续再理解指标概念时便不会有偏差。其次要了解清楚底层数据的来源，例如网页日志分为哪几种，客户端日志是实时采集还是延迟采集，这对于保障数据的统一性而言非常重要。再次要建立一批Dim信息表，这些表要记录每一种主属性所对应的其他维度信息，例如用户属性对应的有行业、客户类型、注册时间等信息，这些表是静态的，但需要有非常明确的定义和解释。然后要做相关的指标采集，例如Hive表信息如何定时读取对应的Mysql库，例如每一个字段的定义是否有人工准确标注，例如表的运行情况能否从运维那里要一个接口来读取，例如表之间的血缘关系是否有闭环图检查等等。最后还要有统一的对外接口，方便其他平台来读取和使用，例如实时平台来读取维度信息等。
