【数据架构】数据网格解释

简介: 【数据架构】数据网格解释

“我想指出,所提供的链接都不是附属的,我从本文中提到的公司中没有任何收获。我做这一切是因为直到最近我才听说过数据网格,我很期待这次活动,并希望在此之前深入了解一下。我还认为这可能会让其他人感兴趣,并付出了额外的努力以清晰简洁的方式分享我的笔记。”

本文/报告的目的是根据 Zhamak Dehghani 在即将举行的 Datanova — 数据网格峰会之前关于 Martin Fowler 的前两篇文章,分享和解释我对数据网格的理解。许多句子直接取自扎马克的文章。

Dahghani 女士最近出版了一本关于该主题的书。我还没有读过它,但我毫不怀疑它会澄清这篇文章的一些内容。

作为图表的忠实粉丝,我尝试制作一些图表来解释一些概念。

在接下来的文章中,我首先简要介绍 Zhamak Dehghani。我继续解释什么是数据网格以及为什么它很重要。我简要总结一下它是如何工作的。最后,分享几个我自己的问题。

在本文末尾,您将找到数据网格技术术语表和本文使用的或您可能感兴趣的资源列表。

扎马克·德加尼是谁?


Zhamak Dehghani — source ThoughtWorks

Zhamak 拥有计算机科学专业的工程学士学位和信息技术管理硕士学位。她做了几年软件工程师。今天,她是 ThoughtWorks 的新兴技术总监,过去 10 年她一直在该公司工作。

“她在 2018 年创立了 Data Mesh 的概念,这是大数据管理向数据去中心化的范式转变,此后一直在向更广泛的行业宣传这一概念。

Zhamak 是 ThoughtWorks 技术顾问委员会的成员,并为创建 ThoughtWorks 技术雷达做出了贡献。她作为技术专家工作了 20 多年,并为分布式计算通信以及嵌入式设备技术方面的多项专利做出了贡献。” — 思想工场


什么是数据网格,为什么它很重要?

尽管我们仍然在通过科学方法发现或重新发现早已超越直觉的智慧,但在许多领域,人类已经对自己感兴趣的主题产生了透彻的理解:意识、生活、冲突、教与学等。, 21 世纪的特点是两个尚未彻底分析的概念:敏捷方法和数据的力量。

数据和敏捷性可能早在我们开始创造特定术语来描述它们之前就已经存在,但只是“最近”,这要归功于我们新发现的计算能力,我们才真正了解它们的重要性。

数据网格是敏捷思维和对数据的透彻理解的结果。数据网格最简单的形式是处理数据的敏捷框架。

目前,数据湖是大型刚性结构。数据从这些刚性结构中提取、处理并作为一个单一的超级强大的数据平台提供服务。然而,数据湖存在一些“可扩展性”缺陷

  • 由于数据在一个地方全部处理,因此它们通常不利于轻松添加新的数据源,这在数据是黄金且高效处理是关键的世界中至关重要。
  • 他们冒着负责摄取、处理或提供数据的专业团队之间沟通问题的风险。与中国耳语游戏类似,最终用户的需求很容易被那些摄取和处理数据的人误解
  • 它们不利于可互换的用例和实验


(Simplified diagram of a data lake)

上图可能显示了添加新数据源将如何需要更新整个数据湖,这涉及各种流程和多个独立团队。每个新客户或新来源都意味着修改复杂性不断增加的结构。

刚性总比没有好,因此数据湖曾经是必要的。然而,敏捷总是比刚性好,数据网格是刚性数据湖的敏捷改进。

数据网格如何工作?

[ 重要的!] 这可能只是我遇到的一个问题。我认为数据产品是核心功能基于数据的产品

数据产品是“通过使用数据促进最终目标的产品”——DJ Patil,Data Jujitsu。

汽车不是数据产品,但 GPS 是。在线流媒体服务是一种数据产品,但视频商店不是。但是,对于 Zhamak Dehghani 来说,由于产品就是数据本身,因此术语数据产品用于将特定数据域定义为产品。重要的是要理解,在这种情况下,数据产品是一个有据可查、高质量的特定领域数据集,数据消费者(数据科学家、分析师等)可以通过 API 使用它。数据网格的目标是为公司的最终数据产品(它向消费者提供的产品)提供服务。我将通过将 Dehghani 女士的“数据产品”称为“领域数据产品”来尝试澄清这一点。

数据网格是一个框架。虽然只有某些技术可能允许其实施,但并不限于特定技术。因此,Zhamak Dehghani 仅提供原理和逻辑架构来解释如何实现它。

数据网格基于四个原则:

面向领域的去中心化数据所有权和架构

