Amazon Redshift 权威指南——通过数据共享实现协作

“数据共享是加速数字化转型的业务必需品。”
——Gartner

数据共享，是指让内部与外部利益相关方能够访问他们在自身数据系统中无法获取的信息。它让相关方可以直接访问生成方（producer）域内产生或采集并存储的数据，从而围绕共同的业务目标与优先级开展协作。数据组织正从传统的“大一统”式单体部门（往往导致平台迭代缓慢），转向由小型分布式团队构建模块化、快速迭代的数据产品的形态。这种“现代数据共同体”（Modern Data Community）是一种从单体数据组织向解耦、敏捷、小团队转变的组织与文化变革。

通过构建健壮的数据共享架构，数据与分析负责人可以在正确的时间获取正确的数据，从而交付有意义的业务成果。诸如美国国立卫生研究院（NIH）等机构已实施数据管理与共享政策，强调数据共享是研究流程的基础组成部分，以最大化公众获取研究结果的能力。

数据共享倡导在“数据所在之处、此时此刻”充分利用信息与资源，并据此采取行动。企业越早开始共享数据并用以指导决策，就越能为交付业务结果赢得时间。

“数据即新石油”一语出自英国数学家与数据科学家创业者 Clive Humby。过去二十年，这一点被反复验证：数据驱动业务决策、指导科研、支撑技术。组织收集与存储的数据空前丰富，但随之而来的挑战是：如何高效共享与协作使用这些数据。

在本章中，你将学习如何使用 Amazon Redshift 在海量数据上实现共享与协作。我们将首先给出“Amazon Redshift 数据共享概览”，并描述不同的“数据共享用例”。随后深入讲解 Redshift 的“数据共享关键概念”，以及“如何使用数据共享”。我们会探讨“跨账号数据共享”的实现方式，并展示在“面向多租户的 Analytics as a Service（AaaS）存储模式”中使用数据共享的不同方案。接着，我们将说明如何启用“通过 AWS ADX 集成的外部数据共享”，以便将数据货币化并让客户使用其自有的 Redshift 计算资源即时访问数据。我们还会简要介绍如何“从数据湖查询与向数据湖卸数”作为数据共享的机制。最后，讲解如何使用 “Amazon DataZone 发现与共享数据”，以编目并治理对数据共享（data-share）的访问。

Amazon Redshift 数据共享概览

Amazon Redshift 的数据共享（data sharing）支持在多个数据仓库之间即时、细粒度、且保持“事务一致”的数据访问，无需复制或搬迁数据。由此你可以构建多仓架构（multi-warehouse），并针对不同类型的工作负载分别扩展各自的数据仓库。Redshift（Serverless 或 RA3 预置）内置数据共享特性，能力包括：

• 对所有消费者的实时且事务一致的数据视图
• 组织内外的安全与受治理的协作
• 与外部方共享数据以实现数据变现

“实时一致视图”确保用户总能看到随仓库更新而变化的最新一致数据。你可以在同一账号内、跨账号、同区域或跨区域安全地与其他 Redshift 数据仓库共享数据。为了构建可扩展的分析架构，你需要综合考虑查询与写入性能、弹性以及性价比。Redshift 的数据共享提供了另一个满足多样工作负载需求的扩展机制。

Redshift 的 RA3 架构使数据共享成为可能：数据存于 Redshift Managed Storage（RMS） ，底层落在 Amazon S3，同时将近期热点数据缓存在计算节点的 SSD 上以加速处理。消费者数据仓库的查询直接从 RMS 层读取数据，因此不会影响生产者仓库的性能，并实现彼此工作负载隔离（见图 7-1）。这让你可以为不同工作负载分别配置、独立伸缩，获得更优的价格-性能。

注：DC2 节点类型不支持数据共享，因为其不使用 RMS。欲使用数据共享，请参考“升级到 RA3 节点类型”或“迁移到 Redshift Serverless”的官方文档。

数据共享用例

Gartner 指出：“对外共享数据的数据与分析负责人，其可衡量经济收益是未共享者的 3 倍。”数据共享具有显著的经济价值。典型用例包括：通过工作负载分离提升可扩展性、促进跨团队协作、构建 AaaS 方案、提升运维效率与数据质量、以及总体改善数据可达性。具体来看：

• 工作负载分离
  当 ETL 负载很重时，可采用多仓架构：一个仓库专职采集/写入，另一个仓库专职查询。二者各自调优，互不干扰。

• 跨团队协作
  公司内不同部门共享与访问数据，以更高效地做决策。例如市场部基于 Redshift 中的数据更精准投放，财务部据此做收入预测。通过共享同时隔离计算资源，彼此处理需求不会相互“打架”（见图 7-2）。

• Analytics as a Service（AaaS）
  AaaS 提供方汇聚社媒、网站分析、ERP 等多源数据入仓，叠加业务洞察后按订阅共享。例如基于第 3 章的学生数据模型，教育科技 AaaS 厂商可汇总出勤与成绩数据，产出提升学生结果的洞察，并通过与 AWS Data Exchange（ADX） 的集成向院校售卖订阅以实现数据变现。数据生产者也可使用 AWS Clean Rooms 与合作方在不暴露原始数据的前提下协同计算。

• 提升研发生命周期（SDLC）敏捷性
  开发/测试环境常缺少“像生产一样”的数据。通过数据共享，可将生产数据共享给开发/测试环境以提升用例覆盖与发布效率。如受限于安全策略，可配合 动态数据脱敏（DDM） 屏蔽 PII（见图 7-3）。

数据共享关键概念

Datashare 是 Redshift 中数据共享的基本单元（见图 7-5）。数据所有者（Producer）将数据库对象加入 datashare 中并共享给订阅方（Consumer）。datashare 本身是一个“引用容器”，持有对其他数据库对象的引用。你可以设置访问控制与权限，确保敏感数据仅授权人员可见；这对与外部伙伴或其他 AWS 用户共享尤为重要。每个 datashare 关联到某个 Redshift 数据库。

• 数据生产者（Producer）
  即拥有并共享数据的 Redshift 数据仓库。生产者端的管理员/DBO 使用 CREATE DATASHARE 创建 datashare，并可将 schema、表、视图、SQL UDF 等对象加入其中进行共享。可在同账号/跨账号、同区域/跨区域共享。
• 数据消费者（Consumer）
  即接收 datashare 的 Redshift 数据仓库。生产者授予访问后，消费者管理员创建一个引用该 datashare 的数据库（仅引用，非物理拷贝），并将权限授予用户/组。随后用户以三段式 database.schema.object 直接查询共享对象；也可通过元数据查询列出共享对象与使用情况。对跨账号共享，生产者需额外执行授权，消费者需将一个或多个 Redshift 数据仓库与该 datashare 关联。
• Namespace（命名空间）
  用于标识一个 Redshift（预置或 Serverless）数据仓库。系统会为仓库自动创建 GUID 与 ARN（预置：arn:{partition}:redshift:{region}:{account-id}:namespace:{guid}；Serverless：arn:{partition}:redshift-serverless:{region}:{account-id}:namespace:{guid}）。在共享流程中，namespace GUID/ARN 用于在账号内共享；当前仓库可通过 current_namespace 获取。对跨账号共享，每个消费者账号以其 12 位 AWS 账户 ID 表示，并可关联一个或多个 Redshift 仓库来读取共享数据（见图 7-4）。

