Amazon Redshift：更低的价格、更高的性能 | 亚马逊网络服务

Amazon Redshift：更低的价格、更高的性能 | 亚马逊网络服务

时间戳记：26年2023月6日下午10:XNUMX
源节点： 2959258

与几乎所有客户一样，您希望花费尽可能少的费用，同时获得最佳性能。 这意味着您需要注意性价比。 和 亚马逊Redshift，鱼与熊掌兼得！ 与其他云数据仓库相比，Amazon Redshift 在实际工作负载上可将每用户成本降低高达 4.9 倍，性价比提高高达 7.9 倍，使用并发扩展等先进技术来支持数百个并发用户，增强字符串编码以实现更快的查询性能， 和 Amazon Redshift 无服务器 性能增强。 请继续阅读，了解为什么性价比很重要，以及 Amazon Redshift 性价比如何衡量获得特定级别的工作负载性能所需的成本，即性能 ROI（投资回报率）。

由于价格和性能都纳入性价比计算，因此有两种方式来考虑性价比。 第一种方法是保持价格不变：如果您有 1 美元可花，您可以从数据仓库中获得多少性能？ 具有更好性价比的数据库每花费 1 美元就能提供更好的性能。 因此，在保持价格不变的情况下比较两个成本相同的数据仓库时，性价比更好的数据库将更快地运行您的查询. 查看性价比的第二种方法是保持性能不变：如果您需要在 10 分钟内完成工作负载，那么成本是多少？ 具有更好性价比的数据库将以更低的成本在 10 分钟内运行您的工作负载。 因此，在保持性能不变的情况下，比较两个大小可提供相同性能的数据仓库时，性价比更高的数据库成本更低，可以节省资金。

最后，性价比的另一个重要方面是可预测性。 了解随着数据仓库用户数量的增长，数据仓库的成本对于规划至关重要。 它不仅应该提供当今最佳的性价比，而且还应该可预测地扩展，并随着更多用户和工作负载的增加提供最佳的性价比。 一个理想的数据仓库应该具备 线性标度—扩展数据仓库以提供两倍的查询吞吐量，理想情况下成本应该是两倍（或更少）。

在这篇文章中，我们分享性能结果，以说明与领先的替代云数据仓库相比，Amazon Redshift 如何提供显着更好的性价比。 这意味着，如果您在 Amazon Redshift 上花费的金额与在其他数据仓库之一上花费的金额相同，您将通过 Amazon Redshift 获得更好的性能。 或者，如果您调整 Redshift 集群大小以提供相同的性能，与这些替代方案相比，您将看到更低的成本。

实际工作负载的性价比

您可以使用 Amazon Redshift 为各种工作负载提供支持，从基于复杂提取、转换和加载 (ETL) 的报告的批处理、实时流分析到低延迟商业智能 (BI) 仪表板需要以亚秒级响应时间以及介于两者之间的所有内容同时为数百甚至数千个用户提供服务。 我们不断为客户提高性价比的方法之一是不断审查 Redshift 队列的软件和硬件性能遥测数据，寻找可以进一步提高 Amazon Redshift 性能的机会和客户用例。

由车队遥测驱动的性能优化的一些最新示例包括：

  • 字符串查询优化 – 通过分析 Amazon Redshift 如何处理 Redshift 队列中的不同数据类型，我们发现优化字符串密集型查询将为客户的工作负载带来显着的好处。 （我们将在本文后面更详细地讨论这一点。）
  • 自动物化视图 – 我们发现 Amazon Redshift 客户经常运行许多具有常见子查询模式的查询。 例如，几个不同的查询可能使用相同的连接条件连接相同的三个表。 Amazon Redshift 现在能够自动创建和维护物化视图，然后透明地重写查询以使用机器学习的物化视图 自动物化视图 Amazon Redshift 中的自主功能。 启用后，自动物化视图可以透明地提高重复查询的查询性能，而无需任何用户干预。 （请注意，本文讨论的任何基准测试结果均未使用自动物化视图）。
  • 高并发工作负载 – 我们看到越来越多的用例是使用 Amazon Redshift 来服务类似仪表板的工作负载。 这些工作负载的特点是所需的查询响应时间为个位数秒或更短，数十或数百个并发用户同时运行查询，使用模式尖峰且通常不可预测。 典型的示例是 Amazon Redshift 支持的 BI 仪表板，当大量用户开始新的一周时，该仪表板在周一早上的流量会出现峰值。

