什么是数据网格-以及如何不将其网格化

问数据行业的任何一个人,最近什么是最热的,“数据网格”很可能会上升到列表的首位. 但是什么是数据网格,为什么要构建一个? 好奇的人想知道.

在这个时代 自助式商业智能, 几乎每家公司都认为自己是一家数据优先的公司, 但并不是每个公司都在用它应得的民主化和可伸缩性水平来对待他们的数据架构.

例如,贵公司将数据视为创新的驱动力. 你的老板是业内第一个看到这种潜力的人 雪花 和美人. 或者,你的CDO领导了一个跨职能的计划,向团队传授数据管理的最佳实践,而你的CTO投资了一个数据工程小组. 最重要的是, 然而, 您的整个数据团队都希望有一种更简单的方法来管理您的组织不断增长的需求, 从处理永无止境的临时查询流,到通过中央ETL管道处理不同的数据源.

支持这种民主化和可伸缩性的愿望是,您当前的数据体系结构(在许多情况下), 孤立的数据仓库或 数据湖 使用一些有限的实时流媒体功能)可能无法满足您的需求.

幸运的是,寻求数据新租约的团队只需要看看 数据网格这是一种席卷整个行业的建筑范式.

什么是数据网格?

与软件工程团队从 单片应用到微服务架构在许多方面,数据网格是微服务的数据平台版本.

由扎马克·德哈尼于2019年首次定义, ThoughtWorks顾问和该术语的最初架构师, a 数据网格 是一种数据平台架构类型,它通过利用面向领域的方式来包容企业中无处不在的数据吗, 自助设计. 借用Eric Evans的理论 领域驱动设计, 一个灵活的, 可伸缩的软件开发范例,将代码的结构和语言与其相应的业务领域相匹配.

不像传统的单片数据基础设施那样处理消费, 存储, 转换, 并在一个中央数据湖中输出数据, 数据网格支持分布式, 特定于领域的数据消费者和视图“数据即产品”,,每个领域处理自己的数据管道.

重要的和有争议的是,这意味着 根据传统的数据网格原理, 领域团队拥有底层平台或数据存储层. 连接这些域及其相关数据资产的组织是一个通用的互操作性层,它应用相同的语法和数据标准. 这可能导致一些基础设施重复, 然而,一些团队采用了“数据网格”结构,平台团队拥有更集中的平台.

数据网格经常与类似的术语混淆 数据结构 (显然,所有的数据类比必须在石油或服装领域), 这是由弗雷斯特公司的一位分析师在千禧年之初提出的吗. 数据结构本质上是由虚拟管理层绑定在一起的现代数据平台(或现代数据堆栈)组成的所有各种异构解决方案. 它不像数据网格那样强调去中心化和领域驱动的架构.

而不是重新发明扎马克精心设计的轮子, 推荐一个正规滚球网站将把数据网格的定义归结为几个关键概念,并强调它与传统数据架构的区别.

在高层次上,这里有一个数据网格的例子:

数据网格架构图
A 数据网格架构图由三个独立的组件组成:数据源, 数据基础设施, 以及由职能所有者管理的面向领域的数据管道. 数据网格体系结构的底层是通用互操作性层, 反映与领域无关的标准, 以及可观察性和治理. (图片由蒙特卡罗数据提供.)

