Amazon Redshift 权威指南——Amazon Redshift 入门

Amazon Redshift 让你无需预置服务器或基础设施即可为业务运行分析，因而非常容易上手。它在 AWS 控制台内置基于 Web 的查询编辑器，无需安装软件就能开始装载并分析数据。Amazon Redshift 也兼容你常用的查询编辑器（如 DBeaver、SQL Workbench/J、Toad），可通过提供的 JDBC/ODBC 驱动连接。

在本章中，我们将先给出 Amazon Redshift 架构概览，介绍该平台的关键组件。接着，我们将提供“开始使用 Amazon Redshift Serverless”的步骤，并演示如何通过几次点击就对“示例数据（Sample Data） ”发起查询。我们还会说明“何时使用预置集群（Provisioned Cluster）？ ”，以及如何为无服务器与预置两种数仓“估算你的 Amazon Redshift 成本”。随后，我们会讨论“AWS 账户管理”，介绍如何创建单一账户或在组织内管理多个账户。最后，我们将覆盖“连接到你的 Amazon Redshift 数据仓库”的若干选项，以及如何管理用户访问。

Amazon Redshift 架构概览（Amazon Redshift Architecture Overview）

“名字是什么？玫瑰就算换个名字，依旧芳香如故。”
——《罗密欧与朱丽叶》

莎士比亚借此句表达命名本身并不重要之意。

关于 Redshift 这个名字的由来有多种说法。我们发现，它源自天文学与物理学中的**红移（Red Shift）现象：随着空间“膨胀”，光的波长被拉长，因而在可见光谱中向红色（长波端）**偏移。

由于数据在持续扩张，Amazon Redshift 提供了一个可无缝扩展的存储与分析平台。作为首个完全托管、PB 级的云数据仓库，Amazon Redshift 相比本地数据仓库是一种架构上的跃迁：后者通常需要前期资本投入、扩容成本与专职运维资源。

Amazon Redshift 数据仓库兼容 ANSI SQL，面向 OLAP 工作负载，数据以压缩列式格式存储。该服务既可作为**预置集群（provisioned）提供，也可作为无服务器（serverless）**提供。

图 2-1 展示了一个预置集群。在最新一代 RA3 节点类型下，你可以按需独立扩展计算与存储以匹配工作负载。该节点类型的存储为 Amazon Redshift Managed Storage（RMS） ，其底层由 Amazon S3 支撑。

图 2-1 Amazon Redshift 架构

无服务器架构（见图 2-2）会自动执行多项运维活动，用于监控与伸缩 Amazon Redshift。Redshift Serverless 借助基于机器学习的工作负载监控系统，可自动扩展计算资源以满足负载需求。随着并发用户与新负载的增加，数仓会自动扩展以提供一致的查询执行时间。此外，使用无服务器的上手体验更为简单：仅在使用时计费。结合 RMS 的数据共享能力，某个部门可以在隔离的数仓中使用无服务器分析共享数据，而不影响该共享数据本身。由于不存在“空转付费”，你的团队无需联系管理员去暂停或恢复数仓。

图 2-2 Amazon Redshift 无服务器架构

无论预置还是无服务器，Amazon Redshift 都基于 MPP 框架，由多个 EC2 节点构成，包括 Leader 节点与一个或多个计算节点。此外，Redshift 还包含代码编译、查询计划缓存、结果缓存、数据湖访问、并发扩展（CS）、机器学习、联邦查询与数据共享等组件。后续章节将详细介绍。

借助 Amazon Redshift，你可以在数分钟内上手，并以无服务器或预置方式分析数据。我们将从创建无服务器数据仓库并使用示例数据集运行查询开始。

开始使用 Amazon Redshift Serverless（Get Started with Amazon Redshift Serverless）

Amazon Redshift 的无服务器与预置两种形态在功能上有大量重叠：都能装载与查询结构化/半结构化数据、对 PostgreSQL/MySQL 等业务数据库进行联邦查询、以及查询数据湖中的数据。此外，无服务器与 RA3 预置数仓都建立在 RMS 之上，因此二者均可访问由其他 Redshift 数仓（不论预置或无服务器）产出的数据。尽管针对具体工作负载在两者之间的选择仍有考量，但无服务器显然是最快速的上手途径。

创建 Amazon Redshift 无服务器数据仓库（Creating an Amazon Redshift Serverless Data Warehouse）

Redshift Serverless 通过 **Workgroup（工作组）**与 Namespace（命名空间）来分别管理计算与存储：

• Namespace（命名空间） ：数据库对象的集合，包括数据库、模式（schema）、表、用户、用户权限，以及用于加密数据的 AWS KMS 密钥；还包含 datashare、恢复点（recovery points）与用量限制（usage limits） 等资源。
• Workgroup（工作组） ：计算资源的集合，包括 RPU 基础算力、VPC 子网组、安全组与相关限制。

你可以通过 AWS 控制台、AWS CLI 或 Redshift Serverless API 配置命名空间（存储）与工作组（计算）的属性。

要在 AWS 控制台中部署无服务器数仓，请进入 Create Workgroup 页面并选择配置选项。首先指定工作组名称；然后选择基础 RPU 容量作为初始计算能力（Redshift Serverless 在开始处理工作负载时使用该容量，并可按需自动扩容）。你可以选择最低 8 RPU、最高 512 RPU，默认 128 RPU。关于如何为你的场景确定合适的 RPU 大小，参见“Amazon Redshift Serverless 计算成本”。

最后，选择安全配置（见图 2-3）。这决定了你的数仓在网络拓扑中的部署位置。默认会部署在默认 VPC、子网与安全组中；你可以使用默认设置，或逐项自定义。关于网络配置（私有/公有 VPC 与安全访问）的更多讨论，参见“Private/Public VPC and Secure Access”。

