3节点ra3.16xlarge Redshift集群日加载15-20亿条数据性能优化咨询

已经完成表设计最佳实践落地的前提下，溢写、作业阻塞问题基本都是资源配置、加载策略、队列隔离不到位导致的，按以下优先级调整即可：

1. 先做资源隔离，从根源解决查询阻塞 #

• 立刻把数据加载作业和常规业务查询拆分到独立WLM队列，不要使用默认自动WLM。3台ra3.16xlarge总内存约1.46TiB，给加载队列分配50%内存，设置并发度固定为1，剩余50%内存全部分给业务查询队列，同时开启业务队列的短查询加速（SQA）。配置完成后加载作业最多只会占用一半集群资源，20秒以内的短查询会走SQA预留通道，完全不会被加载作业阻塞。
• 不要给加载队列开自动扩容插槽，ra3自动扩容的计算节点没有本地NVMe缓存，临时溢写会直接走S3存储，IO延迟会高一个数量级，反而拖慢加载速度。

2. 调整加载作业策略，消除内存溢写 #

• 拆分单COPY任务的数据量，不要把单日15-20亿条数据塞到一个COPY任务里跑，单批次控制在1-2亿条，每批跑完立刻提交释放临时内存。单批次数据量过大时，分布式重分布、排序阶段生成的临时数据集会远超单节点内存阈值，必然触发落盘溢写。
• 调整COPY命令参数，加载时显式加上COMPUPDATE OFF、STATUPDATE OFF，关闭加载阶段的自动压缩编码调整、自动统计信息收集。这两个操作会占用加载作业30%以上的内存，还会生成大量临时文件触发溢写，等全量数据加载完成后，单独跑ANALYZE命令更新统计信息即可，压缩编码在表创建阶段按最佳实践固定好就行。
• 加载前临时关闭目标表关联的非必要对象：把外键约束设置为NOT VALID，暂停关联物化视图的自动刷新。加载过程中Redshift会同步维护外键校验、物化视图数据，生成的临时数据量是原始加载数据的2-4倍，是溢写的高发诱因。等加载完成后再手动刷新物化视图、校验约束，整体耗时比边加载边维护低60%以上。

3. 定向优化溢写性能，避免作业失败 #

• 强制临时溢写文件优先写入本地SSD：执行SET temp_tablespaces_raid TO on;，让排序、哈希阶段生成的临时块优先落到ra3节点自带的本地NVMe盘上，不要写到Redshift托管存储层。本地SSD的IOPS是托管存储的10倍以上，就算出现少量溢写也不会导致作业卡顿超时。
• 排查加载数据的分片倾斜：哪怕选对了分布键，也要检查源数据本身的键值分布，执行SELECT slice, COUNT(*) FROM <目标表名> GROUP BY 1;查看各分片数据量，如果单分片数据量超过平均值20%，就会先触发单节点内存溢写拖慢全作业。遇到倾斜场景可以临时把加载阶段的表分布改成DISTSTYLE RANDOM，加载完成后再执行ALTER TABLE按目标分布键重分布，整体性能比直接加载倾斜数据高4-5倍。
• 调整单查询溢写触发阈值：默认配置下查询占用分配内存的80%就会开始提前溢写，可以通过WLM配置把这个阈值调到90%，ra3.16xlarge单节点488GiB的内存余量足够支撑这个调整，能减少大量不必要的提前溢写。

验证方法 #

每调整一个参数就跑1亿条测试数据加载，查询系统表stl_wlm_query、stl_load_commits看作业的溢写块数、内存占用指标，直到单批次加载溢写块数降到个位数，再放开全量加载作业即可。

内容的提问来源于stack exchange，提问作者JohnWick