Redshift集群通过数据聚合提升查询性能的优化方案咨询

聚合表设计核心逻辑 #

• 别上来就照搬OLAP立方体做全量维度预聚合，先拉取近30天的业务查询日志做统计，筛选出占总查询量80%的高频过滤字段、group by维度、常用聚合指标，优先覆盖这些场景的聚合粒度，比如「日期+业务线+区域」「日期+用户分层」这类通用粒度，冷门的细粒度查询直接走底层宽表即可，避免为了1%的场景浪费90%的存储和计算资源。
• 做分层设计不要堆逻辑到单表：第一层先做DWD层打宽表，提前固化几个超大表的关联逻辑，避免每次用户查询都触发跨节点大表shuffle join；第二层在打宽表的基础上，按业务场景构建不同粒度的DWS聚合表，不要把所有粒度的聚合逻辑塞到同一张表里。
• 保留粒度下钻能力：高聚合粒度的表必须保留可关联低粒度表的维度键，比如按天聚合的表要带全日期字段，支持后续关联小时级表做数据补全或者细粒度查询，不要把粒度做死导致后续业务查询适配不了。

之前方案失效的补漏要点 #

• 物化视图刷新失败基本是两个共性问题：一是物化视图嵌套了多层join、用到了非确定性函数（比如current_date、random()），不支持增量刷新，全量刷新扫超大表直接打满资源超时；二是刷新时没做分区裁剪，每次重跑全量数据。后续如果还要用物化视图，只给单聚合逻辑的DWS表层配增量物化视图即可，多层join的宽表刷新自己写调度任务控制，比依赖原生物化视图的刷新逻辑可控得多。
• 调sortkey没效果大概率是配置逻辑错了：聚合表统一把最常用的时间过滤字段放在复合sortkey的首列，后面依次跟其他高频过滤维度，不要选高基数字段（比如用户ID、订单ID）做sortkey；单表数据量超过10亿行时直接开启并发排序，不要依赖默认的小表排序策略。
• 优先检查大表的distkey配置：把所有参与join的超大表的distkey设置为高频关联键，确保相同键值的数据落在同一个计算节点，从根源减少跨节点数据传输，这个优化对大表join的性能提升远高于调整sortkey。

聚合表运维与落地配套 #

• 刷新策略和业务资源做隔离：T+1的离线聚合数据全部放在凌晨业务低峰期，按分区增量重刷，不要每次全表重跑；对实时性要求高的场景，配置15分钟/1小时级的微批调度，只刷新增时间分区的数据。所有刷新、跑批任务全部投递到低优先级资源队列，不要和业务高峰的用户查询抢资源。
• 做透明路由减少业务改造成本：在聚合表上层封装和原有复杂视图同名的视图，通过查询条件判断自动路由：符合聚合表粒度、时间范围的查询直接走聚合表，细粒度、特殊维度的查询自动路由到底层宽表，业务侧不用修改任何代码就能拿到性能提升。
• 加基础校验和运维动作：每次聚合表刷新完成后，自动对比核心指标（比如行数、总金额、总用户数）和底表的差值，超过阈值直接告警；每周定期对聚合表跑VACUUM和ANALYZE更新统计信息，避免优化器因为统计信息不准选错执行计划；超过1年的冷历史数据直接迁移到S3用Redshift Spectrum外表查询，不要占用集群本地存储和计算资源。
• 业务高峰时段给核心业务队列开短查询优先策略，避免个别慢SQL占满整个集群资源导致所有查询排队。

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