元数据管理

MetaData的狭义解释用于描述数据. 从广义上讲，除了业务逻辑直接读取和写入的业务数据外，还可以使用维护整个系统操作所需的所有其他信息/数据. 它称为元数据. 例如，数据表的Schema信息，任务的血液关系，用户与脚本/任务之间的权限映射关系信息等等.

一方面，管理这些附加元数据信息的目的是使用户能够更有效地挖掘和使用数据，另一方面，使平台管理员可以更有效地进行系统维护和管理. 但是通常这些元数据信息分散在平台的各种系统和过程中，并且它们的管理也可能或多或少地通过各系统自己的工具，程序或过程逻辑来实现. 那么，元数据管理平台用于什么呢？是否应将所有信息收集或收集到系统中以进行统一管理？元数据管理平台的管理范围应包括哪些特定数据？

数据治理的第一步是收集信息. 显然，没有数据就无法分析，也就不可能有效地管理和改善平台的数据链接. 因此，元数据管理平台的一个非常重要的功能是信息的收集. 至于收集哪些信息，则取决于业务需求和要解决的目标问题. 元数据管理平台还需要考虑如何以适当的形式显示这些元数据信息. 此的上下游系统，以真正帮助大数据平台完成质量管理闭环工作.

应收集信息. 尽管没有绝对标准，但对于大数据开发平台，常见的元数据信息包括:

数据表结构的模式信息

数据的空间存储，读写记录，权限归因和其他各种统计信息

数据血缘关系信息

数据的业务属性信息

关于这四个项目的更具体的讨论:

[数据表结构的架构信息]

数据表结构信息，狭义定义的元数据信息通常是指这部分内容. 无论是SQL还是NoSQL数据存储组件，大多数组件都具有管理和查询表架构的能力. 例如，Hive自己的表结构信息最初存储在外部中，并且Hive还提供了诸如show table和describe table之类的语法来查询此信息. 那么，为什么我们要开发另一个元数据管理系统来管理这些信息呢？有很多可能的原因. 对集中管理的需求可能是原因之一，但更重要的原因是，从本质上讲，这些系统的元数据信息管理方法通常旨在满足系统本身的功能. . 也就是说，它们不存在用于数据质量管理的目的. 由于需求的定位不同，它们通常无法从功能形式或交互方式的角度直接满足数据质量管理的需求.

例如，如果您想了解表结构的历史更改记录，很显然元数据管理，大多数系统本身都不设计此类功能. 即使具有某些功能，上游和下游的其他业务系统也通常不适合直接从系统中获取此类信息，因为如果这样做，系统的安全性和彼此之间的直接依赖关系通常是问题. 因此元数据管理，收集表结构信息不仅是信息的简单汇总，而且更重要的是，从平台管理和业务需求的角度考虑如何组织和汇总数据以促进系统集成并实现最终业务价值.

[数据存储空间，读写记录，权限归属和其他各种统计信息]

此类信息可能包括但不限于: 数据占用多少基础存储空间，是否最近修改了数据，谁在什么时候使用了数据，谁有权管理和查询数据. 数据等. 此外，还可以包括统计信息，例如昨天添加了多少个表，删除了多少个表以及创建了多少个分区.

在正常工作流程中，大多数人可能不需要或不在乎此类信息. 但是，当涉及到数据质量管理主题时，此信息对于系统和服务的优化，数据安全管理和故障排除通常是必不可少的重要信息，因此通常也可以从角度查看此类信息. 审核审计.

类似于表结构信息，对于此类审计信息的收集和管理，通常特定的基础数据存储管理组件本身无法直接满足我们的需求，需要通过特殊的元数据管理平台进行统一收集，流程和管理.

[数据血液关系信息]

什么是血统信息或血统，称为血统？简而言之，它是数据的上游和下游来源，以及数据来自何处. 知道此信息有什么用？它非常通用. 对于最简单的示例，如果数据存在问题，则可以根据血液关系在上游对其进行检查，以查看问题出在哪里. 另外，通过数据的血液关系，可以建立产生这些数据的任务之间的依赖关系，以帮助调度系统进行调度，或者确定失败或错误的任务可能影响哪些下游数据.

分析数据的血缘关系似乎很简单，但实际上并不容易，因为数据的来源多种多样，处理数据的方式以及所使用的计算框架也可能不同，但并非如此. 所有系统天生就有能力获取相关信息. 对于不同的系统，可以分析血液关系的特定粒度可能有所不同，有些可以在表级别，有些甚至可以在现场级别.