高并发工作负载尤其具有非常广泛的适用性：大多数数据仓库工作负载都以并发方式运行，数百甚至数千用户同时在 Amazon Redshift 上运行查询的情况并不少见。 Amazon Redshift 旨在保持查询响应时间可预测且快速。 Redshift Serverless 通过根据需要添加和删除计算来自动为您完成此操作，以保持查询响应时间快速且可预测。 这意味着 Redshift Serverless 支持的仪表板在被一两个用户访问时会快速加载，即使许多用户同时加载它也会继续快速加载。

为了模拟这种类型的工作负载，我们使用了源自 TPC-DS 的基准测试和 100 GB 数据集。 TPC-DS 是一个行业标准基准测试，包括各种典型的数据仓库查询。 在 100 GB 的相对较小规模下，该基准测试中的查询在 Redshift Serverless 上运行平均需要几秒钟，这代表了加载交互式 BI 仪表板的用户所期望的结果。 我们对此基准测试运行了 1-200 个并发测试，模拟 1-200 个用户尝试同时加载仪表板。 我们还对几个流行的替代云数据仓库进行了重复测试，这些数据仓库也支持自动扩展（如果您熟悉这篇文章） Amazon Redshift 继续保持性价比领先地位，我们没有包括竞争对手 A，因为它不支持自动扩展）。 我们测量了平均查询响应时间，这意味着用户等待查询完成（或仪表板加载）的时间。 结果如下图所示。

竞争对手 B 可以很好地扩展，直到大约 64 个并发查询，此时它无法提供额外的计算，并且查询开始排队，导致查询响应时间增加。 尽管竞争对手 C 能够自动扩展，但其扩展后的查询吞吐量低于 Amazon Redshift 和竞争对手 B，并且无法保持较低的查询运行时间。 此外，当计算耗尽时，它不支持排队查询，这会阻止它扩展到超过 128 个并发用户。 超出此范围提交其他查询将被系统拒绝。

在这里，即使数百个用户同时运行查询，Redshift Serverless 也能够将查询响应时间保持在 5 秒左右相对一致。 随着仓库负载的增加，竞争对手 B 和 C 的平均查询响应时间稳步增加，这导致当数据仓库繁忙时，用户必须等待更长的时间（最多 16 秒）才能返回查询。 这意味着，如果用户尝试刷新仪表板（甚至可能在重新加载时提交多个并发查询），Amazon Redshift 将能够使仪表板加载时间更加一致，即使该仪表板正在由数十或数百个其他数据加载用户同时。

因为 Amazon Redshift 能够为短查询提供非常高的查询吞吐量（正如我们在 Amazon Redshift 继续保持性价比领先地位），它还能够在更有效地扩展时处理这些更高的并发性，因此成本显着降低。 为了量化这一点，我们使用已发布的价格来查看性价比 按需定价 对于前面测试中的每个仓库，如下图所示。 值得注意的是，使用 预留实例 (RI)，特别是通过全额预付款选项购买的 3 年 RI，在预配置集群上运行 Amazon Redshift 的成本最低，与按需或其他 RI 选项相比，具有最佳的相对性价比。

因此，Amazon Redshift 不仅能够在更高的并发性下提供更好的性能，而且能够以显着降低的成本实现这一点。 性价比图表中的每个数据点都相当于在指定并发下运行基准测试的成本。 由于性价比是线性的，因此我们可以将任意并发下运行基准测试的成本除以并发度（此图表中的并发用户数），以告诉我们为此特定基准添加每个新用户的成本。

前面的结果很容易复制。 基准测试中使用的所有查询都可以在我们的 GitHub存储库 性能的衡量方法是启动数据仓库、在 Amazon Redshift 上启用并发扩展（或其他仓库上的相应自动扩展功能）、开箱即用加载数据（无需手动调整或特定于数据库的设置），然后运行每个数据仓库上的并发查询流的并发数为 1-200，步长为 32。 相同的 GitHub 存储库引用了预生成（且未修改）的 TPC-DS 数据 亚马逊简单存储服务 （Amazon S3）使用官方 TPC-DS 数据生成套件进行各种规模的计算。

