在Redshift加载期间增加磁盘使用量

Question

上下文

• 我目前正在使用单个节点上相对较小的数据集dw2.large Redshift群集
• 当前数据集为~9 gb（压缩）/ 90m行
• 数据大约每小时加载到Redshift群集
• 一次只能运行一个负载
• 传入数据的大小各不相同，但可以合理地假设它在此示例中大致一致
• {/ 1}}查询每天运行一次

问题

我在期间看到磁盘使用 Redshift负载增长的速度超出了我的预期。如果查看下面的第一个图表（按分钟显示磁盘使用情况），您可以看到一个磁盘使用频段。底边是数据集的“实际”大小，上边缘是加载期间的峰值数据使用。第二个图表按小时显示磁盘使用情况 - 相同的数据集，但是负载的峰值被平滑掉。

峰值和基数以相同的速度增长。换句话说，加载期间的峰值磁盘使用量似乎主要是总数据大小的函数，而不是传入的数据大小。

载荷的执行大致类似于this merge strategy。具体来说，它使用以下步骤：

1. 开始交易
2. 使用与真实表相同的模式创建临时表
3. 运行VACUUM查询以从Redshift导入数据（使用COPY，JSON和GZIP选项）
4. 从真实表中已复制的临时表中删除数据
5. 删除临时表中重复的数据
6. 使用MANIFEST将数据加载到真实表格中（通过使用显式列列表，这与Redshift文档略有不同，因为表格使用INSERT INTO字段）
7. 删除临时表
8. 结束交易

问题

• 预计峰值磁盘使用量是否会与总数据大小成比例增长？如果是这样，这是令人担忧的，因为群集磁盘中越来越大的部分似乎会被“浪费”。

• 是否有任何策略以不遵循此模式的方式加载数据？我已经尝试过不频繁地加载数据（过去常常每10分钟发生一次），你可以在第一个图表的后面部分看到峰值之间有更多的空白。这似乎没有任何影响。

Answer 1

使用复制命令时，Redshift需要额外的空间来执行排序。这导致临时的空间使用高峰。对于RedShift而言，9gb是没有意义的，它目标是使用太字节数据。当您处理严重数据量时，图片将会有所不同：您仍会看到峰值，但不会看到总数据的两倍。