(不过,如果你还没有读过,我强烈推荐你阅读她那篇开创性的文章, 如何超越单片数据湖到分布式数据网或者观看马克斯·舒尔特的科技演讲 为什么Zal和o转变为数据网格. 你不会后悔的。.

面向领域的数据所有者和管道

数据网格将领域数据所有者之间的数据所有权联合起来,这些数据所有者负责将其数据作为产品提供, 同时也促进了跨不同位置的分布式数据之间的通信.

而数据基础设施负责为每个域提供处理它的解决方案, 域的任务是管理摄取, 清洁, 和 聚合 生成可供商业智能应用程序使用的资产. 每个域负责拥有自己的ETL管道, 而是一组应用于所有存储域的功能, 目录, 并维护原始数据的访问控制. 一旦数据被提供给给定域并由给定域进行转换, 然后,域所有者可以利用这些数据来满足他们的分析或操作需求. 数据沿袭 能否帮助数据领导者了解整个组织的消费模式,并帮助他们向更分散的结构过渡.

自助服务功能

数据网格利用面向领域的设计原则来提供自助式数据平台,该平台允许用户抽象技术复杂性,并专注于他们的个人数据用例.

正如Zhamak概述的那样, 面向领域设计的主要关注点之一是维护每个领域中的数据管道和基础设施所需的工作和技能的重复. 为了解决这个问题, 数据网格将与领域无关的数据基础设施功能收集并提取到处理数据管道引擎的中央平台中, 存储, 流媒体基础设施. 与此同时, 每个领域都负责利用这些组件来运行定制的ETL管道, 为他们提供必要的支持,以方便地提供他们的数据,以及真正拥有流程所需的自主权.

通信的互操作性和标准化

每个领域的底层都是一组通用的数据标准,这些标准有助于在必要时促进领域之间的协作——通常都是这样. 不可避免的是,一些数据(包括原始来源和经过清理的数据), 改变了, 和服务数据集)将对多个领域有价值. 实现跨领域协作, 数据网格必须在格式上标准化, 治理, 可发现性, 元数据字段, 其他数据特性. 此外, 就像一个单独的微服务, 每个数据域必须定义并同意它们将向其消费者“保证”的sla和质量度量.

为什么要使用数据网格?

直到最近, 许多公司利用连接到无数商业智能平台的单个数据仓库. 这样的解决方案是由一小群专家维护的,经常背负着巨大的技术债务.

今天, 当前的架构是一个具有实时数据可用性和流处理的数据湖, 以摄入为目标, 丰富, 转换, 并从一个集中的数据平台提供数据. 对于许多组织来说,这种类型的体系结构在以下几个方面存在不足:

  • 中央ETL管道使团队对不断增长的数据量的控制更少
  • 每个公司都变成了数据公司, 不同的数据用例需要不同类型的转换, 把重物放到中央站台上

这样的数据湖导致断开连接的数据生产者, 不耐烦的数据消费者, 更糟糕的是, 积压的数据团队努力跟上业务需求的步伐. 而不是, 面向领域的数据架构, 比如数据网格, 为团队提供两方面的优势:一个集中的数据库(或分布式数据湖),其中域(或业务区域)负责处理他们自己的管道. 作为Zhamak 认为, 通过将数据架构分解成更小的部分,可以很容易地扩展数据架构, 面向领域的组件.

从单片数据湖迁移到分布式数据网格

数据网格提供了一种解决方法 数据的湖泊 通过为数据所有者提供更大的自主权和灵活性, 促进更多的数据实验和创新,同时减轻数据团队通过单一管道满足每个数据消费者需求的负担.

与此同时, 数据网格的自助式基础设施即平台为数据团队提供了一个通用的, 域无关, 并且常常采用自动化的方法来实现数据标准化, 数据产品谱系, 数据产品监控, 报警, 日志记录, 数据产品质量指标(换句话说), 数据收集和共享). 综上所述, 与传统数据架构相比,这些优势提供了竞争优势, 由于消费者和消费者之间缺乏标准化的数据,哪些产品经常受到阻碍.

配合还是不配合,这是一个问题

处理大量数据源并且需要对数据进行实验的团队(换句话说), (快速转换数据)考虑利用数据网格是明智的.

推荐一个正规滚球网站将一个简单的计算放在一起,以确定您的组织是否有必要投资于数据网格. 请回答每个问题, 下面, 用一个数字把它们加在一起得到一个总数, 换句话说, 您的数据网格得分.

  • 数据源数量. 贵公司有多少数据源?
  • 数据团队的规模. 你的数据团队中有多少数据分析师、数据工程师和产品经理(如果有的话)?
  • 数据域数量. 有多少个职能团队(市场、销售、运营等).)依靠你的数据来源来驱动决策, 你们公司有多少种产品, 以及有多少数据驱动的功能正在被构建? 加总数.
  • 数据工程瓶颈. 在1到10的范围内,数据工程团队成为新数据产品实现瓶颈的频率是多少, 1代表"从不" 10代表"总是" ?
  • 数据治理. 在1到10的范围内,数据治理对您的组织的优先级是多少, 1分是“我不在乎”,10分是“它让我整晚睡不着”?

数据网格得分

在一般情况下, 你的分数越高, 您公司的数据基础设施需求越复杂,要求越高, 反过来, 您的组织就越有可能从数据网格中受益. 如果你的得分在10分以上,那么 实现一些数据网格 最佳实践可能对您的公司有意义. 如果你的分数在30分以上, 这样,您的组织就处于数据网格的最佳位置, 你应该明智地加入数据革命.

