在Redshift上加载到超宽表中的速度很慢

Question

我有一些超宽表（1500+列），我正在尝试将数据加载到其中。我正在使用清单文件从S3加载GZIPped文件。 表的distkey是'date'，S3中的每个文件只包含一个特定日期的信息。这些列大多是float个，有几个date和varchar s。

每个文件大约有16000行，1500列，并且大约是84 MiB gzip。即使遵循加载的最佳实践，我们也看到非常差的负载性能：100记录/秒或大约300 kB / s。

有没有针对超宽表提高负载速度的建议？我正在使用类似技术以相当合理的速度将数据加载到更窄的表中，因此我有理由相信这是表格宽度的伪像。

Answer 1

将文件分隔为DISTKEY字段并不一定能提高加载速度。 Amazon Redshift将使用多个节点并行导入文件。读取一个特定输入文件的节点不一定是用于存储数据的相同节点。因此，数据将在节点之间发送（在加载过程中是预期的）。

如果新创建了表，则加载过程将automatically使用前100,000行确定每列的最佳压缩类型。然后它将删除该数据并重新启动加载过程。要避免这种情况，请创建在每列上定义压缩的表，或者在COMPUPDATE选项设置为OFF的情况下运行COPY命令。另一方面，如果表中已有数据，则将跳过此自动过程。

加载过程可能消耗太多内存并且正在溢出到磁盘。尝试增加wlm_query_slot_count增加COPY命令可用的内存。但是，我不确定此参数是否适用于COPY命令（它用于'查询'，并且COPY命令可能不符合查询条件）。

Answer 2

添加以供将来参考： 一个有用的优化是从Gzipped JSON切换到CSV文件。这将每个文件从84 MiB减少到11 MiB，并使加载速度提高了三倍。