数据网格是特定领域数据产品的网络。它比数据湖具有更好的扩展性,因为新的数据源或新的数据消费者只意味着添加一个新的域(数据产品),而不是重新访问整个数据湖。

数据作为产品

每个域都像消费者一样为数据工程师服务,并具有以下属性。

  • 可发现:所有可用数据域的注册表(或市场)。
  • 可寻址:允许数据消费者以编程方式访问的唯一地址。
  • 值得信赖:域“所有者”提供数据的质量保险以及数据出处和数据沿袭作为与域数据产品相关的元数据。
  • 自我描述的语义和语法:域元数据应该足够清晰,任何人都可以自己开始使用数据。
  • 可互操作并受全球标准监管:得益于全球质量和识别标准,数据可以跨域处理。
  • 安全并受全球标准监管:使用企业身份管理系统 (SSO) 和基于角色的访问控制。
  • 领域数据跨职能团队:领域特定的产品所有者和数据工程师,能够处理从源到数据消费者的整个领域数据。

作为平台的自助数据基础设施

每个域的数据集都需要可供任何希望使用它们的人使用。访问数据集的数据消费者需要通过上一个原理中的属性描述找到一个完善的数据产品。

联合计算治理

数据湖的优势在于,如果不遵循数据湖标准,则没有任何效果。因此,保证整个数据网格的功能至少与数据湖一样的唯一方法是实施全局治理全局治理意味着两套标准:全球标准和领域特定标准。其中包括与数据产品属性相关的标准,例如数据质量、数据集之间的交叉引用、命名约定、元数据语法等。

数据网格可以很容易地与 Python 进行比较。Python 的强大之处不仅在于它是一种简单的编码语言,还在于任何遵循全球库标准的开发人员都可以构建一个新的 Python 库(一种代码产品)并使其在官方 Python 库的全球市场上可用。每个开发人员还可以自由设置自己的附加库标准。

在她的文章中,Zhamak 将数据产品显示为属于域,但没有没有数据产品的域,所以在我的情况下,它们是相同的。

单个数据域(数据产品)可以表示如下:


(A single data domain and its components)

使用六边形表示单个数据域,我们可以像这样表示数据网格:


(A simple data mesh diagram with five data domains)

域 4 和域 5 使用来自其他域的数据,但它们也可能从自己的来源获取自己的数据。

Zhamak 还谈到了多平面数据平台。 (请参阅数据网格原理和逻辑架构)老实说,虽然她将平面定义为“代表一个存在层次——既集成又分离”,但我不确定平面是什么意思。😅

我的理解是,数据网格需要多个接口,以便使用它的任何人都可以轻松访问其不同的组件。例如,数据消费者需要访问数据产品(数据集和相关元数据)的完整注册表。其他用户可能需要访问治理标准,并且能够轻松了解它们是全局的还是特定于某些域的。其他用户可能需要访问数据网格本身的可视化表示、访问其基础架构等。

下图试图在单个图像中解释数据网格:

640.png


(The full data mesh as I understand it)

作为去中心化领域特定数据产品的网络,对于需要管理许多数据源和数据消费者的企业而言,数据网格有可能成为一个非常强大的解决方案,但对于数据网格的构建和工作方式没有清晰的界面在公司内部,扩展和维护结果可能比数据湖更加混乱和耗时。

结论和问题

我很高兴发现了数据网格,并期待了解更多信息并澄清一些混乱的元素。我期待着这次会议,阅读这本书,如果可能的话,我会更新这篇文章或写另一篇文章。

每个数据域都应该由一个独立的团队管理。这是否意味着公司需要为每个新领域雇佣一个全新的团队?这不违背域的可扩展性吗?

每个数据域的管道都必须遵循全局数据治理规则,那么治理规则的变化不会导致每个管道的变化吗?

除了上一个问题,每个域的域数据管道是否应该在一个公共基础设施中注册并独立地为每个域提供服务,类似于开源 Python 库?下图可以阐明我的意思:


(Data mesh code Registry concept)

这引发了其他问题,例如数据团队之间的脚本所有权。此外,如果修改脚本 5 以适应仅适用于域 2 的修改而不是新脚本,则需要为域 3 和 4 创建旧脚本 5 的副本。(域拥有自己的域似乎更简单代码,也许我正在将这种敏捷性推到很远。😆)

今天可能没有任何现有的特定数据网格技术,但在我看来,作为域管道功能、域数据集和访问全球治理标准的注册表的单一平台将是这样一项技术。现有的任何其他东西都可以作为更完整解决方案的 MVP 方法。

