amazon-web-services - 将大型数据集从 Redshift 卸载到 S3 失败并出现 I/O 错误

Question

我真正想要完成的是更改几列的数据类型。特别是一些存储为字符串的列，这些列需要是日期。我试图使用具有类似问题的 CREATE TABLE/SELECT 命令。 I/O 错误或连接断开。

我认为导出和重新导入数据可能比尝试通过或多或少地循环读取/写入如此多的数据来滥用集群更有效。

我已经尝试了配置了大超时(10 小时)的 Aginity Workbench 和 SQL Workbench J。 SQL Workbench J 今天设法运行了 2 小时 12 分钟，然后失败了，我一遍又一遍地看到同样的错误。

An I/O error occured while sending to the backend.

这是一个相当大的数据块……目前有 2,028,448,405 行(我说“目前”是因为我们每天增加大约 7000 万行)。但我希望 Redshift 能够轻松处理这个问题。

UNLOAD ( 'select weekday, day, month, year, guid,

      ...,

      colN
  from actions a
  where a.colN in (\'my\',\'penguin\',\'lolz\')'
)
TO 's3://penguin-lolz-bucket/all.csv' 
CREDENTIALS 'aws_access_key_id=$id;aws_secret_access_key=$key
ALLOWOVERWRITE;</code>

谷歌搜索错误消息让我看到了大量关于超时配置或一般连接问题的帖子。

更新 1:

因此进行了一些更改，到目前为止查询已经运行了 3 个小时没有错误:

从 TO 字段中删除文件名

仅为此进程创建了一个新存储桶

将 GZIP 和 PARALLEL 选项添加到查询

这是基于我可能会超出存储桶容量和/或每个文件的最大对象大小的想法。

更新 2:
UNLOAD 现在按预期执行。 (在我在 UPDATE 1 中所做的更改之后)

专业提示 :在执行这样的大型卸载时，请密切关注 AWS Redshift 控制台中查询的状态(当您深入查看集群详细信息时，您会在其中一个“选项卡”中找到它)。我为此使用了 SQL Workbench J。大约 5 个小时后，SQL Workbench J 显示查询仍在运行。但是 AWS Redshift 控制台显示它已经完成并且确实如此。

Answer 1

这是因为您的查询需要很长时间并且 SQL Workbench 断开连接。

您可以使用 PHP 或 shell(使用 pgsql_connect)编写小脚本并使用卸载查询。

确保在后台运行脚本。如果您从本地 PC 运行脚本，请确保它没有与网络断开连接。

其他选项是，如果您有 EC2 实例在 EC2 上运行您的脚本。