在Spark SQL中怎样使用ROW_NUMBER解决数据倾斜-SQL-PHP中文网

row_number() 直接用于高基维长尾key会加剧数据倾斜，必须通过加盐两阶段编号：先打散热点key再局部排序，最后归并取代表；同时需过滤null/空字符串并避免count(distinct)误用。

在spark sql中怎样使用row_number解决数据倾斜

ROW_NUMBER() 本身会加剧数据倾斜

直接用 ROW_NUMBER() OVER (PARTITION BY user_id) 处理高基维且长尾分布的 key（比如少数用户占点击量 90%），会让所有同 user_id 的行被拉到同一个 task，完全不 shuffle，等于把压力全堆给一个 executor。这不是“解决”倾斜，是主动制造单点瓶颈。Spark 不会对窗口函数做预聚合或分片，它只保证分区内部有序，所以一旦 PARTITION BY 字段存在热点，ROW_NUMBER() 就会卡死。

必须配合加盐（salting）做两阶段编号

核心思路是：先打散热点 key，再局部编号，最后归并取代表。不能跳过“拆”这一步。

第一阶段：对原始 key 加随机后缀，比如 CONCAT(user_id, '_', CAST(FLOOR(RAND() * 50) AS STRING))，把一个大 user_id 拆成最多 50 个子组
第二阶段：按新字段分组聚合基础指标（如最早时间、事件类型），再用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY salted_group) 给每个用户下的子组排序
第三阶段：过滤出每用户下 ROW_NUMBER = 1 的记录，作为该用户的代表样本或聚合入口

盐值数量选 10–50 足够，太多会导致小 key 的 group by 开销反超；太少则无法压平长尾。注意 RAND() 在 Spark SQL 中每次调用返回不同值，必须在子查询里固化一次，否则外层引用会不一致。

COUNT(DISTINCT) 场景下别硬套 ROW_NUMBER()

想靠 ROW_NUMBER() 实现“每个用户去重后的第 N 条记录”？这是典型误用。因为 ROW_NUMBER() 作用在原始行上，不去重，结果不可控。真实需求往往是：每个用户首次出现的某个设备 ID 或 去重后按时间排序的第三种行为。

若需精确去重后编号，先用 COLLECT_SET(device_id) OVER (PARTITION BY user_id) 收集集合，再用 SIZE() 或 element_at() 取值——但必须确保 device_id 是有限枚举，否则集合膨胀 OOM
若可接受近似，改用 APPROX_COUNT_DISTINCT(device_id) OVER (PARTITION BY user_id)，支持窗口且误差可控
绝对不要写 COUNT(DISTINCT device_id) OVER (PARTITION BY user_id)，Spark SQL 会报错或退化为全广播

容易忽略的 null 和空字符串陷阱

PARTITION BY 字段含大量 NULL 或空字符串时，它们会被归为同一分区，极易形成隐式热点。比如日志中 user_id IS NULL 的记录有 200 万条，ROW_NUMBER() OVER (PARTITION BY user_id) 会把这 200 万全塞进一个 task。