Novo Nordisk 如何在 AWS 上构建现代数据架构

Original URL：https://aws.amazon.com/blogs/big-data/how-novo-nordisk-built-a-modern-data-architecture-on-aws/

Novo Nordisk 是一家领先的全球制药公司，该公司生产拯救生命的药物，每天救助超过 3400 万名患者。他们在开展业务时坚持自己的三条基本原则，即他们必须努力实现环境可持续性、社会可持续性和财务可持续性。将 AWS 和数据结合使用可帮助他们实现所有这些目标。

数据贯穿于 Novo Nordisk 的整个价值链。从基础研究、生产线、销售和营销、临床试验、药物警戒到面向患者的数据驱动型应用程序。因此，奠定坚实的基础，以能够提供最大价值的方式存储、保护和使用数据，这是改进业务成果的核心驱动因素之一。

我们与 AWS Professional Services 协作，使用现代化数据架构来构建数据和分析解决方案。Novo Nordisk 与 AWS Professional Services 之间的协作是一种具有战略意义的长期密切互动，这两家企业的开发人员多年来一直紧密合作。数据和分析环境围绕数据网格的核心原则而构建，即数据域所有权去中心化、数据即产品、自助服务数据基础设施和联合计算治理。这使环境用户能够通过使用数据来加快实现最佳业务成果。我们将这一原则与进化型架构中的要素相结合，使得我们可以在 AWS 不断开发新服务和功能时适应不同的功能。

在本系列文章中，您将了解 Novo Nordisk 和 AWS Professional Services 如何构建数据和分析生态系统，从而在 PB 级的数据规模下加快创新速度：

• 在第一篇文章中，您将了解如何通过整体设计使各个组件能够以模块化方式组合起来。我们将深入探究如何基于数据网格架构来构建数据管理解决方案。
• 第二篇文章将讨论我们如何在整个解决方案所包含的各个系统之间建立信任网络。我们将演示如何使用事件驱动型架构，并结合使用基于属性的访问控制，确保在大规模环境中遵守权限边界。
• 在第三篇文章中，我们演示最终用户如何在不影响数据治理的情况下，通过所选工具使用数据。这包括如何配置 Okta、AWS Lake Formation 和 Microsoft Power BI，以便实现基于 SAML 的联合身份，将 Amazon Athena 用于企业商业智能（BI）活动。

符合制药公司要求的环境

作为一家制药企业，Novo Nordisk 必须遵守 GxP。GxP 是“Good x Practice”（良好实践）指南和法规的缩写，由欧洲药品管理局、美国食品和药物管理局等监管机构定义。这些指南旨在确保医药产品能够安全有效地用于其预期用途。在数据环境中，GxP 合规性涉及对决策制定和流程中使用的数据实施完整性控制，并用于指导如何实施变更管理流程，以确保长期持续实现合规性。

由于此数据环境为整个企业内的各个团队提供支持，因此，每个单独的数据所有者都必须保留对其数据的责任。这些特性旨在使数据所有者能够在管理数据时获得自主权和透明度，从而承担这一责任。这包括处理个人身份信息（PII）数据和其他敏感工作负载的能力。我们将在这篇文章中详细介绍为了提供对环境的可追溯性而添加的审计功能。

解决方案概览

完整的解决方案由一系列广泛的独立服务构成，这些服务协同工作，采用去中心化数据治理模型支持 PB 级的数据和分析。以下为该解决方案的示意图。

该架构分为三个独立的层：数据管理、虚拟化和使用。最终用户位于使用层，他们使用自己选择的工具。这是为了将尽可能多的 AWS 原生资源抽象为应用程序原语。使用层集成到虚拟化层中，后者将对数据的访问抽象化。虚拟化层的用途是在数据使用解决方案和数据管理解决方案之间进行转换。对数据的访问由我们所说的数据管理解决方案进行管理。在这篇文章的下文中，我们将讨论一种通用数据管理解决方案。此架构中的每个层都是相互独立的，仅依赖于明确定义的接口。

