这篇文章是与 Claudia Chitu 合作撰写的 来自 ACAST 的 Spyridon Dosis。
公司成立于2014， Acast 是世界领先的独立播客公司，致力于提升播客创作者和播客广告商的终极聆听体验。通过倡导独立、开放的播客生态系统，Acast 旨在利用播客蓬勃发展所需的工具和货币化来推动播客发展。
该公司使用 AWS 云服务来构建数据驱动的产品并扩展工程最佳实践。为了确保在增长和盈利阶段建立可持续的数据平台，他们的技术团队采用了去中心化的 数据网格架构.
在这篇文章中，我们讨论 Acast 如何通过采用数据网格的概念来克服大规模数据处理团队之间耦合依赖关系的挑战。
该问题
随着加速增长和扩张，Acast 遇到了引起全球共鸣的挑战。 Acast 发现自己拥有不同的业务部门以及整个组织生成的大量数据。现有的整体式集中式架构正在努力满足数据消费者不断增长的需求。数据工程师发现维护和扩展数据基础设施越来越具有挑战性，从而导致数据访问、数据孤岛和数据管理效率低下。一个关键目标是从业务需求出发，增强端到端用户体验。
Acast 需要应对这些挑战，以达到运营规模，这意味着全球范围内能够独立运营和提供价值的人数最多。在这种情况下，Acast 试图应对这种整体结构的挑战以及产品团队、技术团队和最终消费者的快速实现价值的挑战。值得一提的是，他们还有其他产品和技术团队，包括运营或业务团队，但没有 AWS 账户。
Acast 拥有数量不等的产品团队，通过合并现有团队、拆分团队、添加新人员或简单地创建新团队来不断发展。在过去的两年里，他们有 2-10 个团队，每个团队由 20-4 人组成。每个团队至少拥有两个 AWS 账户，最多 10 个账户，具体取决于所有权。这些帐户生成的大部分数据在下游用于商业智能 (BI) 目的和 亚马逊雅典娜，每天都有数百名企业用户使用。
Acast 实施的解决方案是在 AWS 上构建的数据网格。该解决方案反映了组织结构，而不是明确的架构决策。根据逆康威策略，Acast 的技术架构与业务架构表现出同构性。在这种情况下，业务用户可以通过数据网格架构更快地获得洞察并直接了解特定领域的所有者是谁，从而加快协作速度。当我们讨论 AWS 认证中使用的 AWS Identity and Access Management (IAM) 角色时，这一点将进一步详细说明，因为其中一个角色专用于业务组。
成功的参数
Acast 成功引导和扩展了一个新的面向团队和领域的数据产品及其相应的基础设施和设置，从而减少了收集见解的摩擦并提高了用户和消费者的满意度。
实施的成功意味着评估数据基础设施、数据管理和业务成果的各个方面。他们将指标和指标分为以下几类：
- 数据用量 – 清楚地了解谁在消费什么数据源，通过消费者和生产者的映射来具体化。与用户的讨论表明，他们更高兴能够以更简单的方式更快地访问数据、更结构化的数据组织以及对生产者的清晰映射。在推进数据驱动文化（数据素养、数据共享和跨业务部门协作）方面已经取得了很多进展。
- 数据治理 – 通过其服务级别对象说明数据源何时可用（以及其他详细信息），团队知道要通知谁，并且在出现数据延迟或其他数据问题时可以在更短的时间内通知。随着数据管理员角色的到位，所有权得到了加强。
- 数据团队生产力 – 通过工程回顾，Acast 发现他们的团队非常重视就其数据域做出决策的自主权。
- 成本和资源效率 – 这是 Acast 观察到的一个领域，通过在启用扩展的同时跨账户读取数据，数据重复减少，从而降低成本（在某些账户中，100% 删除数据副本）。
数据网格概述
数据网格是一种社会技术方法，通过使用面向领域的自助设计（从软件开发的角度来看）来构建分散的数据架构，并借用了 Eric Evans 的领域驱动设计理论以及 Manuel Pais 和 Matthew Skelton 的理论团队拓扑理论。建立上下文来理解什么是数据网格非常重要，因为它为后续的技术细节奠定了基础，并且可以帮助您理解本文中讨论的概念如何适应更广泛的数据网格框架。
在深入了解 Acast 的实现之前回顾一下，数据网格概念基于以下原则：
- 它是领域驱动的，而不是管道作为首要关注点
- 它将数据作为产品
- 这是一个让用户满意的好产品（数据可信、文档可用、易于使用）
- 它提供联合计算治理和去中心化所有权——一个自助数据平台
领域驱动架构
在 Acast 拥有运营和分析数据集的方法中，团队的结构基于域的所有权，通过 API 或以编程方式从 Amazon S3 存储或使用 Athena 作为 SQL 查询引擎直接从数据生产者处读取数据。下图显示了 Acast 域的一些示例。
如上图所示，某些域与其他域的操作或分析端点松散耦合，具有不同的所有权。其他人可能对业务有更强的依赖性，这是预期的（一些播客也可以是广告商，为自己的节目创建赞助创意并开展活动，或使用 Acast 的软件即服务来交易广告）。
数据作为产品
将数据视为产品需要三个关键组件：数据本身、元数据以及相关代码和基础设施。在这种方法中，负责生成数据的团队被称为 生产者。这些生产者团队对消费者有深入的了解，了解他们的数据产品是如何利用的。数据生产者计划的任何更改都会提前传达给所有消费者。这种主动通知可确保下游流程不会中断。通过提前向消费者提供通知，他们有足够的时间准备和适应即将到来的变化，保持平稳、不间断的工作流程。生产者并行运行初始数据集的新版本，单独通知消费者，并与他们讨论开始使用新版本所需的时间范围。当所有消费者都使用新版本时，生产者使初始版本不可用。
数据模式是从团队之间共享文件的通用商定格式推断出来的，在 Acast 中就是 Parquet。数据可以在文件、批处理或流事件等中共享。每个团队都有自己的 AWS 账户，作为独立自主的实体，拥有自己的基础设施。对于编排，他们使用 AWS云开发套件 (AWS CDK) 用于基础设施即代码 (IaC) 和 AWS胶水 用于元数据管理的数据目录。用户还可以向生产者提出改进数据呈现方式或用新数据点丰富数据以产生更高商业价值的请求。
由于每个团队都拥有一个 AWS 账户和来自 Athena 的数据目录 ID，因此可以通过 Amazon S3 之上的分布式数据湖的镜头轻松地看到这一点，并使用一个映射所有账户的所有目录的通用目录。
同时，每个团队还可以将其他目录映射到自己的帐户并使用自己的数据，这些数据与其他帐户的数据一起生成。除非是敏感数据，否则可以通过编程方式或从 AWS管理控制台 以自助服务的方式，无需依赖数据基础设施工程师。这是一种与领域无关的共享数据自助服务方式。产品发现是通过目录注册进行的。出于互操作性的目的，Acast 仅使用了整个公司普遍同意和采用的少数标准，解决了交换数据或使用与领域无关的数据时的分散孤岛和摩擦问题。
遵循这一原则，团队可以确保数据安全、可信和准确，并在每个域级别管理适当的访问控制。此外，在中央帐户上，为不同类型的权限和访问定义了角色，使用 AWS IAM 身份中心 权限。所有数据集都可以从一个中央帐户发现。下图说明了它的检测方式，其中两种类型的用户（消费者）组承担两种 IAM 角色：一种可以访问有限数据集（即受限数据），另一种可以访问非受限数据。对于服务帐户，还有一种方法可以承担这些角色中的任何一个，例如数据处理作业所使用的帐户 适用于 Apache Airflow 的 Amazon 托管工作流 例如（亚马逊 MWAA）。
Acast 如何解决高度对齐和松散耦合的架构
下图显示了 Acast 团队如何组织数据和相互协作的概念架构。
阿卡斯特使用了 架构良好的框架 帮助中央账户改进在云中运行分析工作负载的实践。通过该工具的镜头，Acast 能够更好地进行监控、 成本优化、性能和安全性。它帮助他们了解可以改善工作量的领域、如何通过自动化解决方案解决常见问题，以及如何衡量成功、定义 KPI。这节省了他们获得知识的时间，否则他们需要更长的时间才能找到这些知识。 Acast 信息安全官 Spyridon Dosis 表示：“我们很高兴 AWS 始终领先于发布支持多账户设置配置、评估和审查的工具。这对我们来说是一个很大的优势，因为我们在一个去中心化的组织中工作。” Spyridon 还补充道，“我们重视的一个非常重要的概念是 AWS 安全默认设置（例如 S3 存储桶的默认加密）。”
在架构图中，我们可以看到，除了拥有中心账户的团队之外，每个团队都可以成为数据生产者，中心账户作为中心数据平台，对多个领域的逻辑进行建模，绘制完整的业务图景。所有其他团队都可以是数据生产者或数据消费者。他们可以连接到中央账户并通过跨账户 AWS Glue 数据目录发现数据集，在 Athena 查询编辑器或 Athena 笔记本中对其进行分析，或者将目录映射到他们自己的 AWS 账户。对中央 Athena 目录的访问是通过 IAM Identity Center 实现的，具有开放数据和受限数据访问的角色。
对于非敏感数据（开放数据），Acast 使用一个模板，其中数据集默认向整个组织开放以供读取，并使用条件提供组织分配的 ID 参数，如以下代码片段所示：
在处理财务等敏感数据时，团队使用协作数据管理员模型。数据管理员与请求者合作评估预期用例的访问理由。他们共同确定适当的访问方法来满足需求，同时保持安全性。这可能包括 IAM 角色、服务账户或特定 AWS 服务。这种方法使技术组织外部的业务用户（这意味着他们没有 AWS 账户）能够独立访问和分析他们所需的信息。通过通过 IAM 策略授予对 AWS Glue 资源和 S3 存储桶的访问权限，Acast 提供自助服务功能，同时仍然通过人工审核管理敏感数据。数据管理员的角色对于理解用例、评估安全风险以及最终促进通过分析洞察加速业务的访问非常有价值。
对于 Acast 的用例，不需要精细的行级或列级访问控制，因此该方法就足够了。然而，其他组织可能需要对敏感数据字段进行更细粒度的治理。在这些情况下，解决方案如 AWS湖形成 可以实现所需的权限，同时仍然提供自助数据访问模型。欲了解更多信息，请参阅 使用 AWS Lake Formation 和 AWS Glue 设计数据网格架构.
同时，团队可以直接从 Amazon S3 或通过 API 读取其他生产者的信息，将依赖性保持在最低限度，从而提高开发和交付的速度。因此，一个账户可以同时是生产者和消费者。每个团队都是自治的，并对自己的技术堆栈负责。
额外的学习内容
阿卡斯特学到了什么？到目前为止，我们已经讨论了架构设计是组织结构的影响。由于技术组织由多个跨职能团队组成，并且遵循数据网格的通用原则很容易引导一个新团队，因此 Acast 了解到这并不是每次都能顺利进行。为了在 AWS 中建立一个全新的账户，团队会经历相同的过程，但考虑到他们自己的特殊性，略有不同。
这可能会产生一定的摩擦，并且很难让所有数据生产团队都达到数据生产者的高度成熟度。这可以通过这些跨职能团队的不同数据能力来解释，而不是专门的数据团队。
通过实施去中心化解决方案，Acast 调整其团队以适应不断变化的业务需求，从而有效地应对了可扩展性挑战。这种方法确保了高度解耦和对齐。此外，他们还加强了所有权，显着减少了识别和解决问题所需的时间，因为上游源很容易知道，并且可以通过指定的 SLA 轻松访问。数据支持查询量减少了 50% 以上，因为业务用户能够更快地获得洞察。值得注意的是，他们成功消除了之前仅为了满足下游请求而复制的数十 TB 的冗余存储。这一成就是通过实施跨账户读取而实现的，从而消除了这些管道的相关开发和维护成本。
结论
Acast 使用逆康威策略并采用 AWS 服务，其中每个跨职能产品团队都有自己的 AWS 账户，以构建数据网格架构，从而实现可扩展性、高所有权和自助数据消费。这对公司来说效果很好，考虑到如何处理数据所有权和运营，以满足他们的工程原则，从而使数据网格成为一种效果，而不是故意的意图。对于其他组织，所需的数据网格可能看起来有所不同，并且该方法可能有其他学习内容。
总而言之，一个 AWS 上的现代数据架构 让您能够在不影响性能的情况下，以低成本高效构建数据产品和数据网格基础设施。
以下是一些可用于在 AWS 上设计所需数据网格的 AWS 服务示例：
作者简介
克劳迪娅·奇图 是一位数据策略师，也是分析领域有影响力的领导者。她专注于使数据计划与组织的总体战略目标保持一致，利用数据作为长期规划和可持续增长的指导力量。
斯吡啶酮剂量 是 Acast 的信息安全专家。 Spyridon 支持组织以安全的方式设计、实施和运营其服务，保护公司和用户的数据。
斯里坎特·达斯 是 Amazon Web Services 的加速实验室解决方案架构师。他在大数据分析和数据工程方面拥有超过 13 年的经验，喜欢构建可靠、可扩展且高效的解决方案。工作之余，他喜欢旅行并在社交媒体上写下自己的经历。
