distribute by 对窗口排名性能关键，因其确保数据按窗口分区键均匀分发至多 reducer 并行排序；若缺失或与 order by 前缀不一致，将导致单 reducer 处理全量数据而 oom。

为什么 DISTRIBUTE BY 对窗口排名性能关键

在 Hive 中跑 ROW_NUMBER() 或 RANK() 时，如果没加 DISTRIBUTE BY，所有数据会被 shuffle 到单个 reducer，极易 OOM 或卡死。根本原因：窗口函数默认按整个输入分区排序，而 Hive 的执行模型要求排序字段必须是 DISTRIBUTE BY 的键（或其前缀），否则无法并行分片排序。

DISTRIBUTE BY 必须和 ORDER BY 前缀一致

这是最容易出错的地方——DISTRIBUTE BY 字段必须是 ORDER BY 字段的最左前缀，否则结果错误且不报错。

• ✅ 正确：DISTRIBUTE BY user_id ORDER BY user_id, event_time
• ❌ 错误：DISTRIBUTE BY event_time ORDER BY user_id, event_time（reducer 内部排序跨用户，排名乱）
• ⚠️ 注意：DISTRIBUTE BY (user_id, dt) 可以，但 ORDER BY 必须以 (user_id, dt) 开头，比如 ORDER BY user_id, dt, event_time

如何写一个安全高效的带排名 SQL

典型场景：给每个用户的点击事件按时间排序。关键不是“怎么写”，而是“怎么避免隐性错误”。

• 显式写出 DISTRIBUTE BY，不要依赖 Hive 自动推导（Hive 3.1+ 虽支持自动，但旧版本/复杂嵌套下不可靠）
• 确保 ORDER BY 字段包含 DISTRIBUTE BY 全部字段，且顺序严格一致
• 如果要按时间全局去重排名（如 TopN 每日活跃用户），用 DISTRIBUTE BY dt + ORDER BY dt, cnt DESC，而非只 ORDER BY cnt DESC
• 示例：

  SELECT user_id, event_time,  
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time) AS rn  
  FROM logs  
  DISTRIBUTE BY user_id  
  SORT BY user_id, event_time;

  注意这里用 SORT BY（局部排序）而非 ORDER BY（全局排序），因为 DISTRIBUTE BY 已保证同 user_id 进入同一 reducer，SORT BY 更轻量

常见陷阱与兼容性提醒

Hive 版本差异会悄悄破坏你的逻辑：

• Hive 2.x 默认关闭 hive.optimize.sort.dynamic.partition，导致 DISTRIBUTE BY + 窗口函数可能退化成单 reducer；需手动设为 true
• 使用 Tez 引擎时，DISTRIBUTE BY 仍有效，但若混用 CLUSTER BY（等价于 DISTRIBUTE BY + SORT BY），窗口函数行为可能异常，建议拆开写
• 如果 PARTITION BY 和 DISTRIBUTE BY 字段不一致（如 PARTITION BY user_id, dt 但 DISTRIBUTE BY user_id），部分 reducer 会收不到完整分区数据，导致排名断续甚至重复
• 别依赖 EXPLAIN 输出里的 “Group By Operator” 行判断是否并行——要看 MapReduce/Tez 阶段的 reducer 数量，以及 key 的分布熵

真正决定窗口是否并行的，从来不是语法多漂亮，而是 DISTRIBUTE BY 键是否能让数据均匀落桶，且恰好覆盖窗口分区边界。这点在数据倾斜严重时尤为致命。