Redshift 支持在不同粒度通过数据库对象共享数据，且同一数据库可创建多个 datashare。一个 datashare 可包含该数据库中多个 schema 的对象。但注意：共享的是 datashare 本身，而非单个对象。这种灵活性带来更精细的访问控制，可按用户/业务定制。例如只向某校管理员共享该校学生信息；或在商业场景中，仅向某供应商共享其对应商品的销售明细（见图 7-5）。

如何使用数据共享（How to Use Data Sharing）

要使用数据共享，首先确定你要共享的数据，并找到包含相关数据的 schema、表和视图。进行共享时，先创建一个 DATASHARE 元数据对象，把需要共享的数据库对象（schemas、tables、views）加入该 datashare，然后将其授权给同一账户内的其他 namespace，或授权给 其他 AWS 账户。下面用一个具体示例走完整流程。

在同一账号内共享数据（Sharing Data Within the Same Account）

我们使用第 3 章示例 3-1 的学生学习数据集来说明如何在同一账号内与组织内的消费者共享数据。你可以通过控制台或 SQL 脚本创建并共享 datashare。下面的示例 7-1 与 7-2 给出具体步骤。

示例 7-1：创建 datashare

-- Creating a datashare (producer)
CREATE DATASHARE learnshare SET PUBLICACCESSIBLE TRUE;

上面的 learnshare 是 datashare 名称；在同一命名空间内必须唯一。SET PUBLICACCESSIBLE 指定该 datashare 是否可共享给“可公网访问”的数据仓库，默认值为 FALSE。

示例 7-2：向 datashare 添加对象

-- Add schema to datashare
ALTER DATASHARE learnshare
  ADD SCHEMA openlearn;

-- Add openlearn materialized view to datashares.
ALTER DATASHARE learnshare
  ADD TABLE openlearnm.mv_student_lmsactivities_and_score;

-- View shared objects
SHOW DATASHARES;
SELECT * FROM SVV_DATASHARE_OBJECTS;

SHOW DATASHARES/SVV_DATASHARE_OBJECTS 输出示例（字段译名如下）：

• share_name：共享名
• share_owner：共享拥有者
• source_database：源数据库
• consumer_database：消费者数据库
• share_type：共享类型
• createdate：创建时间
• is_publicaccessible：是否公网上可访问
• share_acl：共享 ACL
• producer_account：生产者账号
• producer_namespace：生产者命名空间

若要将 某个 schema 下所有表 一次性加入共享，可用：

ALTER DATASHARE learnshare ADD ALL TABLES IN SCHEMA openlearn;

要获取 消费者 的命名空间，可以登录消费者侧的 Redshift 数据仓库，运行示例 7-3 的 SQL，或在控制台查看。

示例 7-3：查看当前用户与命名空间

SELECT user, current_namespace;

拿到消费者数据仓库的 <<consumer namespace>> 后，在生产者侧使用 GRANT 将 datashare 的使用权授予该命名空间（示例 7-4）：

示例 7-4：向命名空间授权使用 datashare

GRANT USAGE ON DATASHARE learnshare TO NAMESPACE '<<consumer namespace>>';

在 消费者侧，创建一个 引用生产者 datashare 的本地数据库。注意这个数据库只是 指针/引用，本身不存放数据。创建后即可用“三段式” db_name.schema.view 直接 实时查询（示例 7-5）：

示例 7-5：基于远端 datashare 创建本地数据库并查询

CREATE DATABASE openlearn_db
FROM DATASHARE learnshare
OF NAMESPACE '<producer_namespace>';

SELECT school_id, code_module, code_presentation,
  final_result, sum(sum_of_clicks)
FROM  openlearn_db.openlearnm.mv_student_lmsactivities_and_score
GROUP BY 1,2,3,4
ORDER BY 1,2,3,4;

可选地，你也可以在消费者仓库中创建一个 external schema，指向生产者数据库中的指定 schema。这样做便于在消费者侧进行 schema 级访问控制，且引用共享对象时可以使用 两段式 标识（localschema.table），而无需三段式（external_db.producerschema.table）。见示例 7-6：

示例 7-6：从本地数据库创建 external schema 并查询

CREATE EXTERNAL SCHEMA openlearn_schema
FROM REDSHIFT DATABASE 'openlearn_db' SCHEMA 'openlearn';

SELECT school_id, code_module, code_presentation,
  final_result, sum(sum_of_clicks)
FROM  openlearn_schema.mv_student_lmsactivities_and_score
GROUP BY 1,2,3,4
ORDER BY 1,2,3,4;

跨账号数据共享（Sharing Data Across Accounts Using Cross-Account Data Sharing）

除了组织内的内部共享（用于打破数据孤岛），你也可以使用 跨账号数据共享 将数据安全地共享给外部机构。常见场景包括：

• 子公司向母公司回报财务报表
• 企业/政府机构与其他组织或关联机构共享数据
• AaaS 提供商与订阅客户共享数据
• 医疗机构与政府部门共享数据

跨账号共享时，创建 datashare 并添加要共享的对象的步骤与同账号共享一致，但授权对象变为 消费者 AWS 账号（示例 7-7）。消费者侧的管理员随后可将 一个或多个数据仓库 关联到该 datashare 以进行读取。

加密兼容性：Redshift 支持在 加密配置同质 的数据仓库之间共享数据。即：可以在两个或多个 加密 的 Redshift 仓库之间共享；同一账号内也可在两个或多个 未加密 的仓库之间共享。跨账号与跨区域共享 时，生产者与消费者 都必须加密；密钥可不同。

示例 7-7：将 datashare 授权给消费者 AWS 账号

-- Granting access to consumer AWS Account
GRANT USAGE ON DATASHARE learnshare TO ACCOUNT <AWS_Account>;

对于 跨账号共享，在 datashare 对消费者可见之前，还需一个 “授权（authorize）”步骤 以便由管理者/数据所有者审批（见图 7-6）。授权完成后，消费者账号即可看到该 datashare。

若需集中管理跨账号、跨区域、跨多个 Redshift 仓库的多份 datashare，可自建 Web 界面进行授权/关联；也可使用 CLI 命令 authorize-data-share 与 associate-data-share-consumer 自动化流程。

在 消费者侧，可以将一个或多个 Redshift 数据仓库与该 datashare 关联（Associate） 。在控制台的 datashares 菜单下，“From other accounts” 选项卡会显示来自其他账户的 datashare；选择后点击 Associate 即可（见图 7-7）。

关联完成后，登录该消费者仓库，按以下两步即可查询共享对象的数据：
1）创建一个 引用 datashare 的数据库；
2）使用三段式 db_name.schema.table 查询（示例 7-8）。

示例 7-8：基于远端 datashare 创建本地数据库并查询

CREATE DATABASE openlearn_db
FROM DATASHARE learnshare
OF ACCOUNT '<<producer_account>>' NAMESPACE '<<producer_namespace>>';

SELECT * FROM learn_db.learnshare. mv_student_lmsactivities_and_score;

