

 从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

# Amazon Redshift Serverless 的计算容量
<a name="serverless-capacity"></a>

使用 Amazon Redshift Serverless，计算容量可以自动纵向扩展和缩减以满足工作负载需求。计算容量是指分配给 Amazon Redshift Serverless 工作负载的处理能力和内存。常见用例包括处理流量高峰期、运行复杂分析或高效处理大量数据。以下术语提供了有关 Amazon Redshift 如何管理计算容量的详细信息。

**PRU**

Amazon Redshift Serverless 以 Redshift 处理单元 (RPU) 为单位测量数据仓库容量。RPU 是用于处理工作负载的资源。一个 RPU 提供 16 GB 内存。

**基本容量**

 此设置指定 Amazon Redshift Serverless 用于处理查询的基本数据仓库容量。基本容量以 RPU 为单位指定。您能够以 Redshift 处理单元 (RPU) 为单位设置基本容量。设置更高的基本容量可确保提高查询性能，尤其是对于需要大量资源的数据处理作业。Amazon Redshift Serverless 的原定设置基本容量为 128 个 RPU。您可以将**基本容量**设置从 4 个 RPU 调整为 512 个 RPU。您可以将此值设置为 4 个 RPU，或者在 8 个或大于 8 个 RPU 时采用 8 的倍数（8、16、24...512）。您可以使用 AWS 管理控制台、`UpdateWorkgroup` API 操作或 AWS CLI 中的 `update-workgroup` 操作来设置此值。

由于最低基本容量为 4 个 RPU，您可以根据数据仓库的成本和容量需求，灵活地运行从较简单到更复杂的工作负载。4 个基本 RPU 容量面向所含数据少于 32 TB 的仓库，而 8、16 和 24 个 RPU 的基本 RPU 容量面向所需数据少于 128 TB 的工作负载。如果数据要求大于 128 TB，则必须至少使用 32 个基本 RPU。此外，如果工作负载中的表具有大量列数和更高的并发度，我们建议使用 32 个或更多的基本 RPU。

可用的最大基本 RPU 为 1024，可为工作负载添加最高级别的计算资源。这为支持高度复杂的工作负载提供了更大的灵活性，并加快了数据的加载和查询速度。

**注意**  
以下 AWS 区域中提供 1024 的扩展最大基本 RPU 容量。在其它区域中，最大基本容量为 512 个 RPU。  
 美国东部（弗吉尼亚州北部） 
 美国东部（俄亥俄州） 
 美国西部（俄勒冈州） 
欧洲地区（爱尔兰）
欧洲地区（法兰克福）
将基本容量设置在 512-1024 之间时，可以按 32 为单位递增或递减 RPU。

如果您管理更大、更复杂的工作负载，可以考虑增加 Redshift Serverless 数据仓库的大小。较大的仓库可以访问更多的计算资源，从而可以更高效地处理查询。

 下面是一些拥有更高的基本容量会带来好处的实例：
