Redshift 集群：查询挂起并填满空间答案

【问题标题】：Redshift cluster: queries getting hang and filling up spaceRedshift 集群：查询挂起并填满空间
【发布时间】：2018-08-16 17:05:45
【问题描述】：

我有一个包含 3 个节点的 Redshift 集群。不时地，随着用户对其运行查询，我们以这种不愉快的情况结束，其中一些查询运行的时间比预期的要长（即使是简单的查询，超过 15 分钟），并且集群存储开始增加，如果你不这样做'不要终止长期存在的查询，它会占用 100% 的存储空间。

我想知道为什么会发生这种情况。我的经验是多种多样的，有时是单个查询执行此操作，有时是同时运行不同的并发查询。

【问题讨论】：

你在同时运行 etl 吗？ dms?
是的，我有一些在上面连续运行的 ETL 作业
当 etl 和查询作业之间存在争用时，我遇到了类似的问题
可能有很多更新直到最后才提交。执行较小的已提交批次可能会减少临时存储需求。您也可以find size of database, schema, table in redshift了解空间的去向。
您的工作肯定会相互竞争。这可以通过使用Query Queues 来最小化，该Query Queues 可以为不同类别的查询（例如ETL 与ad-hoc 查询）提供有保证的资源。但是，您的磁盘空间耗尽更令人担忧，应首先通过找出哪些活动正在消耗磁盘空间来进行调查。

【解决方案1】：

我们看到发生这种情况的一个特定场景与LISTAGG 有关。 LISTAGG 的类型是 varchar(65535)，虽然 Redshift 在存储到磁盘时优化了隐式尾随空白，但在处理过程中需要内存中的全宽。

如果您有一个返回一百万行的查询，那么您最终会得到 1,000,000 行乘以每个LISTAGG 的 65,535 个字节，即 65 GB。这会很快让您陷入与您所描述的情况类似的情况，查询会花费意外的时间或因“磁盘已满”错误而失败。

前几天我的团队讨论了更多on our team blog。

【讨论】：

【解决方案2】：

这通常发生在构造不佳的查询将过多数据溢出到磁盘时。例如，用户不小心指定了笛卡尔积（tblA 中的每一行都连接到 tblB 的每一行）。

如果这种情况经常发生，您可以实施一个 QMR 规则，在查询被中止之前限制磁盘溢出量。

【讨论】：