图 2-3 工作组名称与安全配置

接着，新建一个命名空间（见图 2-4），或将工作组关联到已有命名空间。命名空间将承载你的数据库对象。

图 2-4 命名空间

如果创建新命名空间，系统会提示你指定权限与管理员凭据（见图 2-5）。与预置集群类似，权限通过 IAM 角色定义，工作组可**假设（assume）**该角色以访问你 AWS 环境中的其他资源。如下例所示，我们创建了一个 RedshiftRole，授予其 AmazonRedshiftAllCommandsFullAccess 策略，并将其设为默认。

注意：与 Redshift 数仓关联的 IAM 角色定义的是 Redshift 服务可访问的 AWS 服务与资源（如对 S3 的读写）；这不同于赋予数据库用户/组/角色的数据库内权限。

图 2-5 权限与管理员凭据

最后，为新命名空间选择是否要自定义加密与日志（见图 2-6）。

图 2-6 加密与日志

完成后，你可以在 Redshift Workgroups 页面查看工作组列表（图 2-7），获取工作组端点以及 JDBC/ODBC URL 等信息。关于连接选项，参见“连接到你的 Amazon Redshift 数据仓库”。

图 2-7 工作组列表

当配置为 8 或 16 RPU 时，支持的 RMS 容量上限为 128 TB。如果你的托管存储超过 128 TB，则不能将 RPU 降级到 32 RPU 以下。

示例数据（Sample Data）

当你让 Amazon Redshift 运行起来之后——无论使用无服务器还是预置模式——就可以开始创建构建数据仓库方案所需的数据模型。

当你创建 Amazon Redshift 无服务器数据仓库时，系统会提供 3 个示例数据集供你上手交互。第一个数据集 tickit 由 7 张表组成：2 张事实表与5 张维度表（见图 2-8）。该示例数据库应用帮助分析师跟踪虚构网站 Tickit 的销售活动（用户在此网站在线买卖体育赛事、演出与音乐会的门票）。分析师可以识别门票随时间的流转、卖家的成交成功率，以及最畅销的活动、场馆与季节。分析师可据此为高频买卖双方制定激励措施，吸引新用户，并推动广告与促销。

图 2-8 Tickit 示例数据模型

启用示例数据模型并使用查询编辑器发起查询

（Activate Sample Data Models and Query Using the Query Editor）

你可以使用 Amazon Redshift Query Editor V2 来启用示例数据集并开始查询。关于如何使用 Query Editor V2 的更多细节，参见“使用 Query Editor V2 查询数据库”。完成认证后，展开 sample_data_dev 数据库；然后点击各个 schema 旁边的文件夹图标以打开示例笔记本（见图 2-9）。这一步会创建示例的数据模型表、数据以及与之相关的查询。Query Editor V2 同时支持笔记本与编辑器两种界面。启用数据集时，示例查询也会在笔记本界面中打开，你即可对数据执行查询。

图 2-9 查询 tickit 示例数据集

启用示例数据集后，你就可以开始查询数据。先从笔记本中提供的查询里，尝试以下基于 tickit 数据的示例。

第一个查询（示例 2-1）用于统计每个活动的总销售额。

示例 2-1 每个活动的总销售额（Total sales revenue per event）

SELECT e.eventname, total_price
FROM (
  SELECT eventid, sum(pricepaid) total_price
  FROM   tickit.sales
  GROUP BY eventid) Q, tickit.event E
WHERE Q.eventid = E.eventid
QUALIFY ntile(1000) over(order by total_price desc) = 1
ORDER BY total_price desc;

第二个查询（示例 2-2）用于获取某一天的总销售数量。

示例 2-2 指定日期的总销售数量（Total sales quantity for a date）

SELECT sum(qtysold)
FROM   tickit.sales, tickit.date
WHERE  sales.dateid = date.dateid
AND    caldate = '2008-01-05';

你也可以点击 + 按钮并选择 Editor 菜单项，打开查询编辑器界面（见图 2-10）。

图 2-10 在编辑器模式下查询 tickit 示例数据集

在编辑器中输入以下查询并运行查看结果。该查询（示例 2-3）用于检索前 10 位买家的总购买数量。

示例 2-3 前 10 位买家的总销售数量（Total sales quantity for top 10 buyers）

SELECT firstname, lastname, total_quantity
FROM   (SELECT buyerid, sum(qtysold) total_quantity
        FROM  tickit.sales
        GROUP BY buyerid
        ORDER BY total_quantity desc limit 10) Q, tickit.users
WHERE Q.buyerid = userid
ORDER BY Q.total_quantity desc;

下面这个查询（示例 2-4）用于查找历史总销售额处于 99.9 分位的活动。

示例 2-4 处于销售额 99.9% 分位的活动（Events in the 99.9% of sales）

SELECT eventname, total_price
FROM  (SELECT eventid,
        total_price,
        ntile(1000) over(order by total_price desc) as percentile
       FROM (SELECT eventid, sum(pricepaid) total_price
             FROM   tickit.sales
             GROUP BY eventid)) Q, tickit.event E
       WHERE Q.eventid = E.eventid
       AND percentile = 1
ORDER BY total_price desc;

另外两个数据集是 tpch 与 tpcds，它们来自 tpc.org 的标准基准数据集。TPC-H 与 TPC-DS 属于决策支持基准，包含一组面向业务的即席查询与并发数据修改；其查询与数据设计旨在具有广泛的行业相关性，可代表性地评估通用决策支持系统的性能。

这些数据模型位于 sample_data_dev 数据库中的同名 schema：tpch 与 tpcds。像之前对 tickit 那样，点击各 schema 名称旁的文件夹图标即可启用相应数据模型并访问相关对象。此操作会在笔记本界面中打开所有示例查询（见图 2-11）。现在可以尝试运行示例查询：第一个查询会返回被计费、发货与退货的业务量。