以Hive表为例，通过分析Hive脚本的执行计划，可以相对准确地定位字段级数据的血液关系. 如果是由MapReduce任务生成的数据，则从外部角度来看，可能只有通过分析MR任务输出的Log信息才能大致确定目录级别的读写关系，从而间接获取血液数据的关系.

[数据业务属性信息]

前三种信息可以通过技术手段从底层系统拥有的信息中获得一定程度的获取，也可以通过对特定过程的第二次过程分析获得. 相反，数据的业务属性信息通常与底层系统本身的操作逻辑无关，大部分需要通过其他方式从外部获取.

那么，业务属性信息是什么？最常见的是，例如，数据表的统计口径信息，该表的用途，每个字段的特定统计方法，业务描述，业务标签，脚本逻辑的历史更改记录，更改原因等. 此外，您可能还担心谁负责相应数据表的开发，特定数据业务部门的归属等等.

如果所有上述信息需要数据开发人员有意识地填写，这不是不可能的，但显然是不可靠的. 毕竟，对于大多数学生而言，对核心链接之外的工作负载的自然反应是完成数据开发工作，而无需这样做. 如果没有流程系统的规范，如果没有实际价值，那么相关信息的填充将很容易成为负担或手续.

因此，尽管通常需要通过外部手段手动输入这部分信息，但仍需要尽可能地考虑并与流程集成，以使其成为业务开发必不可少的一部分. 例如，可以通过整个数据平台的开发过程规范来收集部分信息，并将其嵌入相应数据的开发过程中. 例如，当任务脚本或表单架构被修改时，可以强制填写历史更改记录. 业务所有者的信息可以通过当前开发人员的业务线和开发组归属自动进行映射和填充；通过标准的维度索引管理系统，尽可能地标准化和定义现场统计方法信息.

通常，数据的业务属性信息必须首先为业务服务，因此需要将其收集和显示与业务环境尽可能地集成在一起. 只有这样，才能真正使用这部分元数据信息. 效果.

Apache Atlas

社区中的开源元数据管理系统解决方案，例如Hortonworks推广的Apache Atlas. Atlas的体系结构解决方案应该相当典型. 基本上，此类系统通常由核心组件的三个部分组成: 元数据收集，存储和查询显示. 此外，还将为整个元数据收集过程，元数据格式定义和服务部署的配置管理提供管理背景.

与Atlas的实现相对应，Atlas通过各种挂钩/桥插件收集多个数据源的元数据信息，通过一组自定义Type系统定义元数据信息的格式，并通过搜索引擎匹配元数据. 对于全文索引和数据的条件检索，除了意外的UI控制台外，Atlas还可以通过Rest API提供服务. Atlas的总体设计侧重于数据亲属的收集以及表单维度中基本信息和业务属性信息的管理. 为此，Atlas设计了一个通用的Type系统来描述此信息. Type的主要基本类型包括DataSet和Process，前者用于描述各种数据源本身，后者用于描述数据处理过程，例如ETL任务.

从数据源的角度来看，Atlas现有的Bridge实施主要包括适用于Sqoop，Storm和Falcon的Bridge以及Hive，HBase，HDFS和Kafka，但从过程的角度来看，这三者更多，最终登陆的数据源仍然是以上四个数据源. 特定Bridge的实现主要是通过上述基础存储和Hook机制在Hive SQL Post Execute Hook，HBase协处理器等计算引擎的各个过程中实现的，并将收集的数据传输到通过Kafka消息队列或其他订阅者使用Atlas服务器.

在业务信息管理方面，Atlas允许用户通过用户定义的Type属性信息来实现诸如填充数据业务信息或标记数据之类的操作，这便于随后进行有针对性的数据过滤和检索.

最后，Atlas可以与Ranger结合使用，与基于路径或表名/文件名的静态授权相比，Ranger可以以Atlas中用户定义的数据标签的形式对数据执行动态授权管理. 这种基于标签的方法有时可以在某些特定情况下更灵活地处理权限管理工作.

总的来说，从结构原理的角度来看，Atlas的实现是相对合理的，但是从现阶段来看，Atlas的具体实现还比较粗糙，许也可用，但还不完善. 状态. 此外，Atlas在数据审核流程中没有做很多工作，并且它与整体数据业务流程集成的能力也非常有限. Atlas项目本身已经处于孵化器状态很长时间了，因此每个人都需要加倍努力以帮助其改进.

Cloudera Navigator数据管理

另一个更常见的解决方案是Navigator，它主要在Cloudera CDH发行版中得到推广. 与Atlas相比，Navigator的整体实现更为成熟，并且更像一个完整的解决方案. Navigator的产品定位是数据管理数据管理. 从本质上讲，它也通过管理元数据来管理数据，但是周围的工具和支持设施相对完整，并且具有Cloudera Manager管理背景的产品集成工作也已进行得更加彻底. 与Atlas相比，Navigator的整体组件架构也更加复杂.