+  查询很复杂，运行需要很长时间。
+  表中有大量的列。
+  查询包含了大量的 JOIN。
+  查询聚合或扫描来自外部源（例如数据湖）的大量数据。

 有关 Amazon Redshift Serverless 配额和限制的更多信息，请转至 [Amazon Redshift Serverless 对象的配额](amazon-redshift-limits.md#serverless-limits-account)。

## Amazon Redshift Serverless 容量的注意事项和限制
<a name="serverless-rpu-capacity-considerations"></a>

Amazon Redshift Serverless 容量有下列注意事项和限制 有关 Redshift Serverless 的一般注意事项，请参阅[使用 Amazon Redshift Serverless 时的注意事项](serverless-usage-considerations.md)。
+ 4 个基本 RPU 的配置支持高达 32 TB 的托管式存储容量。如果您使用的托管式存储超过 32 TB，则无法将基本 RPU 设置为少于 8 个 RPU。
+ 8 或 16 个基本 RPU 的配置支持高达 128 TB 的 Redshift 托管式存储容量。如果您使用的托管式存储超过 128 TB，则无法将基本 RPU 设置为少于 32 个 RPU。
+ 编辑工作组的基本容量，可能会导致工作组上运行的一些查询被取消。
+ Redshift Serverless 使用以下增量为您的数据仓库扩展 RPU：
  + 4 到 8 个 RPU：以 4 个 RPU 为单位递增。
  + 8 到 512 个 RPU：以 8 个 RPU 为单位递增。
  + 512 到 1024 个 RPU：以 32 个 RPU 为单位递增。
+ 只有 8 个或更多的 RPU 才支持 Vacuum boost。对于 8 个及更少的 RPU，请改用以下命令：

  ```
  VACUUM [FULL | SORT ONLY | DELETE ONLY | REINDEX | RECLUSTER] [table_name] [TO threshold PERCENT]
  ```

### 具有 4 个 Redshift 处理器（RPU）容量的 Redshift Serverless
<a name="serverless-rpu-capacity-considerations-4rpu"></a>

具有 4 个基本 RPU 容量的 Redshift Serverless 非常适合较小或要求较低的工作负载。该入口点提供了灵活且经济实惠的解决方案。此入门级配置支持最多具有以下资源的数据仓库：
+ 多达 32 TB 的 Redshift 托管式存储。
+ 每个表最多 100 列 
+ 64 GB 的内存

如果您需要超过这些限制，则必须手动增加基本容量，而不是依赖自动扩缩。一旦您将数据仓库扩展到超过 4 个 RPU，数据仓库将继续使用更多的 RPU，而且 Amazon Redshift 不会将数据仓库缩减回到 4 个 RPU。

**注意**  
使用 4 个基本 RPU 时，您可以创建超过 100 列的表，但我们建议您将表限制在 100 列。超过此限制可能导致数据仓库在查询执行期间耗尽其内存，这会降低性能。

您可以在以下 AWS 区域中创建使用 4 个 RPU 的数据仓库：
+ 美国东部（俄亥俄州）
+ 美国东部（弗吉尼亚州北部）
+ 美国西部（北加利福尼亚）
+ 美国西部（俄勒冈州）
+ 亚太地区（孟买）
+ 亚太地区（新加坡）
+ 亚太地区（悉尼）
+ 亚太地区（东京）
+ 欧洲地区（爱尔兰）
+ 欧洲地区（斯德哥尔摩）

## AI 驱动的扩展和优化
<a name="serverless-auto-optimization"></a>

人工智能驱动的扩展和优化功能适用于提供 Amazon Redshift Serverless 的所有 AWS 区域。

Amazon Redshift Serverless 提供 AI 驱动的高级扩展和优化功能，可满足不同的工作负载要求。数据仓库可能存在以下预置问题：
+ 为了提高资源密集型查询的性能，可能会过度预置数据仓库
+ 为了节省成本，数据仓库可能预置不足。

在数据仓库工作负载的性能和成本之间取得适当平衡具有挑战性，尤其是对于临时查询和在数据量不断增长的情况下。在运行混合工作负载（包括低资源密集型和高资源密集型查询）时，需要进行智能扩展。AI 驱动的扩展和优化功能可根据数据增长自动扩展无服务器计算或 RPU。此功能还有助于将查询性能保持在目标性价比目标范围内。AI 驱动的扩展和优化会随着数据量增加而动态分配计算资源，从而确保查询持续达到性能目标。AI 驱动的扩展和优化使该服务能够无缝适应不断变化的工作负载需求，而无需手动干预或复杂的容量规划。

Amazon Redshift Serverless 根据查询复杂度和数据量等因素，提供更全面、响应更快的扩展解决方案。此功能考虑到优化工作负载的性价比，同时保持灵活性，以高效处理不断变化的工作负载和不断增长的数据集。Amazon Redshift Serverless 可以自动对 Amazon Redshift Serverless 端点进行 AI 驱动的优化，以满足您为无服务器工作组指定的性价比目标。如果您不知道要为工作负载设置多少基本容量，或者您的工作负载的某些部分可能从分配更多资源中获益，则这种自动性价比优化特别有用。

**示例**

如果组织运行的工作负载通常只需要 32 个 RPU，但突然引入了更复杂的查询，那么您可能不确定多大的基本容量才合适。设置较高的基本容量可以提高性能，但也会产生更高的成本，因此成本可能会不符合您的期望。Amazon Redshift Serverless 使用 AI 驱动的扩展和资源优化，自动调整 RPU 以满足您的性价比目标，同时优化组织的成本。无论工作负载大小如何，这种自动优化都会非常有用。如果您有任意数量的复杂查询，自动优化可以帮助您实现组织的性价比目标。

**注意**  
性价比目标是特定于工作组的设置。不同的工作组可以有不同的性价比目标。

为了保持成本的可预测性，请设置允许 Amazon Redshift Serverless 向您的工作负载分配的最大容量限制。

要配置性价比目标，请使用 AWS 控制台。在创建无服务器工作组时，必须明确启用您的性价比目标。还可以在创建无服务器工作组后修改性价比目标。当您启用性价比目标时，它会默认设置为**平衡**。

**编辑工作组的性价比目标**

1. 在 Amazon Redshift Serverless 控制台中，选择**工作组配置**。

1. 选择要为其编辑性价比目标的工作组。选择**性能**选项卡，然后选择**编辑**。

1. 选择**性价比**目标，然后将滑块调整到所需的设置。

1. 选择**保存更改**。

1. 要更新 Amazon Redshift Serverless 可以向工作负载分配的最大 RPU 数量，请选择**工作组配置**部分的**限制**选项卡。

可以使用**性价比目标**滑块在成本和性能之间设置所需的平衡。通过移动滑块，您可以选择以下选项之一：
+ **针对成本进行优化** – 此设置优先考虑成本节约。Amazon Redshift Serverless 尝试在不产生额外费用的情况下，自动纵向扩展计算容量。Amazon Redshift Serverless 还尝试缩减计算资源以降低成本，这可能会增加查询运行时间。
+ **平衡** - 此设置可在性能和成本之间取得平衡。Amazon Redshift Serverless 可针对性能进行扩展，并可能导致适度的成本增加或减少。这是对于大多数 Amazon Redshift Serverless 数据仓库的建议设置。
+ **针对性能进行优化** - 此设置优先考虑性能。为了获得高性能，Amazon Redshift 会前瞻性扩展，这可能会产生更高的成本。
+ 中间位置：也可以将滑块设置为**平衡**与**针对成本进行优化**或**针对性能进行优化**之间的两个中间位置之一。如果针对成本或性能的全面优化过于极端，请使用这些设置。

### 选择性价比目标时的注意事项
<a name="serverless-auto-optimization-considerations"></a>

可以使用性价比滑块来为工作负载选择所需的性价比目标。AI 驱动的扩展和优化算法会随时间推移从工作负载历史记录中进行学习，并提高预测和决策的准确性。

**示例**

对于此示例，假设查询耗时 7 分钟，花费 7 美元。下图显示了未扩展情况下的查询运行时间和成本。

![\[Amazon Redshift Serverless 自动扩缩的示例查询图。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/mgmt/images/autoscale_example_query.png)


给定的查询可能会以几种不同的方式进行扩展，如下所示。根据您选择的性价比目标，AI 驱动的扩展可以预测查询如何权衡性能与成本，并相应地对其进行扩展。选择不同的滑块选项会产生以下结果：

![\[Amazon Redshift Serverless 自动扩缩的示例查询图。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/mgmt/images/autoscale_example_scaling.png)

+ **针对成本进行优化** – 使用**针对成本进行优化**选项，数据仓库可以进行扩展，且偏向于降低成本的选择。在前述示例中，超线性扩展方法演示了这种行为。只有根据扩展模型预测以具有成本效益的方式进行扩展，才会进行扩展。如果扩展模型预测无法对给定的工作负载进行成本优化的扩展，则数据仓库将无法扩展。
+ **平衡** – 使用**平衡**选项，系统可以在平衡成本和性能考虑因素的同时进行扩展，而成本的增加可能有限。**平衡**选项可执行超线性、线性以及可能的次线性工作负载扩展。
+ **针对性能进行优化** – 使用**针对性能进行优化**选项，除了以前用于提高性能的方法外，系统也可以进行扩展（即使成本更高也是如此），而且可能与运行时间改进不成比例。使用**针对性能进行优化**，系统可以执行超线性扩展、线性扩展和次线性扩展（如果可能）。滑块位置越接近**针对性能进行优化**位置，Amazon Redshift Serverless 允许的次线性扩展就越多。

设置**性价比**滑块时，请注意以下几点：
+ 您可以随时更改性价比设置，但工作负载扩展不会立即更改。随着系统了解当前的工作负载，扩展会随着时间推移而变化。我们建议对无服务器工作组进行 1-3 天的监控，以验证新设置的影响。
+ 性价比滑块选项**最大容量**和**最大 RPU 小时数**一起发挥作用。**最大容量**和**最大 RPU 小时数**是相应的控件，用于限制 Amazon Redshift Serverless 支持数据仓库扩展的最大 RPU，以及 Amazon Redshift Serverless 支持数据仓库耗用的最大 RPU 小时数。无论性价比目标设置如何，Amazon Redshift Serverless 始终遵守并强制执行这些设置。

### 监控资源自动扩缩
<a name="serverless-auto-optimization-monitoring"></a>

可以通过以下方式监控 AI 驱动的 RPU 扩展：
+ 在 Amazon Redshift 控制台上查看已使用的 RPU 容量图表。
+ 在 CloudWatch 下中的 `AWS/Redshift-Serverless` 和 `Workgroup` 下监控 `ComputeCapacity` 指标。
+ 查询 [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html) 视图。提供特定的查询 ID 或查询文本以标识时间段。使用此时间段查询 [SYS\$1SERVERLESS\$1USAGE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_SERVERLESS_USAGE.html) 系统视图来查找 `compute_capacity` 值。`compute_capacity` 字段显示在查询运行时期间扩展的 RPU。

使用以下示例查询 `SYS_QUERY_HISTORY` 视图。用查询文本替换示例值。

```
select query_id,query_text,start_time,end_time, elapsed_time/1000000.0 duration_in_seconds
from sys_query_history
where query_text like '<query_text>'
and query_text not like '%sys_query_history%'
order by start_time desc
```

 运行以下查询，来查看 `compute_capacity` 在从 `start_time` 到 `end_time` 的时间段内扩展的情况。将以下查询中的 `start_time` 和 `end_time` 替换为前一个查询的输出：

```
select * from sys_serverless_usage
where end_time >= 'start_time'
and end_time <= DATEADD(minute,1,'end_time')
order by end_time asc
```

有关使用这些功能的分步说明，请参阅 [Configure monitoring, limits, and alarms in Amazon Redshift Serverless to keep costs predictable](https://aws.amazon.com/blogs/big-data/configure-monitoring-limits-and-alarms-in-amazon-redshift-serverless-to-keep-costs-predictable/)。

### 使用 AI 驱动的扩展和优化时的注意事项
<a name="serverless-auto-optimization-considerations"></a>

使用 AI 驱动的扩展和优化时应考虑以下事项：
+ 对于 Amazon Redshift Serverless 上需要 32 到 512 个基本 RPU 的现有工作负载，我们建议使用 Amazon Redshift Serverless AI 驱动的扩展和优化来获得最佳结果。建议不要将此功能用于少于 32 个基本 RPU 或多于 512 个基本 RPU 的工作负载。
+ 性价比目标会自动优化工作负载，但结果可能会有所不同。我们建议随着时间的推移使用此功能，这样，系统就可以通过运行具有代表性的工作负载来了解您的特定模式。
+ AI 驱动的扩展和优化根据 Amazon Redshift Serverless 实例上运行的工作负载，使用最佳时间将优化应用于无服务器工作组。

要了解有关 AI 驱动的优化和资源扩展的更多信息，请观看以下视频。

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/U3f2FObbvKc/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/U3f2FObbvKc)