图 2-11 查询 tpch 示例数据集

何时使用预置集群？（When to Use a Provisioned Cluster?）

Amazon Redshift 提供第二种部署选项，使你可以对数据仓库拥有更多可控性。在设置 Amazon Redshift 数据仓库时，关键考量是选择最契合你的工作负载的配置与架构，从而获得开箱即用的最佳性能。

亚马逊创始人 Jeff Bezos 在 2020 年 11 月 23 日的一篇文章中写道：

决策分两类：有些是不可逆且影响重大的，我们称之为“单向门”（one-way doors）[…] 这类决策需要慢且谨慎地做。我在亚马逊时常扮演“首席减速官”的角色：“等一下，这个决策影响很大且不可逆，我还想再从 17 个角度分析一遍。”问题在于，大多数决策并非如此，大多数是双向门（two-way doors）。

如 Bezos 所言，在无服务器与预置之间选择是一个双向门决策；即便一开始没有选到最优配置，由于 Amazon Redshift 是按需付费的云方案，可在数分钟内增加或移除容量。你的分析架构设计应当且可以基于快速试验与验证。

预置集群为你提供细粒度调优能力：你可以控制何时与如何调整集群规模、手动配置工作负载管理（WLM），以及决定何时暂停/恢复数据仓库。虽然预置集群的运维工作更多一些，但它为可预测负载提供了更多优化成本与性能的选项。若你的负载非常稳定且恒定，使用预置集群并购买预留实例往往是更具成本优化的方案。

在设计生产数仓架构时，你有多种选择：需要决定是否把负载放在一个 Redshift 数仓，或拆分/隔离到多个 Redshift 数仓；并在单仓或多仓的前提下，决定使用预置还是无服务器。下例（图 2-12）展示了两种支持同一工作负载的不同策略。

图 2-12 Amazon Redshift 部署选项

在第 1 章 “AWS for Data” 中，你已经了解到现代数据架构鼓励分布式团队独立拥有并设计其面向领域的解决方案。下面的 Amazon Redshift 数据网格架构（图 2-13）展示了一种同时利用一个预置数仓与多个无服务器数仓的方案。在该环境中：

1）使用一个预置数仓进行多源数据摄取，因为该负载稳定且在一天中长时间运行。你可以购买预留实例并对可预测的成本拥有完全掌控。
2）再设置一个无服务器数仓，通过数据共享读取预置数仓中的数据；该无服务器数仓的用户既读取共享数据，也会装载自己的数据、与共享数据进行关联并按需汇总，进而精选（curate）出新的数据集。该无服务器数仓的用户就成为其领域/部门数据的“维护者”。他们可以访问领域外的数据，但不再依赖其他组织的处理节奏。
3）最后，再设置另一个无服务器数仓，同样通过数据共享从预置数仓读取数据，并读取（2）中无服务器数仓精选出的数据集。每个负载在需要的计算量、运行时段与活跃时长等方面的画像各不相同。

图 2-13 Redshift 数据网格架构

无论你选择哪种部署选项，在两者之间切换都可以使用快照/还原（snapshot/restore）流程。关于如何将预置集群的快照还原为无服务器数据仓库的更多细节，请参见在线文档。

创建 Amazon Redshift 预置集群（Creating an Amazon Redshift Provisioned Cluster）

使用预置（provisioned）选项部署 Amazon Redshift，意味着你将按某种节点类型预置若干计算节点，组成一个集群（cluster） 。要部署 Redshift 预置集群，请前往 Create Cluster 页面并选择你的配置项。你也可以参照 AWS 文档中的步骤创建一个示例 Redshift 集群。

在第一步中，你将选择集群名称与规模（见图 2-14）。关于如何为你的使用场景确定最佳集群规模，参见“Amazon Redshift Provisioned Compute Cost”。

图 2-14 集群名称与规模

接下来，你可以选择是否装载示例数据（可选）并设置管理员凭据（见图 2-15）。

图 2-15 装载示例数据并设置管理员凭据

随后，通过分配 IAM 角色来指定集群权限（见图 2-16），以便你的 Redshift 集群可以代表你访问 AWS 环境中的其他资源。若你计划从 Amazon S3 批量装载数据到 Redshift，则需要这些权限。托管策略 AmazonRedshiftAllCommandsFullAccess 可关联到你的角色，涵盖常见的相关服务。下面的示例中，我们创建了 RedshiftRole，为其分配 AmazonRedshiftAllCommandsFullAccess 策略，并将其设为默认。关于授权 Redshift 代表你访问其他 AWS 服务的更多细节，请参见联机文档。

图 2-16 集群权限

最后，配置集群的附加设置（见图 2-17）。这些设置决定了你的集群在网络配置中的部署位置。默认情况下，集群会部署在默认 VPC、子网与安全组中；你可以沿用默认值或逐项自定义。关于网络配置考量的更多讨论，参见“Private/Public VPC and Secure Access”。

图 2-17 集群附加配置

在 Redshift Clusters 页面可以看到你的集群列表（见图 2-18）。点击某个集群，你可以查看集群端点以及 JDBC/ODBC URL 等通用信息。关于连接选项，参见“连接到你的 Amazon Redshift 数据仓库”。

图 2-18 集群列表

估算你的 Amazon Redshift 成本（Estimate Your Amazon Redshift Cost）

在估算 Redshift 成本时，主要考虑存储与计算两个因素。对于 RA3 节点类型与无服务器，需要将托管存储与计算成本分开考虑（无服务器计算成本或预置计算成本）。若你使用 DC2 节点类型，则只需考虑预置计算成本，因为所有存储都在计算节点本地。

Amazon Redshift 托管存储（Amazon Redshift Managed Storage, RMS）

