LinkedIn-DataHub专题: 元数据中心系统架构演进

LinkedIn-DataHub专题: 元数据中心系统架构演进

本文翻译自 Shirshanka Das 的 DataHub: Popular metadata architectures explained

自从WhereHows(第二代,DataHub前身)在2016年被推出以来,在本文档编写时,元数据中心系统架构经历了三代演变,WhereHows作为最早的元数据中心开源产品影响着后来同类型的项目。在该领域内Lyft’s Amundsen、DataHub处于领先者,Amundsen(2019年10月开源)社区最活跃的,”基于推送“架构之上的DataHub在2019年8月重构推出以来也越来越被关注。
(以下的部分竞品分析可看这)
在这里插入图片描述

第一代架构:Pull-based ETL (基于Pull-ETL模式)

整体架构会简单些,采用单体架构。通常会利用爬取方式定时抓取并结构化数据,存储在一个便于检索的主存储(MySQL/Postgres),和搜索引擎(ES)中,提供一前端展示数据并支持简单检索。1.5 代可能会引入图形数据库(Neo4j)、批处理作业(Spark作业)。
LinkedIn-DataHub专题: 元数据中心系统架构演进_第1张图片

优点:

  • 较少的组件依赖

只需一个查找存储、一个搜索索引和几个爬虫程序,就可以快速聚合元数据,并构建一个有用的应用程序

  • 资源投入少,可快速响应

一般服务于固定场景,可快速响应,较少的资源投入

缺点(主要):

  • pull模式

采集方式虽然很容易实现并可聚合数据,但该方式却及其脆弱。爬虫程序与数据源在不同环境下,往往由各自团队单独管理,共识很容易随着时间推移、产品迭代、人员变动而被打破(比如防火墙规则或密码更改、存储源结构调整),而导致一系列异常。另一个问题,爬虫程序通常会导致负载飙升影响到正常的业务系统以及需考虑增量、非增量带来的影响。而在系统负载过高情况下,爬虫程序总是会被优先挂起或被关闭。这就引出了第二个问题。

  • 数据时效性过低

采集模式都是T+1(n)方式进行,这仅仅只是比以前更有效率了。然而一旦开始运营数据,在多数重要场景下,数据的即时性和高保真度就变得格外重要。(例如数据质量、数据标签)

第二代架构:3-tier app with a service API(支持push的微服务架构)

通过添加基于推送的体系和微服务的API进行存储、检索元数据,第二代架构已经可以为数据资产提供可靠的搜索和发现服务。可能还会引入访问控制,但是元数据依然存储在单个元数据存储区中。
LinkedIn-DataHub专题: 元数据中心系统架构演进_第2张图片

优点:

  • 统一接入方式
  • 可编程

通过服务API,最终可以做到对数据集或字段进行标记,并可对这些数据进行业务操作(如自动删除,提取,备份)

缺点:

  • 没有变更日志

没有日志,当出现问题时,很难重建或修复搜索和图形索引。另外没有实时的元数据变更日志,也无法构建高效的反应系统。

  • 中心化团队

这种架构仍然依赖一个集中化的团队,需要参与到业务数据构建中,支持所有下游消费者希望访问元数据的方式。这不仅限制了中心服务为下游提供动力的能力,也阻碍了业务的快速发展。基于服务的集成操作,还需考虑服务提供方停机带来的影响。

第三代架构:Event-sourced metadata (基于流的组件服务)

基于”中心服务“的元数据解决方案难以跟上企业对元数据用例的需求。要解决这个问题,必须满足两个要求,第一个元数据本身可流动、基于事件的、可实时订阅的;第二个元数据模型是开放的,使用方可按需扩展丰富模型。
在三代架构中做出了两个重大改进:面向日志的元数据体系、面向领域的元数据建模
面向日志的元数据体系:
LinkedIn-DataHub专题: 元数据中心系统架构演进_第3张图片

面向领域的元数据建模:
LinkedIn-DataHub专题: 元数据中心系统架构演进_第4张图片

完整版:
LinkedIn-DataHub专题: 元数据中心系统架构演进_第5张图片

优点:

  • 可以获得基于流的元数据日志(如变更通知)

元数据的细化和丰富可以通过低延迟的日志更改事件来执行

  • 开放扩展

不同的业务团队/用例可附加属性到需要的模型上,以满足不同的需求

缺点:

  • 系统复杂、更多的组件依赖
  • 用户体验可能差、繁琐

开发一个简单的用例,所需的工作量大,繁琐。需要投入一定精力和经验成本在可用性和体验方面下功夫。


经过这样的演化,优良的架构让使用方可以按不同的方式进行对接;可以获得基于流的事件通知;更低时延的查询和全文检索能力;直观的元数据关系图形查询;在不牺牲一致性或时效性情况细化和丰富元数据;更优的用户体验。第三代架构确保我们能够以最具伸缩性和灵活性的方式集成、存储和处理元数据。但这还不够。

“Putting metadata to work is harder than just putting metadata together.”
使用元数据比将元数据放一起更难

首先需要定义正确的元数据模型,以真正捕获对企业有意义的概念。然后,您需要一个支持AI的途径,从这个完整、可靠的数据资产清单过渡到元数据的可信知识图。这将允许您真正释放企业的生产力和治理。

你可能感兴趣的:(DataHub,技术分享,大数据,数据分析)