当该查询从消费者传到生产者时，current_namespace 将等于 消费者的命名空间。因此（若物化视图带有基于 school 表的消费者过滤逻辑）该视图会据此只返回该消费者可见的记录。正如前述，你也可以在消费者侧创建 external schema，以 两段式（external_schema.table）替代 三段式（external_db.producer_schema.table）来引用共享对象。

有关 跨账号数据共享 的详细设置步骤，请参考官方文档 sharing data across AWS accounts。

基于多租户存储模式的“分析即服务（AaaS）”用例

AaaS（Analytics as a Service）提供商为其用户在云端以订阅的方式提供分析能力。此类服务商通常需要为多个用户存储数据，并为各自的订阅者安全地提供访问。采用多租户存储策略可以构建具备成本效益的架构，并按需扩展。多租户意味着一套软件及其支撑的基础设施被共享以服务多个用户。例如，某软件服务商可以将产生的数据集中存放在一个数据仓库中，但允许多个用户安全访问。这种存储策略有助于集中管理数据、简化 ETL 流程并优化成本。如果不使用数据共享，服务商在多租户环境的管理上会很困难，需要在成本与用户体验之间艰难平衡。

使用数据共享扩展多租户架构

以往，实施多租户架构的 AaaS 提供商必须依赖单一数据仓库的资源来满足所有租户的计算与并发需求。随着租户数量增加，你可以开启 Concurrency Scaling 或新建额外的数据仓库；但新增数据仓库意味着更多的摄取（ingestion）管道和更高的运维开销。

借助 Amazon Redshift 数据共享，可以同时实现存储与 ETL 管道简化、成本可控，并保持一致的性能。你可以将数据摄取到一个被指定为生产者（producer）的数据仓库，并把这份实时数据共享给一个或多个消费者（consumer） 。写入生产者的数据可被多个消费者共享，从而彻底隔离 ETL 与 BI 工作负载。访问共享数据的集群彼此隔离，因此生产者的性能不会受到消费者工作负载的影响；消费者可依据自身计算能力获得一致的性能体验。

多个消费者可以直接从生产者的托管存储读取数据，实现无需拷贝与搬移的即时、细粒度且高性能的数据访问。访问共享数据的各类工作负载之间以及与生产者之间都是隔离的。你可以将工作负载分布到多个数据仓库，同时将 ETL 摄取管道简化并收敛到一个主生产者数据仓库，从而获得最佳的性价比。

消费者数据仓库也可以对其自有的数据集充当新的生产者。你可以通过把多个租户共置到同一个消费者上进一步优化成本。例如，将低流量的三级租户组合到一个消费者之上提供低成本方案，而高流量的一级租户则分配独立的计算数据仓库。消费者数据仓库既可以在与生产者相同账户中创建，也可以在不同 AWS 账户中创建。这样你可以对消费者进行独立计费——要么向使用该消费者的业务团队进行分摊，要么允许用户在其自有账户中使用 Redshift 数据仓库，由其自付使用成本。图 7-8 展示了使用数据共享的多租户架构与不使用数据共享、采用单一数据仓库方式在 ETL 与访问模式上的差异。

使用数据共享的多租户存储模式

在多租户策略中，所有租户的数据存放在共享位置，从而简化 ETL 摄取与数据管理。支持此类多租户访问模式的存储策略主要有以下几种（见图 7-9）：

• 池（Pool）模型
  所有租户的数据存放在同一个数据库 schema 中，通过新增列（如 tenant_id）来限定和控制各租户的数据访问。对多租户数据的访问通常通过基于表构建的视图来控制。
• 桥（Bridge）模型
  每个租户的数据存放在同一数据库内的独立 schema 中。
• 孤岛（Silo）模型
  每个租户的数据存放在同一数据仓库内的独立数据库中。

我们将使用学生分析数据模型演示若干结合数据共享的多租户实现策略，并基于第 3 章创建的数据模型给出各策略的步骤。在该用例中，生产者是 AaaS 提供商，负责在一个 Redshift 数据仓库中加载与处理数据；**消费者（租户）**为订阅了学生洞察数据集的一所或多所学校，它们位于一处或多处 Redshift 数据仓库中。

启用跨数据仓库数据共享的高层步骤如下：

1. 在生产者端创建 datashare 并向其中加入需要共享的数据库对象。
2. 在生产者端将 datashare 的使用权限授予消费者（按 namespace 或 AWS 账号）。
3. 在消费者端基于该 datashare 创建外部数据库引用。
4. 在消费者端通过该外部共享数据库查询 datashare 中的表，并为其他用户授权访问。

在接下来的示例中，我们使用 school 表来标识消费者（租户）。由于所有表都包含 school_id 列，你可以利用该列区分不同学校，并仅将授权数据安全地共享给相应消费者。

开始前，请获取生产者与消费者数据仓库的 namespace。可在 AWS 控制台查看，或分别登录数据仓库执行 SELECT CURRENT_NAMESPACE。

下面演示多租户架构模式时，我们使用添加了 school_id 的 Open University Learning Analytics 数据集版本，将多所学校的数据存入各表。该多租户版本数据集位于 Amazon S3。你可以在执行示例 7-9 的脚本创建表后，将其加载进 Redshift。注意我们新增了 school 表用于存放学校详情，并在各表中加入了 school_id 列。样例数据包含两所学校的数据，我们将用它演示如何借助 Redshift 数据共享搭建多租户存储策略。

示例 7-9：创建 schema 与学生信息表

/* ...省略版权与出处说明... */

CREATE SCHEMA openlearnm;

CREATE TABLE "openlearnm"."school"(
  school_id       integer,
  school_name     varchar(50),
  address         varchar(100),
  city            varchar(80),
  website_url     varchar(100),
  consumer_namespace varchar(100))
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."assessments" ( ... );
CREATE TABLE "openlearnm"."courses" ( ... );
CREATE TABLE "openlearnm"."student_assessment" ( ... );
CREATE TABLE "openlearnm"."student_info" ( ... );
CREATE TABLE "openlearnm"."student_registration" ( ... );
CREATE TABLE "openlearnm"."student_lms" ( ... );
CREATE TABLE "openlearnm"."lms" ( ... );

示例 7-10：加载多租户样例数据

COPY "openlearnm"."assessments" FROM 's3://openlearnm-redshift/assessments' ...;
COPY "openlearnm"."courses"     FROM 's3://openlearnm-redshift/courses' ...;
COPY "openlearnm"."student_assessment" FROM 's3://openlearnm-redshift/studentAssessment' ...;
COPY "openlearnm"."student_info"       FROM 's3://openlearnm-redshift/studentInfo' ...;
COPY "openlearnm"."student_registration" FROM 's3://openlearnm-redshift/studentRegistration' ...;
COPY "openlearnm"."student_lms"          FROM 's3://openlearnm-redshift/studentlms' ...;
COPY "openlearnm"."lms"                  FROM 's3://openlearnm-redshift/lms' ...;

池（Pool）模型

Pool 模型是“全集中”的多租户模型，所有租户共享相同的存储结构，最能简化 AaaS 方案。在该模型下，数据集中存放在一个数据库中，所有租户共用一套数据模型。跨租户访问的安全是 Pool 模型的关键：你可以通过数据库视图实现行级过滤，并结合 current_namespace 等机制按触发查询的租户动态过滤。为控制租户数据访问范围，在数据模型中增加用于标识各租户的列（如 consumer_namespace）。

