关于Redshift数据仓库Dist Key与Sort Key配置合理性的确认请求

你的配置方案整体方向非常正确，完全贴合Redshift的最佳实践以及你的数据规模、查询场景，具体分析如下：

维度表配置：DIST STYLE ALL + 代理键SORT KEY #

• 维度表最大仅1M条记录，采用DIST STYLE ALL完全合理：全节点复制维度表，可避免事实表与维度表关联时的跨节点数据传输，大幅提升关联查询效率，且小数据量的全复制不会对节点存储造成压力。
• 以代理键作为SORT KEY：代理键通常是唯一标识且是关联事实表的核心字段，排序后能加速等值关联操作，同时利用Redshift的排序优化提升过滤效率。

事实表配置：DIST STYLE KEY（核心维度代理键） + Dim_Date_ID SORT KEY #

• DIST STYLE KEY绑定BI查询中频繁关联的核心维度代理键：这是Redshift推荐的“共位关联”策略，将事实表与核心维度表的关联数据放在同一节点，彻底消除跨节点关联的数据传输开销，对于10M规模的事实表，这种分布方式比默认的EVEN分布效率高得多。
• 选择Dim_Date_ID作为SORT KEY：日期字段是BI查询中最常用的过滤条件之一，排序后Redshift会生成区映射（Zone Map），查询时能快速跳过不符合日期条件的数据块，显著减少扫描的数据量，提升查询速度。

额外优化建议 #

1. 如果事实表存在多个高频过滤字段（比如除了日期还有业务区域ID），可以考虑使用复合排序键，将最常用的字段放在首位；若Dim_Date_ID是绝对主导的过滤条件，单键排序已足够。
2. 可通过Redshift的EXPLAIN命令查看典型BI查询的执行计划，确认是否存在跨节点传输操作，验证配置的实际效果。
3. ra3.xlplus节点的存储与计算分离特性，让你的配置更适配：全复制维度表不会占用节点计算资源，事实表的KEY分布也能最大化利用节点的计算能力。

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