元数据管理平台对比预研 Atlas VS Datahub VS Openmetadata

大家好,我是独孤风。元数据管理平台层出不穷,但目前主流的还是Atlas、Datahub、Openmetadata三家,那么我们该如何选择呢?

本文就带大家对比一下。要了解元数据管理平台,先要从架构说起。

元数据管理的架构与开源方案

下面介绍元数据管理的架构实现,不同的架构都对应了不同的开源实现。

下图描述了第一代元数据架构。它通常是一个经典的单体前端(可能是一个 Flask 应用程序),连接到主要存储进行查询(通常是 MySQL/Postgres),一个用于提供搜索查询的搜索索引(通常是 Elasticsearch),并且对于这种架构的第 1.5 代,也许一旦达到关系数据库的“递归查询”限制,就使用了处理谱系(通常是 Neo4j)图形查询的图形索引。

很快,第二代的架构出现了。单体应用程序已拆分为位于元数据存储数据库前面的服务。该服务提供了一个 API,允许使用推送机制将元数据写入系统。

第三代架构是基于事件的元数据管理架构,客户可以根据他们的需要以不同的方式与元数据数据库交互。

元数据的低延迟查找、对元数据属性进行全文和排名搜索的能力、对元数据关系的图形查询以及全扫描和分析能力。

Datahub 就是采用的这种架构。

下图是当今元数据格局的简单直观表示:

(包含部分非开源方案)

Apache Atlas

Atlas是Hadoop的数据治理和元数据框架。Atlas于2015年7月开始在Hortonworks进行孵化。

官网地址为:https://atlas.apache.org/

源码地址为:https://github.com/apache/atlas

目前标星1.7K,最新稳定版本2.3.0。

开发语言后端主要为Java,前端功能主要为JS实现。

特性

  • Atlas支持各种Hadoop和非Hadoop元数据类型
  • 提供了丰富的REST API进行集成
  • 对数据血缘的追溯达到了字段级别,这种技术还没有其实类似框架可以实现
  • 对权限也有很好的控制

Atlas包括以下组件:

  • 采用Hbase存储元数据
  • 采用Solr实现索引
  • Ingest/Export 采集导出组件 Type System类型系统 Graph Engine图形引擎 共同构成Atlas的核心机制
  • 所有功能通过API向用户提供,也可以通过Kafka消息系统进行集成
  • Atlas支持各种源获取元数据:Hive,Sqoop,Storm。。。
  • 还有优秀的UI支持

Atlas是Hadoop生态的嫡系,并且天然的集成在Ambari中(不过版本较低,建议自己安装)。

Atlas对Hive的支持极好,对Spark也有一定的支持。

如果熟悉Atlas的API,也可以很好的扩展。

但由于社群活跃度一般,Atlas后期更新乏力。

页面也还是老样子,新版本的页面并不完善,所以还有有很大的局限性。

DataHub (LinkedIn)

LinkedIn开源出来的,原来叫做WhereHows 。经过一段时间的发展datahub于2020年2月在Github开源。

官网地址为:https://datahubproject.io/

源码地址为:https://github.com/linkedin/datahub

目前标星8.8K,最新稳定版本0.12.0。

开发语言为Java和Python。

DataHub是由LinkedIn的数据团队开源的一款提供元数据搜索与发现的工具。

提到LinkedIn,不得不想到大名鼎鼎的Kafka,Kafka就是LinkedIn开源的。LinkedIn开源的Kafka直接影响了整个实时计算领域的发展,而LinkedIn的数据团队也一直在探索数据治理的问题,不断努力扩展其基础架构,以满足不断增长的大数据生态系统的需求。随着数据的数量和丰富性的增长,数据科学家和工程师要发现可用的数据资产,了解其出处并根据见解采取适当的行动变得越来越具有挑战性。为了帮助增长的同时继续扩大生产力和数据创新,创建了通用的元数据搜索和发现工具DataHub。

由于背后有商业化的规划,并且社区活跃,近两年Datahub的更新异常活跃。也将自己的定位为基于现代数据栈的元数据平台。
DataHub实现了端到端的数据发现,数据可观察性和数据治理。并且为开发人员提供了丰富的扩展接口,其目的就是应对不断变化的数据生态。事实证明,元数据管理就应该这样去建设。
DataHub提供了跨数据库、数据仓库、数据湖、数据可视化工具的搜索与发现功能。实现端到端的全流程数据血缘的构建。DataHub是实时的元数据捕捉框架,可以实时感应元数据的变化。同时支持标签,术语表,业务域等元数据的管理。DataHub还提供了丰富的权限支持。在最新的DataHub版本中,可以在页面上去进行元数据的获取操作。
DataHub支持的数据源非常丰富,如Tableai、PowerBI、Superset等数据可视化工具。
也支持Airflow、Spark、ES、Kafka、Hive、Mysql、Oracle等大数据组件的元数据的获取。

Datahub的页面经过最新的改版,规划也较为合理,美观。

Openmatadata

OpenMetadata是一个用于数据治理的一体化平台,可以帮助我们发现,协作,并正确的获取数据。

