用 Amazon Redshift MCP 服务器自动执行运营审查

一个强劲的季度结束了，你的 Amazon Redshift 工作负载也随着业务增长而增长。数据量上升了，新管道已上线，查询的团队也比最初确定集群规模时更多了。没有出问题，但这正是定期进行运营审查能带来回报的时候。它能确认集群是否仍针对当前的使用方式进行了调优，并揭示在扩展过程中优化成本和性能的方法。

Amazon Redshift 已经自动化了大量显著的运营复杂性。自动表优化、自动工作负载管理和自动清理等自主功能处理了大部分复杂工作，因此你可以专注于编写查询，而不是管理基础设施。Amazon Redshift Serverless 更进一步，使用 AI 驱动的扩展来根据工作负载需求调整计算资源。

即便如此，有些决策仍然受益于人的判断。例如，表设计选择可能没有考虑到常见的连接模式，或者自表创建以来查询模式已经发生了变化。这两点都值得重新审视。同样，随着工作负载增加，也值得判断当前的部署模型是否仍然规模合适。

许多组织已将此转变为一项循环性的业务流程：监控仪表板和关键绩效指标（KPI），缩小长时间运行查询的范围，跨团队协作解决问题，并指导用户采用高效的查询模式。这并非 Amazon Redshift 所独有。这是任何生产数据系统的最佳实践。

AWS Enterprise Support 帮助客户进行这些审查。但即使有专家协助，该过程通常每个集群仍需投入 4–8 小时的专注工作：组装诊断查询、解读结果、交叉参考文档，以及将发现汇编成按优先级排序的报告。大多数团队认可其价值，但总是将其降级，优先处理功能交付和日常运营。

在 之前的文章中，我们演示了如何使用 Kiro 和 Amazon Redshift Model Context Protocol（MCP）服务器以自然语言查询 Amazon Redshift。该方法用对话式分析取代了手动浏览模式和手写 SQL。本文更进一步：从 询问关于你的数据的问题 到 询问关于你的集群运营健康状况的问题。

Amazon Redshift MCP 服务器中的 review_cluster 工具让整个诊断过程可以通过一次自然语言请求完成。它评估 12 个诊断领域，识别潜在问题，并返回按优先级排序的建议，这些建议直接链接到 AWS 文档，一次调用即可覆盖预置集群和无服务器工作组。以前需要数小时专家工作的事情现在几分钟即可完成。这使得每周、重大模式更改后或高峰流量事件前审查集群变得切实可行。

在本文中，你将学习如何：

1. 使用自然语言对你的 Amazon Redshift 集群运行自动化运营审查。
2. 解读结构化的发现结果和建议。
3. 通过对话针对具体发现采取行动，将诊断转化为修复，而无需离开 Kiro、Claude 或任何兼容 MCP 的客户端。
4. 将定期审查纳入你的运营工作流程。

什么是 review_cluster 工具？

一次自然语言请求即可触发全面的诊断评估。它补充了服务器的发现和查询工具：那些工具让你以对话方式访问数据，而 review_cluster 则为你的集群健康状况提供同样的能力。该工具针对 Amazon Redshift 系统视图执行一组精选查询，根据已知的最佳实践阈值评估结果，并返回带有按优先级排序建议的结构化发现。每条建议都包含指向相关 AWS 文档的直接链接，因此你可以从识别直接进入修复，无需搜索。整个过程是只读的。不会修改数据，不会更改配置，也不会创建资源。该工具只进行观察和报告。修复决策仍由你做出。

该工具返回一个结构化结果，其中包含：

• 已评估的信号：执行的诊断检查总数。
• 发现结果：触发的条件列表，每个条件包含名称、受影响对象的数量（表、查询、节点）以及关联的建议 ID。
• 建议：去重后的纠正措施列表，按所需工作量排序，并附有文档链接。

它检查的内容

该审查目前跨 12 个诊断领域评估你的集群：

1. 自动表优化（ATO）：Amazon Redshift 的自动调优操作（编码、排序键、分布样式）是否成功完成。
2. 表设计建议：Amazon Redshift Advisor 针对编码、排序键和分布的尚未应用的建议。
3. COPY 和数据摄取性能：文件大小、相对于切片数量的并行度，以及摄取吞吐量模式。
4. 外部查询（Spectrum）性能：针对外部表的查询的分区裁剪有效性、文件大小和扫描效率。
5. 物化视图健康状况：物化视图的陈旧程度、自动刷新状态和维护开销。
6. 节点和存储利用率：磁盘使用情况、节点类型时效性，以及集群是否能从迁移到最新实例代次中受益。
7. 表级统计信息：清理状态、陈旧统计信息、排序键有效性、分布倾斜和压缩编码覆盖率。
8. 查询性能：运行时间最长的查询、嵌套循环连接和磁盘溢出模式。
9. 工作负载使用模式：集群在一天中被使用的密集程度，以及工作负载是否适合当前的部署模型。
10. 工作负载管理（WLM）配置：队列设置、并发扩展、短查询加速、优先级设置和查询监控规则。
11. 工作负载评估：集群的使用模式是否表明它可以从无服务器等其他部署模型中获益。
12. 无服务器扩缩容：无服务器工作组观测到的计算范围是否落在 AI 驱动的扩缩容窗口内。