RMS 采用压缩的列式数据结构，为分析型工作负载的性能而设计。它与计算分离、具备弹性，可从 TB 扩展到 PB。无论是 RA3 预置还是无服务器，RMS 都可以在数仓之间共享；即便某个数仓未处于活跃状态，消费者仍可访问共享数据。例如：若数据的主拥有者是一个预置集群，即便该集群处于暂停状态，消费者仍能访问该数据。这使你可以为不同工作负载选择合适的计算形态，而无需搬移或转换数据；也避免了数据复制，从而降低维护与存储成本。由于你可以在不同计算选项之间自由切换，且即使计算不运行存储仍可用，存储按独立维度计费。

要估算使用 RA3 集群或无服务器数仓时的存储成本，可用压缩后容量 × 月度单价估算。例如存储用量为 10 TB，若价格为 $0.024/GB·月**，则月存储费用为 **$240：

$0.024 * 10 * 1000 = $240

关于 RMS 最新定价，请参见联机文档。

Amazon Redshift 无服务器计算成本（Amazon Redshift Serverless Compute Cost）

对于无服务器，除 RMS 成本外，还需考虑计算成本。Redshift 为计费引入了 RPU 这一计量单位（见图 2-19），表示一段时间内所使用的计算能力。创建工作组时，默认基础容量（base capacity）为 128 RPU。当无服务器从空闲唤醒时使用该基础容量，并在需要更多计算时自动扩容。你可以在配置中编辑 Limits 来调整基础容量。

图 2-19 Amazon Redshift 无服务器基础容量

每条查询都会记录，你只在工作组实际运行查询的时段计费（每次事务最少按 60 秒计）。例如：若使用默认 128 RPU，在某一小时内只提交了 1 条查询，运行 90 秒。以 us-west-2 $0.45/RPU·小时**计费，费用为 **$1.44：

rate/sec = $0.45*128/60/60 = $0.016
secs     = max(90, 60)     = 90
rate*secs= $0.016*90       = $1.44

如果这是一个定时仪表盘，会同时触发 3 条并发查询（15s、30s、90s），最长的 90 秒完成，并且这一小时内只有这批负载，则仍只收 $1.44（工作组仅在这 90 秒内处于运行态，且用 128 RPU 基础容量便完成）：

rate/sec = $0.45*128/60/60 = $0.016
secs     = max(15,30,90,60)= 90
rate*secs= $0.016*90       = $1.44

设定不同的基础容量（Setting a different value for the base capacity）

若将基础容量设为 8 RPU（即 1/16 计算力），原本 90 秒完成的负载很可能需要 16 倍时间（1440 秒），价格仍为 $1.44：

rate/sec = $0.45*8/60/60 = $0.001
secs     = max(1440,60)  = 1440
rate*secs= $0.001*1440   = $1.44

在 8 RPU 这样的小基线下，若查询内存占用很大，可用内存更少、可能发生分页到磁盘，导致时长超过 1440 秒；也有可能因为原 90 秒包含某些不可线性外推的开销而实际用时更短。

另一个考量是60 秒最小计费。如果你有大量短于 60 秒且查询间存在空闲的作业，使用更小的基础容量配置，单查询成本会更低。

例如：某查询在 128 RPU 下运行 1 秒、在 8 RPU 下运行 16 秒；若这一分钟内只运行这 1 条查询，则二者都会触发各自的60 秒最小计费，价格相差 16 倍：

8  RPU rate/sec = $0.001
secs            = max(1,60)  = 60
rate*secs       = $0.060

128 RPU rate/sec= $0.016
secs            = max(16,60) = 60
rate*secs       = $0.960

高频/频繁使用（High/frequent usage）

再如：你有一个流式应用，每分钟向数仓加载一次，但每次加载只需 5 秒（见图 2-20）。由于无服务器对每次事务至少按 60 秒计费，即使每次仅运行 5 秒，也会按 60 秒计。

图 2-20 流式使用时间线

在该例中，总执行时间为 5*60=300 秒，但应用最小计费后，计费时长为 60*60=3600 秒。以 us-west-2 $0.45/RPU·小时**计费，费用为 **$57.60：

rate/sec = $0.45*128/60/60 = $0.016
secs     = max(5,60)*60    = 60*60 = 3600
rate*secs= $0.016*3600      = $57.60

在这些场景中，建议基于查询 SLA 与预算，对基础容量进行实验以找到合适配置；记住你只为实际使用的计算付费。

关于 Redshift 最新定价（含预留容量的节省额度），请参见联机文档。

Amazon Redshift 预置计算成本（Amazon Redshift Provisioned Compute Cost）

对于 RA3 预置集群，除存储成本外，关键的额外成本来自集群规模。规划预置数仓的第一步，是确定节点类型与节点数量。在确定 Amazon Redshift 预置集群规模时，请根据满足分析处理性能 SLA 所需的稳定态计算能力来评估。每种节点类型都有其计算画像（compute profile） ，规格越大、价格越高，你可以据此选择最适合需求的节点类型与数量。下表（表 2-1）汇总了截至 2023 年各节点类型的每节点资源分配。如需最新的计算画像与节点类型说明，请参见联机文档。

表 2-1 RA3 节点类型（RA3 node types）

节点类型	RMS	内存	vCPU
ra3.xlplus	32 TB	32 GB	4
ra3.4xlarge	128 TB	96 GB	12
ra3.16xlarge	128 TB	384 GB	48

在确定节点规格与节点数量时，请结合你的处理需求。从较大节点规格起步，当显著超出性能 SLA 时再考虑换用更小规格。该策略有助于在节点间数据洗牌（shuffle）时减少网络流量。例如，就 vCPU 与内存而言，2 台 ra3.16xlarge ≈ 8 台 ra3.4xlarge ≈ 24 台 ra3.xlplus。如果你以 ra3.16xlarge 起步，发现远超性能 SLA 且CPU 利用率较低，可以使用resize 选项将集群调整为更小的节点类型。关于集群调整的更多信息，请参见联机文档。