OpenMetadata提供了数据发现、数据血缘、数据质量、数据探查、数据治理和团队协作的一体化平台。它是发展最快的开源项目之一,拥有充满活力的社区,并被各行业垂直领域的众多公司采用。 OpenMetadata 由基于开放元数据标准和API 的集中式元数据存储提供支持,支持各种数据服务的连接器,可实现端到端元数据管理,让您可以自由地释放数据资产的价值。

官网地址:https://open-metadata.org/

源码地址:https://github.com/open-metadata/OpenMetadata

目前标星3.4K,最新版本为1.2.3。

主要开发语言,后端为Java,前端为TS。

其UI非常美观,其操作和使用逻辑,也符合业务人员的习惯。

优缺点对比

Datahub:

优势:

强大的数据发现和搜索功能,方便用户快速定位所需数据。

提供数据质量元数据,帮助用户理解和信任数据。

支持多种数据源,包括传统的关系数据库和现代的数据湖。

社区活跃,不断有新功能和改进加入。

劣势: 初学者可能会觉得界面和配置相对复杂。

在某些情况下,集成新的数据源可能需要额外的开发工作。

Atlas:

优势:

与Apache Hadoop生态系统深度集成,特别适合Hadoop用户。

提供强大的数据血缘和分类功能,有助于数据治理。

支持自定义的元数据类型和模型。

开源,有较大的社区支持和贡献。

劣势:

主要针对Hadoop生态系统,可能不适合非Hadoop环境。

用户界面和用户体验不如一些商业产品。

如何选择?

毫无疑问,从活跃度和发展趋势来看,Datahub都是目前最炙手可热的元数据管理平台。Openmatadata更有数据治理、数据资产管理平台的样子。而Atlas和Hadoop联系紧密,也有自己优势。

那么我们该如何选择呢?首先应该明确需求。

相信读到这篇文章的人,大部分还是想做一个元数据管理平台,以开展企业的数据治理工作。如果学习过DAMA的数据治理体系,我们应该知道做元数据管理要梳理好数据源都在哪,并尽可能的管理公司的全量数据。

而功能方面,是否需要数据血缘功能,术语表、标签等功能都是需要调研的内容。那我们一步步来分析。

1、梳理数据源

数据仓库与BI是大部分企业必备的,也是重要的元数据来源。不同企业的的搭建方式不同,前几年可能更多的是离线数仓,多采用Hive,Spark等大数据技术搭建。近几年数据湖技术,实时数仓技术出现,更多的企业会选择如Hudi,Iceberg等技术,而实时数仓多采用Doris,Paimon等技术,在实时处理中,还要考虑收集Flink实时计算引擎的元数据。

而部分企业也希望将业务系统,如Oracle,Mysql等数据库的元数据进行收集。

除此以外,还有一些业务元数据也是需要梳理的,一般通过接口、页面都可以操作。

原生支持所有组件的元数据管理平台是不存在的。但是好在元数据管理平台都提供了丰富的API接口,是可以扩展的。

所以在对数据源梳理后,并结合上面元数据管理平台的特性,可以做出基本的选择。

如果企业需要管理的数据源主要是大数据组件,Hive和Spark为主,可以使用Atlas快速的搭建一个元数据管理平台,由于原生的支持,基本不需要做很多的适配,只要安装配置好就可以。

但是如果企业收集元数据不限于此,建议选择更灵活的Datahub和Openmetadata,反正都要做适配,做二次开发,不如直接选一个更灵活的。

2、明确需求

我们先来看看三个平台的功能。

Altas有搜索,数据血缘,标签,术语表等功能。

Datahub有搜索,数据血缘,数据分析,标签,术语表等功能,也可以集成数据质量框架,如GreatExceptions。

Openmetadata有搜索,数据血缘,数据质量,数据分析,标签,术语表功能,并且有团队协作的功能。

如果这些能满足公司的需要就是可以选择的,如果不能,那么多余的功能就需要另外的开发了。

二开这里简单说一下,如果是元数据管理平台+数据治理工具的组合,建议选择Datahub基本可以覆盖所有的元数据管理功能,也有很好的扩展性。

而如果想选择一个平台大而全,可以考虑在Openmetadata基础上二开,毕竟支持的功能多一些。

3、可行性

虽然完事具备,但是能不能实行,其实并不一定。实现元数据管理的难度巨大

在项目开始之前,必须要考虑实现的难度,如果不需要二开,可能只需要有经验的技术人员或者运维人员安装好就可以。

但是如果需要二开,则必须考虑开发难度。

Atlas后端主要为Java,需要高级的Java开发人员进行钻研,如需要更改页面,也需要前端人员的配合。

Datahub后端Java和Python都有的,而核心的数据摄取部分,主要是Python为主,熟悉Python框架的同学会更好上手。如需要更改页面,也需要前端人员的配合。

Openmetadata后端为Java,前端为TS。同样都是要有相关经验的人员参与的。

元数据管理并不容易,我在搭建二开环境的过程中也是遇到了很大的困难,但是熟悉开源项目的源码对于自研项目也有着非常大的帮助,没有白走的路,越是困难收获也会更大。

欢迎加入大数据流动,共同学习元数据管理相关知识,未完待续~

热门相关:朔明   锦绣医妃之庶女凰途   史上第一宠婚:慕少的娇妻   抗日之全能兵王   陆爷的小祖宗又撩又飒