此架构的核心是将访问权限封装在 AWS Identity and Access Management（IAM）角色会话中。数据管理层侧重于为 IAM 角色提供正确的权限和治理，虚拟化层提供对该角色的访问权限，使用层则抽象化该角色在所选工具中的使用。

技术架构

整个架构中的三个层均有不同的责任，但没有单一的实施。可以将其视为抽象类。它们可以在具体的类中实施，在我们的例子中，它们依赖基本 AWS 服务和功能。我们来逐个了解这三个层。

数据管理层

数据管理层负责提供对数据的访问和治理。如下图所示，数据管理层中的最小构造是一个 Amazon Simple Storage Service（Amazon S3）存储桶和一个 IAM 角色的组合，该角色提供对 S3 存储桶的访问权限。此构造可以扩展，用于包含 Lake Formation 的精细权限、使用 AWS CloudTrail 进行的审计以及 AWS Security Hub 提供的安全响应功能。下图还显示，单个数据管理解决方案没有单一跨度。该解决方案可以跨许多 AWS 账户，由任意数量的 IAM 角色组合构成。

我们特意不在此图中说明这些角色的信任策略，因为它们是虚拟化层和数据管理层之间的协同责任。我们将在本系列的下一篇文章中详细介绍其工作方式。数据工程专业人员通常直接与数据管理层交互，他们在该层上整理和准备数据以供使用。

虚拟化层

虚拟化层的用途是跟踪谁能执行什么操作。它本身不具备任何功能，但可以将数据管理生态系统的需求转换到使用层，反之亦然。这样使得使用层上的最终用户能够根据自身权限，访问和操作一个或多个数据管理生态系统上的数据。该层从最终用户处抽象出有关数据访问的技术详细信息，例如权限模型、角色代入和存储位置。它拥有可与其他层交互的接口并强制执行抽象化逻辑。在六角形架构的情境中（请参阅 Developing evolutionary architecture with AWS Lambda（使用 AWS Lambda 开发进化型架构），接口层将充当域逻辑、端口和适配器。另外两个层是操作者。数据管理层将层的状态传达给虚拟化层，并反过来接收有关要信任的服务环境的信息。虚拟化层架构如下图所示。

使用层

使用层是数据产品的最终用户所处的位置。这可能是数据科学家、商业情报分析师或任何使用数据产生价值的第三方。对于此类架构而言，使用层必须具有基于挂钩的登录流程，以便在登录时修改应用程序中的授权。这是为了将 AWS 的特定要求转换到目标应用程序中。成功启动客户端应用程序中的会话后，将由应用程序本身来进行数据层抽象化，因为这将是应用程序特定的。这是另一个重要的分离操作，可将一些责任推送到去中心化的单元。许多现代软件即服务（SaaS）应用程序都支持这些内置机制，例如 Databricks 或 Domino Data Lab，而更传统的客户端应用程序（例如 RStudio Server）在这个方面提供的原生支持更有限。在缺少原生支持的情况下，可以向下转换到操作系统用户会话来启用抽象化。以下为使用层的示意图。

在按预期方式运用使用层时，用户不知道虚拟化层的存在。下图说明了数据访问模式。

模块化

采用六角形架构模式，以及将使用层和数据管理层委托给主要和次要操作者，所带来的主要优势之一意味着可以在发布了新功能而需要新解决方案时，更改或替换它们。这将提供一种中心辐射型模式，在这种模式下，许多不同类型的生产者/使用者类系统可以互连并同时联合工作。例如，当前在 Novo Nordisk 中运行的解决方案支持多个同步数据管理解决方案，并且在使用层上以同构方式公开。这包括一个数据湖、本文中介绍的数据网格解决方案和几个独立的数据管理解决方案。它们对多种类型的使用应用程序公开，从自定义托管应用程序、自托管应用程序到 SaaS 产品等。

数据管理生态系统

为了扩大数据的使用并提高自由度，Novo Nordisk 与 AWS Professional Services 共同构建了一个名为 Novo Nordisk Enterprise DataHub（NNEDH）的数据管理和治理环境。NNEDH 实施了去中心化的分布式数据架构和数据管理功能，例如企业业务数据目录和数据共享工作流。NNEDH 是前面介绍的概念性框架中的数据管理生态系统的一个示例。

