数据管理架构:单体数据架构与分布式数据网格比较 - enyo


这篇博文将帮助读者了解单体数据架构、与单体数据架构相关的挑战,以及分布式数据网格如何帮助组织将其分析数据转换为产品并构建高度可扩展、弹性和数据驱动的应用程序。目标受众是有兴趣了解更多关于单体数据架构和分布式数据网格的软件工程师、数据工程师、数据科学家、MLOps 工程师、软件开发人员和数据库架构师。
数据管理架构控制组织如何收集、存储、保护、排列、集成和使用数据。良好的数据管理架构可以清楚地了解数据的各个方面,以及企业如何充分利用数据以促进业务增长和盈利。相反,糟糕的数据管理架构会导致数据集不一致、数据孤岛和数据质量问题,从而使数据毫无价值或影响组织运行分析、数据仓库 (DW) 和商业智能 (BI) 活动的能力,尤其是大数据.
传统上,大多数组织更喜欢从一个中央数据团队和一个整体数据管理架构开始,其中所有数据操作都在一个单一的、集中的数据平台之间进行。虽然整体数据架构相对容易设置,并且可以在不降低性能的情况下处理小规模数据分析和存储,但随着时间的推移,事情会变得不堪重负。此外,随着数据量和需求的增加,中央数据管理团队往往会成为瓶颈。
Zha m ak Dehghani 引入:分布式数据网格提供了一种协调并有望解决与以前的数据架构相关的挑战的方法,这些挑战通常被数据消费者和生产者之间的数据标准化挑战所阻碍。分布式数据网格将我们推向更强大、敏捷、精简、多功能的团队和领域驱动 的业务结构。它以分散的方式结合了最佳的数据管理方法,同时保持了数据即产品的观点、自助用户访问、领域意识和治理。
 
单体数据架构
单体数据架构是一个框架,其中应用程序数据从单个集中式数据存储中存储、转换、操作、使用、管理等。单体数据架构由一个庞大的平台团队管理,适用于业务领域相对简单且数据格局不会不断变化的小型组织,但它们对不断发展的工程团队提出了一些挑战。让我们来看看其中的一些挑战。

  • 扩展性

首先担心的是单体数据架构不能无限扩展,而且大多数单体数据库根本不能自动扩展。随着应用程序工作负载和数据量呈指数级增长,单体数据库逐渐变得缓慢、昂贵且难以维护。对于具有快速和广泛变化的用例、多个数据源和数据消费者的组织来说,在一个地方使用和协调由一个中央团队管理的无处不在的数据的能力也会减弱。
  • 响应新需求

其次,单体数据库通常具有高延迟和高吞吐量,这是由于应用程序中不同的断开连接的团队和方法的并发数据库读取/写入而自然产生的。对于单体数据架构,在不改变整个数据管道的情况下响应新需求也具有挑战性。
  • 创新和实验的空间

第三,单体数据架构缺乏模块化,技术同质化。当单体数据库出现故障或无响应时,它会影响整个应用程序并停止所有与数据库相关的活动。此外,如果工程团队被迫为应用程序采用单一数据库,那么创新和实验的空间就不大了。
现在您了解了单体数据架构的含义和局限性。现在让我们看看一个更优化的数据架构,它主要解决与单体架构相关的挑战。
 
分布式数据网格
这是一种支持分布式高度分散的数据网格,将“数据即产品”视为产品,并支持分布式、“特定领域的数据所有者”,负责以易于使用、用户友好的方式处理自己的数据产品和管道,同时增强不同位置的分布式数据之间的通信。在许多方面,分布式数据网格是微服务的平台版本
通过将整个数据架构分解为更小、面向领域和更分散的组件,并让不同的团队管理每个领域,工程团队可以通过分布式数据网格轻松实现可扩展性。这样,随着用例数量、数据源和访问模型多样性的增加,可以更轻松地进行横向扩展。它还允许团队构建高度可扩展、数据驱动的应用程序并有效地使用数据来更好地改进营销活动、降低成本、优化业务运营并做出更明智的决策。
分布式数据网格具有自助式“基础设施即平台”和“联合计算治理”设计,可实现域自治,并为数据产品监控和治理、数据标准化提供与域无关、可互操作和通用的方法、日志记录、警报、产品质量指标等。在分布式数据网格中,数据库故障的影响大大降低,每个团队都可以更改其数据平台、引入新功能并部署功能更新,而无需更改其他数据存储。
 
何时从单体数据网格过渡到去中心化数据网格
分布式数据网格并不是适合所有组织和团队的灵丹妙药。可以想象,单体数据架构也不会消失。在从单体式数据架构过渡到分布式数据架构之前,组织需要做好功课并确保迁移对企业来说是一个明智的决定。
以下是组织及其团队在评估向分散数据网格过渡的准备情况时应提出的一些问题:
  • 数据团队规模:我们的数据团队有多少数据工程师、数据分析师、数据科学家和产品经理?
  • 数据大小:我们的数据有多大?它以什么速度增长?
  • 数据多样性和来源:我们有多少数据用例和来源?
  • 数据瓶颈:数据团队多久忙于解决技术债务(因此减缓新数据产品的实施并使其成为瓶颈)?
  • 交货时间:尽管我们的团队规模不断扩大,但每个团队的成员是否相互脱节,或者他们是否缺乏领域知识?
  • 数据域的数量:有多少职能团队依赖我们的数据存储做出决策,我们有多少数据驱动的产品和功能?
  • 数据治理:我们组织的数据治理有多少偏好?是否存在关于谁控制的政治内讧