MPP系统中ORGANIZE BY/DISTRIBUTE BY对CREATE TABLE性能影响及分布键选择

DISTRIBUTE BY（部分系统叫HASH DISTRIBUTION）和ORGANIZE BY（部分系统叫CLUSTER BY）是Netezza、Teradata、Synapse这类MPP系统建表时的核心配置，对CREATE TABLE语句的性能影响主要体现在以下两个维度：

DISTRIBUTE BY 的影响 #

• 如果是CREATE TABLE AS SELECT（CTAS）建表场景，指定分布键后，数据库需要对源数据的分布键字段做哈希计算，再把每行数据路由到对应的计算节点存储，这部分哈希运算和数据路由会增加建表阶段的CPU和网络开销，属于一次性前置成本。
• 若分布键选择不当导致数据倾斜，建表写入时会出现部分节点负载远高于其他节点的情况，直接拉长整体建表耗时，极端情况下甚至会触发单节点存储容量不足的报错。
• 如果不指定分布键，绝大多数MPP系统会走默认分布规则（比如Azure Synapse默认用轮询分布、Teradata默认用主索引分布），建表时不需要额外做哈希分片计算，建表速度更快，但会大幅拖累后续的查询性能。

ORGANIZE BY 的影响 #

• ORGANIZE BY 定义的是单节点内部的数据排序存储规则，建表写入时需要对单节点内的全量数据按指定字段排序，会额外消耗单节点的CPU和内存资源，大表建表时这部分开销会非常明显。
• 排序后的数据在后续范围查询、分组聚合操作时可以大幅减少扫描的数据量，属于典型的在建表阶段投入成本，换取后续查询性能收益的配置。

合理的分布键可以让MPP系统的并行计算能力最大化发挥，选取时可以参考以下规则：

• 优先选高基数字段：确保哈希分片后数据能均匀分布到所有计算节点，避免数据倾斜，比如用户ID、订单ID这类唯一值占比高的字段都是优选，不要选性别、业务状态这类只有少量枚举值的低基数字段，否则会出现少数节点存储绝大多数数据的情况。
• 优先选高频关联字段：如果两张表用同一个字段作为分布键，关联运算时不需要跨节点拉取数据，直接在本地节点就能完成Join，能大幅降低关联的网络开销，避免大规模数据Shuffle。
• 尽量不选高频更新字段：分布键字段一旦更新，数据对应的哈希值就会发生变化，需要把整行数据迁移到对应的目标节点，会产生额外的IO和网络开销，严重时还会引发事务锁冲突。
• 小尺寸维度表可以直接用全量复制分布：如果表的数据量很小（比如维度表数据量小于100万行），可以直接设置为全节点复制，每个计算节点都存储一份全量数据，后续和任何大表关联都不需要跨节点拉取数据，查询性能提升非常明显。

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