窗口分区列须满足高基数、分布均匀、语义合理三条件；首选 event_id 等高基数均匀列，避免 user_id 等易倾斜列，验证方法包括唯一值比例＞0.1及top10占比分析。
为什么不能随便选窗口分区列
窗口函数的性能直接取决于 PARTITION BY 列的选择。选错会导致数据倾斜、内存溢出或任务卡死——比如用 user_id 分区，但其中某个 ID 占了全量 30% 数据，这个分区就会拖慢整个作业；反过来，如果用高基数且分布均匀的列（如 event_id），每个分区数据量小且均衡，Shuffle 和计算压力就小得多。
如何判断一列是否适合作为窗口分区列
核心是看三点：基数、分布均匀性、业务语义合理性。实操中建议按顺序验证：
- 用
SELECT COUNT(DISTINCT col) / COUNT(*) FROM table粗估唯一值比例，> 0.1 是较安全的下限 - 跑
SELECT col, COUNT(*) c FROM table GROUP BY col ORDER BY c DESC LIMIT 10，检查 Top 10 值的占比总和是否 - 确认该列在业务逻辑上确实构成自然分组边界，例如时间窗口内按
device_id排序累计点击数，比按session_id更合理（后者可能跨天、不连续）
常见反模式与替代方案
以下写法看着顺手，实际容易翻车：
-
PARTITION BY DATE(event_time)：日期粒度太粗，单日数据量大时必然倾斜；改用PARTITION BY DATE(event_time), HOUR(event_time)或加user_id % 100打散 -
PARTITION BY CONCAT(year, month, day)：字符串拼接不改变分布本质，仍可能集中；不如直接用原生日期类型 + 二级分区列 -
PARTITION BY rand()：破坏业务语义，窗口结果不可解释；仅限调试阶段临时打散，不可上线
真正有效的打散方式是组合列，例如 PARTITION BY user_id % 16, DATE(event_time)，既保留用户维度，又通过取模控制单分区上限。
Spark SQL执行前必须做的检查
窗口操作一旦提交，出问题很难中断重试。上线前务必确认：
- 目标表已按分区列做了
CLUSTER BY或DISTRIBUTE BY预处理（尤其在读取 Hive 表时） - 设置了合理
spark.sql.adaptive.enabled=true和spark.sql.adaptive.skewJoin.enabled=true，应对隐性倾斜 - 用
EXPLAIN FORMATTED查看物理计划，确认窗口算子出现在 Exchange 节点之后，且分区数与预期一致（比如numPartitions=200）
最常被忽略的是：窗口定义里没写 ORDER BY 却依赖排序行为，Spark 会默认按任意顺序处理，结果不可复现。只要用了 ROW_NUMBER() 或 LAG()，ORDER BY 就不是可选项。
