关键字:元数据管理、血统采集、血统生命周期、图数据库、数据地图
元数据是描述数据的数据(data about data),是指从信息资源中抽取出来用于描述其特征与内容的数据,从一般意义上来讲,元数据是指数据的类型、名称、和值等;在关系型数据库中,常常指数据表的属性、取值范围、数据来源,以及数据之间的关系等。
元数据的管理有着十分重要的作用,它能够为数据用户提供完整的数据定义信息,减少数据冗余,有利于识别与查找数据。同时,能够追踪数据在数据库中发生的任何变化,帮助用户理解数据在整个血统生命周期的来龙去脉,实现简单高效地管理大数据系统中的海量数据,并且通过数据资源的有效追踪、发现、查找来挖掘大数据系统中数据的价值。
在大数据治理活动中,元数据与元数据管理有以下要点。
(1)数据管理
数据管理要求能够追踪数据的整个生命周期,包括数据的来源、数据的修改与删除,并能够支持快速的检索。
(2)元数据建模
元数据建模通过结合标签与数据属性的方式来更好地理解数据及生命周期,从而实现对元数据的快速建模。
(3)易于交互的解决方案
通过建立统一的、贯穿Hadoop生态系统的元数据库,定义统一的元数据标准,为系统中不同组件的元数据信息进行交互提供基础。
Apache Atlas是一个可伸缩和可扩展的元数据管理工具与大数据治理服务,其设计的目的是为了与其他大数据系统组件交换元数据,改变以往标准各异、各自为战的元数据管理方式,构建统一的元数据库与元数据定义标准,并且与Hadoop生态系统中各类组件相集成,建立统一、高效且可扩展的元数据管理平台。
对于需要元数据驱动的企业级Hadoop系统来说,Apache Atlas提供了可扩展的管理方式,并且能够十分方便的支持对新的商业流程和数据资产进行建模。其内置的系统类型(Type System)允许Atlas与Hadoop大数据生态系统之内或之外的各种大数据组件进行元数据交换,这使得建立与平台无关的大数据管理系统成为可能。同时,面对不同系统之间的差异以及需求的一致性问题,Atlas都提供了十分有效的解决方案。
Atlas能够在满足企业对Hadoop生态系统的预设要求的条件下,高效地与企业的平台的所有生态系统组件进行集成。同时,Atlas可以应用预先设定的模型在Hadoop中实现数据的可视化,提供易于操作的审计功能,并通过数据血统查询来丰富企业的各类商业元数据。它也能够让任何元数据消费者与其相互协作而不需要在两者之间构建分离的接口。另外,Atlas中的元数据的准确性和安全性由Apache Ranger来保证,Ranger能够在运行时阻止那些不具备权限的数据访问请求。
1、元数据交换:允许从当前的组件导入已存在的元数据或模型到Atlas中,也允许导出元数据到下游系统中。
2、数据血统采集:Atlas在平台层次上,针对Hadoop组件抓取数据血统信息,并根据数据血统间的关系构建数据的血统生命周期。
3、数据血统生命周期可视化:通过Web服务将数据血统生命周期以可视化的方式展现给客户。
4、快速数据建模:Atlas内置的类型系统允许通过继承已有类型的方式来自定义元数据结构,以满足新的商业场景的需求。
5、丰富的API:提供了目前比较流行且灵活的方式,能够对Atlas服务、HDP组件、UI及外部组件及外部组件进行访问。
1、数据分类
(1)Atlas提供了导入或定义数据注释的功能,这些数据注释可以根据具体的商业业务分类来定义。通过这些分类后的数据注释,可以实现数据分类的功能。
(2)Atlas提供了定义、添加注释以及自动获取数据集与基础元素之间关系的功能,这些基础元素包括数据源、数据目标及其衍生的过程。
(3)向第三方系统导出元数据。
2、集中审计
(1)对于每一个访问数据的应用以及交互过程,Atlas会抓取其安全访问信息。
(2)对于每一个执行的操作活动及其具体步骤,Atlas能够将这些操作信息抓取下来。
3、搜索与数据血统
(1)在Atlas中,用户可以预先定义访问路径,并通过这些路径来浏览数据分类与数据审计的信息。
(2)用户利用Atlas全文搜索这一特性,可以快速与准确地定位相关数据及审计事件。
(3)可视化的数据血统允许用户深入挖掘数据具体的来源、操作方式以及安全策略等整个数据血统生命周期中的各类信息。
4、安全与策略引擎
(1)基于数据分类的计划、属性和角色,Atlas使得数据管理策略间的关系更加合理化。
(2)通过数据分类,Atlas也支持自定义策略以防止数据不适当的衍生
(3)通过数据表项中的值或者属性,Atlas支持对数据表中的列或者行添加标签。
Apache Atlas的各组成部分的架构图如下图所示。
1、元数据源(Metadata Sources)
Atlas支持与多种数据源相互整合,在未来会有更多的数据源被整合到Atlas之中。目前,导入与管理的数据源有Hive、Sqoop、Falcon、Storm和Hbase。
这意味着:在Atlas中定义了原生的元数据模型来表示这些组件的各种对象;Atlas 中提供了相应的模块从这些组件中导入元数据对象,包括实时导入(HOOK)和批处理 (Batch)导入两种方式。
2、应用简介(Apps)
在Atlas的元数据库中存储着各种组件的元数据,这些元数据将被各式各样的应用所使用,以满足各种现实业务与大数据治理的需要。
(1) Atlas管理界面:作为其中的一个应用是基于Web UI方式的,它允许管理员与数据科学家发现元数据信息和添加元数据注解。在诸多主要的功能中,Atlas提供了搜索接口与类SQL语言,这些特性在Atlas的架构中扮演着十分重要的角色,它们能够被用于查询Atlas中的元数据类型和对象。另外,该管理界面使用Atlas的REST API来构建它的功能。
(2)基于各种策略的标签验证:对于整合了诸多Hadoop组件的Hadoop生态系统, Apache Ranger是一个高级安全解决方案。通过与Atlas整合,Ranger允许管理员自定义元数据的安全驱动策略来对大数据进行高效的治理。当元数据库中的元数据发生改变时,Atlas会以发送事件的方式通知Ranger。
(3)商业业务分类:从各类元数据源中导入Atlas的元数据以最原始的形式存储在元数据库中,这些元数据还保留了许多技术特征。为了加强挖掘与治理大数据的能力,Atlas提供了一个商业业务分类接口,允许用户对其商业领域内的各种术语建立一个具有层次结构的术语集合,并将它们整合成能够被Atlas管理的元数据实体。商业业务分类这一应用,目前是作为Atlas管理界面的一部分而存在的,它通过REST API来与Atlas 集成。
3、集成交互模块(Integration)
Atlas提供了两种方式供用户管理元数据。
(1)API : Atlas的所有功能都可以通过REST API的方式暴露给用户,以便用户可以对 Atlas中的类型和实体进行创建、更新和删除等操作。同时REST API也是Atlas中查询类型和实体的主要机制。
(2)消息(Messaging)系统:除了 REST API,用户可以选择基于Kafka的消息接口来与Atlas集成。这种方式有利于与Atlas进行元数据对象的交换,也有利于其他应用对Atlas中的元数据事件进行获取和消费。当用户需要以一种松耦合的方式来集成Atlas时,消息系统接口变得尤为重要,因为它能提供更好的可扩展性和稳定性。在Atlas中,使用Kafka作为消息通知的服务器,从而使得上游不同组件的钩子(HOOK)能够与元数据事件的下游消费者进行交互。这些事件被Atlas的钩子所创建,并冠以不同的Kafka主题。
4、核心(Core)模块
在Atlas的架构中,其核心组成部分为其核心功能提供了最为重要的支持。
(1)类型系统(Type System) : Apache Atlas允许用户根据自身需求来对元数据对象进行建模。这样的模型由被称为“类型”(Type)的概念组成,类型的实例被称为“实体” (Entity),实体能够呈现出元数据管理系统中实际元数据对象的具体内容。同时,Atlas中的这一建模特点允许系统管理员定义具有技术性质的元数据和具有商业性质的元数据,这也使得在Atlas的两个特性之间定义丰富的关系成为可能。
(2)导入/导出(Ingest/Export) : Atlas中的导入模块允许将元数据添加到Atlas中,而导出模块将元数据的状态暴露出来,当状态发生改变时,便会生成相应的事件。下游的消费者组件会获取并消费这一事件,从而实时地对元数据的改变做出响应。
(3)图引擎(Graph Engine):在Atlas内部,Atlas使用图模型(一种数据结构)来表示 元数据对象,这一表示方法的优势在于可以获得更好的灵活性,同时有利于在不同元数据 对象之间建立丰富的关系。图引擎负责对类型系统中的类型和实体进行转换,并与底层图 模型进行交互。除了管理图对象,图引擎也负责为元数据对象创建合适的索引,使得搜索 元数据变得更为高效。
(4)Graph Engine:在内部,Atlas保留使用Graph模型管理的元数据对象。这种方法提供了极大的灵活性,并可以有效处理元数据对象之间的丰富关系。图引擎组件负责在Atlas类型系统的类型和实体以及基础图持久性模型之间进行转换。除了管理图形对象外,图形引擎还为元数据对象创建适当的索引,以便可以有效地搜索它们。Atlas使用JanusGraph(图数据库)存储元数据对象。默认情况下,Atlas使用独立的HBase实例作为JanusGraph(图数据库)的后备存储。为了为元数据存储提供HA,我们建议将Atlas配置为使用分布式HBase作为JanusGraph(图数据库)的后备存储。这样做意味着您可以从HBase提供的HA保证中受益。Atlas通过JanusGraph(图数据库)索引元数据以支持全文本搜索查询,为了为索引存储提供HA,官方建议将Atlas配置为使用Solr或Elasticsearch作为JanusGraph(图数据库)的后备索引存储,从而提高搜索的效率。
1、定义统一的元数据标准
元数据的标准大致可以分为两类:一类是指元数据建模,即对将来的元数据的建模规范进行定义,使得元数据建模的标准在制定之后,所产生的元数据都以统一的方式建模和组织,从而保证了元数据管理的一致性。另一类是指元数据的交互,是对已有的元数据组织方式以及相互交互的格式加以规范定义,从而实现不同组件、不同系统之间的元数据交互。
Apache Atlas核心中的Type System (类型系统)为定义统一的元数据标准提供了最重 要的支持。在Atlas的类型系统中定义了 3个概念,分别是类型、实体和属性。若将其与面向对象语言中的类、对象和属性类比,这3个概念就变得十分易于理解了。
在类型系统中,类型是对某一类元数据的描述,定义了某一类元数据由哪些属性组成, 属性的属性值也需要定义为某一类型。在元数据管理的实际应用中,Atlas从数据源获取某一个元数据对象时,会根据其隶属的类型建立相应的实体,这个实体就是该元数据对象在 Atlas中的表示。
在Atlas的类型系统中,元型可分为基本元型、集合元型、复合元型,所有的类型都 是基于这些元型来定义的。同时,Atlas中也提供了若干预置的类型,用户可以直接使用这些类型,或者通过继承的方式来复用这些类型。正是由于所有类型的背后都是统一的元型, 并且所有类型都是继承自某些预置的类型,这实际上就给元数据对象的建模定义了标准。 这样统一的规范和标准使得高效且可靠的元数据交换成为可能。
2、高效的元数据获取与交换体系
为了建立可扩展、松耦合的元数据管理体系,Apache Atlas支持多种元数据获取方式,并且针对大数据生态系统中的不同组件,其元数据的获取方式是相互独立的,这就满足了大数据系统高内聚和低耦合的要求。另外,Apache Atlas的元数据库是唯一的,统一的元数据库保证了元数据的一致性,减少了元数据交换过程中不必要的转换,使不同组件之间的元数据交换高效而稳定。
Apache Atlas获取元数据包括Batch批处理和HOOK两种方式。对于通过Batch批处理的方式获取元数据。在该方式中,Atlas允许用户执行某一脚本获取相应组件的元数据信息,将该组件的元数据信息更新到元数据库中。即,当用户不执行获取元数据的脚本时,相应组件的数据变更不会导致Atlas元数据库中的信息变更;当用户执行获取元数据的脚本时,相应组件中若存在数据的变更,Atlas就会将其所有新增的元数据信息存入元数据库中。
对于通过HOOK的方式获取元数据,针对每一种组件,都有相应的HOOK,用户可以根据自身需要针对不同组件对HOOK进行配置。当配置完成后,相应组件的HOOK会监听该组件的各种操作,一旦该组件的状态发生变化,HOOK会自动创建相应的元数据对象,并发送给Atlas 处理。
使用Kafka作为消息通知系统(Notification)。即不同组件只需要与Kafka进行交互,再由Kafka将元数据对象封装成消息传递给Atlas。当向Atlas元数据管理系统中添加新的大数据组件时,只需要将遵循Kafka规范的HOOK添加到系统之中,即可让Atlas对这一新的组件进行管理,从而满足了元数据管理系统的高扩展性要求。
3、允许针对不同商业对象进行元数据建模
以往的元数据管理组件考虑了用户的诸多需求,为用户设计了诸多的元数据类型,但这种设计思想往往也限制了元数据管理组件的应用。因为不管元数据管理组件的设计者如何高明,也难以概括实际商业场景中涉及的所有元数据对象,因此在使用以往的元数据管理组件时,用户常常会遇到实际商业场景中的元数据对象与组件提供的建模模型不匹配的情况,只能选择近似的类型对实际场景中的元数据对象进行建模,这使得元数据的管理极为不便。
但Apache Atlas有所不同,它提供了若干的预置类型,这些类型的背后也定义了统一且易于复用的元数据对象的元型,并且允许用户通过继承的方式来创建符合实际需求的元数据类型,这就极大地满足了用户对于不同商业对象进行建模的需求,解决了其他元数据管理组件难以匹配所有商业场景中元数据对象的难题。
4、可视化的血统采集与血统生命周期
Apache Atlas能够通过批处理或者HOOK的方式从元数据源获取元数据信息,前者需要用户手动运行脚本来执行,后者则会自动监听相应组件的各类操作。无论采取怎样的方 式,从各类组件获取的元数据对象是十分丰富与多样的,包括血统采集的数据源和采集方式,被采集血统的结构,血统的状态变化及其相应操作,以及数据最后被删除等各种元数据对象信息。这些信息都会被包装成相应的元数据类型,并生成对应的元数据实体,通过消息通知系统发送给Atlas并存储到元数据库中。
但Atlas并不是简单地将这一系列的元数据信息直接存入元数据库中,而是将它们之间的关系也存入元数据库中(图数据库)。同时,为了更好地表示元数据之间的关系,Atlas在其Web UI 中提供了对于数据血统的可视化显示,能够为用户提供直观且明晰的数据地图及血统生命周期, 使得用户从一幅数据血统图中就能够了解数据从进入大数据系统开始,到中间经历的各种变化,到最后从大数据系统中消亡的整个数据血统生命周期(见下图)。
Netflix公司的数据存储在Amazon S3、Druid、Elasticsearch、Redshift、Snowflake和 MySql 中。并且需要使用Spark、Presto、Pig和Hive消费、处理和生成数据集。因为数据源的多样性,为了确保数据平台能够横跨这些数据集成为一个“单一”的数据仓库,应用而生了Metacat。Metacat是一种元数据服务,方便发现、处理和管理数据。
1、元数据系统的联合视图(所有数据存储的元数据访问层)
2、用于数据集元数据的统一API(各种计算引擎可以用来访问不同数据集的集中式服务)
3、数据集的任意业务和用户元数据存储
1、数据源(Data Source):支持RDS、AMAZON REDSHIFT、HIVE、Druid、Snowflke
2、计算引擎(Compute):支持Pig、HIVE、Spark、presto
Metacat是一种联合服务,提供统一的REST/Thrift接口来访问各种数据存储的元数据。元数据存储仍然是模式元数据的事实来源,所以Metacat没有保存这部分元数据。Metacat只保存业务相关和用户定义的元数据。它还将所有关于数据集的信息发布到Elasticsearch,以便进行全文搜索和发现。
Metacat的功能可以分为以下几类:
1、数据抽象和互操作性
2、业务和用户定义的元数据存储
3、数据发现
4、数据变更审计和通知
5、Hive Metastore优化
Netflix使用多种查询引擎(如Pig、Spark、Presto和Hive)来处理和使用数据。通过引入通用的抽象层,不同的引擎可以交互访问这些数据集。例如:从Hive读取数据的Pig脚本能够从Hive列类型的表中读取数据,并转成Pig类型。在将数据从一个数据存储移动到另一个数据存储时,Metacat通过在目标数据存储中创建具有目标类型的表来简化这一过程。Metacat提供了一组预定义的数据类型,可将这些类型映射到各个数据存储中的数据类型。例如,我们的数据移动工具使用上述功能将数据从Hive移动到Redshift或Snowflake。
Metacat的Thrift服务支持Hive的Thrift接口,便于与Spark和Presto集成。我们因此能够通过一个系统汇集所有的元数据变更,并发布有关这些变更的通知,实现基于数据驱动的ETL。当新数据到达时,Metacat可以通知相关作业开始工作。
Metacat也会保存数据集的业务和用户定义元数据。我们目前使用业务元数据来存储连接信息(例如RDS数据源)、配置信息、度量指标(Hive/S3分区和表)以及数据表的TTL(生存时间)等。顾名思义,用户定义的元数据是一种自由格式的元数据,可由用户根据自己的用途进行定义。
业务元数据也可以大致分为逻辑元数据和物理元数据。有关逻辑结构(如表)的业务元数据被视为逻辑元数据。我们使用元数据进行数据分类和标准化我们的ETL处理流程。数据表的所有者可在业务元数据中提供数据表的审计信息。他们还可以为列提供默认值和验证规则,在写入数据时会用到这些。
存储在表中或分区中的实际数据的元数据被视为物理元数据。我们的ETL处理在完成作业时会保存数据的度量标准,在稍后用于验证。相同的度量可用来分析数据的成本和空间。因为两个表可以指向相同的位置(如Hive),所以要能够区分逻辑元数据与物理元数据。两个表可以具有相同的物理元数据,但应该具有不同的逻辑元数据。
作为数据的消费者,我们应该能够轻松发现和浏览各种数据集。Metacat将模式元数据和业务及用户定义的元数据发布到Elasticsearch,以便进行全文搜索。我们的Big Data Portal SQL编辑器因此能够实现SQL语句的自动建设和自动完成功能。将数据集组织为目录有助于消费者浏览信息,根据不同的主题使用标签对数据进行分类。我们还使用标签来识别表格,进行数据生命周期管理。
作为数据存储的中央网关,Metacat将捕获所有元数据变更和数据更新。我们还围绕数据表和分区变更开发了通知推送系统。目前,我们正在使用此机制将事件发布到我们自己的数据管道(Keystone),以更好地了解数据的使用情况和趋势。我们也将事件发布到Amazon SNS。我们正在将我们的数据平台架构发展为基于事件驱动的架构。将事件发布到SNS可以让我们数据平台中的其他系统对这些元数据或数据变更做出“反应”。例如,在删除数据表时,我们的S3数据仓库管理员服务可以订阅这些事件,并适当地清理S3上的数据。
由RDS支持的Hive Metastore在高负载下表现不佳。我们已经注意到,在使用元数据存储API写入和读取分区方面存在很多问题。为此,我们不再使用这些API。我们对Hive连接器(在读写分区时,该连接器直接与RDS通信)进行了改进。之前,添加数千个分区的Hive Metastore调用通常会超时,在重新实现后,这不再是个问题。
1、模式和元数据的版本控制,用于提供数据表的历史记录。例如,跟踪特定列的元数据变更,或查看表的大小随时间变化的趋势。能够查看过去某个时刻元数据的信息对于审计、调试以及重新处理和回滚来说都非常有用。
2、为数据lineage服务提供数据表的上下文信息。例如,在Metacat中汇总数据表访问频率等元数据,并发布到数据lineage服务中,用于对数据表的关键性程度进行排序。
3、增加对Elasticsearch和Kafka等数据存储的支持。
4、可插拔的元数据验证。由于业务和用户定义的元数据是自由形式的,为了保持元数据的完整性,我们需要对其进行验证。Metacat应该有一个可插拔的架构,可在存储元数据之前执行验证策略
1、血统采集(数据源):Atlas支持数据源有Hive、Sqoop、Falcon、Storm和Hbase。Metacat支持的数据源RDS、AMAZON REDSHIFT、HIVE、Druid、Snowflke。
Atlas血统采集是从所支持的数据源进行导入元数据,而Metacat是直接获取相对应的所支持数据库的元数据。
2、元数据管理的模式:Atlas需要按照统一元数据规则,对元数据进行配置导入。而Metacat是直接从所支持的数据源中获取各自的元数据,对源数据库的元数据进行相应的转换,以形成元数据系统的联合视图,从而达到查询引擎交互查询不同数据系统的目的。
Atlas的Type System满足所支持的所有数据系统元数据标准,而且它允许我们通过继承它的预定义类型来实现符合我们自己需求的元数据类型。Metacat也可以根据业务需求定义自己的元数据,但它是直接在数据源的数据库中进行定义。
3、血统的生命周期:Altas利用图数据库提供了UI界面,可直观的看到血统的生命周期。Metacat没有相应的UI界面,它将数据集组织为目录帮助消费者浏览信息,它使用标签来识别表格,进行血统的生命周期管理。
4、图数据库:Atlas应用了JanusGraph作为源数据的图数据库,并用Hbase作为图数据库的后备存储,同时Atlas为实现通过图数据库索引元数据以支持全文本搜索查询,官网建议将Solr或Elasticsearch作为JanusGraph(图数据库)的后备索引存储,从而提高搜索的效率。Metacat将关于元数据的所有信息存储到Elasticsearch中。
5、数据地图:Atlas所提供的UI界面不仅可以看到血统的生命周期,而且还可以确定目标数据是由那些来源数据所形成,同时也可以定位到各个来源数据所属的数据系统甚至可以定位到那个库的那个表。Altas同时支持数据字段的来源追踪。这对数据异常的追踪和定位提供了极大的方便。Metacat可以通过Elasticsearch查询元数据的相关信息,进行相应数据管理。
6、数据状态的检测:Atlas中的导出模块,将元数据的状态暴露出来,一旦状态发生改变,将会生成相应的事件,下游的消费者会获取到相应的事件,并实时的作出元数据状态的响应。Metacat可以对所有元数据和数据的变更进行捕获,通过消息推送系统将事件推送到外部的数据管道,来了解数据的使用情况及趋势。
7、组件的可扩展性:Atlas扩展新的大数据组件时,只需要将组件的HOOK按照kafka的规范添加到系统中即可,这样Atlas就可以对这一新的组件进行管理。Metacat扩展新的数据源时需要进行相应的开发,这也是Metacat未来待增强的特性之一。
8、Hive Metastore:Atlas和Metacat支持的数据源都有Hive,但Atlas使用的是传统的Hive Metastore,而Metacat对传统的Hive Metastore进行了相应的改进,避免了添加数千个分区的Hive Metastore调用时会发生超时的问题。
9、元数据的验证:Atlas通过集成Apache Ranger来保证元数据的准确性及安全性,并能够在运行时阻止那些没有权限的数据访问请求。Metacat对于可拔插的元数据验证架构还是其将来待增强的特性之一。
如有不当之处,请不吝赐教。
参考文献:《大数据治理与安全:从理论到开源实践》–刘驰等编著 2017.8
参考博客:https://www.codercto.com/a/19908.html