如果你尚未运行实际负载、需要一个初始集群规模，Redshift 控制台提供了一个工具（图 2-21）可帮助你在考虑所需存储量及工作负载等参数的基础上选择合适的集群规模。

图 2-21 Help me choose

Amazon Redshift 预置集群的一个关键计费方面是：你可以选择按需计费（On-Demand） ，也可以购买预留实例（Reserved Instances）以获得固定成本与较大折扣。在 Help Me Choose 工具中，会给出计算成本汇总（图 2-22）。
承诺 1 年预留可享约 33% 折扣，承诺 3 年预留可享约 61% 折扣。

图 2-22 示例成本估算

对于 Amazon Redshift 预置集群，有若干特性会带来额外的可变成本；相比之下，在 Redshift 无服务器里这些能力被打包计入 RPU：

• 并发扩展（Concurrency Scaling） ：在突发活动期间自动配置临时集群。
• Amazon Redshift Spectrum：使用独立的计算资源来查询 Amazon S3 数据湖中的数据。

第 5 章“扩展与性能优化”将更详细讨论并发扩展；第 3 章“数据建模与数据摄取”与第 4 章“数据转换策略”将详细说明如何查询外部数据。此处提前提及，是为了强调你可以控制这些特性，从而获得更可预测的成本结构。

AWS 账户管理（AWS Account Management）

要启动包括 Amazon Redshift 在内的任一 AWS 服务，你都需要一个 AWS 账户。AWS 账户由创建该账户的根用户（root）所有。创建账户后，你可以通过 IAM（Identity and Access Management） 创建其他用户并分配权限。之所以强调账户，是因为与其他 AWS 服务相同，你可以通过在不同账户中启动 Redshift 数仓来建立边界，例如将开发与生产分离（见图 2-23）。

图 2-23 AWS Control Tower、AWS Organizations 与 AWS 账户

AWS Organizations 可帮助你集中管理多个 AWS 账户、分配资源、将账户分组为组织单元（OU） 、在 OU 级别应用治理与安全策略，并通过指定管理账号（management account）来合并计费、享受数量折扣。其他账户为成员账号。

设立一个专门的安全 OU并使用隔离的审计账号，可让安全团队快速审阅整个组织的访问；单独的日志账号可集中所有日志文件；当你能将所有数据相关联时，端到端问题排查也更容易。可参考“使用 AWS Organizations 最佳实践搭建多账号 AWS 环境”的短视频。

与其手动设计 AWS Organizations 与多账号，不如使用 AWS Control Tower。它是一个独立服务，提供规范化（prescriptive）体验，按最佳实践蓝图自动搭建 Organizations 与账户，并使用**预置的服务控制策略（SCP）**与治理规则覆盖安全、运维与合规。

无论你是新上云，还是已有多账号环境，都可以使用 AWS Control Tower。它会自动搭建着陆区（landing zone）以便将外部文件引入分析环境，施加护栏（guardrails）用于持续治理，自动化资源供给工作流，并提供预置看板以在 OU、账户与护栏之上获得可视化。更多详情可观看短视频 “What Is AWS Control Tower?” 。

连接到你的 Amazon Redshift 数据仓库（Connecting to Your Amazon Redshift Data Warehouse）

当你确定了部署架构后，下一个需要自问的问题就是：如何控制对数据的访问以满足安全要求。如今 IT 组织面临的固有挑战，是在确保安全的同时，让数据平台的访问灵活且易于管理。管理员需要能够为所有需要访问的人开通权限与工具，并确保方式符合公司策略、且通过批准的网络路径访问。
根据你需要管理的用户数量，以及你是否已有用于用户管理、认证与授权的基础设施，你可能会在若干策略中做出取舍。连接建立后，用户的身份会存储在 Amazon Redshift 的元数据中；该身份可以被分配到一个或多个组，授权所用的角色以及该用户的活动都会被记录以便追溯。Amazon Redshift 提供多种功能以实现安全且灵活的访问；选择哪些选项需要综合多方面考量。此外，AWS 也提供了多种访问 Redshift 的工具，并有多种方式结合这些安全功能使用。

私有/公有 VPC 与安全访问（Private/Public VPC and Secure Access）

无论选择无服务器还是预置形态，Amazon Redshift 总是部署在 VPC 与子网中。根据你的选择，数仓可以仅允许内部资源访问，或允许公网资源访问。关于如何为你的组织确定最佳 VPC 策略，可在联机文档中查阅 VPC 场景。
此外，当你使用基于 JDBC/ODBC 驱动的工具连接 Redshift 时，实质是通过 TCP/IP 连接到特定主机名与端口。与任何部署在 VPC 内的 AWS 服务一样，你可以通过自定义附加到数据仓库的安全组的入站规则来控制流量。关于安全组与入站规则的更多内容，参见联机文档。最后，如果 Redshift 需要访问VPC 外或其他 AWS 账户中的 AWS 服务，**VPC 端点（VPC endpoint）**可能适用。可在联机文档了解更多。

下图示例架构（图 2-24）含有私有子网 + AWS Direct Connect，企业用户常用，因为它能够限制访问，仅允许公司内网用户或通过 VPN 的外部用户接入。为确保至 AWS 云的高带宽与安全连接，该架构利用 Direct Connect；虚拟私有网关（Virtual Private Gateway）确保传输数据安全且加密。配置正确时，AWS 云中的资源（如 Redshift 数据仓库与分析工具）均可通过私有 IP 访问，无论用户在内网还是外部客户端。

