Database 在红移时缓慢加载到超宽表中

我有几个超宽的表（1500多列），我正试图将数据加载到这些表中。我正在使用清单文件从S3加载gzip文件。 表的distkey是“date”，S3中的每个文件只包含一个特定日期的信息。这些列主要是

float

s，还有一些

date

s和

varchar

s

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

---

对于提高超宽表的加载速度，是否有任何建议？我正在使用类似的技术以相当合理的速度将数据加载到更窄的表中，因此我有理由相信这是表宽度的产物。

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

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

---

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

添加以供将来参考：

---

一个有帮助的优化是从Gzip JSON文件切换到CSV文件。这将每个文件从84 MiB减少到11 MiB，并将加载速度提高了三倍。

对于一个表，您有单个文件吗？没有，我有多个文件，它们是数据库中切片数的倍数。它们也被表的distkey切分，这样数据库中就没有任何广播了。为什么要使用日期的distkey？这是经常用于联接操作的列吗？或者您这样做纯粹是为了加快加载过程？我们希望此表上的查询模式仅获取一个或几个日期的信息。如果您是在有限的日期范围内进行查询，则日期应该是SORTKEY，而不是DISTKEY。如果使用DISTKEY，则只有少数节点可以参与。快速提示：通常连接的列，请使用DISTKEY。WHERE语句中使用的列使用SORTKEY。请参阅：我们已经超过了100k行的界限，并且已经计算了压缩类型。我们还使用5个插槽（此队列定义的最大插槽数）运行。我在其他地方看到CSV是加载速度最快的。但我想知道CSV与固定宽度相比如何