在数据Copy期间，Redshift的存储空间被耗尽

【以下的回答经过翻译处理】 是的，这是有可能的。 简要来说，使用DISTSTYLE ALL（比如AUTO方式的初始阶段），Redshift需要在每个节点的第一个片上（而不是所有片上）复制表的副本。如果你有2个节点，空间将是2倍，以此类推。是的，在COPY过程中，所有数据文件都需要解压缩，列需要进行编码/压缩（使用临时空间），并且经常需要排序（更多的临时空间）才能写入磁盘。假设Parquet/Snappy的压缩比率为3，这是一个额外的3倍因子，以此类推。

记住一个关键指标很有用：单个Redshift片可以轻松地每秒加载>5MB/秒/片或18 GB / 秒/片（无论节点类型如何）。数据大小是原始的！对于具有16片的大节点类型，您应该至少期望每个节点200 GB。如果您的COPY时间明显变长（比预期的长），这表明发生了一些错误（例如空间问题）。下面是一个有用的查询，可以帮助你排除“磁盘已满”的问题：

select '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,node_num,query_id,temp_blocks from pg_catalog.stl_disk_full_diag;

建议： 1.将DISTSTYLE更改为EVEN或KEY（如果可以找到一个好的DISTKEY）。从EVEN开始也可以。 2.先将一小组文件加载到目标表中。目的是获得更好的snappy压缩和性能。 3.为了加快速度，使用更大的集群（经典调整大小）。另一个更快的选项是将您的集群弹性调整为2倍大小。当Copy结束后，验证完数据，再使用弹性调整回到原来的大小。