在 AWS 内，Amazon Redshift 部署于私有子网，意味着其无直连互联网的能力，任何访问都必须来自 VPC 内或经由虚拟私有网关。然而，部分 AWS 服务并不运行在你的 VPC 内。对 Redshift 的 COPY/UNLOAD 至关重要的 Amazon S3 就是关键一例。为确保 S3 与 Redshift 之间的数据传输走你的 VPC，需要启用增强型 VPC 路由（enhanced VPC routing） ，并在私有子网的路由表中配置指向 S3 的 VPC 端点。关于增强型 VPC 路由的配置方法，参见联机文档。

图 2-24 私有子网 + AWS Direct Connect

存储密码（Stored Password）

在 Redshift 中维护用户最简单的机制，是创建本地用户并将密码存储在 Redshift 元数据中。这几乎适用于任何数据库平台，可通过 CREATE USER 轻松完成，例如：

CREATE USER name PASSWORD 'password';

该策略通常用于用户很少的场景；随着用户数量增长，运维开销会随之上升。

临时凭证（Temporary Credentials）

仅适用于预置集群的一种方式是临时凭证。它基于 GetClusterCredentials API：该调用接受 DbUser 与 DbGroups 参数（用于将用户加入一个或多个数据库组以实现授权），以及 AutoCreate 参数（若设置，将在数据库中自动创建用户）。API 返回该用户的临时密码，拿到后即可用用户名 + 临时密码登录。

要在预置数仓中使用临时凭证，用户需先通过认证并关联到一个 IAM 身份（IAM 用户或扮演的 IAM 角色）。该身份需要拥有允许调用 redshift:GetClusterCredentials 的 IAM 策略。若需动态创建用户/加入组，可附加 redshift:CreateUser 与 redshift:JoinGroup。为避免越权，建议在策略中收窄范围，加入条件确保获取临时凭证的DbUser 与其自身身份匹配。以下示例策略授予用户访问 dev 数据库与加入 marketing 组的权限，并通过条件确保 aws:userid 与传入的 DbUser 一致（用于 GetClusterCredentials）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "redshift:GetClusterCredentials",
        "redshift:CreateUser",
        "redshift:JoinGroup"
      ],
      "Resource": [
        "arn:aws:redshift:*:123456789012:cluster:rs-cluster",
        "arn:aws:redshift:*:123456789012:dbuser:rs-cluster/${redshift:DbUser}",
        "arn:aws:redshift:*:123456789012:dbname:rs-cluster/dev",
        "arn:aws:redshift:*:123456789012:dbgroup:rs-cluster/marketing"
      ],
      "Condition": {
        "StringLike": {
          "aws:userid": "*:${redshift:DbUser}"
        }
      }
    }
  ]
}

除通过已登录的 IAM 身份来查询 Redshift 外，这一策略也内置进了 JDBC/ODBC 驱动：只需指示驱动使用 IAM 认证并传入你的 IAM 身份。如何配置 JDBC/ODBC 使用 IAM 凭证，请参见联机文档。

传递 IAM 身份的简单方式是提供 AccessKeyID 与 SecretAccessKey。示例 JDBC URL：

jdbc:redshift:iam://examplecluster:us-west-2/dev?
    AccessKeyID=AKIAIOSFODNN7EXAMPLE&
    SecretAccessKey=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

联邦用户（Federated User）

另一种方式是联邦用户。预置集群使用 GetClusterCredentialsWithIAM，无服务器使用 GetCredentials。与 GetClusterCredentials 类似，这些 API 会为用户获取临时密码；不同之处在于：它们不通过参数传入授权信息，而是根据已登录身份读取。

• 无服务器：从 aws:userid 读取用户名，并从主体标签 RedshiftDbRoles 读取数据库角色以授权会话。
• 预置：读取存于 aws:userid 的用户名。

两种情况下，若用户不存在，默认会自动创建。拿到临时密码后即可登录。

与 GetClusterCredentials 相同，要使用联邦用户，用户需先通过认证并关联到一个 IAM 身份。该身份需要允许调用：预置为 redshift:GetClusterCredentialsWithIAM，无服务器为 redshift-serverless:GetCredentials。使用联邦用户方案时，无需额外权限；若是无服务器并需启用基于角色的授权，需确保所用 IAM 身份设置了 RedshiftDbRoles 主体标签。下面是授予访问 dev 数据库的示例策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:*:123456789012:workgroup/rs-workgroup"
    }
  ]
}

与 GetClusterCredentials 一样，联邦用户也内置在 JDBC/ODBC 驱动中；当你在驱动中声明使用 IAM 认证时，连接无服务器数仓默认采用此方式。配置方法请见联机文档。

基于 SAML 的 IdP 认证（SAML-Based Authentication from an Identity Provider）

在企业与大规模部署中，用户身份通常不存放在 IAM，而是存放在 Okta、Azure AD、PingFederate 等 IdP 中。若是如此，在 IAM 或 Redshift 元数据里再维护一套目录既不可扩展，用户可能还隶属多个组，按组组合维护独立 IAM 角色会极其困难。AWS 原生支持通过 AssumeRoleWithSAML 从 IdP 建立 IAM 身份。在此策略下，可扮演一个拥有 GetClusterCredentials 权限的 IAM 角色。该能力已内置在 Redshift 的 JDBC/ODBC 驱动中。图 2-25 展示了在建立与 Redshift 的连接前，SQL 客户端如何与 IdP、AWS STS 与 IAM 交互。

图 2-25 SAML 认证

关于支持的不同 IdP 与特性（如多因子认证），请参见联机文档。
关于配置 Okta IdP 的分步指南，可参考使用 OktaCredentialsProvider 插件的博客；如需多因子认证，可参考使用 BrowserSamlCredentialsProvider 的相关文章。

