将文件从s3复制到红移需要很长时间

Question

我正在使用AWS到COPY从我的S3存储桶到我的Redshift群集中的表的日志文件。每个文件大约有100MB，我没有'gziped'。我现在有600个这样的文件，并且仍在增长。我的群集有2个dc1.large计算节点和一个领导节点。

问题是，COPY手术时间过大，至少40分钟。加速它的最佳方法是什么？

1）获得更多节点ou是一个更好的节点机器？ 2）如果我gzip的文件，它会真的很重要的方面COPY手术时间增益？

3）这里有一些设计模式有帮助吗？

Answer 1

罗德里戈，

下面是正确答案：

1 - 有可能是一些优化你改变你的硬件设置，然后才能做。你必须进行测试，但确保完成所有优化之后，如果仍然需要更好的性能，我会建议使用更多的节点。

2 - Gzipped文件可能会提高性能。但我怀疑还有其他优化需要先做。见红移文档这一建议：http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-compress-data-files.html

3 - 下面是你应该看看按重要性顺序的事情：

1. 分布键 - 您的分布键跨多个片，提供不错的分布？如果你有一个“坏”的分配密钥，这将解释你所看到的问题。
2. 编码 - 确保编码是最佳的。使用ANALYZE COMPRESSION命令。
3. 排序键 - 您是否选择了适合此 表的排序键。拥有良好的排序键可以对压缩产生巨大影响，进而影响读取和写入时间。
4. 真空 - 如果您在此表中执行了多项测试，您是否在测试之间抽真空。删除或更新后，Redshift不会删除数据（更新将作为删除和插入进行处理，而不是就地更新）。
5. 多个文件 - 您应该有大量的文件。你已经这样做了，但对于试图将数据加载到Redshift的人来说，这可能是一个很好的建议。
6. 清单文件 - 使用清单文件允许Redshift并行化您的负载。

即使在双节点群集中，我预计60GB的负载也会比您看到的更快。检查这6个项目，让我们知道。

感谢

@BigDataKid