Navigator被定位为数据管理，因此将在数据审核管理上做更多的工作. 除了在诸如Hive / Impala之类的表中收集和管理血统信息外，还可以将Navigator配置为收集HDFS读写操作记录诸如Yarn / Spark / Pig操作统计信息之类的信息. Navigator还为用户提供了各种统计分析视图和查询管理工具来分析这些数据. 从基础实现的角度来看，Navigator还可以通过Hook或Plugin的形式从各种基础系统的操作中获取相关信息. 但是，与Atlas不同，Navigator的元数据收集和传输过程不会将此信息写入消息队列，而是主要通过这些插件写入相关服务所在的本地日志文件，然后部署在每个服务节点上的Cloudera Manager Agent读取，过滤，分析这些信息并将其传输到Audit Server.

此外，Navigator还通过独立的Metadata Server收集和分析一些非Log源元数据信息，并统一提供外部元数据配置管理服务. 用户还可以配置策略策略，以使Metadata Server能够根据用户定义的规则自动为用户完成数据标签的标记，从而提高数据自动化和自主管理的能力.

总体而言，Navigator和Cloudera Manger产品集成工作相对完成，如果您使用CDH分发系列人像套件来管理您的集群，那么使用Navigator应该是一个不错的选择. 但是，如果它是一个自我管理的集群或一个自我构建的大数据开发平台，则很难使用深度集成和自定义的Navigator，但是无论如何，对于独立开发的元数据管理系统，总体设计思路Navigator的功能仍然值得学习.

蘑菇街元数据管理系统实践

蘑菇街大数据平台元数据管理系统，一般的系统架构思想也与上述系统相似，系统的开发是一个随着整个开发平台需求的发展而逐步扩展的过程，因此从数据从上面的角度来看，管理并没有太多地关注数据格式类型系统的一般适用性. 例如，这部分Schema信息的管理主要集中于表类型信息的管理，例如Hive，HBase等，而不是完全通用的类型系统. 另一方面，在外部服务方面，还将更加关注元数据管理系统与业务系统应用程序需求之间的关联. 架构类似，下面简要介绍产品交互形式和一些特殊功能的特殊效果设置.

除表元数据信息管理外，元数据管理系统的主要功能之一是“业务组”的管理. 业务组的设计目标是将整个大数据开发平台作为大数据开发平台来运行. 人事自治管理单位的组织形式. 所有数据和任务管理任务都委托给业务组，并由业务组管理员进行管理.

从元数据管理系统的角度来看，业务组的管理包括数据和任务到业务组的映射，业务组内的角色的映射等. 此外，为了适应业务的快速变化，具有诸如数据资产所有权转移之类功能的用户.

通常，业务组的管理功能更多地与大数据开发平台的其他组件结合在一起，例如集成开发平台IDE，该集成开发平台IDE在开发平台中基于业务组提供多租户开发. 例如，环境管理功能与调度系统相结合，可以根据任务和数据业务组的归属信息在任务调度期间实现计算资源的配额管理.

最后，我想再说几句有关数据的血液关系追踪. 在Atlas和navigator中，与数据有关的元数据和与血液有关的信息主要是通过计算框架本身支持的运行时挂钩获得的. 例如，配置单元挂钩处于语法分析阶段，风暴挂钩处于拓扑提交阶段. 这样做的好处是，血统的可追溯性分析是基于实际运行任务的信息. 如果插件已完全部署，就不会有遗漏的问题，但是有许多问题很难用这种方式解决，例如:

一个简短的摘要是基于运行时信息来收集血液关系. 由于缺乏静态的业务信息协助，如何识别和更新生命周期以及血缘关系的有效性将是一个难题，并且在一定程度上受到限制. 适用范围. 我们的方法是血液信息的收集不是在运行时进行的，而是在脚本保存时进行的. 由于开发平台统一管理所有用户的任务脚本，因此我们可以静态分析脚本，以及脚本本身的业务信息，并知道开发平台的执行状态和生命周期. 因此在一定程度上可以解决上述问题. 当然，该解决方案也有其自身的缺点，需要克服. 例如: 如果脚本控件不到位，则血缘关系分析可能不完整；血缘关系是基于最新脚本的静态逻辑关系，不能基于实际操作. 分析示例. 但是，从需求的角度来看，这些缺点对我们来说不是很核心的问题，或者可以通过系统的支撑结构在一定程度上解决.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-283262-1.html