去中心化架构：从集中式数据湖到分布式架构

Novo Nordisk 的集中式数据湖由来自全球 30 多个业务数据域的 2.3 PB 数据构成，可以为整个价值链中的 2000 多名内部用户提供服务。它已成功运行多年，是目前支持的数据管理生态系统之一。

在集中式数据架构中，将在一个中心位置（也就是托管在一个数据存储中的中央数据湖）复制、存储和处理每个数据域中的数据。这种模式在大规模下面临难题，因为它由中央团队保留数据所有权。在大规模环境中，这种模型减缓了向数据驱动型企业转型的历程，因为与该域关系最密切的专业人员并未充分获得数据的所有权。

下图显示了整体式数据湖架构。

在去中心化的分布式数据架构中，来自每个域的数据保存在域内，采用自己的数据存储和计算账户。在这种情况下，数据与域专家保持密切联系，因为他们最了解自己的数据，并且是围绕其数据构建的任何数据产品的最终所有者。他们经常与业务分析师密切合作来构建数据产品，因此，知道高质量的数据对其数据产品的使用者意味着什么。在这种情况下，数据责任也是去中心化的，每个域都有自己的数据所有者，由数据的真正所有者承担责任。但是，此模式可能不适合小规模应用，例如，一家只拥有一个业务部门和几十个用户的企业，因为它会增加 IT 团队在管理企业数据方面的开销。它更适合大型企业或寻求发展和扩大规模的中小型企业。

Novo Nordisk 数据网格架构如下图所示。

数据域和数据资产

要在整个企业中实现数据域的可扩展性，必须具有标准权限模型和数据访问模式。此标准的限制性不得过高，以免成在特定使用场景中成为阻碍因素，但应将其标准化，以便在数据管理层和虚拟化层之间使用相同的接口。

NNEDH 上的数据域通过称作环境 的构造实施。环境包含至少一个 AWS 账户和一个 AWS 区域。这是一个工作场所，数据域团队可以在其中工作和协作构建数据产品。它将 NNEDH 控制面板与域的数据和计算所在的 AWS 账户关联起来。数据访问权限也是在环境级别定义的，并由数据域的所有者管理。这些环境具有三个主要组件：数据管理和治理层、数据资产和用于数据处理的可选蓝图。

在数据管理和治理方面，数据域依赖 Lake Formation、AWS Glue 和 CloudTrail。这些组件的部署方法和设置已经跨数据域实现标准化。这样一来，NNEDH 控制面板就能以标准化方式对数据域进行连接和管理。

环境中每个域的数据资产都在一个数据集中进行整理，该数据集是用于构建数据产品的相关数据的集合。它包括技术元数据（例如，数据格式、大小和创建时间）和业务元数据（例如，生产者、数据分类和业务定义）。一个数据产品可以使用一个或多个数据集。它通过托管式 S3 存储桶和 AWS Glue Data Catalog 实施。

数据处理可通过不同的方式实施。NNEDH 为具有与数据资产的预定义连接的数据管道提供蓝图，从而加快数据产品的交付。数据域用户可以随意使用其域上的任何其他计算功能，例如，使用蓝图上未预定义的 AWS 服务，或者从在使用层中实施的其他分析工具访问数据集，如本文前面所述。

数据域角色和角色

在 NNEDH 上，数据域的权限级别通过预定义的角色进行管理，例如数据所有者、数据管理员、开发人员和读者。每个角色都与一个具有预定义权限级别的 IAM 角色关联。这些权限基于用户对这些角色的典型需求。不过，要使数据域具有更大的灵活性，可以根据需要自定义和扩展这些权限。

与每个角色关联的权限仅与数据域的 AWS 账户上允许的操作相关。对于有关数据资产的责任，对资产的数据访问由特定的资源策略而不是 IAM 角色管理。仅每个数据集的所有者或由该所有者委派的数据管理员能够授予或撤消数据访问权限。