数据网格词汇表

 

  • 数据网格:专注于去中心化数据管理的数据框架。
  • 数据产品:将数据用作其核心功能的一部分的产品。
  • 数据即产品:当数据是最终产品时。消费者是数据消费者:业务分析师、数据科学家、数据分析师、数据工程师等等。他们将“购买”数据并在自己的数据产品中使用。
  • 领域:计算机程序的目标主题领域。在这种情况下,数据的目标主体。如果数据用于分析“用户配置文件”,则域为“用户配置文件”,如果用于分析“歌曲”,则域为“歌曲”。
  • 域数据产品:特定于数据网格中唯一域的数据产品。
  • 源域数据集:一个数据集,它紧密地代表创建时的原始数据,并且没有为特定消费者拟合或建模。
  • 消费者对齐的域数据集:经过面向消费者的转换的源域数据集。
  • 域数据团队:负责专门管理数据网格内的数据域的数据团队。
  • 领域数据产品所有者:A P.O.负责将数据作为产品交付。
  • 领域驱动设计:将系统分解为围绕业务领域能力构建的分布式服务。
  • 架构量子:可以独立部署且具有高功能凝聚力的最小建筑单元,包括其功能所需的所有结构元素。
  • 联合计算治理:由域数据产品所有者和数据平台产品所有者联合领导的决策模型,具有自治和域本地决策权,同时创建并遵守一组全局规则——规则适用于所有数据产品及其接口——以确保一个健康且可互操作的生态系统。
相关文章
|
27天前
|
机器学习/深度学习 数据采集 人工智能
揭秘!47页文档拆解苹果智能,从架构、数据到训练和优化
【8月更文挑战第23天】苹果公司发布了一份47页的研究文档,深入解析了其在智能基础语言模型领域的探索与突破。文档揭示了苹果在此领域的雄厚实力,并分享了其独特的混合架构设计,该设计融合了Transformer与RNN的优势,显著提高了模型处理序列数据的效能与表现力。然而,这种架构也带来了诸如权重平衡与资源消耗等挑战。苹果利用海量、多样的高质量数据集训练模型,但确保数据质量及处理噪声仍需克服。此外,苹果采取了自监督与无监督学习相结合的高效训练策略,以增强模型的泛化与稳健性,但仍需解决预训练任务选择及超参数调优等问题。
128 66
|
5天前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
16 5
|
21天前
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
26天前
|
存储 监控 安全
大数据架构设计原则:构建高效、可扩展与安全的数据生态系统
【8月更文挑战第23天】大数据架构设计是一个复杂而系统的工程,需要综合考虑业务需求、技术选型、安全合规等多个方面。遵循上述设计原则,可以帮助企业构建出既高效又安全的大数据生态系统,为业务创新和决策支持提供强有力的支撑。随着技术的不断发展和业务需求的不断变化,持续优化和调整大数据架构也将成为一项持续的工作。
|
1月前
|
机器学习/深度学习 自然语言处理 数据处理
|
1月前
|
缓存 程序员 调度
第3章-图形处理单元-3.1-数据并行架构
第3章-图形处理单元-3.1-数据并行架构
27 1
|
18天前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
33 0
|
28天前
|
存储 缓存 Java
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
31 0
|
30天前
|
存储 安全 关系型数据库
"揭秘!如何设计数据库架构,让信息系统心脏强健无比?一场关于数据效率、安全与可扩展性的深度探索"
【8月更文挑战第19天】数据库架构是信息系统的核心,关乎数据存储效率与安全及应用性能和扩展性。优秀设计需综合考量业务需求、数据模型选择、查询优化、事务处理、安全性和扩展性。首先,深刻理解业务需求,如电商系统需高效处理并增长商品、订单等数据。其次,基于需求选择合适的数据模型,如关系型或非关系型数据库。再者,优化查询性能与索引策略以平衡读写负载。同时,考虑事务处理和并发控制以保证数据一致性和完整性。最后,加强安全性措施和备份恢复策略以防数据风险。通过这些步骤,可以构建稳健高效的数据库架构,支持系统的稳定运行。
22 0
|
1月前
|
消息中间件 缓存 Kafka
图解Kafka:架构设计、消息可靠、数据持久、高性能背后的底层原理
【8月更文挑战第15天】在构建高吞吐量和高可靠性的消息系统时,Apache Kafka 成为了众多开发者和企业的首选。其独特的架构设计、消息可靠传输机制、数据持久化策略以及高性能实现方式,使得 Kafka 能够在分布式系统中大放异彩。本文将通过图解的方式,深入解析 Kafka 的这些核心特性,帮助读者更好地理解和应用这一强大的消息中间件。
86 0