在 Skyeng，我们使用 Amazon Redshift，包括并行扩展，因此我们发现 dotgo.com 创始人 Stefan Gromoll 为 intermix.io 撰写的这篇文章很有趣。 翻译完成后，数据工程师 Daniyar Belkhodzhaev 分享了我们的一些经验。
允许通过向集群添加新节点来进行扩展。 处理峰值请求数量的需要可能会导致节点的过度配置。 并发扩展与添加新节点不同，它根据需要增加计算能力。
Amazon Redshift 并行扩展为 Redshift 集群提供了额外的容量来处理峰值请求量。 它的工作原理是将请求转移到后台新的“并行”集群。 请求根据 WLM 配置和规则进行路由。
并行扩展定价基于具有免费套餐的信用模型。 在免费积分之上，付款基于并行扩展集群处理请求的时间。
作者在其中一个内部集群上测试了并行扩展。 在这篇文章中，他将讨论测试结果并提供有关如何开始的提示。
集群要求
要使用并行扩展，您的 Amazon Redshift 集群必须满足以下要求：
- 平台： EC2-VPC；
— 节点类型： dc2.8xlarge、ds2.8xlarge、dc2.large 或 ds2.xlarge；
— 节点数量： 从 2 到 32（不支持单节点集群）。
可接受的请求类型
并行缩放并不适合所有类型的查询。 在第一个版本中，它只处理满足三个条件的读请求：
— SELECT 查询是只读的（尽管计划了更多类型）；
— 查询未引用具有 INTERLEAVED 排序风格的表；
- 该查询不使用 Amazon Redshift Spectrum 引用外部表。
要路由到并行扩展集群，请求必须排队。 此外，符合队列条件的查询 ，不会在并行规模集群上运行。
队列和 SQA 需要正确的配置 。 我们建议首先优化您的 WLM - 这将减少并行扩展的需要。 这很重要，因为并行扩展仅在一定时间内免费。 AWS 声称并行扩展将对 97% 的客户免费，这给我们带来了定价问题。
并行扩展的成本
AWS 提供了用于并行扩展的信用模型。 每个活动集群 每小时累积积分，每天最多可享受一小时的免费并行扩展积分。
仅当您的并行扩展集群使用量超过您收到的积分金额时，您才需要付费。
成本是按高于免费速率使用的并行集群的每秒按需速率计算的。 您只需在请求期间付费，每次激活并行扩展集群时至少收取一分钟费用。 每秒点播费率是根据一般定价原则计算的 ，也就是说，它取决于集群中的节点类型和节点数量。
启动并行扩展
每个 WLM 队列都会触发并行扩展。 转到 AWS Redshift 控制台并从左侧导航菜单中选择工作负载管理。 从以下下拉菜单中选择集群的 WLM 参数组。
您将在每个队列旁边看到一个名为“并发扩展模式”的新列。 默认为“禁用”。 单击“编辑”，您可以更改每个队列的设置。
布局
并行扩展的工作原理是将适当的请求转发到新的专用集群。 新集群与主集群具有相同的大小（类型和节点数量）。
用于并行扩展的默认集群数量为一 (1)，最多可以配置十 (10) 个集群。
并行扩展的集群总数可以通过 max_concurrency_scaling_clusters 参数设置。 增加此参数的值会提供额外的冗余集群。
监控
AWS Redshift 控制台中还提供了几个附加图表。 最大配置并发扩展集群图表显示 max_concurrency_scaling_clusters 随着时间的变化的值。
活动扩展集群的数量显示在用户界面的“并发扩展活动”部分中：
在“查询”选项卡中，有一列指示查询是在主集群中还是在并行扩展集群中执行：
无论特定查询是在主集群中执行还是通过并行扩展集群执行，它都会存储在 stl_query.concurrency_scaling_status 中。
值为1表示查询在并行规模集群中执行，其他值表示在主集群中执行。
示例：
并发扩展信息还存储在其他一些表和视图中，例如 SVCS_CONCURRENCY_SCALING_USAGE。 此外，还有许多目录表存储有关并行扩展的信息。
结果
作者于 18 年 30 月 00 日 GMT 大约 29.03.2019:3:20 开始对内部集群中的一个队列进行并行扩展。于 30 年 00 月 29.03.2019 日大约 XNUMX:XNUMX:XNUMX 将 max_concurrency_scaling_clusters 参数更改为 XNUMX。
为了模拟请求队列，我们将该队列的槽数从 15 个减少到 5 个。
下面是 intermix.io 仪表板图表，显示减少槽数后运行和排队的请求数。
我们看到队列中请求的等待时间有所增加，最长时间超过了5分钟。
以下是来自AWS控制台的有关这段时间发生的事情的相关信息：
Redshift 根据配置启动了三 (3) 个并行扩展集群。 尽管我们集群中的许多请求已排队，但这些集群似乎未得到充分利用。
使用情况图与扩展活动图相关：
几个小时后，作者检查了队列，看起来有 6 个请求正在并行运行。 我们还通过用户界面随机测试了两个请求。 我们还没有检查当多个并行集群同时处于活动状态时如何使用这些值。
发现
并行扩展可以减少峰值负载期间请求在队列中花费的时间。
根据基本测试的结果，加载请求的情况得到了部分改善。 然而，仅并行扩展并不能解决所有并发问题。
这是由于可以使用并行扩展的查询类型受到限制。 例如，作者有很多带有交错排序键的表，而我们的大部分工作量都在写作上。
尽管并行扩展不是设置 WLM 的通用解决方案，但使用此功能非常简单明了。
因此，作者建议将它用于 WLM 队列。 从一个并行集群开始，通过控制台监控峰值负载，以确定新集群是否得到充分利用。
随着 AWS 增加对其他查询类型和表的支持，并行扩展应该逐渐变得越来越高效。
Skyeng 数据工程师 Daniyar Belkhodzhaev 的评论
Skyeng 也立即注意到了并行扩展的可能性。
该功能非常有吸引力，特别是考虑到 AWS 估计大多数用户甚至不需要为此支付额外费用。碰巧的是，在 24 月中旬，我们收到了一系列针对 Redshift 集群的不同寻常的请求。 在此期间，我们经常使用并发扩展（Concurrency Scaling）；有时会增加一个集群，一天 XNUMX 小时不间断地工作。
这使得即使不能完全解决队列问题，至少也可以使情况可以接受。
我们的观察结果与 intermix.io 人员的印象基本一致。
我们还注意到，虽然有请求在队列中等待，但并非所有请求都会立即转发到并行集群。 显然发生这种情况是因为并行集群仍然需要时间来启动。 因此，在短期峰值负载期间，我们仍然有较小的队列，并且相应的警报有时间触发。
在摆脱了四月份的异常负载后，我们正如AWS所期望的那样，进入了偶尔使用模式——在免费规范范围内。
您可以在 AWS Cost Explorer 中跟踪并行扩展成本。 您需要选择服务 - Redshift，使用类型 - CS，例如 USW2-CS:dc2.large。您可以阅读有关俄语价格的更多信息
来源： habr.com