无论使用 Okta 还是其他 IdP，通用步骤为：

1. 在 IdP 中创建一个SAML 应用供用户访问；
2. 将应用配置为引用 IAM 角色并传递用户/组信息；
3. 从 IdP 下载该应用的元数据；
4. 在 AWS 控制台中创建 IdP并导入元数据。

原生 IdP 集成（Native IdP Integration）

当应用可通过 OAuth 令牌建立信任关系时，Redshift 还提供如 BrowserAzureOAuth2CredentialsProvider 等插件。此时不依赖 API 或 IAM 来建立信任，而是由 Redshift 驱动直接向 IdP 发起初始请求，校验凭据并（如需）弹出 MFA，然后获取 OAuth 令牌；接着 Redshift 服务使用该令牌向 IdP 获取组授权信息。图 2-26 给出了与 Microsoft Power BI 的原生 IdP 架构，以及使用 Azure Active Directory 作为 IdP 时的工作流程。

图 2-26 原生 IdP 架构

关于将 Power BI 与 Active Directory 的原生 IdP 集成起来的详细步骤，可参见相关博客。

Amazon Redshift Data API

连接并查询 Redshift 的另一种方式是使用 Amazon Redshift Data API（见图 2-27）。在该策略下，用户不直接连接 Redshift，而是连接到一个安全的 HTTP 端点；你可以使用该端点在无需管理连接的情况下运行 SQL。Data API 的调用是异步的。应用需能够访问互联网；若在私有 VPC 中运行应用，可配置 VPC 端点。如何配置端点，参见联机文档。

图 2-27 Amazon Redshift Data API

使用 Data API 前，用户需先在 AWS 中通过认证并关联到 IAM 身份。该身份需要拥有 redshift-data: 前缀的一组权限，例如元数据查询（ListTables, ListSchemas）、执行命令（ExecuteStatement, GetStatementResults）与监控查询（DescribeStatement）。完整命令列表见联机文档。

使用 Data API 时有两种认证方式：

• 临时凭证：调用 API 时传入 DbUser，且不传 SecretArn（详见“临时凭证”）。
• 存储密码：调用 API 时传入 SecretArn，且不传 DbUser（详见“存储密码”）。

下面示例演示如何使用 Data API，配合存储于 Secrets Manager 的凭据执行一个简单的 CREATE SCHEMA：

aws redshift-data execute-statement \
  --database <your-db-name> \
  --cluster-identifier <your-cluster-id> \
  --secret-arn <your-secret-arn> \
  --sql "CREATE SCHEMA demo;" \
  --region <your-region>

关于如何更全面地使用 Amazon Redshift Data API 的指南，可参考相关博客。

使用 Query Editor V2 查询数据库（Querying a Database Using the Query Editor V2）

在确定好认证策略之后，下一步就是查询你的数据。Amazon Redshift 提供两个版本的查询编辑器——旧版查询编辑器与 Query Editor V2（见图 2-28），二者都可用于在 Redshift 数仓中编写并运行查询。虽然旧版仍可使用，但我们推荐采用 Query Editor V2，因为它具备更多功能：除编辑与运行查询外，还可管理数据库对象、可视化结果，并与团队共享你的工作。它以树形面板展示数据库、模式与所有对象，便于快速访问。

图 2-28 Query Editor V2

Query Editor V2 有两种标签页类型（见图 2-29）：Editor 与 Notebook。

• Editor 标签页可将所有查询集中在一页并一次性触发执行；它会按顺序执行所有查询，并在不同结果选项卡中展示结果。
• SQL Notebook 标签页包含 SQL 与 Markdown 单元格，可在单个文档中组织、注释并共享多条 SQL。

脚本与笔记本都可保存并分享以便协作。本文全书将使用 Query Editor V2，这也是 Redshift 查询的未来方向。

图 2-29 Query Editor V2 的标签类型

在 AWS 控制台中访问 Query Editor V2，可点击 Query data 按钮下方的链接（见图 2-30）。

图 2-30 Query data

要让用户可访问 Query Editor V2，可将下表任一 AWS 托管策略附加到 IAM 用户或角色（表 2-2）。这些托管策略也会授予访问所需的其他相关服务的权限。若需自定义，也可创建自管策略。

表 2-2 Query Editor V2 策略

策略	说明
AmazonRedshiftQueryEditorV2FullAccess	授予对 Query Editor V2 的完全访问，主要供管理员使用。
AmazonRedshiftQueryEditorV2NoSharing	允许使用 Query Editor V2，不含共享能力。用户不能与团队共享查询。
AmazonRedshiftQueryEditorV2ReadSharing	允许使用 Query Editor V2，有限共享。被授予者可以读取团队共享的已保存查询，但不能更新。
AmazonRedshiftQueryEditorV2ReadWriteSharing	允许使用 Query Editor V2，可共享资源。被授予者可读取与更新团队共享的资源。

为实现团队间查询协作，你可以给 IAM 主体打标签。例如，有一组用户属于 marketing_group，你希望他们彼此共享查询：为他们的角色 marketing_role 赋予 AmazonRedshiftQueryEditorV2ReadSharing 策略，并给该角色添加标签 sqlworkbench-team=marketing_group。此后，使用 marketing_role 登录的终端用户即可在 Query Editor V2 中按策略共享查询。

使用查询编辑器连接 Redshift 数仓时，会提示若干连接方式：

• Federated user（联合用户）
• Temporary credentials（临时凭证）
• Database username and password（数据库用户名/密码）
• AWS Secrets Manager

注意：临时凭证选项在 Query Editor V2 中仅适用于预置集群。

联合用户（Federated user）

当在 Query Editor V2 中选择联合用户（见图 2-31）时，预置与无服务器会有不同表现：