继续本用例，在 school 表中加入 consumer_namespace 来控制来自不同学校（各自 Redshift 数据仓库）的订阅访问。运行示例 7-11 可见每所学校的 consumer_namespace 值都是唯一的。

示例 7-11：学校与 consumer_namespace 的映射

SELECT * FROM openlearnm.school;

（输出略：包含 school_id、school_name、consumer_namespace 等）

图 7-10 展示了 Pool 模型的体系结构。

在生产者侧创建数据库视图

在多租户架构中，你可以像“构建星型模型”部分那样创建物化视图，但这里要将 school 表纳入并在 WHERE 子句中使用 school_id 做行级限制。示例 7-12 给出 Pool 模型的物化视图脚本（注意此处对象存放在 openlearnm schema 中）。

示例 7-12：学生活动总分与均分的物化视图

CREATE materialized view openlearnm.mv_student_lmsactivites_and_score AS
SELECT ...
FROM openlearnm.student_info st
LEFT JOIN ( ... FROM openlearnm.student_lms ... ) st_lms_clicks
  ON ...
LEFT JOIN ( ... FROM openlearnm.STUDENT_ASSESSMENT ... ) scores
  ON ...;

为基于消费者命名空间限制行访问，可创建视图 v_student_lmsactivites_and_score，将上面的物化视图与 school 表连接，并利用系统变量 current_namespace 做过滤（示例 7-13）。

示例 7-13：用于计算学生成绩的视图（基于 current_namespace 过滤）

CREATE VIEW openlearnm.v_student_lmsactivites_and_score AS
SELECT ...
FROM openlearnm.mv_student_lmsactivites_and_score mvs
LEFT JOIN openlearnm.school s
  ON mvs.school_id = s.school_id
WHERE s.consumer_namespace = current_namespace;

在生产者创建 datashare 并授予消费者使用

准备就绪后，连接到生产者数据仓库，创建 datashare learnsharem，将 openlearnm schema 与上述视图加入共享，然后将使用权限授予消费者（示例 7-14；请替换消费者的 namespace）。

示例 7-14：生产者侧设置 datashare

CREATE DATASHARE learnsharem;

ALTER DATASHARE learnsharem ADD SCHEMA openlearnm;
ALTER DATASHARE learnsharem ADD TABLE openlearnm.v_student_lmsactivities_and_score;

GRANT USAGE ON DATASHARE learnsharem TO NAMESPACE '<<consumer namespace>>';

在消费者侧，创建引用该 datashare 的本地数据库（示例 7-15）。该数据库仅为指针/引用，不存放数据。

示例 7-15：消费者创建本地引用数据库

CREATE DATABASE openlearnm_db
FROM DATASHARE learnsharem
OF NAMESPACE '<producer_namespace>';

创建完成后，可直接用三段式 db.schema.view 实时查询（示例 7-16）。注意，即使不写显式的 WHERE 过滤，查询也仅返回该消费者所对应学校的数据，因为在视图层已按 current_namespace 与 school 表关联做了限制。

示例 7-16：查询视图

SELECT *
FROM openlearnm_db.learnsharem.v_student_lmsactivities_and_score;

想了解如何设置与测试多个消费者的更详细步骤，可参考博客 “Implementing Multi-tenant Patterns in Amazon Redshift Using Data Sharing” 。

使用基于角色的行级安全（RLS）

替代在生产者侧通过视图实现隔离，你也可以使用基于 RBAC 的 RLS（Row-Level Security） 在表级为各消费者限制行访问。延续之前的例子，假设 school 表中仍有 consumer_namespace，且所有表都共享给所有消费者，则可定义如下 RLS 策略（示例 7-17），强制连接 school 表，仅返回 consumer_namespace = current_namespace 的学校数据。

示例 7-17：创建 RLS 策略

CREATE RLS POLICY consumer
WITH (school_id int)
USING (school_id = (
  SELECT school_id
  FROM school
  WHERE consumer_namespace = current_namespace));

GRANT SELECT ON
  student,
  course_outcome,
  course_registration,
  degree_plan
TO RLS POLICY consumer;

随后将该策略附加到含 school_id 的表，并授予 school 角色（示例 7-18）。任何关联到该数据库角色的用户只会看到自己的数据。

示例 7-18：将策略附加到对象并赋予角色

ATTACH RLS POLICY consumer ON student TO ROLE school;
ATTACH RLS POLICY consumer ON course_outcome TO ROLE school;
ATTACH RLS POLICY consumer ON course_registration TO ROLE school;
ATTACH RLS POLICY consumer ON degree_plan TO ROLE school;

桥（Bridge）模型

Bridge 模型在同一数据库中为每个租户创建独立 schema 存储数据，且各 schema 采用相同表结构。你为每个 schema 创建独立的 datashare，并仅与对应消费者共享，使每个 schema 的查询工作负载被路由到各自的消费者。这种模式在 Silo 与 Pool 之间取得平衡：既具备一定的数据隔离，又能在不同 schema 之间复用 ETL 代码。若不使用数据共享，所有查询都会进入同一个数据仓库；而在 Redshift 中，你最多可创建 9,900 个 schema（若超过此限，可考虑建立更多数据库）。详见 Redshift 配额与限制。图 7-11 展示了 Bridge 模型。

在生产者侧创建 schema 与表

延续前述用例，首先在生产者中为每个租户创建单独的 schema（例如 learnschema_school1 与 learnschema_school2），并在各自 schema 下建立与示例 3-1 一致的表结构。为最大化 ETL 代码复用，请确保各 schema 的数据模型保持一致。

在生产者创建 datashare 并授予消费者使用

为 Bridge 模型创建两个 datashare：learnshare-school1 与 learnshare-school2，并将各自 schema 下的所有表加入对应 datashare，然后将使用权限授予相应消费者（可在同账户或跨账户）。

示例 7-19：创建 datashare

CREATE DATASHARE learnshare-school1;
CREATE DATASHARE learnshare-school2;

示例 7-20：向 datashare 添加对象

ALTER DATASHARE learnshare-school1 ADD SCHEMA learnschema_school1;
ALTER DATASHARE learnshare-school2 ADD SCHEMA learnschema_school2;

ALTER DATASHARE learnshare-school1 ADD ALL TABLES IN SCHEMA learnschema_school1;
ALTER DATASHARE learnshare-school2 ADD ALL TABLES IN SCHEMA learnschema_school2;

示例 7-21：为消费者命名空间授予使用权限

GRANT USAGE ON DATASHARE learnshare-school1
  TO NAMESPACE '<consumer1_namespace>';

在 消费者（school1） 侧，创建引用该 datashare 的本地数据库并查询（示例 7-22）。你也可以通过 SVV_DATASHARES/SVV_DATASHARE_OBJECTS 或 SHOW DATASHARES 查看共享详情。

示例 7-22：消费者创建本地引用数据库并查询

CREATE DATABASE learndb_school1
  FROM DATASHARE learnshare-school1
  OF NAMESPACE '<producer_namespace>';

SELECT *
  FROM learndb_school1.learnschema_school1.v_student_lmsactivities_and_score;

SHOW DATASHARES;
SELECT * FROM SVV_DATASHARES;
SELECT * FROM SVV_DATASHARE_OBJECTS;

