从补丁 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 最佳实践
在下文中，您可以查找针对计划概念验证、设计表、将数据加载到表中和为 Amazon Redshift 编写查询的最佳实践，还可以查找有关使用 Amazon Redshift Advisor 的讨论。
Amazon Redshift 与其他 SQL 数据库系统不同。为充分实现 Amazon Redshift 架构的优势，您必须专门设计、构建和加载表来使用大规模并行处理、列式数据存储和列式数据压缩。如果数据加载和查询执行时间超过预期或超过您预计等待的时间，您可能忽视了关键信息。
如果您是经验丰富的 SQL 数据库开发人员，我们强烈建议您在开发 Amazon Redshift 数据仓库前查阅主题。
如果您是 SQL 数据库开发新手，本主题并不适合入门。我们建议您首先阅读《Amazon Redshift 入门指南》**中的[运行命令以在数据仓库中定义和使用数据库](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html)，然后亲自尝试这些示例。
在本主题中，您可以找到最重要的开发原则的概述，以及实施这些原则的具体提示、示例和最佳实践。没有任何一种做法可以适用于所有应用。应在完成数据库设计之前评估所有选项。有关更多信息，请参阅[自动表优化](t_Creating_tables.md)、[在 Amazon Redshift 中加载数据](t_Loading_data.md)、[查询性能优化](c-optimizing-query-performance.md)和参考章节。
**Topics**
+ [为 Amazon Redshift 执行概念验证（POC）。](proof-of-concept-playbook.md)
+ [设计表的 Amazon Redshift 最佳实践](c_designing-tables-best-practices.md)
+ [Amazon Redshift 加载数据的最佳实践](c_loading-data-best-practices.md)
+ [设计查询的 Amazon Redshift 最佳实践](c_designing-queries-best-practices.md)
+ [采用 Amazon Redshift Advisor 的建议](advisor.md)
# 为 Amazon Redshift 执行概念验证（POC）。
Amazon Redshift 是一种流行的云数据仓库，它提供完全托管的基于云的服务，可与组织的 Amazon Simple Storage Service 数据湖、实时流、机器学习（ML）工作流、事务性工作流等集成。以下各节将指导您完成对 Amazon Redshift 执行概念验证（POC）的过程。此处的信息可帮助您为 POC 设定目标，并利用可自动为 POC 预置和配置服务的工具。
**注意**
如需 PDF 格式的信息副本，请选择 [Amazon Redshift 资源](https://aws.amazon.com/redshift/resources/)页面上的**运行您自己的 Redshift POC** 链接。
执行 Amazon Redshift 的 POC 时，您需要测试、证明和采用各种功能，包括出色的安全功能、弹性扩展、易于集成和摄取以及灵活的去中心化数据架构选项。
![\[显示概念验证流程中各个步骤的描述。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-steps-overview.png)
请遵循以下步骤，以成功执行 POC。
## 步骤 1：确定 POC 的范围
![\[表明范围步骤是概念验证流程中的当前步骤。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-step1.png)
执行 POC 时，您可以选择使用自己的数据，也可以选择使用基准测试数据集。选择自己的数据时，您可以对数据运行自己的查询。使用基准测试数据时，基准测试中提供了示例查询。如果您尚未准备好使用自己的数据执行 POC，请参阅[使用示例数据集](#use-sample-datasets)了解更多详细信息。
一般来说，我们建议 Amazon Redshift POC 使用两周的数据。
首先执行以下步骤：
1. **确定您的业务和功能需求，**然后进行倒推。常见的示例有：更快的性能、更低的成本、测试新的工作负载或功能，或者将 Amazon Redshift 与其他数据仓库进行比较。
1. **设定具体目标，**这些目标将成为 POC 的成功标准。例如，从*更快的性能*出发，列出您希望加速的前五个流程，并将当前的运行时间和所需的运行时间一并列出。这些可以是报告、查询、ETL 流程、数据摄取，或者您当前的任何棘手问题。
1. **确定运行测试所需的具体范围和构件**。您需要哪些数据集才能迁移或持续摄取到 Amazon Redshift 中，以及需要哪些查询和流程来运行测试以根据成功标准进行衡量？ 有两种方式可执行此操作：
**自带数据**
+ 要测试自己的数据，请列出测试成功标准所需的最低可行数据构件清单。例如，如果您当前的数据仓库有 200 个表，但您要测试的报告只需要 20 个表，则仅使用较小的表子集可以更快地运行 POC。
**使用示例数据集**
+ 如果您没有准备好自己的数据集，仍可使用行业标准的基准数据集（如 [TPC-DS](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/CloudDataWarehouseBenchmark/Cloud-DWB-Derived-from-TPCDS) 或 [TPC-H](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/CloudDataWarehouseBenchmark/Cloud-DWB-Derived-from-TPCH)）开始对 Amazon Redshift 执行 POC，并运行示例基准测试查询以利用 Amazon Redshift 的强大功能。创建 Amazon Redshift 数据仓库后，可以从其内部访问这些数据集。有关如何访问这些数据集和示例查询的详细说明，请参阅[步骤 2：启动 Amazon Redshift](#proof-of-concept-launch)。
## 步骤 2：启动 Amazon Redshift
![\[表明 Amazon Redshift 启动步骤是概念验证流程的当前步骤。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-step2.png)
Amazon Redshift 可通过快速、简单且安全的大规模云数据仓库服务，使您更快地获得见解。您可以通过在 [Redshift Serverless 控制台](https://console.aws.amazon.com//redshiftv2/home?#serverless-dashboard)上启动仓库来快速开始工作，在几秒内将数据转化为见解。有了 Redshift Serverless，您就可以专注于交付业务成果，而不必担心管理数据仓库。
### 设置 Amazon Redshift Serverless
首次使用 Redshift Serverless 时，控制台会引导您完成启动仓库所需的步骤。您也可能有资格获得账户中的 Redshift Serverless 使用积分。有关选择免费试用的更多信息，请参阅 [Amazon Redshift 免费试用](https://aws.amazon.com/redshift/free-trial/)。按照《Amazon Redshift 入门指南》**中的[使用 Redshift Serverless 创建数据仓库](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html#serverless-console-resource-creation)中的步骤，使用 Redshift Serverless 创建数据仓库。如果您没有想要加载的数据集，该指南还包含有关如何加载示例数据集的步骤。
如果您之前在自己的账户中启动过 Redshift Serverless，请按照《Amazon Redshift 管理指南》**中的[创建带有命名空间的工作组](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-workgroups-create-workgroup-wizard.html)中的步骤进行操作。仓库可用后，您可以选择加载 Amazon Redshift 中提供的示例数据。有关使用 Amazon Redshift 查询编辑器 v2 以加载数据的信息，请参阅《Amazon Redshift 管理指南》**中的[加载示例数据](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-sample-data)。
如果您自带数据而不是加载示例数据集，请参阅[步骤 3：加载数据](#proof-of-concept-load-data)。
## 步骤 3：加载数据
![\[表明加载步骤是概念验证流程中的当前步骤。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-step3.png)
启动 Redshift Serverless 后，下一步是为 POC 加载数据。无论您是上传简单的 CSV 文件、从 S3 中摄取半结构化数据，还是直接流式传输数据，Amazon Redshift 都能灵活地将数据从源位置快速轻松地移动到 Amazon Redshift 表中。
选择以下方法之一以加载数据。
### 上传本地文件
为了快速摄取和分析，您可以使用 [Amazon Redshift 查询编辑器 v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2.html) 轻松从本地桌面加载数据文件。它能够处理各种格式的文件，如 CSV、JSON、AVRO、PARQUET、ORC 等。要让您的用户以管理员身份使用查询编辑器 v2 从本地桌面加载数据，您必须指定一个通用 Amazon S3 存储桶，并且必须为该用户账户[配置适当的权限](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data-local)。您可以遵循[使用查询编辑器 V2 在 Amazon Redshift 中轻松安全地加载数据](https://aws.amazon.com/blogs//big-data/data-load-made-easy-and-secure-in-amazon-redshift-using-query-editor-v2/)，以获取分步指导。
### 加载 Amazon S3 文件
要将数据从 Amazon S3 存储桶加载到 Amazon Redshift 中，请首先使用 [COPY 命令](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-tables-from-s3.html)，指定源 Amazon S3 位置和目标 Amazon Redshift 表。确保正确配置 IAM 角色和权限，以允许 Amazon Redshift 访问指定的 Amazon S3 存储桶。请遵循[教程：从 Amazon S3 加载数据](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-data.html)，以获取分步指导。您也可以选择查询编辑器 v2 中的**加载数据**选项，直接从 S3 存储桶加载数据。
### 持续数据摄取
[自动复制（预览版）](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-copy-job.html)是 [COPY 命令](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-tables-from-s3.html)的扩展，可自动从 Amazon S3 存储桶持续加载数据。当您创建 COPY 作业时，Amazon Redshift 会检测何时在指定路径中创建新的 Amazon S3 文件，然后自动加载这些文件，无需您的干预。Amazon Redshift 会跟踪加载的文件，以确认它们只加载一次。有关创建 COPY 作业的说明，请参阅[COPY JOB](r_COPY-JOB.md)
**注意**
自动复制目前处于预览状态，仅在特定 AWS 区域的预置集群中受支持。要创建用于自动复制的预览集群，请参阅[创建 S3 事件集成以自动从 Amazon S3 存储桶复制文件](loading-data-copy-job.md)。
### 加载流数据
串流摄取直接以低延迟、高速度的方式将流数据从 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 和 [Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com/msk/) 摄取到 Amazon Redshift 中。Amazon Redshift 串流摄取使用实体化视图，该视图将利用[自动刷新](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html#materialized-view-auto-refresh)功能直接从流中更新。实体化视图映射到流数据来源。在实体化视图定义中，您可以对流数据执行筛选和聚合。有关从流中加载数据的分步指南，请参阅 [Amazon Kinesis Data Streams 入门](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started.html)或[开始使用 Amazon Managed Streaming for Apache Kafka 串流摄取](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started-MSK.html)。
## 步骤 4：分析数据
![\[表明分析步骤是概念验证流程中的当前步骤。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-step4.png)
创建 Redshift Serverless 工作组和命名空间并加载数据后，您可以通过从 [Redshift Serverless 控制台](https://console.aws.amazon.com//redshiftv2/home?#serverless-dashboard)的导航面板打开**查询编辑器 v2** 来立即运行查询。您可以使用查询编辑器 v2 针对自己的数据集测试查询功能或查询性能。
### 使用 Amazon Redshift 查询编辑器 v2 进行查询
您可以从 Amazon Redshift 控制台访问查询编辑器 v2。有关如何使用查询编辑器 v2 配置、连接和运行查询的完整指南，请参阅[使用 Amazon Redshift 查询编辑器 v2 简化数据分析](https://aws.amazon.com/blogs//big-data/simplify-your-data-analysis-with-amazon-redshift-query-editor-v2/)。
或者，如果您想在 POC 中运行负载测试，则可以通过以下步骤来安装和运行 Apache JMeter。
### 使用 Apache JMeter 运行负载测试
要执行负载测试以模拟“N”个用户同时向 Amazon Redshift 提交查询，可以使用基于 Java 的开源工具 [Apache JMeter](https://jmeter.apache.org/)。
要安装和配置 Apache JMeter 以在 Redshift Serverless 工作组中运行，请按照[使用 AWS 分析自动化工具包自动进行 Amazon Redshift 负载测试](https://aws.amazon.com/blogs//big-data/automate-amazon-redshift-load-testing-with-the-aws-analytics-automation-toolkit/)中的说明进行操作。它使用 [AWS 分析自动化工具包（AAA）](https://github.com/aws-samples/amazon-redshift-infrastructure-automation/tree/main)（一种用于动态部署 Redshift 解决方案的开源工具）来自动启动这些资源。如果您已将自己的数据加载到 Amazon Redshift 中，请务必执行步骤 5 – 自定义 SQL 选项，以确保提供要针对表进行测试的相应 SQL 语句。使用查询编辑器 v2 对每个 SQL 语句进行一次测试，以确保它们运行时没有错误。
完成自定义 SQL 语句并最终确定测试计划后，请进行保存并在 Redshift Serverless 工作组中运行测试计划。要监控测试进度，请打开 [Redshift Serverless 控制台](https://console.aws.amazon.com/redshiftv2/home?#serverless-query-and-database-monitoring)，导航到**查询和数据库监控**，选择**查询历史记录**选项卡，然后查看有关查询的信息。
要查看性能指标，请在 Redshift Serverless 控制台上选择**数据库性能**选项卡，以监控**数据库连接**和 **CPU 利用率**等指标。在这里，您可以查看图表以监控使用的 RPU 容量，并观察在工作组上运行负载测试时 Redshift Serverless 如何自动扩展以满足并发工作负载需求。
![\[显示所用 RPU 平均容量的示例图。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-rpu-capacity-used.png)
数据库连接是在运行负载测试时要监控的另一个有用指标，您可以通过该指标来了解工作组在给定时间如何处理大量并发连接以满足不断增长的工作负载需求。
![\[显示数据库连接的示例图。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-database-connections.png)
## 步骤 5：优化
![\[表明优化步骤是概念验证流程中的当前步骤。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/poc-step5.png)
Amazon Redshift 通过提供各种配置和功能来支持各个使用案例，使成千上万的用户能够每天处理 EB 级数据，并为其分析工作负载提供支持。在这些选项之间进行选择时，客户希望寻找可帮助他们确定最优数据仓库配置以支持其 Amazon Redshift 工作负载的工具。
### 试用方案
您可以使用[试用方案](https://github.com/aws/redshift-test-drive/tree/main)在潜在配置上自动重播现有工作负载，并分析相应的输出，以评估要将工作负载迁移到的最佳目标。有关使用试用方案评估不同 Amazon Redshift 配置的信息，请参阅[使用 Redshift 试用方案查找适合工作负载的 Amazon Redshift 配置](https://aws.amazon.com/blogs/big-data/find-the-best-amazon-redshift-configuration-for-your-workload-using-redshift-test-drive/)。
# 设计表的 Amazon Redshift 最佳实践
在规划数据库时，某些关键表设计决策对整体查询性能影响很大。这些设计选择可以减少 I/O 操作数和尽量减少处理查询所需的内存，因而对存储需求以至查询性能也有很大影响。
在本节中，您可以找到最重要的设计决策的总结和用于优化查询性能的最佳实践。[自动表优化](t_Creating_tables.md)提供了更为详细的表设计选项说明和示例。
**Topics**
+ [选择最佳的排序键](c_best-practices-sort-key.md)
+ [选择最佳的分配方式](c_best-practices-best-dist-key.md)
+ [让 COPY 选择压缩编码](c_best-practices-use-auto-compression.md)
+ [定义主键和外键约束](c_best-practices-defining-constraints.md)
+ [使用尽可能小的列大小](c_best-practices-smallest-column-size.md)
+ [在日期列中使用日期/时间数据类型](c_best-practices-timestamp-date-columns.md)
# 选择最佳的排序键
Amazon Redshift 根据排序键将您的数据按照排序顺序存储在磁盘中。Amazon Redshift 查询优化程序在确定最佳查询计划时会使用排序顺序。
**注意**
使用自动表优化时，不需要选择表的排序键。有关更多信息，请参阅 [自动表优化](t_Creating_tables.md)。
关于最佳方法的一些建议如下：
+ 要让 Amazon Redshift 选择适当的排序顺序，请指定 `AUTO` 作为排序键。
+ 如果最近使用的数据查询频率最高，则指定时间戳列作为排序键的第一列。
这样查询会更高效，因为可以跳过该时间范围之外的整个数据块。
+ 如果您经常对某列进行范围筛选或相等性筛选，则指定该列作为排序键。
Amazon Redshift 可以不读取该列的整个数据块。之所以能这样做，是因为它会跟踪每个数据块中存储的最小和最大列值，并且可以跳过不适用于指定范围的数据块。
+ 如果您频繁联接表，则指定联接列作为排序键和分配键。
这样，查询优化程序可以选择排序合并联接而不是较慢的哈希联接。因为数据已按联接键排序，所以查询优化程序不用执行排序合并联接的排序阶段。
# 选择最佳的分配方式
在运行查询时，查询优化程序根据执行任何联接和聚合的需要将行重新分配到计算节点。选择表分配方式的目的是通过在运行查询前将数据放在需要的位置来最大程度地减小重新分配步骤的影响。
**注意**
使用自动表优化时，不需要选择表的分配方式。有关更多信息，请参阅 [自动表优化](t_Creating_tables.md)。
关于最佳方法的一些建议如下：
1. 根据共同列分配事实数据表和一个维度表。
事实数据表只能有一个分配键。任何通过其他键联接的表都不能与事实数据表并置。根据联接频率和联接行的大小选择一个要并置的维度。将维度表的主键和事实数据表对应的外键指定为 DISTKEY。
1. 根据筛选的数据集的大小选择最大的维度。
只有用于联接的行才必须分配，因此需要考虑筛选后数据集的大小，而不是表的大小。
1. 在筛选结果集中选择基数高的列。
例如，如果您在日期列上分配了一个销售表，您应该能获得非常均匀的数据分配，除非您的大多数销售都是季节性的。但是，如果您通常使用范围受限谓词进行筛选以缩小日期期间的范围，则大多数筛选行都将出现在有限的一组切片上并且查询工作负载将偏斜。
1. 将一些维度表改为使用 ALL 分配。
如果一个维度表不能与事实数据表或其他重要的联接表并置，您可以通过将整个表分配到所有节点来大大提高查询性能。使用 ALL 分配会使存储空间需求成倍增长，并且会增加加载时间和维护操作，所以在选择 ALL 分配前应权衡所有因素。
要让 Amazon Redshift 选择适当的分配方式，请指定 `AUTO` 作为分配方式。
有关选择分配方式的更多信息，请参阅[用于优化查询的数据分配](t_Distributing_data.md)。
# 让 COPY 选择压缩编码
您可以在创建表时指定压缩编码，但在大多数情况下，自动压缩的效果最好。
ENCODE AUTO 是表的默认设置。将表设置为 ENCODE AUTO 时，Amazon Redshift 会自动管理表中所有列的压缩编码。有关更多信息，请参阅[CREATE TABLE](r_CREATE_TABLE_NEW.md)和[ALTER TABLE](r_ALTER_TABLE.md)。
在加载操作中，COPY 命令自动分析您的数据并对一个空表应用压缩编码。
自动压缩将在选择压缩编码时平衡整体性能。如果排序键列的压缩率远高于同一查询中的其他列，则范围受限扫描的执行效果可能会很差。因此，自动压缩将选择一个效率较低的压缩编码来让排序键列与其他列保持平衡。
假设您的表的排序键为日期或时间戳，并且表使用了很多大型 varchar 列。在这种情况下，您可能通过完全不压缩排序键列来获取更高的性能。请对表运行 [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) 命令，然后使用编码创建一个新表，但忽略排序键的压缩编码。
仅当表为空且尚未指定压缩编码时，自动压缩编码才存在性能开销。对于短期存在的表和经常创建的表（如暂存表），可以使用自动压缩加载该表一次，或运行 ANALYZE COMPRESSION 命令。然后使用这些编码创建新表。您可以将编码添加到 CREATE TABLE 语句中或使用 CREATE TABLE LIKE 来创建采用相同编码的新表。
有关更多信息，请参阅 [使用自动压缩加载表](c_Loading_tables_auto_compress.md)。
# 定义主键和外键约束
如果适当，在表之间定义主键和外键约束。即使只是信息性的，查询优化程序也可以使用这些约束来生成更有效的查询计划。
除非您的应用程序强制实施约束，否则不要定义主键和外键约束。Amazon Redshift 不强制实施唯一约束、主键约束和外键约束。
有关 Amazon Redshift 如何使用约束的其他信息，请参阅[表限制](t_Defining_constraints.md)。
# 使用尽可能小的列大小
不要为了方便而经常使用最大列大小。
而是应考虑您可能存储在列中的最大值，并相应地调整它们的大小。例如，用于存储邮局使用的美国州和地区缩写的 CHAR 列只需要是 CHAR(2)。
# 在日期列中使用日期/时间数据类型
Amazon Redshift 存储 DATE 和 TIMESTAMP 数据的效率高于 CHAR 或 VARCHAR，这可以改善查询性能。在存储日期/时间信息时，请根据所需精度（而不是字符类型）使用 DATE 或 TIMESTAMP 数据类型。有关更多信息，请参阅 [日期时间类型](r_Datetime_types.md)。
# Amazon Redshift 加载数据的最佳实践
加载非常大的数据集可能需要花费很长时间，并且会消耗大量计算资源。数据的加载方式还会影响查询性能。本节介绍使用 COPY 命令、批量插入和临时表有效加载数据的最佳实践。
**Topics**
+ [通过教程学习如何加载数据](c_best-practices-loading-take-loading-data-tutorial.md)
+ [使用 COPY 命令加载数据](c_best-practices-use-copy.md)
+ [使用一个 COPY 命令从多个文件中加载](c_best-practices-single-copy-command.md)
+ [加载数据文件](c_best-practices-use-multiple-files.md)
+ [压缩数据文件](c_best-practices-compress-data-files.md)
+ [在加载前后验证数据文件](c_best-practices-verifying-data-files.md)
+ [使用多行插入](c_best-practices-multi-row-inserts.md)
+ [使用批量插入](c_best-practices-bulk-inserts.md)
+ [按排序键顺序加载数据](c_best-practices-sort-key-order.md)
+ [加载有序数据块中的数据](c_best-practices-load-data-in-sequential-blocks.md)
+ [使用时间序列表](c_best-practices-time-series-tables.md)
+ [计划维护时段](c_best-practices-avoid-maintenance.md)
# 通过教程学习如何加载数据
[教程：从 Amazon S3 加载数据](tutorial-loading-data.md) 指导您逐步将数据上载到 Simple Storage Service（Amazon S3）存储桶，然后使用 COPY 命令将数据加载到您的表中。本教程包含有关解决加载错误的帮助，还比较从单个文件加载和从多个文件加载之间的性能差异。
# 使用 COPY 命令加载数据
COPY 命令从 Simple Storage Service（Amazon S3）、Amazon EMR、Amazon DynamoDB 或远程主机上的多个数据来源并行加载数据。COPY 加载大量数据的效率要比 INSERT 语句高很多，而且存储数据也更有效率。
有关如何使用 COPY 命令的更多信息，请参阅[从 Amazon S3 加载数据](t_Loading-data-from-S3.md)和[从 Amazon DynamoDB 表中加载数据](t_Loading-data-from-dynamodb.md)。
# 使用一个 COPY 命令从多个文件中加载
Amazon Redshift 可自动从多个压缩数据文件并行加载。您可以使用 Amazon S3 对象前缀或清单文件指定要加载的文件。
但如果您使用多个并发 COPY 命令从多个文件加载一个表，系统会强制 Amazon Redshift 执行序列化加载。如果表已定义一个排序列，这种加载会慢得多并且需要在结束时执行 VACUUM 流程。有关使用 COPY 并行加载数据的更多信息，请参阅[从 Amazon S3 加载数据](t_Loading-data-from-S3.md)。
# 加载数据文件
源数据文件采用不同的格式，并使用不同的压缩算法。使用 COPY 命令加载数据时，Amazon Redshift 会加载 Amazon S3 桶前缀引用的所有文件。（前缀是对象键名称开头的一串字符。） 如果前缀指的是多个文件或可以拆分的文件，Amazon Redshift 会利用 Amazon Redshift 的 MPP 架构并行加载数据。这将在集群中的节点间划分工作负载。相比之下，当您从无法拆分的文件加载数据时，Amazon Redshift 会强制执行序列化加载，这样速度会慢得多。以下部分介绍将不同文件类型加载到 Amazon Redshift 的建议方法，具体取决于它们的格式和压缩情况。
## 从可以拆分的文件中加载数据
加载以下文件的数据时，可以自动拆分这些文件：
+ 未压缩的 CSV 文件
+ 列式文件（Parquet/ORC）
Amazon Redshift 会自动将 128MB 或更大的文件拆分成数据块。列式文件（特别是 Parquet 和 ORC）如果小于 128MB，则不会被拆分。Redshift 利用并行工作的切片来加载数据。实现快速加载性能。
## 从无法拆分的文件加载数据
使用 GZIP 等其他压缩算法进行压缩时，JSON 或 CSV 等文件类型不会自动拆分。对于这些文件类型，我们建议您手动将数据拆分为多个大小接近的小文件，这些小文件压缩后的大小介于 1MB 到 1GB 之间。此外，将文件数设为您的集群中切片数的倍数。有关如何将数据拆分为多个文件的更多信息和如何使用 COPY 加载数据的示例，请参阅[从 Amazon S3 加载数据](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-S3.html)。
# 压缩数据文件
当要压缩大型加载文件时，我们建议您使用 gzip、lzop、bzip2 或 Zstandard 来压缩，并将数据拆分为多个小文件。
在 COPY 命令中指定 GZIP、LZOP、BZIP2 或 ZSTD 选项。此示例从一个用竖线分隔的 lzop 文件加载 TIME 表。
```
copy time
from 's3://amzn-s3-demo-bucket/data/timerows.lzo'
iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
lzop
delimiter '|';
```
在某些情况下，您无需拆分未压缩的数据文件。有关如何拆分数据的更多信息以及如何使用 COPY 加载数据的示例，请参阅[从 Amazon S3 加载数据](t_Loading-data-from-S3.md)。
# 在加载前后验证数据文件
在从 Amazon S3 加载数据之前，首先验证 Amazon S3 桶是否包含所有正确的文件，并且仅包含这些文件。有关更多信息，请参阅 [确认在桶中具有正确的文件](verifying-that-correct-files-are-present.md)。
在完成加载操作后，请查询 [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) 系统表以验证所需文件是否已加载。有关更多信息，请参阅 [验证是否正确加载了数据](verifying-that-data-loaded-correctly.md)。
# 使用多行插入
如果不能使用 COPY 命令，而您需要进行 SQL 插入，可以根据情况使用多行插入。如果一次只添加一行或几行，则数据压缩效率低下。
多行插入通过批量进行一系列插入提高性能。下面的示例使用一条 INSERT 语句向一个包含四列的表中插入三行。这仍是少量插入，只是用来说明多行插入的语法。
```
insert into category_stage values
(default, default, default, default),
(20, default, 'Country', default),
(21, 'Concerts', 'Rock', default);
```
有关更多详细信息和示例，请参阅 [INSERT](r_INSERT_30.md)。
# 使用批量插入
带 SELECT 子句使用批量插入操作来实现高性能数据插入。
如果需要将数据或数据子集从一个表移动到另一个表，可以使用 [INSERT](r_INSERT_30.md) 和 [CREATE TABLE AS](r_CREATE_TABLE_AS.md) 命令。
例如，下面的 INSERT 语句从 CATEGORY 表中选择所有行并将它们插入 CATEGORY\$1STAGE 表。
```
insert into category_stage
(select * from category);
```
下面的示例创建 CATEGORY\$1STAGE 作为 CATEGORY 的副本，并将 CATEGORY 中的所有行插入 CATEGORY\$1STAGE。
```
create table category_stage as
select * from category;
```
# 按排序键顺序加载数据
按排序键顺序加载数据可以避免对 vacuum 的需要。
如果每批新数据都遵循表中的现有行，并且 COPY 操作没有大到足以触发特定的加载优化，您的数据将按排序顺序正确存储，不需要运行 vacuum。COPY 在加载时对每批传入数据进行排序，因此您无需对每次加载的行进行预排序。
例如，假设您每天根据当天活动加载数据。如果您的排序键是时间戳列，并且 COPY 操作没有大到足以触发特定的加载优化，您的数据将按排序顺序存储。之所以会出现这种顺序，是因为当天的数据总是附加在前一天的数据的后面。有关更多信息，请参阅 [按排序键顺序加载数据](vacuum-managing-vacuum-times.md#vacuum-load-in-sort-key-order)。有关 vacuum 操作的更多信息，请参阅[对表执行 vacuum 操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html)。
# 加载有序数据块中的数据
如果需要添加大量数据，加载符合排序顺序的有序数据块则不需要使用 Vacuum。
例如，假设您需要加载包含从 2017 年 1 月到 2017 年 12 月的事件的表。假设每个月均在一个单独的文件中，请加载 1 月的行、2 月的行，依此类推。加载完成后，表已完成排序，无需运行 Vacuum。有关更多信息，请参阅 [使用时间序列表](c_best-practices-time-series-tables.md)。
在加载非常大的数据集时，排序操作所需要的空间可能会超出总可用空间。通过加载较小数据块中的数据，每次加载期间使用的中间排序空间会大幅减少。此外，如果 COPY 失败回滚，加载较小的数据块更容易重启。
# 使用时间序列表
如果数据有固定保留期，可以将数据组织为时间序列表序列。在此类序列中，每个表都相同但包含不同时间范围的数据。
您只需在相应表上运行 DROP TABLE 命令即可轻松删除旧数据。此方法比运行大规模 DELETE 流程快得多，并使您不必运行后续 VACUUM 流程以回收空间。要隐藏数据存储在不同表中这一事实，您可以创建 UNION ALL 视图。删除旧数据时，应优化您的 UNION ALL 视图以移除已删除的表。同样，向新表加载新时间段时，只需将新表添加到视图中。为了通知优化程序跳过对与查询筛选条件不匹配的表的扫描，您的视图定义将筛选与每个表对应的日期范围。
避免在 UNION ALL 视图中包含过多的表。每个附加表都会给查询增加一点处理时间。表不需要使用相同的时间范围。例如，您可能拥有不同时间段（如每日、每月、每年）的表。
如果使用时间序列表以时间戳列作为排序键，则可按排序键顺序高效加载数据。这样做将使 vacuum 不必对数据重新排序。有关更多信息，请参阅 [按排序键顺序加载数据](vacuum-managing-vacuum-times.md#vacuum-load-in-sort-key-order)。
# 计划维护时段
如果查询运行时发生计划的维护，查询会终止并回滚，需要重启。将长时间运行的操作（如大型数据加载或 VACUUM 操作）计划在维护时间段之外进行。您也可以通过执行较小增量的数据加载和管理 VACUUM 操作的大小尽可能地降低风险，在需要重启时简化重启。有关更多信息，请参阅[加载有序数据块中的数据](c_best-practices-load-data-in-sequential-blocks.md)和[对表执行 vacuum 操作](t_Reclaiming_storage_space202.md)。
# 设计查询的 Amazon Redshift 最佳实践
要最大程度地提高查询性能，请在创建查询时遵循这些建议：
+ 根据最佳实践设计表，为查询性能提供坚固的基础。有关更多信息，请参阅 [设计表的 Amazon Redshift 最佳实践](c_designing-tables-best-practices.md)。
+ 避免使用 `select *`。仅包含您需要的列。
+ 使用 [CASE 条件表达式](r_CASE_function.md) 执行复杂聚合，而不是从同一表多次选择。
+ 除非绝对必要，否则，不要使用交叉联接。这些没有联接条件的联接会导致两个表的笛卡尔积。交叉联接通常作为嵌套循环联接运行，这是最慢的联接类型。
+ 如果查询中有一个表只用于谓词条件并且子查询返回的行数较少 (不足 200 行)，可以使用子查询。下面的示例使用子查询来避免联接 LISTING 表。
```
select sum(sales.qtysold)
from sales
where salesid in (select listid from listing where listtime > '2008-12-26');
```
+ 使用谓词尽可能限制数据集。
+ 在谓词中，尽可能使用成本最低的运算符。[比较条件](r_comparison_condition.md) 运算符优先于 [LIKE](r_patternmatching_condition_like.md) 运算符。LIKE 运算符优先于 [SIMILAR TO](pattern-matching-conditions-similar-to.md) 或 [POSIX 运算符](pattern-matching-conditions-posix.md)。
+ 避免在查询谓词中使用函数。如果使用函数，则需要大量的行来解析查询的中间步骤，从而增加查询成本。
+ 如果可能，请使用 WHERE 子句限制数据集。查询计划程序可以使用行顺序来帮助确定哪些记录与条件匹配，从而不必扫描大量磁盘数据块。如果没有它，查询执行引擎必须完全扫描参与的列。
+ 添加谓词以筛选参与联接的表（即使谓词应用相同的筛选条件）。查询返回相同的结果集，但 Amazon Redshift 能够在扫描步骤前筛选联接表，然后高效地跳过对这些表数据块的扫描。如果对在联接条件中使用的列进行筛选，则无需指定冗余筛选条件。
例如，假设您需要联接 `SALES` 和 `LISTING` 来查找在 12 月之后列出的票的销售数据并按卖家分组。两个表都按日期排序。下面的查询使用表的公共键联接这两个表，并筛选晚于 12 月 1 日的 `listing.listtime` 值。
```
select listing.sellerid, sum(sales.qtysold)
from sales, listing
where sales.salesid = listing.listid
and listing.listtime > '2008-12-01'
group by 1 order by 1;
```
WHERE 子句不包含针对 `sales.saletime` 的谓词，因此，执行引擎必须扫描整个 `SALES` 表。如果您知道哪些筛选条件能够减少参与联接操作的行数，则也请添加这些筛选条件。下面的示例明显地减少了执行时间。
```
select listing.sellerid, sum(sales.qtysold)
from sales, listing
where sales.salesid = listing.listid
and listing.listtime > '2008-12-01'
and sales.saletime > '2008-12-01'
group by 1 order by 1;
```
+ 在 GROUP BY 子句中使用排序键，以便查询计划程序可以使用更高效的聚合。如果查询的 GROUP BY 列表只包含排序键列，并且其中一列也是分配键，则查询可能适合单阶段聚合。GROUP BY 列表中的排序键列必须包含第一个排序键，然后按排序键顺序包含其他需要使用的排序键。例如，可以使用第一个排序键，第一个和第二个排序键，第一个、第二个和第三个排序键，依此类推。不能使用第一个和第三个排序键。
您可以通过在查询的聚合步骤中运行 [EXPLAIN](r_EXPLAIN.md) 命令和查找 `XN GroupAggregate` 来确认使用单阶段聚合。
+ 如果同时使用 GROUP BY 和 ORDER BY 子句，两个子句中各列的顺序必须相同。也就是，使用下面的方法。
```
group by a, b, c
order by a, b, c
```
不要使用以下方法。
```
group by b, c, a
order by a, b, c
```
# 采用 Amazon Redshift Advisor 的建议
为了帮助您提高性能并降低 Amazon Redshift 集群的运营成本，Amazon Redshift Advisor 为您提供了有关要进行的更改的特定建议。Advisor 通过分析集群的性能和使用量指标来制定其定制建议。这些定制建议与操作和集群设置相关。为帮助您设定优化的优先顺序，Advisor 按影响度顺序对建议进行了排名。
## Advisor 的工作原理
Advisor 基于有关性能统计数据或操作数据的观察来制定建议。Advisor 通过对集群/工作组运行测试以确定测试值是否在指定的范围内，从而生成观察。如果测试结果超出该范围，Advisor 将为集群生成观察。同时，Advisor 将创建有关如何将观察到的值恢复到最佳实践范围内的建议。
对于使用 Amazon Redshift 数据共享的多集群架构，Advisor 现在通过分析数据网格中所有集群/工作组（包括跨不同区域的集群/工作组）的工作负载模式，来提供增强的优化。当您在生产者和使用者集群/工作组之间共享表时，Advisor 会自动从数据网格中的所有使用者端点（除非端点被明确列入拒绝列表）收集查询模式，并将查询模式与生产者工作负载相结合以生成更有效的建议。这意味着您的表优化（包括排序键、分配键和压缩）将基于在整个组织中（而不仅仅是在单个集群中）实际使用数据的方式。Advisor 还支持 Amazon Redshift Serverless，可在暂停和恢复周期中自动保持优化连续性。
例如，假设您的数据仓库包含具有次优分配键的表，而次优分配键会导致计算节点之间出现数据偏斜。在这种情况下，Advisor 会自动建议使用 DISTKEY 参数重新分配表，以指定一个均匀分配数据的列。在另一个示例中，假设 Advisor 观察到集群中的表没有排序键或排序键定义效率低下，而导致查询性能不佳。在这种情况下，Advisor 会根据您的查询模式自动为适当的排序键列提供建议，以改进数据筛选并减少磁盘 I/O。
## 优化数据共享架构
当您使用 Amazon Redshift 数据共享在多个集群/工作组之间分配工作负载时，Advisor 有助于您优化整个数据网格的性能。Advisor 会自动分析如何在所有使用者集群/工作组中查询共享表。这包括了解经常对哪些列进行筛选、哪些表通常联接在一起以及如何扫描数据。通过全面考虑数据使用情况，Advisor 生成建议，以便为共享数据的所有用户提升性能。
通过根据整个组织而不是单个集群的使用模式来优化表，您可以：
+ 根据网格中所有集群/工作组的数据访问模式做出数据驱动的优化决策
+ 通过更有效的压缩策略降低存储成本
+ 提高整个数据网格的资源利用率
## 支持 Advisor 的 Amazon Redshift 区域
Amazon Redshift Advisor 功能仅在以下 AWS 区域中可用：
+ 美国东部（弗吉尼亚北部）区域 (us-east-1)
+ 美国东部（俄亥俄）区域 (us-east-2)
+ 美国西部（加利福尼亚北部）区域 (us-west-1)
+ 美国西部（俄勒冈州）区域 (us-west-2)
+ 非洲（开普敦）区域 (af-south-1)
+ 亚太地区（香港）区域 (ap-east-1)
+ 亚太（海得拉巴）区域（ap-south-2）
+ 亚太地区（雅加达）区域 (ap-southeast-3)
+ 亚太地区（墨尔本）区域（ap-southeast-4）
+ 亚太地区（马来西亚）区域（ap-southeast-5）
+ 亚太地区（孟买）区域（ap-south-1）
+ 亚太地区（大阪）区域 (ap-northeast-3)
+ 亚太地区（首尔）区域 (ap-northeast-2)
+ 亚太地区（新加坡）区域 (ap-southeast-1)
+ 亚太地区（悉尼）区域 (ap-southeast-2)
+ 亚太地区（东京）区域（ap-northeast-1）
+ 加拿大（中部）区域（ca-central-1）
+ 加拿大西部（卡尔加里）区域 (ca-west-1)
+ 中国（北京）区域 (cn-north-1)
+ 中国（宁夏）区域 (cn-northwest-1)
+ 欧洲（法兰克福）区域 (eu-central-1)
+ 欧洲（爱尔兰）区域 (eu-west-1)
+ 欧洲（伦敦）区域 (eu-west-2)
+ 欧洲（米兰）区域 (eu-south-1)
+ 欧洲（巴黎）区域 (eu-west-3)
+ 欧洲（西班牙）区域（eu-south-2）
+ 欧洲地区（斯德哥尔摩）区域 (eu-north-1)
+ 欧洲（苏黎世）区域（eu-central-2）
+ 以色列（特拉维夫）区域（il-central-1）
+ 中东（巴林）区域 (me-south-1)
+ 中东（阿联酋）区域（me-central-1）
+ 南美洲（圣保罗）区域 (sa-east-1)
**Topics**
+ [Advisor 的工作原理](#advisor-how-it-works)
+ [优化数据共享架构](#advisor-data-sharing-optimization)
+ [支持 Advisor 的 Amazon Redshift 区域](#advisor-regions)
+ [查看 Amazon Redshift Advisor 建议](access-advisor.md)
+ [Amazon Redshift Advisor 建议](advisor-recommendations.md)
# 查看 Amazon Redshift Advisor 建议
您可以使用 Amazon Redshift 控制台、Amazon Redshift API 或 AWS CLI 查看 Amazon Redshift Advisor 建议。要查看建议，您必须拥有附加到您的 IAM 角色或身份的 `redshift:ListRecommendations` 权限。
## 在 Amazon Redshift 预置控制台上查看 Amazon Redshift Advisor 建议
您可以在 AWS 管理控制台 上查看 Amazon Redshift Advisor 建议
**在控制台上查看 Amazon Redshift Advisor 针对 Amazon Redshift 集群提供的相关建议**
1. 登录到 AWS 管理控制台并打开 Amazon Redshift 控制台，网址：[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)。
1. 在导航菜单上，选择 **Advisor**。
1. 展开每条建议以查看更多详细信息。在此页面上，您可以对建议进行排序和分组。
## 通过执行 Amazon Redshift API 操作查看 Amazon Redshift Advisor 建议
您可以使用 Amazon Redshift API 列出 Amazon Redshift Advisor 针对 Amazon Redshift 集群提供的相关建议。通常，您可以使用自己选择的编程语言进行开发和应用，然后使用 AWS SDK 调用 `redshift:ListRecommendations` API。有关更多信息，请参阅《Amazon Redshift API 参考》**中的 [ListRecommendations](https://docs.aws.amazon.com/redshift/latest/APIReference/API_ListRecommendations.html)。
## 通过执行 AWS Command Line Interface 操作查看 Amazon Redshift Advisor 建议
您可以使用 AWS Command Line Interface 列出 Amazon Redshift Advisor 针对 Amazon Redshift 集群提供的相关建议。有关更多信息，请参阅《AWS CLI 命令参考》**中的 [list-recommendations](https://docs.aws.amazon.com/cli/latest/reference/redshift/list-recommendations.html)。
# Amazon Redshift Advisor 建议
Amazon Redshift Advisor 提供了有关如何优化 Amazon Redshift 集群以提高性能和节省运营成本的建议。您可以在控制台中找到每条建议的说明，如前所示。您可以在以下章节中找到有关这些建议的更多详细信息。
**Topics**
+ [压缩 COPY 加载的 Simple Storage Service（Amazon S3）文件对象](#cluster-compress-s3-recommendation)
+ [隔离多个活动数据库](#isolate-active-dbs-recommendation)
+ [重新分配工作负载管理 (WLM) 内存](#reallocate-wlm-recommendation)
+ [在 COPY 期间跳过压缩分析](#skip-compression-analysis-recommendation)
+ [拆分 COPY 加载的 Simple Storage Service（Amazon S3）对象](#split-s3-objects-recommendation)
+ [更新表统计数据](#update-table-statistics-recommendation)
+ [启用短查询加速](#enable-sqa-recommendation)
+ [修改表上的分配键](#alter-diststyle-distkey-recommendation)
+ [修改表上的排序键](#alter-sortkey-recommendation)
+ [更改列的压缩编码](#alter-compression-encoding-recommendation)
+ [数据类型建议](#data-type-recommendation)
## 压缩 COPY 加载的 Simple Storage Service（Amazon S3）文件对象
COPY 命令利用 Amazon Redshift 中的大规模并行处理 (MPP) 架构并行读取和加载数据。它可以从 Simple Storage Service（Amazon S3）、DynamoDB 表以及来自一个或多个远程主机的文本输出读取文件。
在加载大量数据时，强烈建议使用 COPY 命令从 S3 加载压缩数据文件。压缩大型数据集可节省将文件上载到 Amazon S3 的时间。COPY 还将在读取文件时解压缩文件，以加快加载过程的速度。
**分析**
加载大型未压缩数据集的耗时的 COPY 命令通常有机会获得相当大的性能改进。Advisor 分析将识别用于加载大型未压缩数据集的 COPY 命令。在这种情况下，Advisor 将生成对 Amazon S3 中的源文件实施压缩的建议。
**建议**：
确保每个加载大量数据或运行很长时间的 COPY 都从 Amazon S3 中提取未压缩的数据对象。您可以通过以超级用户身份运行以下 SQL 命令来识别从 Amazon S3 加载大量未压缩数据集的 COPY 命令。
```
SELECT
wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
AND POSITION('COPY ANALYZE' IN querytxt) = 0
AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size)
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;
```
如果暂存的数据在您加载后保留在 Amazon S3 中（通常位于数据湖架构中），以压缩形式存储此数据可以降低存储成本。
**实施提示**
+ 在压缩后，理想的对象大小在 1–128 MB 之间。
+ 您可以使用 gzip、lzop 或 bzip2 格式压缩文件。
## 隔离多个活动数据库
作为最佳实践，我们建议将 Amazon Redshift 中的数据库与其他数据库隔离。查询在特定数据库中运行且无法访问集群上的任何其他数据库中的数据。但是，您在集群的所有数据库中运行的查询共用同一基础集群存储空间和计算资源。当单个集群包含多个活动数据库时，这些数据库的工作负载通常不相关。
**分析**
Advisor 分析将审查集群上的所有数据库中是否有在同一时间运行的活动工作负载。如果存在在同一时间运行的活动工作负载，Advisor 将生成考虑将数据库迁移到独立的 Amazon Redshift 集群的建议。
**建议**
考虑将每个主动查询的数据库移动到独立的专用集群。使用独立的集群可减少资源争用和提高查询性能。之所以如此，是因为它使您能够为每个集群设置大小，以满足每个工作负载的存储、成本和性能需求。此外，不相关的工作负载经常受益于不同的工作负载管理配置。
要识别哪些数据库是主动使用的，您可以作为超级用户运行此 SQL 命令。
```
SELECT database,
COUNT(*) as num_queries,
AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
MIN(starttime) as oldest_ts,
MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;
```
**实施提示**
+ 由于用户必须专门连接到各个数据库，并且查询只能访问单个数据库，因此将数据库移动到独立集群对用户的影响最小。
+ 移动数据库一个方式是执行以下步骤：
1. 将当前集群的快照暂时还原到相同大小的集群。
1. 从新集群中删除除目标数据库之外的所有数据库。
1. 将集群的大小调整为合适的节点类型并针对数据库的工作负载进行计数。
## 重新分配工作负载管理 (WLM) 内存
Amazon Redshift 将用户查询路由至 [实施手动 WLM](cm-c-defining-query-queues.md) 以进行处理。工作负载管理 (WLM) 将定义这些查询路由至队列的方式。Amazon Redshift 为每个队列分配一部分集群可用内存。队列的内存在队列的查询槽间分配。
当某个队列所配置的插槽数多于工作负载需要的插槽数时，分配给这些未使用的插槽的内存将得不到充分利用。通过将配置的插槽数减少得与峰值工作负载需求匹配，您可以将未充分利用的内存重新分配到活动插槽，并可以提高查询性能。
**分析**
Advisor 分析将审查工作负载并发需求以识别具有未使用的插槽的查询队列。当发现以下内容时，Advisor 将生成一个减少队列中的插槽数的建议：
+ 在整个分析过程中具有并非完全不活动的插槽的队列。
+ 在整个分析过程中具有超过四个插槽（其中至少有两个为非活动插槽）的队列。
**建议**
通过将配置的插槽数减少得与峰值工作负载需求匹配，您可以将未充分利用的内存重新分配到活动插槽。请考虑为插槽从未得到充分利用的队列减少配置的插槽计数。要识别这些队列，您可以通过作为超级用户运行以下 SQL 命令来比较每个队列的峰值每小时插槽需求。
```
WITH
generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
apex AS (
SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
FROM
(select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
FROM stl_wlm_query wq
JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
WHERE wq.userid > 1 AND wq.service_class > 5) iq
GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;
```
`max_service_class_slots` 列表示该小时内查询队列中的 WLM 查询插槽的最大数量。如果存在未充分利用的队列，请通过[修改参数组](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-parameter-groups-console.html#parameter-group-modify)来实施插槽减少优化，如《Amazon Redshift 管理指南》**中所述。
**实施提示**
+ 如果工作负载在卷中高度可变，请确保分析捕获了峰值利用率期间。如果没有，请重复运行上述 SQL 以监控峰值并发需求。
+ 有关解释来自上述 SQL 代码的查询结果的更多详细信息，请参阅 GitHub 上的 [wlm\$1apex\$1hourly.sql 脚本](https://github.com/awslabs/amazon-redshift-utils/blob/master/src/AdminScripts/wlm_apex_hourly.sql)。
## 在 COPY 期间跳过压缩分析
当您将数据加载到具有使用 COPY 命令声明的压缩编码的空表中时，Amazon Redshift 将应用存储压缩。此优化确保了即使在由最终用户加载时，集群中的数据也能被高效存储。应用压缩所需的分析可能需要大量时间。
**分析**
Advisor 分析将检查是否有被自动压缩分析延迟的 COPY 操作。该分析通过对加载中的数据进行采样来确定压缩编码。此采样类似于由 [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) 命令执行的采样。
当您将数据作为结构化流程的一部分加载时（例如在夜间提取、转换、加载 (ETL) 批处理中），您可以预先定义压缩。您还可以优化表定义以永久跳过此阶段而不会造成任何负面影响。
**建议**
要通过跳过压缩分析阶段来提高 COPY 响应能力，请实施以下两个选项之一：
+ 在创建您要使用 COPY 命令加载的任何表时使用列 `ENCODE` 参数。
+ 通过在 COPY 命令中应用 `COMPUPDATE OFF` 参数来完全禁用压缩。
最佳解决方案通常是在表创建期间使用列编码，因为此方法还保留了在磁盘上存储压缩数据的好处。您可以使用 ANALYZE COMPRESSION 命令建议压缩编码，但您必须重新创建表以应用这些编码。要自动执行此流程，您可以使用在 GitHub 上找到的 AWS[ColumnEncodingUtility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/ColumnEncodingUtility)。
要识别触发了自动压缩分析的最新 COPY 操作，请运行以下 SQL 命令。
```
WITH xids AS (
SELECT xid FROM stl_query WHERE userid>1 AND aborted=0
AND querytxt = 'analyze compression phase 1' GROUP BY xid
INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec,
a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime)
starttime, substring(querytxt,1,100) as copy_sql,
ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
FROM stl_query q JOIN xids USING (xid)
WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%')
AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid,
ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec
FROM stl_query q JOIN xids USING (xid)
WHERE (querytxt like 'COPY ANALYZE %'
OR querytxt like 'analyze compression phase %')
GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;
```
**实施提示**
+ 确保在 ETL 过程中创建的所有大尺寸表（例如，暂存表和临时表）声明了除第一个排序键之外的所有列。
+ 估计正在为由前面的 SQL 命令标识的每个 COPY 命令加载的表的预计生命周期长短。如果您确信该表仍然非常小，请使用 `COMPUPDATE OFF` 参数完全禁用压缩。否则，请在使用 COPY 命令加载表之前使用显式压缩创建表。
## 拆分 COPY 加载的 Simple Storage Service（Amazon S3）对象
COPY 命令利用 Amazon Redshift 中的大规模并行处理 (MPP) 架构在 Simple Storage Service（Amazon S3）上的文件中读取和加载数据。COPY 命令从多个文件并行加载数据，向集群中的节点划分工作负载。要实现最佳吞吐量，我们强烈建议您将数据拆分成多个文件，以便利用并行处理。
**分析**
Advisor 分析可识别用于加载在 Amazon S3 中暂存的少量文件中包含的大型数据集的 COPY 命令。加载来自若干文件的大型数据集的耗时的 COPY 命令通常有机会获得相当大的性能改进。当 Advisor 发现这些 COPY 命令需要大量时间时，它会提出相关建议，以通过将数据拆分为 Amazon S3 中的额外文件来提高并行度。
**建议**
在这种情况下，我们建议执行以下操作（按优先顺序列出）：
1. 优化加载的文件数比集群节点数更少的 COPY 命令。
1. 优化加载的文件数比集群切片数更少的 COPY 命令。
1. 优化这样的 COPY 命令：其中的文件数不是集群切片数的倍数。
某些 COPY 命令加载大量数据或运行很长时间。对于这些命令，我们建议您在从 Amazon S3 加载大量数据对象时，其数量应等于集群中的切片数的倍数。要识别 COPY 命令已加载的 S3 对象数，请以超级用户身份运行以下 SQL 代码。
```
SELECT
query, COUNT(*) num_files,
ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
AND POSITION('COPY ANALYZE' IN querytxt) = 0
AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;
```
**实施提示**
+ 节点中的切片数取决于集群的节点大小。有关各种节点类型中切片数的更多信息，请参阅《Amazon Redshift 管理指南》**中的 [Amazon Redshift 中的集群和节点](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes)。
+ 您可以通过指定一个通用前缀（对于集合，则为前缀键），或通过在清单文件中明确列出文件，从而加载多个文件。有关加载文件的更多信息，请参阅[从压缩和未压缩文件中加载数据](t_splitting-data-files.md)。
+ Amazon Redshift 在拆分工作负载时不会考虑文件大小。拆分您的加载数据文件，使文件大小大约相等，压缩后的文件大小介于 1 MB 和 1 GB 之间。
## 更新表统计数据
Amazon Redshift 使用基于成本的查询优化程序为查询选择最佳执行计划。成本估算基于使用 ANALYZE 命令收集的表统计数据。当统计数据过时或丢失时，数据库可能会选择一个效率较低的查询执行计划，尤其是对于复杂的查询。保存最新统计数据可帮助复杂的查询在尽可能短的时间内运行。
**分析**
Advisor 分析可跟踪其统计数据已过时或丢失的表。它将审查与复杂查询关联的表访问元数据。如果使用复杂模式频繁访问的表缺少统计数据，Advisor 将创建**关键**建议以运行 ANALYZE。如果使用复杂模式频繁访问的表具有过时的统计数据，Advisor 将创建**启发式**建议以运行 ANALYZE。
**建议**
每当表内容发生重大变化时，请使用 ANALYZE 更新统计数据。每当使用 COPY 或 INSERT 命令将大量新数据行加载到现有表中时，我们建议运行 ANALYZE。每当使用 UPDATE 或 DELETE 命令修改大量行时，我们也建议运行 ANALYZE。要识别具有缺失或过时的统计数据的表，请以超级用户身份运行以下 SQL 命令。结果将按表的大小顺序排列。
要识别具有缺失或过时的统计数据的表，请以超级用户身份运行以下 SQL 命令。结果将按表的大小顺序排列。
```
SELECT
ti.schema||'.'||ti."table" tablename,
ti.size table_size_mb,
ti.stats_off statistics_accuracy
FROM svv_table_info ti
WHERE ti.stats_off > 5.00
ORDER BY ti.size DESC;
```
**实施提示**
默认 ANALYZE 阈值为 10%。此默认值意味着，如果自上次 ANALYZE 之后，给定表有不到 10% 的行发生了更改，则 ANALYZE 命令将跳过此表。因此，您可以选择在每个 ETL 流程结束时发出 ANALYZE 分析。采用此方法意味着经常会跳过 ANALYZE，但也确保了 ANALYZE 在需要时运行。
ANALYZE 统计数据对在联接中使用的列（例如，`JOIN tbl_a ON col_b`）或作为谓词的列（例如，`WHERE col_b = 'xyz'`）影响最大。默认情况下，ANALYZE 将收集指定的表中的所有列的统计数据。如果需要，您可以通过仅对受 ANALYZE 影响最大的列运行 ANALYZE 来减少运行该命令所需的时间。您可以运行以下 SQL 命令来识别要用作谓词的列。您还可以通过指定 `ANALYZE PREDICATE COLUMNS` 来让 Amazon Redshift 选择要分析的列。
```
WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name,
CASE
WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||')
WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
ELSE NULL::varchar
END AS pred_ts
FROM pg_statistic s
JOIN pg_class c ON c.oid = s.starelid
JOIN pg_namespace ns ON c.relnamespace = ns.oid
JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;
```
有关更多信息，请参阅 [分析表](t_Analyzing_tables.md)。
## 启用短查询加速
短查询加速 (SQA) 让选定的短时查询优先于长时查询。SQA 在专用空间中运行短时查询，因此 SQA 查询不会被迫排在队列中的长时查询后面等待。SQA 仅优先处理用户定义的队列中的短时查询。使用 SQA，短时查询会更快地开始运行，用户会更快地看到结果。
如果您开启 SQA，则可以减少或消除专用于运行短查询的工作负载管理（WLM）队列。此外，长时查询无需与短查询竞争队列中的插槽，因此您可以将 WLM 队列配置为使用较少的查询插槽。当您使用较低的并发度时，查询吞吐量会增加，而且大多数工作负载的总体系统性能会得到提高。有关更多信息，请参阅 [短查询加速](wlm-short-query-acceleration.md)。
**分析**
Advisor 检查工作负载模式，并报告 SQA 可以减少延迟的最近查询的数量以及符合 SQA 条件的查询的每日队列时间。
**建议**
修改 WLM 配置以开启 SQA。Amazon Redshift 使用机器学习算法分析每个有资格的查询。预测质量会随着 SQA 从您的查询模式中学习而改进。有关更多信息，请参阅[配置工作负载管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
当您开启 SQA 时，默认情况下 WLM 会将短查询的最大运行时间设置为动态的。我们建议保留 SQA 最大运行时间的动态设置。
**实施提示**
要检查是否开启了 SQA，请运行以下查询。如果查询返回一行内容，则说明 SQA 已开启。
```
select * from stv_wlm_service_class_config
where service_class = 14;
```
有关更多信息，请参阅 [监控 SQA](wlm-short-query-acceleration.md#wlm-monitoring-sqa)。
## 修改表上的分配键
Amazon Redshift 会根据表分配方式在整个集群中分配表中的行。具有 KEY 分配的表需要一个列充当分配键 (DISTKEY)。表中的行会根据其 DISTKEY 列值分配给集群的节点分片。
适当的 DISTKEY 会在每个节点分片上放置相似数量的行，并会经常在联接条件中引用。当表在 DISTKEY 列上联接时，会发生优化联接，从而加快查询性能。
**分析**
Advisor 会分析您集群的工作负载，以确定表中可从 KEY 分配方式显著获益的最适当的分配键。
**建议**
Advisor 提供 [ALTER TABLE](r_ALTER_TABLE.md) 语句，此类语句根据其分析结果来更改表的 DISTSTYLE 和 DISTKEY。要实现显著的性能优势，请确保实施建议组中的所有 SQL 语句。
使用 ALTER TABLE 重新分配大型表会占用集群资源，并且需要在不同时间进行临时表锁定。在其他集群工作负载较轻时实施每个建议组。有关优化表分配属性的更多详细信息，请参阅 [Amazon Redshift 工程高级表设计手册：分配方式和分配键](https://aws.amazon.com/blogs/big-data/amazon-redshift-engineerings-advanced-table-design-playbook-distribution-styles-and-distribution-keys/)。
有关 ALTER DISTSYLE 和 DISTKEY 的更多信息，请参阅 [ALTER TABLE](r_ALTER_TABLE.md)。
**注意**
如果您没有看到建议，这并不一定意味着当前的分配方式是最合适的。当数据不足或重新分配的预期好处很小时，Advisor 不会提供建议。
Advisor 建议适用于特定的表，就算包含同名列的表也不一定适用。除非表中的数据相同，否则就算多个表共享一个列名，表与这些列也可具有不同的特性。
如果您看到针对 ETL 作业所创建或删除的暂存表的建议，请修改 ETL 过程以使用 Advisor 建议的分配键。
## 修改表上的排序键
Amazon Redshift 根据表[排序键](t_Sorting_data.md)对表行进行排序。表行的排序基于排序键列值。
通过要求从磁盘读取较少的表块，可以使用适当的排序键对表进行排序，从而可以提高查询性能，尤其是那些具有范围受限制的谓词的查询。
**分析**
Advisor 会分析您的集群在几天内的工作负载，以便为您的表确定一个有优势的排序键。
**建议**
Advisor 提供两组 ALTER TABLE 语句，此语句根据其分析更改表的排序键：
+ 一组语句，用于更改当前没有排序键的表以添加 COMPOUND 排序键。
+ 一组语句，用于将排序键从 INTERLEAVED 更改为 COMPOUND 或者没有排序键。
使用复合排序键可以显著降低维护开销。具有复合排序键的表不需要昂贵的 VACUUM REINDEX 操作，这些操作对于交错排序是必需的。在实践中，对于绝大多数 Amazon Redshift 工作负载，复合排序键比交错排序键更有效。但是，如果表很小，那么不使用排序键以避免产生排序键存储开销会更有效。
使用 ALTER TABLE 对大型表进行排序时，会消耗集群资源，并且在不同的时间需要表锁。当集群的工作负载适中时，实施每个建议。有关优化表排序键配置的更多详细信息，请参阅 [Amazon Redshift 工程高级表设计手册：复合和交错排序键](https://aws.amazon.com/blogs/big-data/amazon-redshift-engineerings-advanced-table-design-playbook-compound-and-interleaved-sort-keys/)。
有关 ALTER SORTKEY 的更多信息，请参阅 [ALTER TABLE](r_ALTER_TABLE.md)。
**注意**
如果您没有看到关于表的建议，这并不一定意味着当前配置是最好的。当没有足够的数据或排序的预期好处很小时，Advisor 不会提供建议。
Advisor 建议适用于特定的表，就算包含相同名称和数据类型的列的表也不一定适用。根据表中的数据和工作负载，共享列名的表可以有不同的建议。
## 更改列的压缩编码
压缩是可缩减数据存储大小的列级操作。Amazon Redshift 使用压缩功能，通过减少磁盘输入/输出量来节省存储空间并提高查询性能。我们建议根据每列的数据类型和查询模式对其进行最佳压缩编码。通过最佳压缩，查询可以更高效地运行，并且数据库占用的存储空间最少。
**分析**
Advisor 不断对集群的工作负载和数据库 schema 进行分析，以确定每个表列的最佳压缩编码。
**建议**
Advisor 提供 ALTER TABLE 语句，此语句根据其分析更改特定列的压缩编码。
使用 [ALTER TABLE](r_ALTER_TABLE.md) 更改列压缩编码占用集群资源，并且需要在不同时间进行表锁定。最好在集群工作负载较轻时实施建议。
作为参考，[ALTER TABLE 示例](r_ALTER_TABLE_examples_basic.md) 显示了更改列编码的几个语句。
**注意**
当没有足够的数据或更改编码的预期好处很小时，Advisor 不会提供建议。
## 数据类型建议
Amazon Redshift 有一个用于各种使用案例的 SQL 数据类型库。这些包括整数类型，例如 `INT` 以及存储字符的类型，例如 `VARCHAR`。Redshift 以优化的方式存储类型，以提供快速访问和良好的查询性能。此外，Redshift 还提供了针对特定类型的函数，您可以使用这些函数对查询结果进行格式化或执行计算。
**分析**
Advisor 持续对集群的工作负载和数据库架构进行分析，以确定可从数据类型更改中显著受益的列。
**建议**：
Advisor 提供了使用建议的数据类型添加新列的 `ALTER TABLE` 语句。随附的 `UPDATE` 语句会将数据从现有列复制到新列。创建新列并加载数据后，请更改查询和摄入脚本以访问新列。然后利用在 [SQL 函数参考](c_SQL_functions.md)中找到的专门针对新数据类型的功能和函数。
将现有数据复制到新列可能需要时间。当集群的工作负载较轻时，我们建议您实施每个 Advisor 建议。请在[数据类型](c_Supported_data_types.md)引用可用数据类型的列表。
请注意，当没有足够的数据或更改数据类型的预期好处很小时，Advisor 不会提供建议。