Amazon Redshift Serverless增加至1024 RPUs的更高基本容量

关键要点

在快速发展的数据和分析领域，组织不断寻求优化数据基础设施的新方法，以解锁宝贵的见解。AmazonRedshift通过简化分析过程，助力数千家企业在数据处理上实现新的突破。最新的RedshiftServerless支持最大1024个RPUs（Redshift处理单元）的基本容量，帮助各类企业在处理复杂查询时获得更高的性能与更好的性价比。

在如今不断演进的数据和分析世界中，组织总是在寻求优化数据基础设施和挖掘有价值见解的新方法。 每天帮助成千上万的企业彻底改变他们的数据分析方式。该平台完全托管且支持AI，结合并行处理，使企业能够以前所未有的速度发现洞察。无论是小型初创企业还是大型企业，AmazonRedshift都能帮助您快速做出明智决策，并在规模上提供。

是一种按需计费的无服务器数据仓库服务，无需手动集群配置和管理。这一方法对所有规模的组织而言都是一次重大的变革，尤其是在处理可预测或不可预测的工作负载时。

RedshiftServerless的核心创新在于能够根据工作负载需求自动调整计算资源的规模，实现成本效益和性能的最优化，而无需人工干预。用户可以指定服务用于处理查询的基础数据仓库容量，以保持对特定工作负载的稳定性能，或者使用（驱动AI的规模和优化），更适合需求波动的情况，以优化成本的同时保持性能。基础容量以Redshift处理单元（RU）为单位计算，一个RPU提供16GB的内存。Redshift Serverless的默认配置为128RPUs，具备分析PB（千兆字节）级数据的能力，允许用户进行扩展以获得更多算力或降级以降低资费，从而确保数据仓库的容量符合您的独特需求。通过设置更高的基础容量，您可以改善查询的整体性能，特别是对于资源消耗较大的数据处理作业。如果分配更多的RPU作为基础容量，RedshiftServerless将可获得更丰富的内存与处理能力，以应对您最严格的工作负载。此设置使您能够灵活优化RedshiftServerless以满足特定需求。如果您的查询复杂且资源密集，增加基础容量可确保这些查询高效执行，几乎没有瓶颈或延迟。

在本篇文章中，我们将探讨Redshift Serverless新增的1024 RPUs更高基础容量，这一数字是之前512RPUs最大容量的两倍。这项增强功能使您可以实现对包含高度复杂查询和写入密集型工作负载的高性能处理，同时支持并发数据摄取和转化任务，这些任务需要高吞吐量和低延迟。RedshiftServerless还可以扩展至基础容量的10倍。重点在于帮助您找到性能与成本之间的最佳平衡，以满足您的组织独特的数据仓库需求。通过调整基础容量，您可以对RedshiftServerless进行精细调节，为工作负载提供完美结合的速度和效率。

对1024 RPUs的需求

数据仓库工作负载越来越需要高性能计算资源，以满足现代数据处理的需求。对1024RPUs的需求源于多个关键因素。首先，许多数据仓库使用案例涉及处理PB级的历史数据集，无论是初始数据加载还是周期性再次处理和查询。这一现象在如医疗、金融服务、制造、零售和工程等行业尤为突出，这些行业的第三方数据源可提供PB级的信息，必须及时摄取。此外，许多业务流程的季节性特征，如月底或季度末报告，产生周期性的计算需求峰值，因此需大量可扩展资源。

对数据仓库执行的查询和分析的复杂性也呈指数级增长，许多工作负载现在扫描和处理多PB的数据集。这一复杂的数据处理水平要求大量内存和并行处理能力，而这恰好可以通过1024RPU配置得到有效满足。此外，数据仓库与数据湖和其他分布式数据源的日益集成增加了整体计算负担，迫使企业寻找高性能和可扩展的解决方案。

许多数据仓库环境的特点是高写入密集型工作负载，拥有并发的数据摄取和转换任务，这些任务需要一个高吞吐、低延迟的处理架构。对于那些需要访问极大数据量的工作负载，包含复杂的连接、聚合和许多需要大量内存的列，1024RPU配置可以提供必要性能，帮助满足严格的服务水平协议（SLA），并为下游商业智能和决策过程提供及时的数据可用性。为了控制成本，我们可以在工作组配置的限制 选项卡上设置最大容量，以限制资源使用量。以下截图展示了一个示例：

删除)

在后续的测试中，我们比较了使用1024 RPUs的最大容量与512 RPUs的性能。

何时考虑使用1024 RPUs

在以下场景中，可以考虑使用1024 RPUs：

• 复杂和长时间运行的查询 – 大型仓库提供了处理复杂查询所需的计算能力，这些查询涉及多个连接、聚合和计算。对于分析TB或PB级数据的工作负载来说，1024 RPU容量可以显著提高查询完成时间。
• 数据湖查询扫描大数据集 – 扫描外部数据湖中大量数据的查询受益于额外的计算资源。这为大规模分析提供了更快的处理速度和更低的延迟。
• 高内存查询 – 需要大量内存的查询（例如，包含多个列、大量中间结果或临时表）在更大仓库的提升容量下性能更佳。
• 加速数据加载 – 大容量仓库改善了数据摄取任务的性能，例如将大量数据集加载到数据仓库中。这对于涉及频繁或大规模数据加载的工作负载尤其有利。
• 性能关键性用例 – 对于需要低延迟和高响应性的应用程序或系统，1024 RPU仓库通过分配足够的计算资源以高效处理峰值负载，实现平稳操作。

在性能和成本之间取得平衡