在 Bridge 模式下，因各学校对象按 schema 组织，且 datashare 仅包含该学校的 schema，消费者只能访问与自己相关的对象。例如，school1 仅能查询 learnschema_school1 的数据。

孤岛（Silo）模型

第三种选择是在一个数据仓库中为每个租户创建独立数据库进行存储与访问控制（Silo 模式）。若你希望拥有差异化的数据模型以及独立的监控、管理与安全边界，此模式更合适。Redshift 支持跨数据库查询，这有助于简化数据组织：可将所有租户通用或细粒度的数据集放在中心数据库中，再通过跨库查询把相关数据与各租户数据进行关联。

Silo 模型下创建 datashare 的步骤与 Bridge 类似，但共享粒度从“每个 schema”变为“每个数据库”。图 7-12 展示了其架构。

在生产者侧创建数据库与 datashare

延续用例，步骤如下：

1. 以管理员身份登录生产者，分别为每个租户创建数据库（示例 7-23）。

   CREATE DATABASE learndb_school1;
   CREATE DATABASE learndb_school2;
   

2. 分别登录到 learndb_school1 与 learndb_school2，创建 learnschema（示例 7-24），并在各数据库中按示例 3-1 建表，存放各校数据。该模式的好处是schema 与表名一致，ETL 流程仅需切换数据库连接参数即可复用。

   CREATE SCHEMA learnschema;
   

3. 分别在两个数据库中创建 datashare，并授予各自消费者使用（示例 7-25、7-26）。

示例 7-25：为第一所学校设置 datashare

CREATE DATASHARE learnshare-school1;
ALTER DATASHARE learnshare-school1 ADD SCHEMA learnschema;
ALTER DATASHARE learnshare-school1 ADD ALL TABLES IN SCHEMA learnschema;
GRANT USAGE ON DATASHARE learnshare-school1 TO NAMESPACE '<consumer1_namespace>';

示例 7-26：为第二所学校设置 datashare

CREATE DATASHARE learnshare-school2;
ALTER DATASHARE learnshare-school2 ADD SCHEMA learnschema;
ALTER DATASHARE learnshare-school2 ADD ALL TABLES IN SCHEMA learnschema;
GRANT USAGE ON DATASHARE learnshare-school2 TO NAMESPACE '<consumer2_namespace>';

通过集成 AWS ADX 进行外部数据共享

对于部分用户而言，在同一账户内或跨账户共享数据已足以满足组织内部协作；但在跨组织协作与数据变现场景下，你可以使用 AWS Data Exchange（ADX） 。借助 ADX，你既可以共享存放在 Amazon S3 上的数据，也可以通过 datashare 直接让外部方查询 Amazon Redshift 数据仓库中的数据。

AWS Data Exchange（ADX） 是一个数据市场，数据提供方可以在其中托管数据产品，供订阅者按订阅方式访问。ADX 汇聚三百多家提供商的数据产品，并以文件、API 或 Amazon Redshift datashare 的形式提供订阅访问。订阅者可在数据湖、应用、分析与机器学习模型中直接使用这些数据。作为 AWS 服务，ADX 安全合规，可与 AWS 及第三方工具/服务集成，并提供统一计费与订阅管理。

通过与 Amazon Redshift 的集成，你可以在 ADX 上为 Redshift 数据授权。订阅带有 Redshift datashare 的产品后，ADX 会自动把你加入该产品包含的所有 datashare 的消费者列表。你可以自动生成发票、集中收款，并通过 AWS Marketplace Entitlement Service 自动分发收益。

数据提供方可以在 Amazon Redshift 中按细粒度授权（如 schema、表、视图、UDF）。你可以在多个 ADX 产品间复用同一个 ADX datashare；添加到该 datashare 的任何对象都会对订阅者可见。生产者可通过 Redshift API、SQL 命令及控制台查看由 ADX 代管的所有 ADX datashare。订阅 ADX 含 datashare 产品的消费者对这些对象仅有只读权限。

ADX datashare 是你通过 ADX 共享数据的许可单位。AWS 负责与订阅、数据共享使用相关的计费与收款。通过审核的数据提供方可以将 ADX datashare 添加到 ADX 产品中。订阅包含 ADX datashare 的产品后，你即可访问产品中的这些 datashare。关于 ADX 与 Amazon Redshift 的集成机制，详见章节“通过集成 AWS ADX 进行外部数据共享”。已获批的提供方可以添加 ADX datashare，并将数据作为产品在 ADX 上授权。

当你订阅包含 ADX datashare 的产品后，ADX 会自动将你添加为该产品内所有 ADX datashare 的数据消费者；当你的订阅结束时，ADX 也会自动将你移除。ADX 与 AWS 计费系统集成，为付费产品提供统一的计费、发票、收款与分账。要注册成为 ADX 数据提供方，请参阅 Getting Started as a Provider。

如果你是处于有效订阅状态的消费者（即 ADX 的订阅者），你可以在无需提取、转换、加载（ETL）的情况下，直接在 Amazon Redshift 中发现、订阅并查询细粒度且最新的数据。

若要消费第三方提供方的数据，你可以浏览 AWS Data Exchange 目录，发现并订阅 Amazon Redshift 中的数据集。ADX 订阅生效后，你可以在自己的数据仓库中基于该 datashare 创建数据库，并在 Amazon Redshift 中查询数据。

作为订阅者，你可以直接使用提供方数据，无需额外处理或 ETL；因此数据始终是最新的，可直接用于 Redshift 查询。面向 Amazon Redshift 的 ADX 会为你管理所有授权与支付，所有费用记入你的 AWS 账户。

发布数据产品

要通过 ADX 在 Amazon Redshift 中发布数据产品，你可以创建连接到 Redshift 数据仓库的 ADX datashare。要将 ADX datashare 添加到 ADX 产品中，你必须是已注册的 ADX 提供方。

完成提供方注册后，你可以创建用于发布的数据交换 datashare（面向 Redshift）。当用户订阅包含 datashare 的产品时，他们会获得对该 datashare 中表、视图、schema 与 UDF 的只读访问。

下面演示如何将“学生物化视图”作为数据产品通过 ADX 共享。第一步是创建数据交换 datashare，既可通过控制台（见图 7-13），也可使用脚本创建。

图 7-13. 创建数据交换 datashare

随后为该 datashare 添加数据库对象；在本例中选择 mv_student_lmsactivities_and_score（见图 7-14）。

图 7-14. 为数据交换 datashare 添加对象

创建 datashare 并添加对象后，你可以选择 datashare（如 learnshare_adx），在 AWS Data Exchange 上创建数据集（dataset） （见图 7-15）。之后该 datashare 将在 ADX 上列出，供消费者订阅。

图 7-15. 基于 Redshift Datashare 在 ADX 创建数据集

按步骤创建数据集并最终确定 datashare 版本。接着即可基于该数据集创建数据产品（见图 7-16）。

图 7-16. 由数据集创建产品

详细步骤请参阅联机文档：如何发布包含 Amazon Redshift 数据集的数据产品。注意：你需要注册为 Marketplace Seller 才能发布数据产品；如要发布付费产品且符合条件，必须提交税务与银行信息。

订阅已发布数据产品

