DISTRIBUTE BY与窗口函数“冲突”实为执行逻辑失效：若字段不匹配或顺序错位，DISTRIBUTE BY失效且无提示，导致窗口函数退化为单reducer全局排序而OOM；根本原因是Hive无法自动推导分发策略，必须显式声明DISTRIBUTE BY，且其字段须严格对齐PARTITION BY+ORDER BY最左前缀。
为什么DISTRIBUTE BY和窗口函数会“冲突”
这不是语法报错层面的冲突，而是执行逻辑失效：漏写、字段不匹配或顺序错位时，DISTRIBUTE BY 不起作用，但 Hive 完全不提示。窗口函数（如 ROW_NUMBER()）会退化为单 reducer 全局排序，极易 OOM 或超时。
根本原因在于 Hive 无法从 PARTITION BY user_id ORDER BY event_time 自动推导分发策略 —— 它只管逻辑分区和排序，不管物理数据怎么分到 reducer。必须靠 DISTRIBUTE BY 显式声明数据路由规则。
DISTRIBUTE BY 字段必须严格对齐 PARTITION BY + ORDER BY 最左前缀
常见错误是只写 DISTRIBUTE BY event_time，而 PARTITION BY 是 user_id。这会导致跨用户混排，rn = 1 在多个用户下重复出现。
- ✅ 正确：
DISTRIBUTE BY user_id ORDER BY user_id, event_time - ✅ 合法扩展：
DISTRIBUTE BY (user_id, dt) ORDER BY user_id, dt, event_time - ❌ 错误：
DISTRIBUTE BY event_time ORDER BY user_id, event_time（key 错位） - ⚠️ 危险：
DISTRIBUTE BY user_id ORDER BY event_time（缺少user_id在ORDER BY中，排序无意义）
用 SORT BY 替代 ORDER BY 能省资源，但不能乱换
当已用 DISTRIBUTE BY user_id 把同用户数据送入同一 reducer 后，ORDER BY 就成了强制全局强排序（等效 single reducer），而 SORT BY 只要求每个 reducer 内部有序，开销小得多。
- 推荐写法：
SELECT ..., ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time) FROM t DISTRIBUTE BY user_id SORT BY user_id, event_time -
SORT BY字段必须和DISTRIBUTE BY一致或为其超集，否则 reducer 内部排序无法支撑窗口函数所需的局部有序性 - 不要写
CLUSTER BY user_id：在窗口函数场景中行为不稳定，尤其在 Tez 引擎下可能造成 ranking 断续
Hive 版本和引擎的隐性陷阱必须手动处理
旧版 Hive（2.x）默认关闭 hive.optimize.sort.dynamic.partition，即使写了 DISTRIBUTE BY，窗口函数仍 fallback 到单 reducer。
- 必须显式开启：
SET hive.optimize.sort.dynamic.partition=true - Hive 3.1.3+ 默认开启，但仍建议检查：
SET hive.optimize.sort.dynamic.partition - 若
PARTITION BY是多列（如(user_id, dt)），但DISTRIBUTE BY只写user_id，部分 reducer 会收不到完整分区数据 —— 某天某个用户的数据被切到两个 reducer，rn就会从 1 重复开始
最危险的是它不报错也不警告，你只能靠 EXPLAIN 看执行计划里有没有多个 Reduce Output Operator，或者监控 reducer 数量是否符合预期。
