如何避免大表的红移偏斜？答案

【问题标题】：How to avoid skewing in redshift for Big Tables?如何避免大表的红移偏斜？
【发布时间】：2019-05-08 16:37:33
【问题描述】：

我想将表大小超过 1 TB 的表从 S3 加载到 Redshift。

我不能将 DISTSTYLE 用作 ALL，因为它是一张大桌子。

我不能将 DISTSTYLE 用作 EVEN，因为我想在导致性能问题的连接中使用此表。

我的桌子上的列是

id INTEGER, name VARCHAR(10), another_id INTEGER, workday INTEGER, workhour INTEGER, worktime_number INTEGER

我们的 redshift 集群有 20 个节点。

所以，我在工作日尝试了分发密钥，但表格严重歪斜。

有 7 个不同的工作日和 24 个不同的工作时间。

在这种情况下如何避免偏斜？

如果唯一键的行数不均匀（假设 hour1 有 100 万行，hour2 有 150 万行，hour3 有 200 万行，等等），我们如何避免表倾斜？

【问题讨论】：

如果您提供示例查询，我们可能会提供更好的建议。
我正在使用复制命令将数据从 S3 加载到 redshift。
“假设 hour1 有 100 万行，hour2 有 150 万行，hour3 有 200 万行，依此类推” - 如果如您所说，应该没有偏差。即使将 3m 放在一个节点上，将 1m+2m 放在另一个节点上，Redshift 也会进行分布，等等。必须有一个非常显着的异常值导致偏斜。你能分别按天和小时显示计数以及它们组合的前 20 个吗？

标签： amazon-redshift skew

【解决方案1】：

在撰写本文时（就在 Re-invent 2018 之后），Redshift 提供了自动分发功能，这是一个很好的开始。

以下实用程序将派上用场：

https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminScripts

如前面发布的答案中所述，如果您不喜欢 Automatic DIST 所做的事情，请尝试通过使用不同的 DIST 键复制同一个表来尝试一些组合。创建表后，从 git 存储库运行管理实用程序（最好在 Redshift DB 中的 SQL 脚本上创建一个视图）。

此外，如果您对查询使用模式有很好的了解，那么您可以使用以下查询来检查使用以下 SQL 的排序键的执行情况。

/**Queries on tables that are not utilizing SORT KEYs**/

SELECT t.database, t.table_id,t.schema, t.schema || '.' || t.table AS "table", t.size, nvl(s.num_qs,0) num_qs
FROM svv_table_info t
LEFT JOIN (
SELECT tbl, COUNT(distinct query) num_qs
FROM stl_scan s
WHERE s.userid > 1
AND s.perm_table_name NOT IN ('Internal Worktable','S3')
GROUP BY tbl) s ON s.tbl = t.table_id
WHERE t.sortkey1 IS NULL
ORDER BY 5 desc;

/**INTERLEAVED SORT KEY**/
--check skew
select tbl as tbl_id, stv_tbl_perm.name as table_name, 
col, interleaved_skew, last_reindex
from svv_interleaved_columns, stv_tbl_perm
where svv_interleaved_columns.tbl = stv_tbl_perm.id
and interleaved_skew is not null;

当然，上面的 SQL 总是有改进的余地，这取决于您可能想要查看或深入了解的特定统计信息。

希望这会有所帮助。

【讨论】：

您提到“在撰写本文时（就在 Re-invent 2018 之后），Redshift 提供了自动分发功能”-您是否有指向此的链接或者您可以进一步描述吗？

【解决方案2】：

使用DISTSTYLE EVEN 分配您的表并使用SORTKEY 或COMPOUND SORTKEY。排序键将有助于您的查询性能。先试试这个。

DISTSTYLE/DISTKEY 决定了数据的分布方式。从查询中使用的列中，建议选择导致偏差最少的列作为 DISTKEY。具有许多不同值（例如时间戳）的列将是一个不错的首选。避免使用具有很少不同值的列，例如信用卡类型或星期几。

您可能需要使用不同的 DISTKEY / SORTKEY 组合重新创建表，并根据您的典型查询尝试哪个最适合。

【讨论】：

【解决方案3】：

这是我推荐的架构

1) 使用 dist even 加载到临时表，并根据加载的 s3 数据排序的内容进行排序 - 这意味着您不必清理临时表

2) 使用查询所需的 sort / dist 设置生产表。每次从 s3 复制后，将新数据加载到生产表并清理。

3) 您可能希望有 2 个镜像生产表，并使用后期绑定视图在它们之间翻转。

执行此操作有点复杂，您可能需要一些专业帮助。您的用例可能有一些细节。

【讨论】：