若要消费第三方的数据产品，你可以通过 AWS Data Exchange 订阅来获得数据访问。作为处于有效订阅状态的用户，你可在 ADX 控制台浏览目录，发现包含 ADX datashare 的产品（见图 7-17）。订阅生效后，你可在本方数据仓库中基于该 datashare 创建数据库，并直接在 Amazon Redshift 查询数据。

图 7-17. 在 ADX 浏览数据产品

订阅包含 ADX datashare 的产品后，在你的数据仓库中基于该 datashare 创建数据库，即可直接在 Amazon Redshift 中查询数据，无需 ETL。产品一旦添加了 ADX datashare，订阅者在订阅开始时即自动获得访问权限，并在订阅有效期内持续保有访问。

更多信息参阅在线文档：作为消费者使用 AWS Data Exchange datashare。

在 Amazon Redshift 中使用 AWS Data Exchange 的注意事项

• 生产者与消费者均需使用 RA3 节点类型 才能使用 Redshift datashare。生产者需使用 RA3 或 Serverless，且生产者与消费者数据仓库均需加密。
• 要在 ADX 上发布产品（包括包含 ADX datashare 的产品），必须注册为 ADX 提供方。详见 Getting Started as a Provider。
• 若仅需发现/订阅/查询通过 ADX 提供的 Redshift 数据，则无需注册为提供方。
• 若要通过 ADX datashare 控制对你数据的访问，需将 Publicly Accessible 设置打开。这并不意味着你的 datashare 或消费者数据仓库对公众开放，只是允许其可被设为公开访问。如需修改，可使用 ALTER DATASHARE SET PUBLICACCESSIBLE FALSE 关闭公开可访问设置。
• 生产者不能手动向 ADX datashare 添加或移除消费者；访问基于对包含该 datashare 的 ADX 产品的有效订阅而自动授予/移除。
• 生产者无法查看消费者运行的具体 SQL，只能通过 Redshift 的相关系统表查看元数据（如查询数量、被访问对象）。可利用这些信息了解订阅者的使用模式，以优化产品。
• 不建议对已共享给其他 AWS 账户的 ADX datashare 执行 DROP DATASHARE。否则已有访问的账户会立即失去访问，且该操作不可逆，并可能违反 ADX 的数据产品条款。
• 对于跨区域数据共享，你可以创建 ADX datashare 来共享授权数据。
• 建议将 datashare 设为公开可访问；否则，使用公开可访问消费者数据仓库的 ADX 订阅者将无法使用你的 datashare。

从数据湖查询与卸载到数据湖（Query from the Data Lake and Unload to the Data Lake）

有些场景下，你希望把在数据仓库中已整理（curated）好的数据共享给外部应用。由于 Amazon Redshift 与数据湖深度集成，你可以采用“数据仓库优先”的方法：先把数据存放在数据仓库中，按需再卸载（UNLOAD）到数据湖。Redshift 支持存储与计算解耦，单节点可在数据仓库内存储高达 128TB 的数据。因此，对 OLAP 工作负载而言，你可以把全部数据存进数据仓库。当你希望把 Redshift 中的数据共享给诸如 Amazon SageMaker 等其他服务时，可以使用 UNLOAD 将本地表的数据卸载到 Amazon S3。卸载时可直接转换为推荐格式（如 Parquet 或 ORC），以便与其他服务共享。

UNLOAD 命令的一般语法请参阅官方文档。延续本书示例，如果你想把“学生学习管理系统的参与度”共享给使用其他服务的合作伙伴或用户，可以按 示例 7-27 使用 UNLOAD：

示例 7-27. UNLOAD 示例

UNLOAD ('select * from mv_student_lmsactivities_and_score')
TO 's3://openlearn/studentactivities'
IAM_ROLE default
PARQUET
PARTITION BY (school_id);

你也可以用 INSERT INTO … SELECT 将查询结果写入外部目录（如 AWS Glue、AWS Lake Formation 或 Apache Hive metastore）上的外部表，见 示例 7-28。与外部目录和 S3 的交互需使用创建 CREATE EXTERNAL SCHEMA 时相同的 AWS IAM 角色。有关将 SELECT 结果插入外部表的详细步骤，请参阅相关文档。

示例 7-28. 向外部表写入数据

INSERT INTO external_schema.table_name
{ select_statement }

使用 Amazon DataZone 来发现与共享数据

传统的数据仓库通常通过将多个源系统的明细交易数据集中到单一事实来源来构建。明细数据在应用业务规则后被转换，并以适合快速查询的聚合格式进行存储。近年来，一种强调去中心化的数据管理与治理的新架构正在兴起，即“数据网格（Data Mesh） ”，详见《Data Mesh》章节。数据网格倡导数据的去中心化所有权，旨在在不必将数据移动或复制到中央存储的情况下，便捷访问数据。

在这种模式下，数据生产者（领域专家）创建数据资产、定义数据目录并补充业务定义，按数据域组织；随后将数据产品注册到目录，便于数据消费者按需检索与访问。回顾数据网格架构的四个关键理念：

• 面向域的数据所有权
• 联合式数据治理
• 自服务数据基础设施
• 把数据当作产品的思维

下一节将说明 Amazon DataZone 的组件如何支撑这些关键能力，从而实现数据网格架构。

使用 Amazon DataZone 的数据网格架构用例

数据网格架构适用于多业务线/多子公司的组织，需要在业务单元之间安全共享数据。示例包括：

• 大型金融机构在云上（含 Amazon Redshift 与 Amazon S3）构建现代数据平台，既服务分析、研究、数据科学，也承载治理/监管/财务报表。单账户集中式初始设计在可达性与上限上遇到挑战。通过去中心化与委托各业务单元自主管理数据，在各自账号内共置（co-locate）Redshift 与 S3，实现本地治理与跨账户安全访问。
• 投行组织需在企业范围内自由共享数据，同时控制未授权访问风险。其路径：一是以“数据产品”形式由懂数据的人进行策划与约束；二是引入数据网格架构，让数据技术栈与数据产品对齐。
• 医疗机构可构建“实时病患监测”数据产品，供急救、护理、科研等部门使用。教育系统中，IT 部门为生产者，各学校为订阅者，依据“生产者—消费者模型”安全共享学生相关数据。零售公司可为销售、库存、客户与营销分别设立域，各域团队独立采集/存储/分析域内数据，实现独立的数据驱动决策。

核心目标：去中心化管理、赋能域团队，并在组织内部形成可扩展、可持续的数据生态。

Amazon DataZone 的关键能力与用例

Amazon DataZone 是一项拥抱数据网格理念的数据管理服务，支持数据生产者发布数据产品，并通过 Web 界面将其纳入业务数据目录。发布后，用户可快速搜索并结合业务语义理解数据。你可以基于团队、分析工具与数据资产的组合创建业务用例，以简化对 AWS 分析工具的访问。借助自动化发布/订阅流程，你可以在生产者与消费者之间灵活管理数据所有权与访问授权。

你可以设置安全策略，确保只有合适权限的人能够访问对应数据。DataZone 支持联合式数据治理：让数据集的所有者/领域专家在其相关数据资产上实施安全与访问控制。它还能扩展在 AWS Glue Data Catalog、IAM 与 Lake Formation 中设置的治理控制。DataZone 支持跨 Amazon Redshift、Amazon Athena、AWS Glue、Lake Formation、Amazon QuickSight 的数据访问与共享。