选择合适的仓库大小需要评估工作负载的复杂性和性能要求。虽然1024RPUs的仓库在处理计算密集型任务时表现出色，但需与经济性相平衡。建议测试不同基础容量下的工作负载，或使用Redshift Serverless的价格- 性能滑块查找最佳设置。

何时避免使用更大基础容量

尽管较大的仓库提供强大的性能优势，但并不总是最具性价比的解决方案。在以下场景中，较小的基础容量可能更为合适：

• 基本或小型查询 – 处理小数据集或涉及最小计算的简单查询无需使用1024 RPU仓库的高容量。在这种情况下，较小的仓库可以有效处理工作负载，避免不必要的费用。
• 对成本敏感的工作负载 – 对于可预测且适度复杂的工作负载，较小的仓库能在保持成本控制的同时提供足够的性能。选择更大的容量可能导致开支超标，而性能提升并不成比例。

比较与性价比

之前的最大512 RPUs应能满足大多数用例，但在某些情况下，可能需要更多资源。在512 RPUs时，您的工作组可获得8 TB的内存；而在1024RPU时则增加至16 TB。考虑一个场景，在使用COPY命令摄取大量数据时，涉及的医疗数据集超过30 TB。

为了说明这一点，我们在512 RPU工作组与1024 RPU工作组上摄取了来自数据集。

以下图表展示了详细的运行时间。较1024 RPUs相比，512 RPUs的性能整体提高了44%。您将注意到，较大的摄取工作负载表现出更显著的性能提升。

删除)

在US East（Ohio）AWS区域，以每小时0.36美元的价格运行512 RPUs需6809秒，计算成本为6809 * 512 * 0.36 / 60 / 60 = 348.62美元。

在US East（Ohio）区域，以每小时0.36美元的价格运行1024 RPUs需3811秒，计算成本为3811 * 1024 * 0.36 / 60 / 60 = 390.25美元。

在成本方面，1024 RPUs以12%的较高成本，可以在44%更快的速度下摄取30 TB的数据。

接下来，我们在相同的两个工作组上，运行了，以比较查询性能。

以下图表展示了22个TPC-H查询的详细运行时间。我们看到1024 RPUs在单会话顺序查询执行中的整体性能提升达17%。

删除)

在并发运行20个会话时，性能提升62%，从512 RPUs的6903秒降低至1024 RPUs的2592秒，每个会话均以不同的顺序运行22个TPC-H查询。

请注意，并发执行与顺序执行（17%）的显著差异。并发执行代表了典型的生产系统，在其中多个并发会话运行查询。您的概念验证决策需要基于类似生产的场景，而不仅仅是单用户运行的顺序执行。以下表格比较了两次测试的结果。

| 512 RPU | 1024 RPU
---|---|---
顺序（秒） | 1276 | 1065
并发执行（秒） | 6903 | 2592
总计（秒） | 8179 | 3657
总费用（$） | $418.76 | $374.48

总费用（$）为秒数 * RPUs * 0.36 / 60 / 60。

1024 RPUs在对30 TB基准数据运行TPC-H查询时，速度提高55%，而相较于512 RPUs的成本降低11%。

AmazonRedshift提供和，对跟踪资源利用率非常有帮助。我们分析了来自和表的额外指标，以识别特定的查询执行部分发生了性能改进或下降。值得注意的是，1024RPUs的16 TB内存能够在内存中保存更多的数据块，因此需要从SSD读取的区块减少35%。同时，与512 RPUs相比，需从远程读取的块减少71%。最后，相较于512RPUs，降至SSD（当查询无法分配更多内存时）减少63%；降至S3（SSD缓存完全占用）在1024 RPUs上则完全消失。

以下是从Amazon Redshift控制台捕获的一些运行特征图表。要查找这些内容，请选择“查询与数据库监控”和“资源监控”菜单。

得益于性能的提升，1024 RPUs下的查询完成时间比512 RPUs更快，结果是连接结束更快。

以下图表展示了使用512 RPUs的数据库连接情况。

![Database Connections - 512删除)

以下图表展示了使用1024 RPUs的数据库连接情况。

![Database Connections - 1024删除)

关于查询分类，有三个类别：短查询（少于10秒）、中等查询（10秒到10分钟）和长查询（超过10分钟）。我们观察到，由于性能的改善，1024RPU配置相比于512 RPU配置导致长查询的数量降低。

以下图表展示了使用512 RPUs的查询时长情况。![Duration of Queries (512删除)

以下图表展示了使用1024 RPUs的查询时长情况。

![Duration of Queries (1024删除)

得益于卓越的性能，我们注意到每秒处理的查询数量在1024 RPUs下有所增加。

以下图表展示了使用512 RPUs的每秒查询完成情况。

![Queries Per Second (512删除)

以下图表展示了使用1024 RPUs的每秒查询完成情况。

![Queries Per Second (1024删除)

在以下图表中，我们看到虽然运行的查询数量相似，但1024 RPU端点结束查询的速度却更快，这意味着在运行相同数量的查询时所需时间更短。

以下图表展示了使用512 RPUs的查询执行情况。

![Queries running (512删除)

以下图表展示了使用1024 RPUs的查询执行情况。

![Queries running (1024删除)

在比较两次测试时，没有出现排队现象。

以下图表展示了使用512 RPUs的待队查询情况。

![Queries queued (512删除)

以下图表展示了使用1024 RPUs的待队查询情况。

![Queries queued (1024删除)

以下图表展示了使用512 RPUs的查询运行时分解情况。

![Query Breakdown (512 RPUs)](https://d2908q