元数据与元数据管理
Posted Data+Science+Insight
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了元数据与元数据管理相关的知识，希望对你有一定的参考价值。
元数据与元数据管理
元数据
Apache Ranger 是一个用在 Hadoop 平台上并提供操作、监控、管理综合数据安全的框架。Ranger 的愿景是在 Apache Hadoop 生态系统中提供全面的安全性。 目前，Apache Ranger 支持以下 Apache 项目的细粒度授权和审计：
Apache Falcon是一个开源的hadoop数据生命周期管理框架, 它提供了数据源 (Feed) 的管理服务,如生命周期管理,备份,存档到云等,通过Web UI可以很容易地配置这些预定义的策略, 能够大大简化hadoop集群的数据流管理。
Hortonworks的hadoop发行版HDP中,数据治理包括Falcon和Atlas这两个组件.Atlas主要负责元数据的管理. Falcon主要负责数据生命周期的管理.
任何文件系统中的数据分为数据和元数据。数据是指普通文件中的实际数据，而元数据指用来描述一个文件的特征的系统数据，诸如访问权限、文件拥有者以及文件数据块的分布信息(inode...)等等。在集群文件系统中，分布信息包括文件在磁盘上的位置以及磁盘在集群中的位置。用户需要操作一个文件必须首先得到它的元数据，才能定位到文件的位置并且得到文件的内容或相关属性。
元数据管理有两种方式。集中式管理和分布式管理。集中式管理是指在系统中有一个节点专门司职元数据管理，所有元数据都存储在该节点的存储设备上。所有客户端对文件的请求前，都要先对该元数据管理器请求元数据。分布式管理是指将元数据存放在系统的任意节点并且能动态的迁移。对元数据管理的职责也分布到各个不同的节点上。大多数集群文件系统都采用集中式的元数据管理。因为集中式管理实现简单，一致性维护容易，在一定的操作频繁度内可以提供较满意的性能。缺点是单一失效点问题，若该服务器失效，整个系统将无法正常工作。而且，当对元数据的操作过于频繁时，集中的元数据管理成为整个系统的性能瓶颈。
分布式元数据管理的好处是解决了集中式管理的单一失效点问题， 而且性能不会随着操作频繁而出现瓶颈。其缺点是，实现复杂，一致性维护复杂，对性能有一定影响。
public Customer(String id, String name, String address, String ID) {
这里的Customer 就是元数据的集合，而类的属性就是元数据，用来描述数据是什么的问题。
1001 张三 深圳南山区高新南四道20号 123456789100123456
这条数据并没有任何含义，我们也不清楚该条数据所要表达的内容，但当我们换成如下的方式：
1001 张三 深圳南山区高新南四道20号 123456789100123456
使用编号，姓名，地址，身份证来描述1001 张三 深圳南山区高新南四道20号 123456789100123456。这条数据就有了具体的含义，让我们获取到"编号1001的人的名字是张三，地址在深圳南山区高新南四道20号，身份证号123456789100123456"这样的信息。这里类似与java代码中的Customer zhangsan = new Customer('1001','张三','深圳南山区高新南四道20号','123456789100123456'); 是一个对象。简单的总结就是当我们使用元数据+数据就形成了信息。
数据不会无缘无故的产生，也不会自己表述其具有的含义，更不会自己管理自己，所以我们才会有数据治理。如果用数据库的表设计来说明的话，我们大概分为三个部分，分别如下：
3.物理模型，用来存储ER图实际的物理结构，包括存储结构和存储方法。
按照元数据的功能来划分：1是业务元数据；2和3属于技术元数据；还有一个是操作元数据，主要就是描述数据是怎么产生，如DB的日志，数据使用的时候安全，审计，血缘等信息。数据治理实际就是在管理业务元数据，技术元数据，操作元数据这三方面的内容。那么Atlas的数据治理，有提供了那些核心功能了？
可以看出其包括了数据装载名称，数据库名称和权限拥有者，表名称，视图名称，字段名称，还有数据访问方式，维度，度量，ETL这些分类特性等内容。
从上往下，我们看到的是搜索，血缘，交换，知识存储，审计，数据生命周期，访问控制和策略。
2.2血缘：从数据产生，如ETL的过程，到数据的存储，再到数据的使用。能够方便的让我们定位数据问题，是上游ETL，或者下游数据报表发生数据变化。
2.3.交换：和已有的元数据做对接，比如已经在SAS，BIEE中已经建好的元数据，可以直接导入到Atlas中，或者将Atlas中已有的元数据导出到其他。
2.4.知识存储：数据存储中，Atlas会根据自己的分类，策略规则，类型约束，或者元模型自动的进行存储。例如如下类型的数据：
customer_id order_id product_id time_id sales
Atlas将sales分类为度量Metric。或者如下类型的数据：
Atlas将address分类为PII(Personally Identifiable Information,个人验证信息),这里也是对外提供Rest Api服务的时候涉及的数据标准。另外自己感觉这里的知识存储和DIKW中的K相似，都是让我们知道这些数据如何去使用。
2.5.审计：审计是出于数据安全，隐私，或者法律政策。什么数据应该存，或者怎么存都会有一定的要求或者标准。例如如下类型的数据：
customer_id name phone_num address ID
很显然phone_num,address,ID属于敏感信息，是受隐私保护的。只可惜在中国对数据安全大家都不重视，比如在淘宝购买了商品，然后骗子获取到了你未做敏感信息处理的订单信息和身份信息，然后对你实施诈骗。
2.6.数据生命周期：数据是有时效性的，最简单的例子就是如果你设计数据中心为3年的话，到第四年开始，在第一年进入数据中心的数据就可以转做进线存储或者离线存储，即第一年的数据在这个数据中心的生命周期结束。更别说数据库查询中的临时表，临时为了某个业务场景验证，做开发和测试，完成后就直接删了，这种数据生命周期更短。
2.7.标签策略：最简单的标签就是将元数据的分类，如元数据属于Metric,ETL。或者接6所说的，数据是有时效性的。例如市场部门往往关注今天有多少订单产生，然后偶尔关注这个月产生了多少订单，越往前的数据，使用频率和访问频率越底。这里就可以对数据使用热度标签。
2.8.安全：也就是Atlas中的基于标签的访问控制，最简单的标签就是允许和不允许。数据应该只被该访问的人访问，如果一个用户是报表用户，那他就只能访问那些report的数据，而不会是其他数据，更别说不具有数据访问权限的用户。
上面只是简单的介绍了Atlas是什么和具有的功能，我们来看个简单的例子，业务人员想要了解“2015年12月1日广东的空调销售额是多少”，可以解析为如下内容：
那我们应该如何去实现？大概过程如下：1.查询2015年12月1日所有的订单 --> 2.过滤出其中客户地址是广东的订单 --> 3.对这些订单的销售额进行求和。可是要完成这个报告接着发现有这些问题：订单数据从那里来，怎么获取，获取后存储到那里？实现过程大概如下：1.发现我们需要客户表，产品表，订单表的数据 --> 2.发现这3张表保存在销售数据库 --> 3.采用ETL，将数据加载到报表数据库 --> 4.产生数据报告，结论。在这个过程中会涉及如下图所示的元数据：
说明：这里对sales_fact中的时间字段做了规范化设计，所以产生了时间维度表time_dim。
Atlas采用Text File或者ORC File的方式，简单表述如下图所示:
可以看出，Atlas只是对元数据层进行操作，并不会直接操作到数据层。比如上面中的客户表，可能有手机号，身份证号等字段，但是在"2015年12月1日广东的空调销售额是多少"这个业务中没有任何作用，所以不会管理这两个字段，或者初始设计的时候管理了这两个字段，然后发现没有使用到的时候可以进行del操作。注意，这里的del不涉及到数据层，不同于navicat连接的mysql，直接操作的数据层，把表的列给删除，只是删除了元数据层。
1.数据整合：如果没有元数据，你不可能把客户表，订单表的数据整合在一起，从而发现更多的数据价值；
2.数据追朔：报表数据库中的客户表的数据来源是否是销售数据库的客户表数据；
元数据是指描述数据的数据，通常由信息结构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，比如 UML 模型、数据交易规则、用 Java，.NET，C++等编写的APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等。
在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。
- 业务元数据：主要包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者是业务用户。
- 技术元数据：主要用来定义信息供应链（Information Supply Chain，ISC）各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等，以及存储过程、函数、序列等各种对象。
- 操作元数据：是指应用程序运行信息，比如其频率、记录数以及各个组件的分析和其它统计信息等。
从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。
各个企业的元数据管理策略和元数据管理成熟度差别较大，因此元数据集成体系结构也多种多样。大体上元数据集成体系结构可以分为：
- 点对点的元数据集成体系结构；
- 中央辐射式元数据体系结构；
- 基于 CWM（Common Warehouse MetaModel，公共仓库元模型）模型驱动的点对点元数据集成体系结构；
- 基于 CWM 模型驱动的中央存储库元数据集成体系结构；
- 分布式（联邦式）元数据集成体系结构；
- 层次/星型元数据集成体系结构；
模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。
元模型（Metamodel）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。
1）一个简单的关系型表元模型：描述了如何定义一个关系型表，例如
2）如果要创建一个关系型表模型，基于该表元模型创建一个实例即可：
- 创建一个常见的雇员表 Employees 表模型，Employees 表包含 6 个列，分别是编号、姓、名字、部门编号、经理编号和职位编号
- 另一个实例 department 表模型。department 表包含 2 个列，分别是编号和部门名称
元-元模型就是元模型的模型，有时也被称为本体（ontology），是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。
元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。
- L3 是元-元模型：元类、元属性、元操作
- L2 元模型：类、属性、操作、构件
- L1 模型/元数据：实体-关系（ER）图
- L0 用户对象/用户数据：交易数据、ODS 数据、数据仓库数据、数据集市数据、数据中心数据等
元数据是用来描述数据的数据（Data that describes other data）。单单这样说，不太好理解，我来举个例子。
下面是契诃夫的小说《套中人》中的一段，描写一个叫做瓦莲卡的女子：
（她）年纪已经不轻，三十岁上下，个子高挑，身材匀称，黑黑的眉毛，红红的脸蛋－－一句话，不是姑娘，而是果冻，她那样活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑，动不动就发出一连串响亮的笑声：哈，哈，哈！
这段话里提供了这样几个信息：年龄（三十岁上下）、身高（个子高挑）、相貌（身材匀称，黑黑的眉毛，红红的脸蛋）、性格（活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑）。有了这些信息，我们就可以大致想像出瓦莲卡是个什么样的人。推而广之，只要提供这几类的信息，我们也可以推测出其他人的样子。
这个例子中的"年龄"、"身高"、"相貌"、"性格"，就是元数据，因为它们是用来描述具体数据/信息的数据/信息。
当然，这几个元数据用来刻画个人状况还不够精确。我们每个人从小到大，都填过《个人情况登记表》之类的东西吧，其中包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等......这一套元数据才算比较完备。
在日常生活中，元数据无所不在。有一类事物，就可以定义一套元数据。
喜欢拍摄数码照片的朋友应该知道，每张数码照片都包含EXIF信息。它就是一种用来描述数码图片的元数据。按照Exif 2.1标准，其中主要包含这样一些信息：
Image Description 图像描述、来源. 指生成图像的工具
XResolution/YResolution X/Y方向分辨率 本栏目已有专门条目解释此问题。
ExifOffsetExif信息位置，定义Exif在信息在文件中的写入，有些软件不显示。
ExposureProgram曝光程序 指程序式自动曝光的设置，各相机不同,可能是Sutter Priority（快门优先）、Aperture Priority（快门优先）等等。
ComponentsConfiguration图像构造（多指色彩组合方案）
CompressedBitsPerPixel(BPP)压缩时每像素色彩位 指压缩程度
MeteringMode测光方式， 平均式测光、中央重点测光、点测光等。
FocalLength焦距，一般显示镜头物理焦距，有些软件可以定义一个系数，从而显示相当于35mm相机的焦距 MakerNote(User Comment)作者标记、说明、记录
FlashPixVersionFlashPix版本 （个别机型支持）
ExifImageWidth(Pixel X Dimension)图像宽度 指横向像素数
ExifImageLength(Pixel Y Dimension)图像高度 指纵向像素数
Interoperability IFD通用性扩展项定义指针 和TIFF文件相关，具体含义不详
我再举一个例子。在电影数据库IMDB上可以查到每一部电影的信息。IMDB本身也定义了一套元数据，用来描述每一部电影。下面是它的一级元数据，每一级下面又列出了二级元数据，总共加起来，可以从100多个方面刻画一部电影：
Cast and Crew（演职人员）、Company Credits（相关公司）、Basic Data（基本情况）、Plot & Quotes（情节和引语）、Fun Stuff（趣味信息）、Links to Other Sites（外部链接）、Box Office and Business（票房和商业开发）、Technical Info（技术信息）、Literature（书面内容）、Other Data（其他信息）。
元数据最大的好处是，它使信息的描述和分类可以实现格式化，从而为机器处理创造了可能。
什么是元数据？在前面的集成开发环境建设相关文章：集成开发环境-大数据平台的门户一文中，我们也提到过，元数据MetaData狭义的解释是用来描述数据的数据，广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据表格的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。
管理这些附加MetaData信息的目的，一方面是为了让用户能够更高效的挖掘和使用数据，另一方面是为了让平台管理人员能更加有效的做好系统的维护管理工作。
出发点很好，但通常这些元数据信息是散落在平台的各个系统，各种流程之中的，而它们的管理也可能或多或少可以通过各种子系统自身的工具，方案或流程逻辑来实现。那么我们所说的元数据管理平台又是用来做什么的？是不是所有的信息都应该或者有必要收集到一个系统中来进行统一管理呢，具体又有哪些数据应该被纳入到元数据管理平台的管理范围之中呢？下面我们就来探讨一下相关的内容。
数据治理的第一步，就是收集信息，很明显，没有数据就无从分析，也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集，至于收集哪些信息，取决于业务的需求和我们需要解决的目标问题。
信息收集再多，如果不能发挥作用，那也就只是浪费存储空间而已。所以元数据管理平台还需要考虑如何以恰当的形式对这些元数据信息进行展示，进一步的，如何将这些元数据信息通过服务的形式提供给周边上下游系统使用，真正帮助大数据平台完成质量管理的闭环工作。
应该收集那些信息，虽然没有绝对的标准，但是对大数据开发平台来说，常见的元数据信息包括：
数据的表结构信息，这个很容易理解了，狭义的元数据信息通常多半指的就是这部分内容了，它也的确属于元数据信息管理系统中最重要的一块内容。
不过，无论是SQL还是NoSQL的数据存储组件，多半自身都有管理和查询表格Schema的能力，这也很好理解如果没有这些能力的话，这些系统自身就没法良好的运转下去了不是。比如，Hive自身的表结构信息本来就存储在外部DB数据库中，Hive也提供类似 show table，describe table之类的语法对这些信息进行查询。那么我们为什么还要多此一举，再开发一个元数据管理系统对这些信息进行管理呢？
这么做，可能的理由很多，需要集中管理可以是其中一个理由，但更重要的理由，是因为本质上，这些系统自身的元数据信息管理手段通常都是为了满足系统自身的功能运转而设计的。也就是说，它们并不是为了数据质量管理的目的而存在的，由于需求定位不同，所以无论从功能形态还是从交互手段的角度来说，它们通常也就无法直接满足数据质量管理的需求。
举个很简单的例子，比如我想知道表结构的历史变迁记录，很显然多数系统自身是不会设计这样的功能的。而且一些功能就算有，周边上下游的其它业务系统往往也不适合直接从该系统中获取这类信息，因为如果那样做的话，系统的安全性和相互直接的依赖耦合往往都会是个问题。
所以，收集表结构信息，不光是简单的信息汇总，更重要的是从平台管理和业务需求的角度出发来考虑，如何整理和归纳数据，方便系统集成，实现最终的业务价值。
这类信息，可能包括但不限于：数据占据了多少底层存储空间，最近是否有过修改，都有谁在什么时候使用过这些数据，谁有权限管理和查阅这些数据等等。此外，还可以包括类似昨天新增了多少个表格，删除了多少表格，创建了多少分区之类的统计信息。
在正常的工作流程中，多数人可能不需要也不会去关心这类信息。但是落到数据质量管理这个话题上时，这些信息对于系统和业务的优化，数据的安全管控，问题的排查等工作来说，又往往都是不可或缺的重要信息，所以通常这类信息也可以从Audit审计的角度来归类看待。
与表结构信息类似，对于这类Audit审计类信息的采集和管理，通常具体的底层数据存储管理组件自身的功能也无法直接满足我们的需求，需要通过专门的元数据管理平台中统一进行采集，加工和管理。
血缘 以上是关于元数据与元数据管理的主要内容，如果未能解决你的问题，请参考以下文章