Amazon DataZone 与 Amazon Redshift 及其他 AWS 服务的集成

Amazon DataZone 本身不存储数据，而是作为元数据枢纽，帮助跨孤岛数据集实现便捷访问。为实现数据访问，DataZone 需与实际存储/访问/控制数据的 AWS 服务集成。撰写时支持三类集成：

1. 生产者数据源（Producer data sources）
   从生产者视角，DataZone 可集成 Amazon S3 数据湖与 Amazon Redshift。你可以将存放于 S3、Redshift 表与视图中的数据资产发布到 DataZone 目录；也可将 AWS Glue Data Catalog 中的对象手动发布到 DataZone 目录。
2. 消费者工具（Consumer tools）
   可通过 Amazon Redshift 查询编辑器或 Amazon Athena 访问数据资产；对 Redshift，可通过外部表进行访问。
3. 访问控制与履约（Access control and fulfillment）
   你可以对 Lake Formation 管理的 Glue 表以及 Amazon Redshift 表/视图授予访问权限。DataZone 还会将与你操作相关的标准事件联通到 Amazon EventBridge，以便集成其他 AWS 服务或第三方方案，实现自定义集成。

Amazon DataZone 的组件与能力（Components and Capabilities of Amazon DataZone）

AWS 在 Amazon DataZone 中引入了 “域（domain）” 的概念，用于组织数据资产及与这些资产相关的资源。Amazon DataZone 的域让你能够灵活映射组织的业务领域与实体，包括数据资产、数据源、元数据、业务术语表，甚至关联的 AWS 账户。为了通过发布到中央目录的数据产品在各业务域之间实现安全的数据访问，Amazon DataZone 提供了四个关键组件：

• 业务数据目录（Business data catalog）
• 项目（Projects）
• 治理与访问控制（Governance and access control）
• 数据门户（Data portal）

这些组件属于你创建的域的一部分，如图 7-18 所示。

要完成 Amazon DataZone 及其数据门户的初始设置，你需要先创建一个作为根域的 domain。在数据门户内，域管理员可以再创建其他域。这些组件协同工作，提供构建与运行去中心化数据治理的数据网格架构所需的能力。下面分别介绍。

业务数据目录（Business data catalog）

Amazon DataZone 的核心组件是带有业务友好描述的元数据目录。数据生产者在发布数据产品时会构建该目录，并会随着新产品可供消费而持续增长。该目录可以聚合来自异构数据源的数据集。数据集发布到目录后，消费者可通过 Amazon DataZone 门户（见图 7-24）搜索并发现所需数据。

Amazon DataZone 使用 机器学习（ML） 在编目数据资产时自动建议业务术语，从而减少为技术数据添加可检索业务术语所需的人工工作量。

项目（Projects）

Amazon DataZone 引入 数据项目（projects） ，用于团队协作并获取数据资产。借助项目，组织内的一组用户可以围绕发布、发现、订阅与消费目录中的数据资产开展协作。与依赖个人用户凭证不同，项目作为身份主体来接收对底层资源的授权。每个项目都有一套访问控制，仅授权的个人、组与角色才能访问该项目及其订阅的数据资产，并且只能使用项目权限所定义的工具。项目与一个项目配置（project profile）关联，可被设定为消费者、生产者或二者兼具。你可以通过项目对跨项目的数据资产进行管理与监控，并进行使用审计。

通过数据项目，你能创建并访问将数据、人员与工具按业务用例分组的空间，以便团队在消费数据时协同工作。项目视图中的部分组件包括：

• Subscribed data（已订阅数据） ：包含所有订阅（已批准、待处理与已授予）的请求。
• Publishing（发布） ：包含所有已发布数据、订阅请求、发布作业与全部协议。
• Members（成员） ：列出项目成员及其角色。
• Settings（设置） ：显示项目 ID、账户、VPC 以及项目能力等详情。

项目成员可在受控且安全的范围内协作、交换数据并共享制品；只有显式加入项目的成员才能访问项目中的数据与分析工具。项目在数据管理员（data stewards）所施加的策略下管理所产出的数据资产所有权，从而通过联合式治理实现数据所有权的去中心化。

数据治理与访问控制（Data governance and access control）

通过自动化工作流，消费者可以对其在业务目录中发现的数据产品发起访问请求。该请求会被路由给数据生产者或数据所有者审批。一旦生产者批准，请求方会收到通知，并可无需人工干预地访问数据。数据生产者可以简化审计，按数据集监控谁在使用、在各项目与业务线（LOB）之间监控使用情况与成本。下一节将展示发布与订阅的示例步骤。

数据门户（Data portal）

数据门户是一个独立于控制台的个性化首页，提供自服务能力，消费者可在目录中搜索数据。数据门户是用户访问 Amazon DataZone 的主要入口，它是一个基于浏览器的 Web 应用，用户可在其中对数据进行编目、发现、治理、共享与分析。这使跨职能团队得以协同，并能使用来自身份提供商的现有凭证访问数据与分析工具。

通过门户你可以访问按用户个性化的数据资产视图。图 7-19 展示了订阅请求在工作流中的各种状态。借助该门户，你可以无需登录 AWS 管理控制台、也无需理解底层 AWS 分析服务的细节，即可开展数据分析。

Amazon DataZone 入门（Getting Started with Amazon DataZone）

采用数据网格（data mesh）架构不只是技术问题，更需要思维方式的转变。你需要在组织内对团队进行编制，并落实流程，以迈向生产者—消费者模型。域（domain）为这种转变提供了抓手：它为在业务数据目录中生产与编目的团队注入组织纪律提供了机制。任何数据生产者都可以将数据资产发布到受某个域治理的目录中，并由该域控制哪些消费者可以访问。一个域下可以关联多个围绕具体业务用例的项目（project），人员在项目中协作并访问数据。

本节将带你创建 Amazon DataZone 根域（root domain） 并获取数据门户 URL，随后分别演示数据生产者与数据消费者的基础工作流。完整安装步骤见官方“Getting started”文档，主要包括以下步骤。

步骤 1：创建域与数据门户

开始使用 Amazon DataZone 的第一步是创建域（domain） 。域是 Amazon DataZone 对象（如数据资产、项目、关联的 AWS 账户、数据源等）的集合。域是一个容器，你与团队可以在其中创建所有相关的 Amazon DataZone 实体（包括元数据资产）。你可以将数据资产发布到由特定域治理的目录，并控制哪些关联的 AWS 账户与资源能够访问该域。

步骤 2：创建生产者项目（producer project）

要以生产者身份创建并发布数据产品，需要先创建一个项目，数据产品及相关资产都会归入该项目。在创建项目时，需要指定项目配置（project profile）与数据源连接。项目配置决定项目具备的能力（充当生产者、消费者或两者）；连接详情用于描述数据源。因此，创建项目之前需要先创建项目配置与一个 AWS Glue 连接。

对于数据仓库生产者，还需提供 Amazon Redshift 集群名与 AWS Glue 连接详情。如果尚无 Glue 连接，可以先创建该连接，并在项目中引用。你将从该项目把所生产的数据发布到目录，消费者也将通过项目访问数据。