并非每个领域都适用于每种部署，因为某些检查针对的是仅存在于某一模型中的配置。有四项检查仅适用于预置集群：COPY 并行度相对于切片数量、节点和存储利用率、WLM 配置以及工作负载评估。这些检查调优的是 Amazon Redshift Serverless 会为你管理的构造。无服务器没有需要调整规模的节点或切片，并且它始终使用自动 WLM 而非用户配置的队列，因此这些检查没有可作用的对象。无服务器扩缩容检查则相反：它评估 AI 驱动的 Redshift 处理单元（RPU）扩缩容，这是无服务器特有的，在预置集群上没有对应项。因此，预置集群评估 12 个领域中的 11 个，无服务器工作组评估 8 个，该工具会将实际运行的领域数量报告为已评估的信号。

运行你的首次审查

以下步骤涵盖你需要准备的内容以及如何启动审查。

先决条件

在运行审查之前，请确保你具备：

• 一个配置了 Amazon Redshift MCP 服务器的 MCP 兼容客户端（例如 Kiro）。有关安装和配置步骤，请参阅 Amazon Redshift MCP 服务器 README。
• 有效的 AWS 凭证，并具有该服务器所需的 AWS Identity and Access Management（IAM）权限。
• 授予连接数据库用户的 sys:monitor 角色，这是 review_cluster 所需的唯一一项额外数据库权限。

要授予此访问权限，具有超级用户权限的数据库管理员需运行：

GRANT ROLE sys:monitor TO "IAMR:YourRoleName";

IAM 身份的数据库用户名遵循格式 IAMR:RoleName 或 IAM:UserName。可在 Amazon Redshift 查询编辑器中使用 SELECT current_user 确认你的用户名。GRANT 语句中的双引号对于 IAM 身份名称是必需的。

先决条件就绪后，审查只需一个提示：

Run a review of analytics-cluster

代理会识别目标集群、连接到数据库并执行诊断评估。

以下示例展示了对无服务器工作组进行审查的输出。由于四项仅适用于预置集群的领域不适用，该工具评估了 12 个诊断领域中的 8 个，识别出 8 项发现，并将它们映射到 6 条不同的建议：

Cluster Review: analytics-cluster (Serverless, eu-west-2 / London)
Ran the diagnostic --- result: 8 signals evaluated, 8 findings, 6 recommendations.
Findings
- Missing statistics --- 16 queries hit tables that have never been analyzed
- Dist/Broadcast alerts --- 10 queries reshuffle data across nodes
- Nested loop joins / cross-joins --- 5 long-running queries
- Small tables without ALL distribution --- 4 tables
- Small tables with a manual sort key --- 4 tables
- Large table with data skew --- 1 table (slice imbalance ≥4x)
- Large table distributed by date/datetime --- 1 table
- Variable serverless workload in the AI-scaling range --- 1 workgroup
Recommendations
1. REC_003 --- Analyze tables (fix missing stats). Effort: Low. Run or schedule ANALYZE on the 16 affected tables. Lowest-effort, highest-impact item; also improves the poor distribution/plan decisions the optimizer is making. Docs: https://docs.aws.amazon.com/redshift/latest/dg/t_Analyzing_tables.html
2. REC_007 --- Right-size sort keys. Effort: Low. The 4 small tables carry manual sort keys that add overhead for little benefit --- switch them to ALTER TABLE [table] ALTER SORTKEY AUTO. Docs: https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-sort-key.html
3. REC_008 --- Choose the right distribution style. Effort: Low--Medium. Small tables → DISTSTYLE AUTO/ALL; the skewed large table → pick a better DISTKEY (skew often from NULLs in the key); the date-distributed large table → reconsider the key or move to DISTSTYLE AUTO. This also resolves the 10 Dist/Broadcast query alerts. Docs: https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-best-dist-key.html
4. REC_030 --- Tune serverless AI-driven scaling. Effort: Low. Review your price-performance target (Optimizes for cost / Balanced / Optimizes for performance) and pair it with Max capacity + Max RPU-hours caps to keep cost predictable. Adapts over 1--3 days. Docs: https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-capacity.html
5. REC_009 --- Remove nested loop joins (cross-joins). Effort: Medium. Add join conditions to the 5 cross-join queries. Docs: https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html#nested-loop
6. REC_019 --- Add QMR rules. Effort: Medium. Add query monitoring rules to catch nested loops and long runtimes going forward (log/hop/abort actions). Docs: https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html
Suggested starting point
Start with REC_003 (ANALYZE) --- cheapest, highest-impact, and likely a root cause behind several slow-query findings. Then apply the AUTO table-optimization changes in REC_007 and REC_008, which are mostly one-line ALTER TABLE statements.
Want me to pull the specific table names behind each finding and draft the exact ANALYZE / ALTER TABLE remediation statements?

每项发现代表一个被触发的独立诊断条件。affected_row_count 表示有多少对象匹配该特定条件。这些计数描述的是集群的不同维度，不能跨发现相加。