优化字符串密集型工作负载

如前所述，Amazon Redshift 团队不断寻找新机会，为我们的客户提供更好的性价比。 我们最近推出的一项显着提高性能的改进是一项优化，可加快字符串数据查询的性能。 例如，您可能希望通过以下查询查找位于纽约市的零售商店产生的总收入 SELECT sum(price) FROM sales WHERE city = ‘New York’。 此查询对字符串数据应用谓词 (city = ‘New York’）。 正如您可以想象的那样，字符串数据处理在数据仓库应用程序中无处不在。

为了量化客户工作负载访问字符串的频率，我们使用 Amazon Redshift 管理的数万个客户集群的队列遥测技术对字符串数据类型的使用情况进行了详细分析。 我们的分析表明，在 90% 的集群中，字符串列至少占所有列的 30%，而在 50% 的集群中，字符串列至少占所有列的 50%。 此外，在 Amazon Redshift 云数据仓库平台上运行的大多数查询都会访问至少一个字符串列。 另一个重要因素是字符串数据通常基数较低，这意味着列包含相对较小的唯一值集。 例如，虽然一个 orders 表示销售数据的表可能包含数十亿行， order_status 该表中的列可能只包含数十亿行中的几个唯一值，例如 pending, in process及 completed.

截至撰写本文时，Amazon Redshift 中的大多数字符串列都经过压缩 左旋 or 中部标准 算法。 这些是很好的通用压缩算法，但它们并不是为利用低基数字符串数据而设计的。 特别是，它们要求在操作之前对数据进行解压缩，并且在使用硬件内存带宽方面效率较低。 对于低基数数据，还有另一种更优化的编码方式： 字节字典。 此编码使用字典编码方案，允许数据库引擎直接对压缩数据进行操作，而无需先对其进行解压缩。

为了进一步提高字符串密集型工作负载的性价比，Amazon Redshift 现在引入了额外的性能增强功能，与编码为 BYTEDICT 的低基数字符串列相比，可加快扫描和谓词评估速度，速度提高了 5-63 倍（请参阅中的结果）下一节）与 LZO 或 ZSTD 等替代压缩编码进行比较。 Amazon Redshift 通过对轻量级、CPU 高效、BYTEDICT 编码、低基数字符串列进行矢量化扫描来实现此性能改进。 这些字符串处理优化有效地利用了现代硬件提供的内存带宽，从而实现了字符串数据的实时分析。 这些新引入的性能功能对于低基数字符串列（最多数百个唯一字符串值）来说是最佳的。

通过启用，您可以自动从这种新的高性能字符串增强功能中受益 自动表优化 在您的 Amazon Redshift 数据仓库中。 如果您的表没有启用自动表优化，您可以收到来自 亚马逊红移顾问 在 Amazon Redshift 控制台中了解字符串列是否适合 BYTEDICT 编码。 您还可以使用 BYTEDICT 编码定义具有低基数字符串列的新表。 Amazon Redshift 中的字符串增强功能现已在所有 AWS 区域推出 亚马逊 Redshift 可用.

绩效结果

为了衡量字符串增强功能对性能的影响，我们生成了一个由低基数字符串数据组成的 10TB（太字节）数据集。 我们使用短字符串、中字符串和长字符串生成了三个版本的数据，分别对应于 Amazon Redshift 队列遥测的字符串长度的第 25、50 和 75 个百分点。 我们将此数据加载到 Amazon Redshift 中两次，一次使用 LZO 压缩对其进行编码，另一次使用 BYTEDICT 压缩对其进行编码。 最后，我们测量了返回大量行（表的 90%）、中等行（表的 50%）和少量行（表的 1%）的大量扫描查询的性能。 -基数字符串数据集。 性能结果总结在下图中。

与 LZO 相比，使用新的矢量化 BYTEDICT 编码，具有匹配高百分比行的谓词的查询得到了 5-30 倍的改进，而具有与低百分比行匹配的谓词的查询在此内部基准测试中得到了 10-63 倍的改进。

Redshift 无服务器性价比

除了本文中介绍的高并发性能结果之外，我们还使用 TPC-DS 衍生的云数据仓库基准来比较 Redshift Serverless 与使用更大 3TB 数据集的其他数据仓库的性价比。 我们选择了定价类似的数据仓库，在本例中，使用公开的按需定价，误差在每小时 10 美元的 32% 以内。 这些结果表明，与 Amazon Redshift RA3 实例一样，Redshift Serverless 与其他领先的云数据仓库相比可提供更好的性价比。 与往常一样，这些结果可以通过使用我们的 SQL 脚本来复制 GitHub存储库.

我们鼓励您尝试使用自己的 Amazon Redshift 概念验证 工作负载是了解 Amazon Redshift 如何满足您的数据分析需求的最佳方式。

找到适合您工作负载的最佳性价比

本文中使用的基准测试源自行业标准 TPC-DS 基准测试，并具有以下特征：

  • 模式和数据未经 TPC-DS 修改而使用。
  • 查询是使用官方 TPC-DS 套件生成的，查询参数是使用 TPC-DS 套件的默认随机种子生成的。 如果仓库不支持默认 TPC-DS 查询的 SQL 方言，则将 TPC 批准的查询变体用于仓库。
  • 该测试包括 99 个 TPC-DS SELECT 查询。 它不包括维护和吞吐量步骤。
  • 对于单个 3TB 并发测试，运行了 XNUMX 次电源运行，并为每个数据仓库选取最佳运行。
  • TPC-DS 查询的性价比按每小时成本 (USD) 乘以基准运行时间（以小时为单位）计算，这相当于运行基准的成本。 最新发布的按需定价适用于所有数据仓库，而不是前面提到的预留实例定价。

我们将此称为云数据仓库基准，您可以使用我们的脚本、查询和数据轻松重现前面的基准结果。 GitHub存储库。 它源自本文所述的 TPC-DS 基准测试，因此与已发布的 TPC-DS 结果不可比较，因为我们的测试结果不符合官方规范。

结论

Amazon Redshift 致力于为最广泛的工作负载提供业界最佳的性价比。 Redshift Serverless 以最佳（最低）性价比线性扩展，支持数百个并发用户，同时保持一致的查询响应时间。 根据本文讨论的测试结果，与最接近的竞争对手（竞争对手 B）相比，在相同并发水平下，Amazon Redshift 的性价比高出 2.6 倍。 如前所述，使用具有 3 年预付费选项的预留实例可为您提供最低的运行 Amazon Redshift 成本，与我们在本文中使用的按需实例定价相比，可实现更好的相对性价比。 我们持续性能改进的方法涉及以客户为中心的独特组合，以了解客户用例及其相关的可扩展性瓶颈，再加上持续的车队数据分析，以识别进行重大性能优化的机会。

每个工作负载都有独特的特征，因此如果您刚刚开始， 概念验证 是了解 Amazon Redshift 如何降低成本同时提供更好性能的最佳方式。 在运行您自己的概念验证时，重要的是要关注正确的指标：查询吞吐量（每小时查询数）、响应时间和性价比。 您可以通过自己运行概念验证来做出数据驱动的决策，或者 在协助下 来自 AWS 或 系统集成和咨询合作伙伴.

要了解 Amazon Redshift 的最新动态，请关注 Amazon Redshift 的新增功能 饲料。

关于作者

斯特凡·格罗莫尔 是 Amazon Redshift 团队的高级性能工程师，负责衡量和改进 Redshift 性能。 闲暇时，他喜欢做饭、和三个儿子玩耍以及砍柴。

拉维·阿尼米 是 Amazon Redshift 团队的高级产品管理领导者，负责管理 Amazon Redshift 云数据仓库服务的多个功能领域，包括性能、空间分析、流式摄取和迁移策略。 他拥有关系数据库、多维数据库、物联网技术、存储和计算基础设施服务方面的经验，最近作为一名初创公司创始人使用人工智能/深度学习、计算机视觉和机器人技术。

阿米尔·沙阿 是 Amazon Redshift 服务团队的高级工程师。

桑科特·哈塞 是 Amazon Redshift 服务团队的软件开发经理。

奥瑞斯蒂斯·多时 是 Amazon Redshift 服务团队的首席工程师。

时间戳记：

更多来自 AWS 大数据