• 预置：Query Editor V2 依赖临时凭证方式中的 GetClusterCredentials，但不再提示输入用户/组，而是从两个主体标签读取：RedshiftDbUser 与 RedshiftDbGroups，并将其值传给 API。主体标签可直接在 IAM 设置，也可由 IdP 传入。用于此策略的 IdP 传入的 IAM 角色还需具备使用临时凭证的权限（前文已述）。这种方式可扩展且易用，终端用户只需输入数据库名。关于用 Okta 配置联合登录的详细演示，可参见相关博文。
• 无服务器：Query Editor V2 使用联合用户认证中的 GetCredentials。数据库用户名取自 aws:userid，数据库角色取自主体标签 RedshiftDbRoles。

图 2-31 Query Editor V2 联合用户

临时凭证（Temporary credentials）

临时凭证选项（见图 2-32）与联合用户类似：IAM 身份需要具有使用临时凭证的权限。不同点在于它不依赖主体标签，因此除 Database 外，用户还需手动输入用户名，且不会自动加入任何组。

图 2-32 Query Editor V2 临时凭证

数据库用户名与密码（Database username and password）

选择密码方式（见图 2-33）时，除 Database 与 User name 外，用户须提供密码。为便于后续会话，密码会保存在 Secrets Manager；因此使用查询编辑器的 IAM 身份需具备对 Secrets Manager 的读/写权限。

图 2-33 Query Editor V2 存储密码

AWS Secrets Manager

选择 AWS Secrets Manager（见图 2-34）时，用户只需指定预先创建的 Secret。该 Secret 由管理员预先创建，因而使用查询编辑器的 IAM 身份无需写入 Secrets Manager 的权限。

图 2-34 Query Editor V2 AWS Secrets Manager

更多使用 Query Editor V2 的示例，参见以下博文：

• 《Simplify Your Data Analysis with Amazon Redshift Query Editor V2》
• 《Introducing Amazon Redshift Query Editor V2, a Free Web-based Query Authoring Tool for Data Analysts》
• 《Federate Access to Amazon Redshift Query Editor V2 with AD FS: Part 3》

使用 Amazon QuickSight 的商业智能（Business Intelligence Using Amazon QuickSight）

你可用任意 BI 平台通过 JDBC/ODBC 驱动连接 Redshift（驱动可能随应用打包，或可下载）。常见集成平台包括 MicroStrategy、Power BI、Tableau、Looker。关于使用这些驱动连接 Redshift，参见“使用 JDBC/ODBC 连接 Amazon Redshift”。

AWS 也提供原生云上、无服务器的 BI 服务 Amazon QuickSight，与 Redshift 深度集成，无需额外驱动。QuickSight 采用按用户付费模式，自动扩展，无需运维服务器。你可在 QuickSight Gallery 体验多个在线示例仪表盘。

下图的零售分析示例仪表盘（图 2-35）展示了 QuickSight 的多项关键功能，如内置 ML 的预测与异常检测、可定制叙述与丰富可视化。

图 2-35 QuickSight 示例仪表盘

在众多 QuickSight 数据源（图 2-36）中，连接 Redshift 有两种方式：Redshift Auto-discovered 与 Redshift Manual connect。建立连接后，用户只需几次点击即可开始构建报表与仪表盘。

图 2-36 QuickSight 数据源

• 选择 Redshift Auto-discovered 时，用户选择要连接的 Redshift 实例 ID，并输入数据库、用户名与密码（见图 2-37）。
• 选择 Redshift Manual connect 时，除数据库、用户名与密码外，还需输入数据库服务器与端口（见图 2-38）。

图 2-37 QuickSight Redshift 自动发现连接

图 2-38 QuickSight Redshift 手动连接

使用 JDBC/ODBC 连接 Amazon Redshift（Connecting to Amazon Redshift Using JDBC/ODBC）

许多第三方 BI/ETL 工具通过 JDBC/ODBC 驱动访问数据库平台。Amazon Redshift 提供可下载的开源驱动（不少第三方工具已内置）。AWS 会频繁更新这些驱动以匹配新功能。尽管 Redshift 也兼容 Postgres 驱动，但后者不支持 Redshift 驱动的全部特性（如 IAM 认证）。配置 Redshift 驱动时，可在控制台获取连接 URL。

• 预置集群：在 Cluster summary 页面可找到 JDBC/ODBC URL（图 2-39）。
• 无服务器工作组：在 Workgroup summary 页面可找到 JDBC/ODBC URL（图 2-40）。

图 2-39 Redshift 预置 JDBC/ODBC URL

图 2-40 Redshift 无服务器 JDBC/ODBC URL

下例中，我们使用开源 Java 工具 SQL Workbench/J，基于收集的信息完成客户端配置（图 2-41）。该工具的 Extended Properties 对话框可设置 SAML 认证等功能所需的可选参数。

图 2-41 JDBC 客户端配置

请注意 Autocommit 复选框：该设置常被忽略，但大多数场景应启用。由于 Redshift 遵循 ACID 的原子性（Atomicity） ，它需要在多用户事务之间维持数据状态。若关闭自动提交，Redshift 会把每个连接视为新事务的开始，除非显式 COMMIT，否则不会提交；忽略该设置会导致系统为跟踪多事务状态消耗不必要资源。若遇到此类情况，可使用 PG_TERMINATE_BACKEND 终止空闲连接。

配置 JDBC/ODBC 的更多细节与选项，请分别查阅 JDBC 驱动文档与 ODBC 联机文档。

小结（Summary）

本章介绍了 Redshift 的架构与上手方法，对比了无服务器与预置的部署选项，演示了如何快速查询示例数据，并梳理了认证与连接的不同选择。

下一章将讲解如何针对数据湖、业务库与实时流式来源进行最佳的数据建模与装载。