当该工具返回零项发现时，表明集群在所评估的领域内运行于最佳实践阈值范围之内。

从发现到修复

审查输出不是一份静态报告。它是交互式对话的起点。每项发现都会识别一个特定条件，每条建议都会提供清晰的修复路径以及文档链接。从这里开始，你可以继续在同一个 Kiro 会话中工作，以规划和准备后续步骤。

建议大致分为四大类：

• 快速配置更改：启用并发扩展或短查询加速等操作只需在 Amazon Redshift 控制台中更改一个参数，或进行一次简短的 API 调用。这些是低风险、高影响的调整，通常可以立即应用。
• 批量表操作：与表设计（分布样式、排序键、压缩编码）相关的发现通常会影响多个表。你可以让 Kiro 列出所涉及的具体表，并生成相应的 ALTER TABLE 语句。检查生成的 SQL，然后通过 Amazon Redshift 查询编辑器或你偏好的 SQL 客户端应用它。
• 数据摄取优化：与 COPY 性能相关的发现会指出数据加载方式中的低效之处。例如，源文件可能太小，或者文件数量可能与集群的切片数量不匹配。解决这些问题需要在你的提取、转换和加载（ETL）管道或 Amazon Simple Storage Service（Amazon S3）暂存流程的上游进行更改，而不是在 Amazon Redshift 本身内部进行。
• 架构决策：迁移到 Amazon Redshift Serverless 或调整为 RG 实例等建议需要更广泛的评估。这些不是单条命令即可完成的修复。它们涉及容量规划、工作负载测试，以及可能的迁移步骤。建议文本和所链接的文档提供了开始该规划所需的背景信息。

在呈现发现之后，Kiro 会提出下一步最值得采取的行动，通常从投入最低、影响最大的建议开始。或者，你也可以自己引导对话。例如：

• “哪些表受到分布样式发现的影响？”
• “这些表的 ALTER TABLE 语句会是什么样子？”
• “解释一下并发扩展的作用以及如何启用它。”
• “将此工作负载迁移到无服务器有哪些权衡？”

Kiro 会检索相关详细信息、在适用时生成 SQL，并引用文档。该工具进行诊断并提出建议，但不会修改你的集群。是否应用更改仍由你决定。

最佳实践

充分利用 review_cluster 的提示。

1. 将审查嵌入你的 DataOps 实践。定期的表和集群维护是任何生产数据仓库的一项基础最佳实践，其价值来自一致性。运维审查是更广泛的 DataOps 学科的一个组成部分：即维护清洁、可靠、受治理且始终可用的数据系统的实践。为你的集群定义 KPI，例如查询延迟百分位数、磁盘溢出频率和 WLM 队列等待时间。然后使用定期的 review_cluster 运行来对照这些 KPI 跟踪你的查询和工作负载优化进展。随着时间推移，这会形成一个反馈循环：发现的问题为修复提供依据，KPI 衡量影响，而下一次审查验证改进。
2. 按固定节奏运行审查。像对待测试一样对待运维审查：你运行得越规律，就能越早发现漂移，以免影响用户。考虑每周运行一次审查，在重大 schema 变更之后、在重大数据加载之后，或在预期的高峰流量事件之前运行。
3. 遵循文档链接。每条建议都包含指向相关 AWS 文档的直接链接。这些页面提供了详细指导、边缘案例和配置示例，超出了建议文本所能涵盖的范围。在规划修复时，将它们作为你的主要参考。
4. 从低投入的收益开始。这些建议按投入程度排序。先从快速配置更改（并发扩展、短查询加速、查询监控规则）开始，然后再进行需要更广泛规划的结构性更改。早期收益能建立信心，并且通常足以提升集群性能，从而为更大的更改创造余量。
5. 将审查用作基线。在重大更改前后各运行一次审查，以衡量其效果。例如，在应用表设计建议后，后续审查应显示与表相关的发现更少。这种前后对比模式有助于验证你的更改达到了预期效果。

结论

在这篇博文中，你学习了如何使用 Kiro 以自然语言对 Amazon Redshift 集群运行自动化运维审查。review_cluster 工具评估 12 个诊断领域，从表设计和工作负载管理到节点利用率和数据摄取性能。它返回按优先级排序、可操作的建议，并直接链接到 AWS 文档。

过去需要专家花费数小时组装诊断脚本、解读系统视图输出并汇编发现，现在只需一次请求即可完成。这一转变使得将运维审查纳入你的常规工作流变得切实可行，而不是将其视为一项不频繁、资源密集型的练习。

要开始使用：

1. 确保在 Kiro 中配置了 Amazon Redshift MCP 服务器（参见设置博文）。
2. 将 sys:monitor 角色授予你的数据库用户。
3. 让 Kiro 审查你的集群。

要进一步深入：

• 访问 Amazon Redshift MCP 服务器 文档以获取完整的工具参考。
• 阅读 MCP 协议，以了解 AI 代理如何与外部工具集成。
• 探索 Kiro 以了解其他功能，包括引导文件、钩子和代理自动化。