什么是元数据？元数据是用来描述狭义的数据，从广义上讲，除了那些由业务逻辑直接读写的业务数据外，维持整个系统运行所需的所有其他信息数据都可以称为元数据。 例如，数据的架构信息、任务的亲缘关系、用户与脚本任务之间的权限映射关系等。
管理这些额外的元数据信息的目的，一方面是为了让用户能够更高效地挖掘和使用数据，另一方面是为了让平台管理者在系统维护和管理方面做得更好。
起点是好的，但通常这些元数据信息分散在平台的各个系统和流程中，它们的管理也可能或多或少地通过各个子系统本身的工具、解决方案或流程逻辑来实现。 那么，我们怎么称呼元数据管理平台呢？所有信息是否应该全部采集或必要到一个系统中进行统一管理，元数据管理平台的管理范围应包含哪些具体数据？下面我们一起来看看相关内容。
元数据管理平台是做什么的？
数据治理的第一步是收集信息，很明显，没有数据就没有办法分析，就不可能对平台的数据链路进行有效的管理和完善。 因此，元数据管理平台最重要的功能之一就是信息的收集，而收集什么信息取决于业务的需求和我们需要解决的目标问题。
无论您收集了多少信息，如果它不起作用，那只是浪费存储空间。 因此，元数据管理平台还需要考虑如何以适当的形式展示这些元数据信息，进而如何以服务的形式将这些元数据信息提供给周边的上下游系统，从而真正帮助大数据平台完成质量管理的闭环工作。
对于应该收集哪些信息，没有绝对的标准，但大数据开发平台常见的元数据信息包括：
数据的架构、数据的空间存储、读写记录、权限归属等各类统计信息、数据的血缘信息、数据的业务属性信息等。
让我们详细讨论这四件事。
数据表的架构
数据的表结构信息，这个很容易理解，而狭义的元数据信息通常是指这部分内容，它确实是元数据信息管理系统中最重要的一块内容。
但是，无论是SQL还是NOSQL数据存储组件，它们大多都有自己的管理和查询schema的能力，这也很容易理解，没有这些能力，这些系统本身就无法运行。 例如，Hive 自身的表结构信息存储在外部 DB 数据库中，Hive 也提供了 show table、describe table 等语法来查询这些信息。 那么，为什么我们需要加倍努力，开发一个元数据管理系统来管理这些信息呢？
造成这种情况的原因可能有很多，需要集中管理可能是原因之一，但更重要的原因是，从本质上讲，这些系统的元数据信息管理方法通常是为了满足系统本身的功能而设计的。 换言之，它们并不是为了数据质量管理而存在的，由于需求定位不同，它们通常不能从功能形式和交互手段的角度直接满足数据质量管理的需求。
举个非常简单的例子，如果我想知道表结构的历史，很明显，大多数系统本身并不设计这样的功能。 而且，即使某些功能可用，周边上下游的其他业务系统也往往不适合直接从系统中获取这类信息，因为如果发生这种情况，系统的安全性以及彼此之间的直接依赖和耦合往往会成为一个问题。
因此，收集表结构信息不仅仅是简单的信息汇总，更重要的是从平台管理和业务需求的角度，如何组织和汇总数据，促进系统集成，实现最终的商业价值。
数据存储空间、读写记录、权限所有权等统计信息。
此信息可能包括但不限于数据正在使用多少基础存储空间、最近是否被修改、谁使用了数据以及何时使用、谁有权访问数据等。 此外，还可以包括统计信息，例如昨天添加了多少个分区、删除了多少个分区、创建了多少个分区等。
在正常的工作流程中，大多数人可能不需要或不关心这类信息。 但是，当涉及到数据质量管理的话题时，这些信息对于系统和业务优化、数据安全控制、问题排查等往往是必不可少的，因此通常可以从审计的角度对这类信息进行分类。
与表结构信息类似，对于这类审计信息的收集和管理，具体底层数据存储和管理组件的功能并不能直接满足我们的需求，需要通过专门的元数据管理平台进行统一的收集、处理和管理。
数据的世系信息
什么是血缘信息或血缘信息，简单来说，就是数据之间的上下游目的地关系，数据从**到**。 知道这些信息有什么用？它的通用性很强，举个最简单的例子，如果一个数据有问题，可以按照血缘关系向上游查询，看看问题出在哪里。 此外，我们还可以通过数据的亲缘关系，在产生这些数据的任务之间建立依赖关系，然后辅助调度系统的工作调度，或者用它来判断失败或错误的任务可能对哪些下游数据产生影响，等等。
分析数据的沿袭看似简单，但要做到这一点并不容易，因为数据的多样性、处理数据的手段、使用的计算框架也可能有所不同，而且并非所有系统都具有天生的获取相关信息的能力。 对于不同的系统，可以分析的粒度可能不同，有些可以在表级别，有些甚至可以在字段级别。
以 Hive 表为例，通过分析 Hive 脚本的执行计划，可以准确定位字段级别的数据沿袭。 如果生成了MapReduce任务产生的数据，从外部角度来看，可能只能通过分析MR任务输出的日志信息，在目录级别大致确定读写关系，从而间接推导出数据的血缘依赖关系。
数据的业务属性信息
前三类信息可以通过技术手段在一定程度上从底层系统本身拥有的信息中获取，也可以通过一定的二次加工和分析过程获得。 相反，数据的业务属性信息通常与底层系统本身的运行逻辑无关，大部分信息需要通过其他方式从外部获取。
那么，什么是业务属性信息呢？最常见的，比如一个数据表的统计口径信息，该表是做什么用的，每个字段的具体统计方法，业务描述，业务标签，脚本逻辑的历史变更记录，变更的原因等等，此外，您可能还关心谁负责相应数据的开发**， 业务部门的具体数据等。
如果以上所有信息都需要数据开发者有意识地填写，不是不可能，但显然不靠谱。 毕竟，对于大多数学生来说，对数据开发工作核心环节之外的工作量的自然反应是能干就不干，越无故障越好。 如果没有流程体系的标准化，如果没有实际价值，那么相关信息的填写很容易成为一种负担或仅仅是形式。
因此，虽然这部分信息往往需要通过外部手段手动录入，但仍然需要考虑尽可能地与流程集成，使其成为业务发展中不可或缺的一部分。 例如，可以通过整体数据平台的开发流程规范，将一些信息的采集嵌入到相应数据的开发过程中，例如，在修改任务脚本或模式时，可以强制要求历史变更记录业务所有者信息可以按当前开发人员的业务线和开发组隶属关系自动映射和填充字段的统计信息通过标准的维度指标管理系统尽可能地定义。
一般来说，数据的业务属性信息首先要服务于业务，因此其采集和展示需要尽可能地与业务环境融合，只有这样，这部分元数据信息才能真正发挥出来。
元数据管理相关系统解决方案介绍
apache atlas
社区中常见的开源元数据管理系统解决方案（例如 Hortonworks 推广的 Apache Atlas）基于下图。
Atlas的架构应该说是相当典型的，基本上这种系统会由元数据采集、存储、查询显示三个核心组件组成。 此外，还将有管理后台，用于对整个元数据采集过程、元数据格式定义、服务部署进行配置管理。
与Atlas的实现相对应，Atlas通过各种钩桥插件从多个数据源收集元数据信息，通过一组自定义类型系统定义元数据信息的格式，并通过搜索引擎对元数据进行全文索引和条件检索。
Atlas的整体设计侧重于数据亲属关系的采集和对第一维度的基础信息和业务属性信息的管理。 为此，Atlas设计了一个通用类型系统来描述这些信息。 主要类型包括数据集（用于描述各种数据源本身）和流程（用于描述数据处理过程，例如ETL任务）。
从数据源来看，Atlas现有的桥接实现主要涵盖HIVE、HBASE、HDFS、Kafka，此外还有适配SQOOP、Storm和Falcon的桥接，但这三者更多是从流程角度出发，最终的数据源依然是以上四个数据源。
具体的桥接实现大多是通过上述底层进程的底层存储和计算引擎中的钩子机制实现的，比如Hive SQL的post执行钩子、HBase的协处理器等，采集到的数据通过Kafka消息队列传输给Atlas Server或其他订阅者消费。
在业务信息管理方面，Atlas允许用户通过用户自定义的类型属性信息来填充业务信息或标注数据，方便后续对数据进行有针对性的过滤和检索。
最后，Atlas可以与Ranger结合使用，允许Ranger在Atlas中以用户自定义数据标签的形式动态授权数据。
总体来看，Atlas的实现从结构原则上来说是相当合理的，但从现阶段来看，Atlas的具体实现还是比较粗糙的，很多功能也处于可用但不完善的状态。 此外，Atlas在数据审计方面做的工作不多，与整体数据业务流程的整合能力有限。 Atlas项目本身已经处于孵化器状态很长一段时间了，因此需要一起完成以帮助改进它。
cloudera n**igator data management
另一个常见的解决方案是 Cloudera CDH 发行版中的主 N**igator，相比 Atlas，N**igator 的整体实现更加成熟，更像是一个完整的解决方案，但是，N**igator 并不是开源的，这也难怪，毕竟要卖钱的东西更有动力去改进;）
N**igator的产品定位是数据管理，本质上是通过管理元数据来管理数据，但周边工具和配套设施比较齐全，产品与Cloudera Manager管理后台的集成也比较彻底。 与 Atlas 相比，N**igator 的整体组件架构也要复杂一些。 n**igator 的通用组件架构如下图所示。
除了收集和管理 Hive Impala 等沿袭信息外，还可以配置 N**igator 收集包括 HDFS 读写操作记录、纱线火花清管器等运行统计信息在内的信息。 n**igator 还为用户提供了多种统计分析视图和查询管理工具来分析这些数据。
从底层实现的角度来看，n**igator 还以钩子或插件的形式从各种底层系统的运行中获取相关信息。 但与 Atlas 不同的是，N**igator 元数据采集和传输过程不会将这些信息写入消息队列，而是主要通过这些插件将这些信息写入相关服务所在的本地日志文件中，然后由 CloudEra Manager 部署在每个服务节点上的 Agent 读取、过滤、分析、处理并将信息传输到 Audit Server。
此外，n**igator 还通过独立的元数据服务器收集和分析一些非 log** 元数据信息，并向外界提供元数据配置管理服务。 用户还可以配置策略，允许元数据服务器根据用户定义的规则自动标记数据，从而提高数据的自动管理能力。
总体来说，N**igator 和 Cloudera Manger 的产品集成做得比较好，如果使用 CDH Distribution Family Portrait Kit 来管理你的集群，N**igator 应该是一个不错的选择。 但是，如果是自建集群或者自建大数据开发平台，你很难使用深度集成定制的n**igator，但无论如何，对于自研的元数据管理系统来说，n**igator的整体设计思路还是值得学习的。
蘑菇街元数据管理系统实践
但是，客观地说，我们系统的开发是一个随着整体开发平台需求的演进而逐步扩展的过程，所以从数据管理的角度来看，不存在上述两个系统，因此数据格式类型系统的普遍适用性并不像上述两个系统那样受到关注。 例如，schema 信息的管理主要集中在 ** 类型信息的管理上，如 hive、hbase 等，而不是完全通用的类型系统。 但是，在外部服务方面，我们也会更加关注元数据管理系统与业务系统应用需求之间的关联，架构也差不多。
如图所示，它是我们元数据管理系统产品后台的 hive** 元数据信息查询接口的一部分，主要为用户提供各种基础 schema 信息、业务标签信息、亲属关系信息、样本数据，以及底层存储容量星系、权限、读写修改记录等审计信息。
除了元数据信息管理外，我们元数据管理系统的主要功能之一是对“业务组”的管理，业务组的设计目标贯穿整个大数据开发平台，作为开发者在大数据开发平台上的自主管理单元组织形式。 将所有数据和任务的管理委托给监控组，并由监控组管理员进行管理。
从元数据管理系统的角度来看，业务组的管理包括数据和任务的所有权与业务组的映射、业务组内角色的权限映射等，此外，为了适应业务的快速变化，还为用户提供了数据资产权属关系的转移等功能。
一般来说，业务组的管理功能需要结合大数据开发平台的其他组件，比如集成开发平台IDE在开发平台中提供基于业务组的多租户开发环境管理功能，然后结合调度系统，根据业务组所有权，实现任务调度中计算资源的配额管理任务和数据的信息。
最后，再谈谈数据的沿袭跟踪。 在 Atlas 和 N**igator 中，数据相关的元数据和血缘相关的信息主要通过计算框架本身支持的运行时钩子获取，例如 Hive 的钩子处于语法解析阶段，Storm 的钩子处于拓扑提交阶段。
这样做的好处是，血缘跟踪分析是基于真实运行任务的信息，如果插件全面部署，遗漏会少一些，但是有很多问题不容易用这种方式解决，比如。
如何更新一个过去依赖的血缘，对于一个尚未运行的任务，不再依赖，临时脚本或错误的脚本逻辑无法提前获取血缘信息，或者错误的脚本逻辑污染了血缘数据。
简单来说，就是基于运行时信息来收集亲属关系，由于缺乏静态的业务信息辅助，如何筛选和更新亲属关系的生命周期和有效性将是一个棘手的问题，在一定程度上也会限制其应用范围。
这样做的方式是，世系信息的收集不是在运行时完成的，而是在保存脚本时完成的。 由于开发平台统一管理所有用户的任务脚本，我们可以对脚本进行静态分析，加上脚本本身的业务信息、执行状态和生命周期都是开发平台已知的。 因此，在一定程度上，它可以解决上述几个问题。
当然，这种方案也有其自身需要克服的缺点，比如：如果脚本控制不到位，可能就没有完全覆盖血缘分析;血缘是基于最新脚本的静态逻辑关系，无法基于实际运行的实例进行分析。 但是，从需求的角度来看，这些缺点对我们来说并不是很核心的问题，或者可以通过外围系统的配套建设在一定程度上解决和克服。