要创建项目，请使用数据门户 URL 进入 Amazon DataZone 数据门户，并用 SSO 或 AWS 凭证登录。进入 My Projects 菜单，点击 + 创建新项目（见图 7-20）。如果你是 Amazon DataZone 管理员，可在创建根域的 AWS 账户中，通过 DataZone 控制台获取数据门户 URL。

你也可以选择 “Browse all projects” 查看全部数据项目，列表形式如图 7-21 所示。

步骤 3：为发布准备数据（生产）

在将数据资产发布到数据目录之前，需要先在底层系统中创建数据对象并准备数据。在上一步创建的生产者项目中，点击 “Query data—Amazon Redshift” （见图 7-22），登录 Amazon Redshift 集群以创建数据表并加载数据。此操作会打开 Amazon Redshift Query Editor V2，选择 Federated user 选项登录到数据仓库，然后创建数据库对象与数据。如果已有表，也可以在发布数据产品时选择包含它们。

步骤 4：将数据产品发布到目录

当生产者准备好数据产品后，可以发布到业务数据目录，供消费者搜索与订阅。在生产者项目中选择 “Publish data” 发起发布。发布过程以发布作业（job）与发布协议（publishing agreement）的形式运行：在项目的 Publishing 选项卡下创建发布协议，并通过作业触发发布，同时可以监控作业。以“学生表现”数据产品为例，生产者可按图 7-23 的方式发布到目录。详细步骤见“在 Amazon DataZone 中发布数据”的官方文档。

步骤 5：创建消费者项目（consumer project）

为了订阅底层数据产品，项目同样作为身份主体来接收对底层资源的授权，而不依赖个人用户凭证。要让消费者订阅生产者发布的数据，需要创建一个带有消费者配置（consumer profile）的消费者项目；在创建消费者配置时，添加 “data warehouse Consumer Capability” 能力。消费者在门户中定位到目录里的数据集时，必须先选择消费者项目，再提交访问请求。Amazon DataZone 将根据访问控制校验请求，只授权被允许访问该项目的个人、组与角色。

步骤 6：在 Amazon DataZone 中发现与消费数据

当数据资产发布到某个域后，订阅者可以通过 Amazon DataZone 门户发现并请求订阅。消费者首先在门户中搜索目录（见图 7-24）：在选定的消费者项目下，通过关键字搜索，DataZone 将在所有已编目的数据中返回匹配的数据产品。消费者可查看业务术语表中的描述了解详情；确认数据集后，提交访问请求即可开始分析。

点击 Subscribe（见图 7-25）即可对该数据资产发起订阅请求，并填写申请理由。订阅审批人（在发布协议中定义）会对请求进行审批或驳回。详细步骤见“发现与消费数据”的文档。

步骤 7：生产者审批对已发布数据资产的访问

生产者可在生产者项目中审批消费者的访问请求：进入项目的 Publishing → Subscription Requests 查看所有待审批请求，进行批准/拒绝并填写审批说明。系统会保存这些信息用于后续跟踪（谁批准、何时批准、理由等）。

步骤 8：消费者分析已发布数据资产

一旦获批，订阅者可在消费者项目中查看审批状态，并根据数据源与数据所在位置，使用 Amazon Athena 或 Amazon Redshift Query Editor 来直接查看与分析数据。

在搭建你的数据网格之前，请先完成官方文档 “Setting Up” 部分的准备工作：

• 如果你使用的是全新 AWS 账户，需要为 Amazon DataZone 管理控制台配置相应权限。
• 如果你的 AWS 账户中已有 AWS Glue Data Catalog 对象，还需为 Amazon DataZone 配置数据湖权限。

Amazon DataZone 的安全性（Security in Amazon DataZone）

与其他 AWS 服务一样，Amazon DataZone 的数据保护同样遵循 AWS 共享责任模型。Amazon DataZone 提供了一系列安全功能，供你在制定与实施自身安全策略时参考。你可以将以下最佳实践作为安全方案的指导，但仍应依据你的环境与安全需求进行取舍。更详细的安全配置，请参阅《Amazon DataZone 用户指南》中“安全性”相关文档。

基于 Lake Formation 的授权

Amazon DataZone 使用 Lake Formation 的权限模型来授予访问权限。项目一旦订阅了某个资产，该资产就需要由 Lake Formation 管理。将存放数据的 Amazon S3 存储桶加入 Lake Formation 的位置（Location）是切换权限模型的一部分。
Amazon DataZone 抽象并自动化了通过 AWS Lake Formation 在数据生产者与消费者之间共享数据的流程（原本需人工完成）。对于由 Amazon DataZone 管理的资产，系统会根据数据发布方设定的策略，自动完成对底层表的访问兑现，无需管理员介入或进行数据搬移。

加密

Amazon DataZone 默认使用 AWS KMS 由 AWS 拥有并管理的密钥对服务元数据进行加密。你也可以使用自己管理的 KMS 密钥来加密存放在 Amazon DataZone 数据目录中的元数据。
传输加密方面，Amazon DataZone 采用 TLS 与客户端加密；与 Amazon DataZone 的通信始终通过 HTTPS 进行，从而确保数据在传输过程中始终被加密。

实施最小权限原则

在 Amazon DataZone 的典型用例中，你往往需要在组织内不同业务团队之间共享数据。由于基于 Amazon DataZone 的数据网格架构（data mesh）强调去中心化治理，在授权时更应坚持最小权限原则：
明确谁是数据生产者/消费者、他们对 Amazon DataZone 资源需要哪些权限，并由管理员据此授予；只允许在这些资源上执行你希望放行的具体操作。因此，应仅授予完成任务所必需的权限。落实最小权限对于降低安全风险、减轻误操作或恶意行为的影响至关重要。

使用 IAM 角色

在 Amazon DataZone 中，生产者与消费者之间的通信通过 IAM 角色完成，方式类似于 AWS 服务之间的访问。生产端与客户端应用都必须持有有效凭证，并推荐使用 IAM 角色为应用管理临时凭证，以访问 Amazon DataZone 资源。
不建议将 AWS 凭证直接存放在客户端应用或 Amazon S3 中——这类长期凭证不会自动轮换，一旦泄露将带来显著业务风险。
更多安全细节可参阅《Amazon DataZone 的数据保护（Data Protection in Amazon DataZone）》。

小结

本章阐述了 Amazon Redshift 数据共享如何在组织内外实现无缝数据共享，并内建治理与访问控制；你学会了如何在确保安全的前提下，让业务用户使用各自熟悉的工具分析数据、及时决策。无需搬移数据的共享方式可避免 ETL 过程潜在错误，并保持用户用于关键决策的源数据完整性。
我们讨论了多种数据共享用例：工作负载隔离、跨部门协作、分析即服务（AaaS） 、以及提升研发敏捷性；并基于学生信息数据集，构建了三种不同隔离级别的多租户模型。最后，你了解了 Amazon DataZone，以及如何利用该服务在去中心化治理模式下发现与共享数据。
下一章将聚焦于分析环境中的数据安全与治理：详细介绍可应用于 Amazon Redshift 各组件的访问控制（从粗粒度到细粒度），以及如何为 Redshift 可消费的外部服务设置访问控制，例如数据湖数据、业务数据库、流式数据，以及 AWS Lambda、Amazon SageMaker 等服务。