168大数据

标题: Apache Atlas | 元数据管理框架的独舞 [打印本页]

作者: 168主编    时间: 2021-1-31 16:16
标题: Apache Atlas | 元数据管理框架的独舞
本帖最后由 168主编 于 2021-1-31 16:18 编辑

导读: 本文由張較痩总结分享授权发布,本文主要从元数据管理框架Apache Atlas、WhereHows&DataHub的定位、功能、架构、对比展开介绍~ ( ` ) 笔芯~ 再次感谢張較痩投稿!

  張較痩,大数据行业新人,就职于北京18线互联网公司,正努力向各位同行和前辈学习中!

  关注『数据仓库与Python大数据』,获取更多。

  作者: 張較痩

  正文

  一、定位

  Apache Atlas:Apache Atlas是Hadoop社区为解决Hadoop生态系统的元数据治理问题而产生的开源项目,它为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。

  Linkedin WhereHows:WhereHows是LinkedIn公司为了方便员工发现公司内部数据、跟踪数据集移动、查看各种内部工具和服务的动向,而开发的用于大数据发现和管理的工具。它从不同的源系统中采集元数据,并进行标准化和建模,从而作为元数据仓库完成血缘分析。

  Linkedin DataHub:WhereHows项目已于2018年重新被LinkedIn公司设计为DataHub项目。

  二、厂商

  Apache Atlas:Atlas最早由HortonWorks公司开发,用来管理Hadoop项目里面的元数据,进而设计为数据治理的框架。后来开源出来给Apache社区进行孵化,目前得到Aetna,Merck,Target,SAS,IBM等公司的支持进行发展演进。因其支持横向海量扩展、良好的集成能力和开源的特点,国内大部分厂家选择使用Atlas或对其进行二次开发。

  Linkedin WhereHows&DataHub:由LinkedIn开源,并主要在LinkedIn内部使用。外部应用比较少,暂时没有看到相关应用案例。

  三、功能概览

  Apache Atlas:

  1)查看数据仓库中表与表之间的血缘依赖

  

  2)查看数据仓库表中字段与字段之间的血缘依赖

  

  Linkedin WhereHows:

  1)查看数据仓库中表与表之间的血缘依赖

  

  2)查看数据集和作业流血缘依赖

  

  3)查询元数据

  

  Linkedin DataHub:

  1)搜索元数据

  

  2)查看元数据

  

  3)编辑元数据

  

  4)查看数据集和作业流血缘依赖

  

  四、架构

  Apache Atlas:

  

  MetaSource Sources:目前,Atlas支持从以下来源提取和管理元数据:Hbase、Hive、Sqoop、Storm、Kafka

  Messaging:除了API之外,用户还可以选择使用基于Kafka的消息传递接口与Atlas集成

  采集/导出(Ingest/Export):采集组件允许将元数据添加到Atlas。同样,“导出”组件将Atlas检测到的元数据更改公开为事件。

  类型系统(Type System):用户为他们想要管理的元数据对象定义模型。Type System称为“实体”的“类型”实例,表示受管理的实际元数据对象。

  图形引擎(Graph Engine):Atlas 通过使用图形模型管理元数据对象。

  Titan:目前,Atlas 使用 Titan 图数据库来存储元数据对象

  Metadata Store:采用Hbase来存储元数据

  IndexStore:采用Solr来建索引

  API:Atlas的所有功能都可以通过REST API提供给最终用户,允许创建、更新和删除类型和实体。它也是查询和发现通过Atlas管理的类型和实体的主要方法。

  Atlas Admin UI:该组件是一个基于Web的应用程序,允许数据管理员和科学家发现和注释元数据。Admin UI提供了搜索界面和类SQL的查询语言,可以用来查询由Atlas管理的元数据类型和对象。

  Tag Based Policies:权限管理模块。

  Business Taxonomy:业务分类

  Linkedin WhereHows:

  

  WhereHows支持从HDFS、Teradata、Oracle、HIve、Elastic Search、Druid的数据集和Azkaban、Oozie的作业中将元数据的抽取、加载(ETL)至自身的Repo库。源系统可分为数据集类源系统和作业类源系统。

  数据集类源系统:以Hive为例,WhereHows从Hive的元数据库MySQL中抽取元数据并存储在自身的元数据仓库中,从而最终可以从WhereHows中查看Hive中的元数据信息,如Hive中有哪些Database、Database下有哪些表等。WhereHows不能直接得到数据集的血缘,WhereHows中数据集的血缘是从相关作业的分析中得到的。

  作业类源系统:以Azkaban为例,假设运行hive任务,则WhereHows可以从Azkaban的元数据库中获取作业信息、并从JobHistory获取实际运行的Hive或pig的日志,并对这些元数据以及日志数据解析形成血缘。

  Web UI即前端Web组件,提供可视化查询功能。提供展示元数据的UI,包括Datasets和Flows两个功能视图。

  REST Endpoint作为服务后端,主要提供API接口和执行ETL作业两个功能。

  DataHub:

  

  DataHub提供通过直接API调用或Kafka流的形式来摄取元数据。

  元数据从Kafka获取,元数据的生成者要生产一个标准化的元数据改变事件(MCE)。

  DataHub通过一组通用数据访问对象(DAO)进一步抽象底层数据系统,例如键值DAO、查询DAO和搜索DAO。通过键值DAO的任何更新操作都将自动发出元数据审计事件(MAE)。

  五、对比

  1)Atlas比WhereHows血缘分析粒度较细,支持字段级血缘依赖的跟踪。WhereHows仅支持表级。

  2)Atlas与Apache Ranger集成,可根据与Atlas中实体相关的分类对数据访问进行授权/数据屏蔽。而WhereHows缺乏有效的用户、权限管理能力。

  3)WhereHows比Atlas支持的源系统多。

  4)DataHub刚立项不久,数据管理方面与WhereHows的特性差不多,侧重于元数据的发现(搜索、查询)。

  5)Atlas在同行业中逐渐普及,社区活跃度远高于WhereHows和DataHub。







欢迎光临 168大数据 (http://www.bi168.cn/) Powered by Discuz! X3.2