在 AWS 上设计符合组织愿景的数据网格架构

由 Claudia Chitu、Spyridon Dosis 和 Srikant Das 于 2024 年 1 月 22 日发表在 Amazon Athena，AWS 大数据，客户解决方案 永久链接 [评论(https//awsamazoncom/blogs/bigdata/designadatameshonawsthatreflectstheenvisionedorganization/#Comments)]

关键要点 Acast 采用分散式数据网格架构以解决数据管理挑战，促进组织成长。 透过 AWS 服务，Acast 打造一个自助数据平台，减少了数据冗余。 数据作为产品的理念帮助提升了数据使用效率及用户满意度。 提升组织内部数据治理及安全性，强化业务洞察能力。

重要讯息

此次发文由 Claudia Chitu 和 ACAST 的 Spyridon Dosis 共同撰写。创立于2014年的 ACAST 是全球领先的独立播客公司，致力于提升播客创作者和广告商的收听体验。透过 AWS 云端服务，该公司能够建设基于数据的产品并提升工程最佳实践。为了应对增长和获利带来的挑战，Acast 的技术团队采用了去中心化的数据网格架构。

白鲸加速器免费版本

问题概述

随著业务的快速增长，Acast 面临了一个全球普遍存在的挑战。公司内部拥有多个不同的业务单元和大量数据。现有的单体架构和集中的数据基础设施无法满足不断增长的数据需求，导致数据可访问性差、数据孤岛和数据管理效率低下。他们的主要目标是改善从业务需求出发的端到端用户体验。

Acast 需要解决这些问题，达到操作上的扩展。举例来说，他们希望克服单体结构所带来的挑战，并缩短产品团队和最终用户获得价值的时间。值得一提的是，Acast 拥有其他产品和技术团队，包括不拥有 AWS 账户的业务团队。

Acast 有变化多端的产品团队，不断通过合并、拆分和新增成员来增长。在过去两年中，团队数量在 10 到 20 之间，每个团队由 4 到 10 人组成。每个团队拥有至少两个 AWS 账户，而部分团队则拥有高达十个账户。这些账户所生成的数据大部分用于商业智能BI目的和在 Amazon Athena 上，每天有数百名业务用户使用。

Acast 实施的解决方案是一个基于 AWS 的数据网格，该方案反映了组织架构，而不是明确的架构决策。根据 逆康威操作，Acast 的技术架构与其业务架构呈现同构。这一点将在下文中进一步讨论，尤其是关于用于管理的 AWS 身份与访问管理IAM角色，其中一个角色专门针对业务部门。

成功参数

Acast 成功启动和扩展了一个以团队和领域为导向的数据产品及其相应基础设施，这导致用户在获取洞察上减少了摩擦，并且提高了满意度。

实施的成功意味著他们对数据基础设施、数据管理和商业结果的多个方面进行评估。他们将指标和指标分类为以下几个类别：

分类描述数据使用明确了解谁在消费哪些数据来源，并与用户进行讨论以确保数据访问更简单和结构化。数据治理服务级目标使团队能快速通知数据问题，进一步增强了所有权。数据团队生产力工程回顾显示团队对于自主性做出与其数据领域决策的好处表示赞赏。成本和资源效率Acast 观察到数据冗余的减少，并在某些账户中实现了成本降低例如，通过跨账户读取数据消除 100 的数据副本。

数据网格概述

数据网格是一种社会技术方法，通过使用以领域为导向的自助设计来构建去中心化数据架构，并借鉴了 Eric Evans 的领域驱动设计理论和 Manuel Pais 及 Matthew Skelton 的团队拓朴理论。理解数据网格的背景非常重要，因为这有助于理解后续的技术细节及如何将文中讨论的概念融入数据网格的更大框架中。

回顾 Acast 的实施，数据网格概念基于以下原则：

它以领域为驱动，而不是将管道作为首要关注。它将数据视为产品。它是一个优质产品，能够令用户满意数据可靠，文档可用，易于消费。它提供联邦计算治理和去中心化所有权一个自助数据平台。

领域驱动架构

在 Acast 的方法中，团队根据领域拥有运营和分析数据集，直接从数据生产者读取数据，通过 API 或程序性方式从 Amazon S3 存储或使用 Athena 作为 SQL 查询引擎。例如，以下图示显示了 Acast 的一些领域。

如图所示，某些领域与其他领域的操作或分析端点之间是松散耦合的，拥有不同的所有权。一些领域之间可能存在较强的依赖关系，这是出于业务需要例如，一些播客制作人也可能是广告商，同时为自己的节目创建赞助创意并运行广告活动。

数据作为产品

将数据视为产品意味著三个主要组件：数据本身、元数据以及相关的代码和基础设施。在这一方法中，负责生成数据的团队被称为 生产者。这些生产者团队对其消费者有深入了解，知道其数据产品是如何被使用的。生产者计划的任何变更都会提前通知所有消费者。这种主动通知确保了下游流程不会受到影响，使消费者有足够的时间准备和适应即将到来的变更，保持顺畅的工作流程。生产者并行运行初始数据集的新版，个别通知消费者，并与他们讨论何时开始使用新版本数据集。在所有消费者都使用新版本时，生产者将初始版本设置为不可用。

数据模式是根据团队之间共享文件的共识格式推断的，在 Acast 的情况下是 Parquet。数据可以以文件、批处理或流事件的形式共享等。每个团队都有自己的 AWS 账户，作为独立和自主的实体拥有自己的基础设施。为了进行编排，他们使用 AWS Cloud Development KitAWS CDK作为基础设施即代码IaC，并使用 AWS Glue 数据目录进行元数据管理。用户还可以向生产者提出改善数据呈现方式或通过添加新数据点来丰富数据的请求，以生成更高的商业价值。

每个团队拥有一个 AWS 账户和来自 Athena 的数据目录 ID，从而通过一个分布式数据湖的视角来看待整个架构，该数据湖位于 Amazon S3 之上，并有一个共同的目录映射所有账户的目录。

同时，每个团队也可以将其他目录映射到自己的账户，并使用自己生成的数据以及来自其他账户的数据。除非数据是敏感的，否则数据可以以自助方式通过程序访问或通过 AWS 管理控制台 访问，而不需要依赖数据基础设施工程师。这是一种领域无关的共享自助数据方式。产品发现通过目录登记进行。借助少数经公司共同同意和采纳的标准来实现互操作性，Acast 解决了数据孤岛及数据共享的摩擦。

通过这一原则，团队获得了数据安全、可信和准确的保证，适当的访问控制在每个领域级别进行管理。此外，在中央账户上，界定了不同类型权限和访问的角色，使用 AWS IAM 身份中心 的权限。所有数据集的发现都可以从一个中央账户进行。下图说明了其如何设置，其中两个 IAM 角色被视为两种类型的用户消费者群组：一个对限制性数据的访问有限制，另一个对非限制性数据有访问权。

Acast 如何解决高对齐和松散耦合的架构问题

下图显示了 Acast 团队组织数据和相互合作的概念架构。

Acast 利用 良好架构框架 对其中央账户进行分析，以改善其在云中运行分析工作负载的实践。透过这一工具，Acast 更好地解决了监控、成本优化、性能和安全性的问题。它帮助他们了解可以改善的工作负载区域，以及如何应对常见问题，并自动化地解决这些问题，同时定义 KPI。这为他们节省了以往需要更长时间才发现的学习时间。Acast 的信息安全官 Spyridon Dosis 表示：我们很高兴 AWS 总是提前推出工具，这使得配置、评估和审查多账户设置成为可能。这对于我们在去中心化组织中工作是一个很大的优势。Spyridon 还表示：我们非常重视 AWS 的安全预设例如 S3 存储桶的默认加密这一概念。

在架构图中，我们可以看到每个团队都可以作为数据生产者，除了拥有中央账户的团队，该账户作为中央数据平台，整合多个领域的信息以描绘完整的业务图景。所有其他团队可以成为数据生产者或数据消费者。他们可以连接至中央账户，通过跨账户的 AWS Glue 数据目录发现数据集，并在 Athena 查询编辑器或 Athena 笔记本中进行分析，或者将目录映射到他们自己的 AWS 账户。对中央 Athena 目录的访问是通过 IAM 身份中心实现的，并且开放数据与限制数据能够分开访问。

对于非敏感数据开放数据，Acast 使用一个模板，使数据集默认对整个组织开放以供查阅，使用条件来提供组织分配的 ID 参数，示例如下：

json{ Version 20121017 Statement [ { Effect Allow Principal Action [ s3GetObject s3GetBucket s3List ] Resource [ arnawss3DOCEXAMPLEBUCKET arnawss3DOCEXAMPLEBUCKET/ ] Condition { StringEquals { awsPrincipalOrgID ORGIDNUMBER } } } ]}

在处理如财务等敏感数据时，团队使用协作数据管理员模型。数据管理员与请求者一起评估针对预期用例的访问正当性，并共同确定适当的访问方式以满足需求，同时保持安全性。这可能包括 IAM 角色、服务账户或者特定的 AWS 服务。这种方法使得没有 AWS 账户的业务用户能够独立访问和分析所需的信息。通过为 AWS Glue 资源和 S3 存储桶授权 IAM 政策，Acast 提供了自助能力，同时通过人工审查对敏感数据进行治理。数据管理员角色对理解除用例、评估安全风险和促进通过分析洞察加速业务的访问大有帮助。

在 Acast 的场景中，并不需要粒度的按行或按列的访问控制，所以这一方法是足够的。不过，其他组织可能需要对敏感数据栏位进行更细致的治理。在这些情况下，像 AWS Lake Formation 这样的解决方案可以实施所需的权限，同时仍然提供自助数据访问模式。有关更多信息，请参阅 使用 AWS Lake Formation 和 AWS Glue 设计数据网格架构。

同时，各团队可以直接从其他生产者读取数据，无论是从 Amazon S3 中还是通过 API，最小化了依赖性，提高了开发和交付的速度。因此，一个账户可以并行作为生产者和消费者。每个团队都是自主的，对自己的技术堆栈负责。

额外学习

Acast 从中学到了什么？到目前为止，我们探讨了架构设计是组织结构的结果。由于技术组织由多个跨功能团队组成，并且很容易启动一个新团队，遵循数据网格的共同原则，Acast 学到这并不总是顺利的。设置 AWS 中的全新账户，团队也会经历相同