在数据集级别，所需的角色是数据所有者。通常，他们与一个或多个担任数据产品经理的数据管理员密切合作。数据管理员是数据产品领域的相关数据主题专家，负责解释收集到的数据和元数据，以深度发掘业务洞察并构建产品。数据管理员帮助在每个数据域上的业务用户和技术团队之间建立联系。

企业业务数据目录

为了实现自由并使企业数据资产可供发现，实施了基于 Web 的门户数据目录。它针对在数据域上构建的数据集中的元数据，在单个存储库中构建索引，从而打破整个企业的数据孤岛。数据目录支持跨不同的域进行数据搜索和发现，并可实现数据共享的自动化和治理。

业务数据目录在企业内部实施数据治理流程。它确保了数据所有权 – 企业内部人员负责数据来源、定义、业务属性、关系和依赖项。

业务数据目录的核心构造是数据集。它是业务目录中的搜索单元，同时包含技术元数据和业务元数据。为了从结构化数据中收集技术元数据，它依靠 AWS Glue 爬网程序从最常用的数据格式（包括 CSV、JSON、Avro 和 Apache Parquet）中识别和提取数据结构。它提供数据类型、创建日期和格式等信息。业务用户可通过添加业务情境描述、标签和数据分类来丰富元数据。

数据集定义和相关元数据存储在 Amazon Aurora Serverless 数据库和 Amazon OpenSearch Service 中，使您能够对数据目录运行文本查询。

数据共享

NNEDH 实施数据共享工作流，并支持使用 Lake Formation 在 AWS 账户之间进行对等数据共享。工作流如下所示：

1. 数据使用者请求对数据集的访问权限。
2. 数据所有者通过批准访问请求来授予访问权限。他们可以将访问请求的审批委派给数据管理员。
3. 在访问请求获得批准后，将向生产者账户的 Lake Formation 中的特定数据集添加新权限。

以下示意图显示了数据共享工作流。

安全与审计

Novo Nordisk 数据网格中的数据位于 Novo Nordisk 企业账户所拥有的 AWS 账户中。数据网格的配置和状态存储在 Amazon Relational Database Service（Amazon RDS）中。Novo Nordisk 安全架构如下图所示。

需要记录对 NNEDH 中数据的访问和编辑以供审计之用。我们需要能够指明数据的修改者、修改时间以及修改内容。此外，我们需要能够回答允许该人员当时进行修改的原因。

为了满足这些要求，我们使用以下组件：

• CloudTrail，用于记录 API 调用。我们专门为 S3 存储桶和对象启用了 CloudTrail 数据事件日志记录。通过激活日志记录功能，我们可以将对数据湖中任意文件所做的任何修改追溯到修改者。我们强制在 IAM 角色会话中使用源身份来确保用户的可追溯性。
• 我们使用 Amazon RDS 来存储数据网格的配置。我们记录针对 RDS 数据库的查询。通过结合使用该日志与 CloudTrail，我们能够回答为什么特定人员可以在特定时间修改 Amazon S3 中的某个文件的问题。
• Amazon CloudWatch，用于记录网格中的活动。

除了这些日志记录机制外，还使用以下属性创建 S3 存储桶：

• 使用 AWS Key Management Service（AWS KMS）和客户托管密钥，对存储桶进行服务器端加密
• Amazon S3 默认激活版本控制

对 NNEDH 中数据的访问是在组级别而不是单个用户级别控制的。该组对应于 Novo Nordisk 目录组中定义的组。为了跟踪数据湖中数据的修改者，我们使用了源身份机制，其说明见文章 How to relate IAM role activity to corporate identity（如何将 IAM 角色活动与企业身份相关联）。

小结

在这篇文章中，我们说明了 Novo Nordisk 如何构建现代化数据架构来加快数据驱动型使用场景的交付。它包括一个分布式数据架构（用于扩展以支持整个价值链中超过 2000 名内部用户对 PB 级数据的使用）和一个分布式安全和审计架构（用于处理环境中的数据责任和可追溯性以满足其合规性要求）。

本篇作者