元数据与元数据管理
元数据
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）一个简单的关系型表元模型：描述了如何定义一个关系型表，例如
- 每个表必须有一个名字（字符串）
- 一个表可以有一个简单的关系型表元模型描述了如何定义一个关系型表
- 每个表必须有一个名字（字符串）
- 一个表可以有 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信息的目的，一方面是为了让用户能够更高效的挖掘和使用数据，另一方面是为了让平台管理人员能更加有效的做好系统的维护管理工作。
出发点很好，但通常这些元数据信息是散落在平台的各个系统，各种流程之中的，而它们的管理也可能或多或少可以通过各种子系统自身的工具，方案或流程逻辑来实现。那么我们所说的元数据管理平台又是用来做什么的？是不是所有的信息都应该或者有必要收集到一个系统中来进行统一管理呢，具体又有哪些数据应该被纳入到元数据管理平台的管理范围之中呢？下面我们就来探讨一下相关的内容。
数据治理的第一步，就是收集信息，很明显，没有数据就无从分析，也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集，至于收集哪些信息，取决于业务的需求和我们需要解决的目标问题。
信息收集再多，如果不能发挥作用，那也就只是浪费存储空间而已。所以元数据管理平台还需要考虑如何以恰当的形式对这些元数据信息进行展示，进一步的，如何将这些元数据信息通过服务的形式提供给周边上下游系统使用，真正帮助大数据平台完成质量管理的闭环工作。
应该收集那些信息，虽然没有绝对的标准，但是对大数据开发平台来说，常见的元数据信息包括：
- 数据的表结构Schema信息
- 数据的空间存储，读写记录，权限归属和其它各类统计信息
- 数据的血缘关系信息
- 数据的业务属性信息
数据的表结构信息，这个很容易理解了，狭义的元数据信息通常多半指的就是这部分内容了，它也的确属于元数据信息管理系统中最重要的一块内容。
不过，无论是SQL还是NoSQL的数据存储组件，多半自身都有管理和查询表格Schema的能力，这也很好理解如果没有这些能力的话，这些系统自身就没法良好的运转下去了不是。比如，Hive自身的表结构信息本来就存储在外部DB数据库中，Hive也提供类似 show table，describe table之类的语法对这些信息进行查询。那么我们为什么还要多此一举，再开发一个元数据管理系统对这些信息进行管理呢？
这么做，可能的理由很多，需要集中管理可以是其中一个理由，但更重要的理由，是因为本质上，这些系统自身的元数据信息管理手段通常都是为了满足系统自身的功能运转而设计的。也就是说，它们并不是为了数据质量管理的目的而存在的，由于需求定位不同，所以无论从功能形态还是从交互手段的角度来说，它们通常也就无法直接满足数据质量管理的需求。
举个很简单的例子，比如我想知道表结构的历史变迁记录，很显然多数系统自身是不会设计这样的功能的。而且一些功能就算有，周边上下游的其它业务系统往往也不适合直接从该系统中获取这类信息，因为如果那样做的话，系统的安全性和相互直接的依赖耦合往往都会是个问题。
所以，收集表结构信息，不光是简单的信息汇总，更重要的是从平台管理和业务需求的角度出发来考虑，如何整理和归纳数据，方便系统集成，实现最终的业务价值。
这类信息，可能包括但不限于：数据占据了多少底层存储空间，最近是否有过修改，都有谁在什么时候使用过这些数据，谁有权限管理和查阅这些数据等等。此外，还可以包括类似昨天新增了多少个表格，删除了多少表格，创建了多少分区之类的统计信息。
在正常的工作流程中，多数人可能不需要也不会去关心这类信息。但是落到数据质量管理这个话题上时，这些信息对于系统和业务的优化，数据的安全管控，问题的排查等工作来说，又往往都是不可或缺的重要信息，所以通常这类信息也可以从Audit审计的角度来归类看待。
与表结构信息类似，对于这类Audit审计类信息的采集和管理，通常具体的底层数据存储管理组件自身的功能也无法直接满足我们的需求，需要通过专门的元数据管理平台中统一进行采集，加工和管理。
血缘信息或者叫做Lineage的血统信息是什么，简单的说就是数据之间的上下游来源去向关系，数据从哪里来到哪里去。知道这个信息有什么用呢？用途很广，举个最简单的例子来说，如果一个数据有问题，你可以根据血缘关系往上游排查，看看到底在哪个环节出了问题。此外我们也可以通过数据的血缘关系，建立起生产这些数据的任务之间的依赖关系，进而辅助调度系统的工作调度，或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。
分析数据的血缘关系看起来简单，但真的要做起来，并不容易，因为数据的来源多种多样，加工数据的手段，所使用的计算框架可能也各不相同，此外也不是所有的系统天生都具备获取相关信息的能力。而针对不同的系统，血缘关系具体能够分析到的粒度可能也不一样，有些能做到表级别，有些甚至可以做到字段级别。
以hive表为例，通过分析hive脚本的执行计划，是可以做到相对精确的定位出字段级别的数据血缘关系的。而如果是一个MapReduce任务生成的数据，从外部来看，可能就只能通过分析MR任务输出的Log日志信息来粗略判断目录级别的读写关系，从而间接推导数据的血缘依赖关系了。
前面三类信息，一定程度上都可以通过技术手段从底层系统自身所拥有的信息中获取得到，又或着可以通过一定的流程二次加工分析得到。与之相反，数据的业务属性信息，通常与底层系统自身的运行逻辑无关，多半就需要通过其他手段从外部获取了。
那么，业务属性信息都有哪些呢？最常见的，比如，一张数据表的统计口径信息，这张表干什么用的，各个字段的具体统计方式，业务描述，业务标签，脚本逻辑的历史变迁记录，变迁原因等等，此外，你也可能会关心对应的数据表格是由谁负责开发的，具体数据的业务部门归属等等。
上述信息如果全部需要依靠数据开发者的自觉填写，不是不行，但是显然不太靠谱。毕竟对于多数同学来说，对于完成数据开发工作核心链路以外的工作量，很自然的反应就是能不做就不做，越省事越好。如果没有流程体系的规范，如果没有产生实际的价值，那么相关信息的填写很容易就会成为一个负担或者是流于形式。
所以，尽管这部分信息往往需要通过外部手段人工录入，但是还是需要尽量考虑和流程进行整合，让它们成为业务开发必不可少的环节。比如，一部分信息的采集，可以通过整体数据平台的开发流程规范，嵌入到对应数据的开发过程中进行，例如历史变迁记录可以在修改任务脚本或者表格schema时强制要求填写；业务负责人信息，可以通过当前开发人员的业务线和开发群组归属关系自动进行映射填充；字段统计方式信息，尽可能通过标准的维度指标管理体系进行规范定义。
总体来说，数据的业务属性信息，必然首先是为业务服务的，因此它的采集和展示也就需要尽可能的和业务环境相融合，只有这样才能真正发挥这部分元数据信息的作用。
社区中开源的元数据管理系统方案，常见的比如Hortonworks主推的Apache Atlas，它的基本架构思想如下图所示
Atlas的架构方案应该说相当典型，基本上这类系统大致都会由元数据的收集，存储和查询展示三部分核心组件组成。此外，还会有一个管理后台对整体元数据的采集流程以及元数据格式定义和服务的部署等各项内容进行配置管理。
对应到Atlas的实现上，Atlas通过各种hook/bridge插件来采集几种数据源的元数据信息，通过一套自定义的Type 体系来定义元数据信息的格式，通过搜索引擎对元数据进行全文索引和条件检索，除了自带的UI控制台以外，Atlas还可以通过Rest API的形式对外提供服务。
Atlas的整体设计侧重于数据血缘关系的采集以及表格维度的基本信息和业务属性信息的管理。为了这个目的，Atlas设计了一套通用的Type体系来描述这些信息。主要的Type基础类型包括DataSet和Process，前者用来描述各种数据源本身，后者用来描述一个数据处理的流程，比如一个ETL任务。
Atlas现有的Bridge实现，从数据源的角度来看，主要覆盖了Hive，HBase，HDFS和Kafka，此外还有适配于Sqoop, Storm和Falcon的Bridge，不过这三者更多的是从Process的角度入手，最后落地的数据源还是上述四种数据源。
具体Bridge的实现多半是通过上述底层存储，计算引擎各自流程中的Hook机制来实现的，比如Hive SQL的Post Execute Hook，HBase的Coprocessor等，而采集到的数据则通过Kafka消息队列传输给Atlas Server或者其它订阅者进行消费。
在业务信息管理方面，Atlas通过用户自定义Type 属性信息的方式，让用户可以实现数据的业务信息填写或者对数据打标签等操作，便于后续对数据进行定向过滤检索。
最后，Atlas可以和Ranger配套使用，允许Ranger通过Atlas中用户自定义的数据标签的形式来对数据进行动态授权管理工作，相对于基于路径或者表名/文件名的形式进行静态授权的方式，这种基于标签的方式，有时候可以更加灵活的处理一些特定场景下的权限管理工作。
总体而言，Atlas的实现，从结构原理的角度来说，还算是比较合理的，但从现阶段来看，Atlas的具体实现还比较粗糙，很多功能也是处于可用但并不完善的状态。此外Atlas在数据审计环节做的工作也不多，与整体数据业务流程的集成应用方面的能力也很有限。Atlas项目本身很长时间也都处于Incubator状态，因此还需要大家一起多努力来帮助它的改进。
Cloudera Navigator Data Management
另外一个比较常见的解决方案是Cloudera CDH发行版中主推的Navigator，相比Atlas而言，Navigator的整体实现更加成熟一些，更像一个完整的解决方案，不过，Navigator并不是开源的，也难怪，毕竟要卖钱的的东西，也就更有动力去完善 ；）
Navigator的产品定位是Data Management数据管理，本质上也是通过管理元数据来管理数据，但周边工具和配套设施相对完善，和Cloudera Manager管理后台的产品集成工作也做得比较彻底。相比Atlas来说，Navigator的整体组件架构也更加复杂一些。Navigator的大致组件架构如下图所示
Navigator定位为数据管理，所以对数据的审计管理方面的工作也会做得更多一些，除了采集和管理Hive/Impala等表格的血缘信息，Navigator也可以配置采集包括HDFS的读写操作记录，Yarn/Spark/Pig等作业的运行统计数据在内的信息。Navigator同时还为用户提供了各种统计分析视图和查询管理工具来分析这些数据。
从底层实现来看，Navigator同样通过Hook或着Plugin插件的形式从各种底层系统的运行过程中获取相关信息。但与Atlas不同的是，Navigator的元数据采集传输处理流程并没有把这些信息写入到消息队列中，而是主要通过这些插件写入到相关服务所在的本地Log文件中，然后由Cloudera Manager在每台服务节点上部署的Agent来读取，过滤，分析处理并传输这些信息给Audit Server。
此外Navigator还通过独立的Metadata Server来收集和分析一些非Log来源的元数据信息，并统一对外提供元数据的配置管理服务。用户还可以通过配置Policy策略，让Metadata Server自动基于用户定义的规则，替用户完成数据的Tag标签打标工作，进而提升数据自动化自治管理的能力。
总体而言，Navigator和Cloudera Manger的产品集成工作做得相对完善，如果你使用CDH发行版全家福套件来管理你的集群的话，使用Navigator应该是一个不错的选择。不过，如果是自主管理的集群或者自建的大数据开发平台，深度集成定制的Navigator就很难为你所用了，但无论如何，对于自主开发的元数据管理系统来说，Navigator的整体设计思想也还是值得借鉴的。
蘑菇街大数据平台的元数据管理系统，大体的体系架构思想和上述系统也比较类似，不过，客观的说我们的系统的开发是一个伴随着整体开发平台的需求演进而渐进拓展的过程，所以从数据管理的角度来说，没有上述两个系统那么关注数据格式类型系统的普遍适用性。比如Schema这部分信息的管理，就主要侧重于表格类信息的管理，比如Hive，HBase等，而非完全通用的类型系统。但相对的，在对外服务方面，我们也会更加注重元数据管理系统和业务系统应用需求的关联，架构大同小异，下面主要简单介绍一下产品交互形态和一些特殊的功能特效设定等。
如图所示，是我们的元数据管理系统的产品后台针对Hive表格元数据信息的部分查询界面，主要为用户提供表格的各种基础schema信息，业务标签信息，血缘关系信息，样本数据，以及底层存储容量星系，权限和读写修改记录等审计信息。
除了表格元数据信息管理以外，我们的元数据管理系统主要的功能之一是“业务组”的管理，业务组的设计目标是贯穿整个大数据开发平台的，做为大数据开发平台上开发人员的自主管理单元组织形式。将所有的数据和任务的管理工作都下放到业务组内部由业务组管理员管理。
从元数据管理系统的角度来说，业务组的管理，包括数据和任务与业务组的归属关系映射，业务组内角色的权限映射关系等，此外，为了适应业务的快速变化，也给用户提供的数据资产的归属关系转移等功能。
总体来说，业务组的管理功能，更多的是需要和大数据开发平台的其它组件相结合，比如和集成开发平台IDE相结合，在开发平台中提供基于业务组的多租户开发环境管理功能，再比如与调度系统相结合，根据任务和数据的业务组归属信息，在任务调度时实施计算资源的配额管理等。
最后，关于数据的血缘关系跟踪，再多说两句。在Atlas和navigator中，主要通过计算框架自身支持的运行时hook来获得数据相关元数据和血缘相关信息，比如hive的hook是在语法解析阶段，storm的hook是在topology submit阶段。
这么做的优点是血缘的追踪分析是基于真实运行任务的信息进行分析的，如果插件部署全面，也不太会有遗漏问题，但是这种方式也有很多不太好解决的问题，比如
- 如何更新一个历史上有依赖后来不再依赖的血缘关系
- 对于一个还未运行的任务，不能提前获取血缘信息
- 临时脚本或者错误的脚本逻辑对血缘关系数据的污染
简单总结一下，就是基于运行时的信息来采集血缘关系，由于缺乏静态的业务信息辅助，如何甄别和更新血缘关系的生命周期和有效性会是一个棘手的问题，一定程度上也限制了应用的范围。
我们的做法是，血缘信息的采集不是在运行时动进行的，而是在脚本保存时进行的。由于开发平台统一管理了所有用户的任务脚本，所以，我们可以对脚本进行静态的分析，加上脚本本身业务信息，执行情况和生命周期对开发平台是可知的。所以一定程度上能解决上述提到的几个问题。
当然，这种方案也有自己的短板需要克服，比如：如果脚本管控不到位，血缘关系分析可能覆盖不全；血缘关系是基于最新的脚本的静态的逻辑关系，无法做到基于某一次真实的运行实例进行分析。不过，这些短板对我们来说从需求的角度来说都不是很核心的问题，又或者通过周边系统的配套建设可以在一定程度上加以解决克服的。
1，大数据平台——是指服务于大数据计算或存储的平台，包括大数据的计算集群(hive、spark、flink、storm等等)和存储集群(如hadoop、hbase等等)。
2，大数据平台涉及的元数据——由大数据作业的业务逻辑直接读写处理的业务数据，都不是元数据，除此之外的数据都是元数据。例如数据表的schema信息、任务之间的血缘关系、任务的权限映射关系、数据的业务属性、数据占用的磁盘空间等等。
1，管理元数据的目的——有助于用户更高效地分析数据，有助于系统和业务的优化，有助于数据的安全管控，有助于数据生命周期的管理，有助于任务问题的排查，有助于数据质量的保证。
2，怎样发挥元数据的价值——元数据信息通过服务的形式(例如REST接口)提供给上下游系统使用。
这个问题也就是元数据管理到底是管理什么。对大数据开发平台来说，常见的元数据包括以下6点：
（1） SQL或者NoSQL中的表视图信息，例如MySQL中可以通过SHOW CREATE TABLE table_name来获取表结构；hive中可以用HQL的SHOW PARTITIONS table_name获取该表的分区信息
（2） 表结构的变迁记录，例如mysql中的某表增/减了一个什么字段、修改了什么字段等信息
（1） 数据的上游和下游是哪里，也就是数据从哪来的、将会用到哪里去
（2） 收集数据的血缘关系的作用——如果某数据有问题，可检查它的上游数据以便定位问题；也有助于理清处理这些数据的任务之间是如何互相依赖的
上述元数据信息大部分需要人工录入，但是最好是整合到业务开发流程中，让它们成为业务开发的必须环节。比如说，在修改任务脚本时或修改表格schema时强制开发者填写。
![勒索病毒.[tsai.shen@mailfence.com].faust、.[support2022@cock.li].faust引起的数据被加密恢复](https://img-blog.csdnimg.cn/1cb61e7299d241738b9e270cc89a1e00.png)
