我在S3上有一大组数据，这些数据以几百个CSV文件的形式存在，总容量约为1.7 TB（未压缩）。我正试图将它复制到Redshift集群上的一个空表中。
集群是空的（没有其他表），并且有10个dw2大节点。如果我在表上设置了一个排序键，复制命令会占用所有可用的磁盘空间，大约25%的时间，然后中止。如果没有排序键，则复制成功完成，并且使用的可用磁盘空间永远不会超过45%。无论我是否也设置了分发密钥，这种行为都是一致的。
我真的不知道为什么会发生这种事，也不知道这是否是意料之中的事。有人见过这种行为吗？如果是的话，你对如何避开它有什么建议吗？一个想法是尝试单独导入每个文件，但我很想找到一种方法，让Redshift自己处理该部分，并在一个查询中完成所有操作。
Redshift团队对此给出了答案。群集需要至少2.5倍于传入数据大小的可用空间，才能用作排序的临时空间。您可以放大群集，复制数据，然后重新调整大小。
每个dw2.大机箱有0.16 TB的磁盘空间。当您说您有一个由10个节点组成的集群时，可用的总空间约为1.6 TB。您已经提到，您有大约1.7 TB的原始数据（未压缩）要在红移中加载。
当您使用复制命令将数据加载到红移时，红移会自动压缩数据并将其加载到表中。加载任何数据库表后，您都可以通过以下查询看到压缩编码
Select "column", type, encoding
from pg_table_def where tablename = 'my_table_name'
当表并没有排序键时加载数据。查看正在应用哪些压缩。我建议您每次为测试加载数据时都删除并创建表，这样每次都会分析压缩编码。使用复制命令加载表后，请参阅下面的链接并启动脚本以确定表大小
http://docs.aws.amazon.com/redshift/latest/dg/c_analyzing-table-design.html
因为当您为表应用排序键并加载数据时，排序键也会占用一些磁盘空间。
因为具有out排序键的表比具有排序键的表格需要更少的磁盘空间。
您需要确保对表应用了压缩。
当我们应用排序键时，它需要更多的存储空间。当您应用排序键时，您需要检查是否也按排序顺序加载数据，以便数据将以排序方式存储。这需要避免vacuum命令在加载数据后对表进行排序。