category
这篇文章是软件工程师、数据工程师、数据科学家、MLOps工程师、软件开发人员和数据库架构师的必读书目，他们有兴趣了解有关整体数据架构和分布式数据网格的更多信息。
介绍
数据管理架构-控制组织如何收集、存储、保护、安排、集成和使用数据。一个好的数据管理架构-可以清晰地了解数据的各个方面，以及企业如何充分利用数据实现业务增长和盈利。相反，糟糕的数据管理架构会导致不一致的数据集、不兼容的数据仓库和数据质量问题，使数据变得毫无价值或影响组织运行分析、数据仓库（DW）和商业智能（BI）活动的能力，尤其是大数据。
传统上，大多数组织倾向于从一个中央数据团队和一个单一的数据管理架构开始，在该架构中，所有数据操作都在一个单一、集中的数据平台上进行。虽然单片数据架构相对容易设置，可以处理小规模的数据分析和存储而不会降低性能，但随着时间的推移，情况会变得越来越糟。此外，随着数据量和需求的增加，中央数据管理团队往往成为瓶颈。
由Zhamak Dehghani介绍，分布式数据网格提供了一种协调并希望解决与以前的数据架构相关的挑战的方法，这些挑战通常会受到数据消费者和生产者之间的数据标准化挑战的阻碍。分布式数据网格推动我们走向更强大、更敏捷、更精简、多功能的团队和领域驱动的业务结构。它以分散的方式结合了最佳的数据管理方法，同时维护数据即产品的观点、自助服务用户访问、域意识和治理。
这篇文章将帮助读者了解整体数据架构、与整体数据架构相关的挑战，以及分布式数据网格如何帮助组织将其分析数据转化为产品，并构建高度可扩展、弹性和数据驱动的应用程序。目标受众是软件工程师、数据工程师、数据科学家、MLOps工程师、软件开发人员和数据库架构师，他们对整体数据架构和分布式数据网格感兴趣。
单片数据结构
单片数据架构-是一个框架，应用程序数据从一个集中的数据存储库中存储、转换、操作、消费和管理e.t.c。单片数据架构由一个庞大的平台团队管理，适用于业务领域相对简单且数据环境不不断变化的小型组织，但它们对不断发展的工程团队提出了若干挑战。让我们来看看其中的一些挑战。
第一个问题是单片数据架构不能无限扩展，大多数单片数据库根本无法自动扩展。随着应用程序工作量和数据量呈指数级增长，单一数据库逐渐变得缓慢、昂贵和难以维护。由一个中央团队管理的在一个地方使用和协调无处不在的数据的能力也会降低，因为组织的用例、多个数据源和数据消费者都在快速而广泛地变化。
其次，单片数据库通常具有高延迟和吞吐量，这自然是由应用程序中不同的断开连接的团队和方法并发的数据库读/写引起的。对于单片数据架构，在不改变整个数据管道的情况下响应新需求也是一项挑战。
第三，单片数据架构缺乏模块化，并且受到技术同质化的影响。当单个数据库出现故障或无响应时，它会影响整个应用程序并停止所有与数据库相关的活动。此外，如果工程团队被迫为一个应用程序采用一个数据库，那么创新和实验的空间就不大了。
最终，一个单一的数据架构自然会导致住院数据消费者、断开连接的数据生产者和积压的工程团队，他们背负着沉重的技术债务，在一个变化动态、企业需要快速创新的敏捷世界中努力奋斗。
现在您了解了单片数据架构的含义和局限性。现在我们来看一个更优化的数据架构，它主要解决与单片架构相关的挑战。
分布式数据网格
分布式数据网格高度分散，将数据视为产品，并支持分布式“特定领域数据所有者”，负责以易于消费、用户友好的方式处理自己的数据产品和管道，同时增强不同位置分布式数据之间的通信。在许多方面，分布式数据网格是微服务的平台版本。
工程团队可以通过将整个数据架构分解为更小、面向领域和更分散的组件，并让不同的团队管理每个领域，从而轻松实现分布式数据网格的可扩展性。这样，随着用例数量、数据源和访问模型的多样性的增加，可以更容易地进行扩展。它还允许团队构建高度可扩展的数据驱动应用程序，并有效地使用数据来更好地改进营销活动、降低成本、优化业务运营和做出更明智的决策。
分布式数据网格为数据所有者提供了更大的灵活性、更高的生产力和自主权。通过向最接近数据的人分配和分散责任，分布式数据网格降低了每个数据库的读/写速率，促进了数据创新，并消除了工程团队使用单个数据管道或数据存储满足每个数据消费者需求的负担。在分布式数据网格中，每个团队可以自由决定如何收集、组织、存储和使用数据。
第三，分布式数据网格具有自助式“基础架构即平台”和“联合计算治理”设计，可实现域自治，并为数据产品监控和治理、数据标准化、日志记录、警报、产品质量度量等提供不可知域、互操作和通用的方法。在分布式数据网格中，数据库故障的影响大大降低，每个团队都可以在不改变其他数据存储的情况下更改其数据平台、引入新功能和部署功能更新。
何时从单片数据网格过渡到分散数据网格
分布式数据网格不是适合所有组织和团队的灵丹妙药。正如您可以想象的那样，单片数据架构也不会消失。在从单一数据架构-过渡到分布式数架构-之前，组织需要做好功课，确保迁移对业务来说是明智的决定。
以下是组织及其团队在评估向分散数据网格过渡的准备情况时应提出的一些问题：
- 数据团队规模：数据团队中有多少数据工程师、数据分析师、数据科学家和产品经理？
- 数据大小：我们的数据量有多大？它的增长速度是多少？
- 数据种类和来源：我们有多少数据用例和来源？
- 数据瓶颈：数据团队多长时间忙于解决技术债务（从而减缓新数据产品的实施并将其变成瓶颈）？
- 交付周期：尽管我们的团队规模在增长，但每个团队的成员是否都不联系，或者他们是否缺乏领域知识？
- 数据域的数量：有多少职能团队依赖我们的数据存储做出决策，我们有多少数据驱动的产品和功能？
- 数据治理：我们的组织对数据治理有多大偏好？是否存在关于谁控制的政治内讧
通过提出这些问题并评估响应，组织可以决定是坚持传统的整体架构还是改用分散架构。总的来说，拥有基于微服务的应用程序、非常苛刻和复杂的数据基础设施要求、高数据量、众多数据源和域以及经常不堪重负的大型团队规模的公司将从数据网格中获益更多。否则，我认为去中心化的解决方案将是过度的。
结论
组织需要采用一种新的方法来大规模管理数据，以利用数据增强和改善生活和业务的各个方面。尽管过去的技术进步解决了数据量和数据处理计算的规模，但它们无法解决其他方面的规模问题，例如数据源的扩散、数据环境的变化、对变化的响应速度以及数据用户和用例的多样性。
数据网格架构解决了这些维度，并推动了组织结构和技术架构的新逻辑视图。正确实施的数据网格弥补了IT和业务领导者之间的差距，为他们提供了一个平台，以确保业务战略和技术协调一致，推动业务向前发展。通过从单一数据架构转向分布式数据网格，组织和工程团队可以从根本上缩短交付周期，更好地将数据用于多个用例，并构建可扩展的、数据驱动的应用程序，使其与当前向云原生架构和生态系统的转变保持一致。
