【发布时间】：2018-02-20 11:19:35
【问题描述】：
由于查询运行了 100 多个小时，在 Aginity 中，我们看到我们的集群大小从 1 TB 变为 5 TB。
通过检查 svv_table_info，我们发现每个表的大小比我们过去看到的要大得多。之后，我们检查了 AWS 控制台，我们看到大小增加是在 5 天前开始的，同时 100 小时运行查询已经开始。
杀死查询后，Redshift 大小恢复到 1 TB 后几分钟，每个表大小恢复正常。
为什么会这样？
仅作记录，运行 100 小时的查询并未涉及在查询运行时大小急剧增加的所有表。
已编辑
我现在无法真正重现该错误。但步骤如下：
在 Aginity 中，我无意中看到集群的大小为 5TB，即使集群只有 2 个 ds2.xlarge 节点（总共 4TB）
我查询 svv_table_info 以获取每个表的大小 - 它们的总和为 5TB，我发现它们中的大多数看起来都大得惊人
我看到 DWH 拥有所有最新数据，尽管“据报道”它已满至少 2 天（它的大小也超过 4TB）
我看到一个运行了 100 多个小时的查询，其中一位数据分析师留下了一个打开的笔记本。查询没有涉及到所有看起来大得不合理的表
我终止查询，片刻后一切恢复正常
所以： - 如果我们只有 2x2TB = 4TB 的可用空间，Redshift 怎么可能增长到 5TB！
【问题讨论】：
-
当同样的事情发生在我身上时，我的查询中有一个错误，它产生了一个大表的笛卡尔积，因此 n 平方行数......这会溢出到磁盘。仔细检查您的加入条件
-
您假设 svv_table_info 中的表大小反映了磁盘上的实际大小，但这并不总是正确的。总表大小可能看起来 > 4TB，但这是由于 svv_table_info 计算表大小的方式，这是近似值。不管 svv_table_info 告诉你什么，你只有 4TB 的磁盘。集群大小没有“从 1TB 变为 5TB”——集群大小始终为 4TB（在这种情况下）。您正在查看的是 已使用百分比 磁盘空间，您最初使用的大约是 25%，然后运行这个大查询时使用率上升到 100%。
标签： amazon-redshift