以下是如何分解你的分数:

  • 1–15考虑到数据生态系统的规模和单维性,您可能不需要数据网格.
  • 15–30你们的组织正在迅速成熟, 甚至可能正处于一个十字路口,在真正能够依靠数据. 推荐一个正规滚球网站强烈建议合并一些数据网格最佳实践和概念,以便以后的迁移可能会更容易.
  • 30岁或以上您的数据组织是您公司的创新驱动力, 数据网格将支持任何正在进行或未来的举措,使数据民主化,并在整个企业中提供自助服务分析.

随着数据变得越来越普遍,数据消费者的需求也在不断多样化, 推荐一个正规滚球网站预计,对于拥有300多名员工的云计算公司来说,数据网格将变得越来越普遍.

数据可观察性与数据网格
图片由Meme Generator提供.网.

如何实现数据网格

数据网格与其说是一种进化,不如说是对技术的彻底改革, 人, 以及整个数据团队的流程. 面对如此宏大的目标,很难知道从哪里开始.

推荐一个正规滚球网站向四位成功实施数据网格的数据领导者征求了他们的建议. 完整的视频可以在上面看到,但总的来说,他们建议:

  • 选择合适的试点项目首先与一个团队合作可以让您有机会学习如何实现数据网格的宝贵经验,随着时间的推移,这将是您在整个组织中采用该体系结构所必需的. 对于试点项目,关注具有清晰、可量化业务价值的数据产品. 选择需求或价值不明确的数据产品是没有意义的. 但是,也不要野心太大. 避免试点改革关键的财务报告可能是个好主意.
  • 不要等待完美的平台; 考虑一下如何实现数据网格,就好像你正在改造一所房子,而你住在里面. 而不是拆除现有的结构,从头开始, 您希望逐个房间地查看并逐步更新您的数据体系结构, 突显出 金色的途径 供领域团队遵循.
  • 为自己定义自助服务在组织中定义面向领域的体系结构和自助服务数据基础结构取决于您的业务需求.例如, 一个组织通过帮助数据生产者通过Fivetran获取数据来提供自助服务. 另一项优先考虑的是让领域控制谁可以访问数据,并简化数据可视化标准. 
  • 定义独立发展的领域:通常, 仍然会有一些跨域或共享域的数据将继续集中管理, 通常是在数据平台团队中, 服务跨越两个或更多域的企业用例.  一旦确定了这些定义域, 为领域团队配备相关的跨职能人才和领域专业知识,使其能够独立发展
  • 专注于构建值得信赖的数据产品:通常, 推荐一个正规滚球网站已经看到数据组织倾向于清晰的标准,而不是沉重的治理框架, 重点是值得信赖和可发现的数据产品. 

不要忘记数据的可观察性

对于数据行业中的许多人来说,使用数据网格体系结构的巨大潜力既令人兴奋又令人生畏. 事实上, 推荐一个正规滚球网站的一些客户担心,数据网格不可预见的自主性和民主化会引入与数据发现和健康相关的新风险, 以及数据管理.

考虑到数据网格的相对新奇性, 这是一个合理的担忧, 但我会鼓励好奇的人去阅读细则. 而不是引入这些风险, 数据网格实际上要求数据具有可伸缩的、自服务的可观察性.

事实上,域名不能真正 自己的 他们的数据,如果他们没有 数据可观测性. 根据Zhamak的说法,任何良好的数据网格所固有的这种自助服务能力包括:

  • 对静态和动态数据进行加密
  • 数据产品版本控制
  • 数据产品模式
  • 数据产品发现、目录注册和发布
  • 数据治理和标准化
  • 数据生产沿袭
  • 数据产品监控、警报和日志记录
  • 数据产品质量指标

当包装在一起时, 这些功能和标准化提供了一个健壮的可观察性层. 数据网格范式也要求有一个标准化的, 单个域处理这些可观察性租户的可伸缩方式, 允许团队回答这些问题以及更多的问题:

  • 我的数据新鲜吗??
  • 我的数据损坏了吗??
  • 如何跟踪模式更改?
  • 管道的上游和下游依赖关系是什么?

如果你能回答这些问题, 您可以放心,您的数据是完全可观察的-并且可以信任.

数据网格的(近期)未来

数据网格创建者Zhamak Dehghani的LinkedIn帖子宣布了下一个数据.

