Redshift：范围连接的 DIST KEY 和 SORT KEY 策略

Question

我有一个缓慢变化的维度来表示我们所有文章主数据的变化，并且非常庞大：150 亿行并且还在增长。

该表目前分布在（国家、供应商）等自然集合中。

由于表的性质，使用它的大多数查询都是范围连接，例如在变化的文章属性上简单地计算订单：

SELECT x.article_id, x.changing_article_season, COUNT(*) counting_orders
FROM article_slow_changing_dimension x
LEFT JOIN orders y ON x.article_id=y.article_id
AND y.order_timestamp BETWEEN x.from_timestamp AND y.to_timestamp

在这里选择排序键有什么有趣的策略？ 我正在考虑做 SORTKEY(from_timestamp, to_timestamp) 但我不确定。

我尝试了一些方法，但任何测试都需要很长时间才能设置，而且实际上很难凭经验进行评估。有什么想法吗？

编辑：添加一些基于 cmets 的细节 1/ 桌子被吸尘 2/ 集群非常小（4 个节点），查询运行速度非常快，但它不在生产环境中，所以基本上只有我的开发人员在运行一些查询。我想在投入生产之前进行优化 3/ 现在大约有 150 亿行，聚合一个特定的时间戳需要 1 分钟；但我想把它推到 20 秒

Answer 1

很好的问题。

一点背景知识，排序键有 2 个主要用途：1) 最大限度地减少从磁盘扫描的数据，以及 2) 使大型表之间的连接能够使用合并连接（最快连接）。 https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html

SORTKEY(from_timestamp, to_timestamp) 通常是一个很好的选择，但它不会提高示例查询的性能。如果您在 WHERE from_timestamp > '2019-01-01' AND to_timestamp < current_date 之类的谓词中使用这些字段，它会更有帮助。

这种范围连接的优化程度是有限的，因为数据库必须将其视为笛卡尔积（又名“CROSS JOIN” - 将来自a 的每一行与来自b 的每一行连接起来） )。您知道连接将匹配单行，但数据库不知道。

在全维度 DW 中，我将创建一个 article_sk 代理键。该值将解析为 SCD 中的一个值。不过，这会使 ETL 过程复杂化，因为您必须在处理过程中注入代理键。

您可以做的另一件事是使用article 列分配两个表。这允许在每个切片上并行完成连接。但是，article 可能不会是您的orders 事实表的自然分布键（通常是customer 或account）。