数据网格创建者Zhamak Dehghani刚刚让数据世界沸腾起来 她的声明 她期待已久的创业 nextdata, ,旨在增强数据开发人员的能力, 用户和所有者拥有愉快的体验,其中数据产品是一流的原始产品, 内置信任.”

数据网格继续火热,推荐一个正规滚球网站的首席执行官Barr预测它将成为 2023年十大最热门的数据工程趋势. 看看团队如何在实现完全去中心化的数据网格和仍然包含某种数据网格的架构之间取得平衡,这将是一件很有趣的事情 卓越中心.

有兴趣了解更多关于数据网格的知识? 除了扎马克和麦克斯的资源, 看看推荐一个正规滚球网站最喜欢的一些关于这个数据工程新星的文章:

你的公司正在构建一个数据网吗? 接触 巴尔摩西和Lior Gavish 用你的经验,技巧和痛点. 推荐一个正规滚球网站很乐意听到你的消息! 或者在下面预约时间与推荐一个正规滚球网站交谈.

对“什么是数据网格-以及如何不将其网格化”的8个回复

  1. 肖恩·戈登 说:

    我读datamesh已经快一年了,据我所知, 这是一种哲学, 不是产品或任何技术. Starburst采用这个术语来指代他们的数据连接器生态系统. 数据湖似乎真的解决了描述中提出的问题, 但我也认为,问题的核心是你描述的是一个管理不善的组织,没有好的领导,没有明确的道路,没有允许每个人做自己的事情,现在他们有一大堆垃圾需要修复. 我认为数据网格哲学是一个需要修复的糟糕设计的创可贴. 在我看来,告诉数据团队他们需要将数据存储更改为pub/sub类型的架构并不能解决任何问题. 围绕这一概念重新配置一切所需的工作量远远大于解决潜在问题.

  2. Jaspreet 说:

    总结一下我的理解

    数据网格是通过使用数据产品(数据集市)中的数据基础设施来分散管理不同的数据源 , Microservices API , 流数据等)通过使用数据管道由不同的域所有者拥有和管理.

    -这有助于跨组织的不同领域之间的数据共享更加可行,并且还增加了随着业务领域的变化而更改数据网格的灵活性,并提供了在添加/删除领域方面的可扩展功能,以及通过修改底层数据基础设施来实现更快处理的技术增强

    如果我的理解不正确,请随时添加删除

  3. 将知更鸟 说:

    贾斯普蕾特,没错! 通过将数据管理分散到不同的领域团队, 你可以更好地利用他们的领域知识, 专业知识, 以及敏捷性,为业务提供更快、更有意义的见解.

  4. Vamshi 说:

    谁在数据网概念中拥有底层平台/存储层的责任? 由领域团队或常规数据平台团队拥有是好的吗?

    • 迈克尔Segner 说:

      根据传统的数据网格原则,领域团队拥有底层平台/存储层(这可能导致一些重复)。, 然而,有许多团队采用了“数据网格”结构,平台团队拥有一个更集中的平台。.

  5. 马克斯·马文 说:

    我认为数据领域与数据主题领域几乎相同. e.g. 客户、销售、产品等.. 那么,为什么不放弃从一个集中的团队中为不同主题领域的所有者构建数据管道的责任呢? 对于已经在数据仓库或数据湖上进行了大量投资并花费了数年时间来构建它的组织来说,这不是更便宜的选择吗.

  6. ForHave 说:

    我不确定数据网格是什么,但我也不确定我是否需要一个.

    • 您可以像考虑应用程序的微服务一样考虑数据的数据网格. 这样做的目的是为了摆脱由于单个COE(卓越中心)试图支持跨多个业务单元的交付而导致数据处理管道失去速度时形成的单一数据沼泽. 数据网格是一个术语,用于将这个庞大的数据湖分解成几个更小的湖,这些湖可以通过称为数据产品的质量控制接口访问彼此的数据. 如果你的公司太小,目前还没有遇到这个问题, 那么Data Mesh绝对不适合你. 如果你感受过痛苦, 或者作为IT组织末端的业务用户无法支持您的需求, 或者可怜的IT人员拼命工作,为比你应该做的更多的BU提供服务,并且没有得到所有深夜的爱, 那么数据网格可能是需要考虑的东西.

留言回复

您的电子邮件地址将不会被公布. 必填项被标记 *