COUNT(DISTINCT)直接OOM是因为执行器在内存中构建哈希表时超限，如Spark每个task用HashSet存user_id，基数超千万易爆4GB；应改用两阶段GROUP BY、Expand、打散热点或近似算法。
为什么COUNT(DISTINCT)会直接OOM而不是慢？
不是计算逻辑卡住了，是执行器在内存里建哈希表时直接炸了：java.lang.OutOfMemoryError: Java heap space。Spark 每个 task 都要为当前分区的 user_id 维护一个 HashSet；Hive/MySQL 也会把所有非 NULL 值全 load 进内存去重。一旦 distinct 基数超千万（比如设备 ID、订单号），单个 task 内存轻松突破 4GB——尤其当 spark.executor.memory 设为 12G 但 memoryOverhead 只有 2G 时，JVM native 内存早被吃光。
用两阶段 GROUP BY 替代单次 COUNT(DISTINCT)
核心思路：把“去重 + 计数”拆成 map-side 局部去重 + reduce-side 全局聚合，避免中间数据膨胀和单点哈希表。
- 单字段场景（如按
dt统计每日 UV）：SELECT dt, COUNT(*) FROM (SELECT DISTINCT dt, user_id FROM log WHERE dt = '2026-09-15') t GROUP BY dt - 多字段场景（
COUNT(DISTINCT uid), COUNT(DISTINCT aid)）不能简单套用，否则要写两个子查询再 JOIN，维护成本高；应改用 Expand 规避方案——先 UNION ALL 扩展行，加类型标记，再聚合：SELECT dt, SUM(IF(type='uid', 1, 0)) AS uv, SUM(IF(type='aid', 1, 0)) AS av
FROM (
SELECT dt, user_id AS val, 'uid' AS type FROM log GROUP BY dt, user_id
UNION ALL
SELECT dt, app_id AS val, 'aid' AS type FROM log GROUP BY dt, app_id
) t
GROUP BY dt - 注意：第一层
GROUP BY dt, user_id能天然触发 map-side combine，大幅减少 shuffle 数据量；而原写法COUNT(DISTINCT user_id)在 Spark 中会插入Expand节点，1 行变 N 行，直接导致 shuffle 数据翻倍甚至 30 倍
强制打散 + 控制分桶数防倾斜
即使走两阶段，如果 user_id 存在热点（如测试账号、机器人 ID），仍可能把大量数据路由到同一 reducer，引发单点 OOM 或长尾。
- SparkSQL 中加 hint 强制 repartition：
SELECT /*+ REPARTITION(2000) */ dt, COUNT(*) FROM (SELECT DISTINCT dt, user_id FROM log) t GROUP BY dt - Hive 可开启自动两阶段优化（需统计信息准确）：
SET hive.optimize.countdistinct=true;，但仅对单个COUNT(DISTINCT)生效；多个字段仍无效 - 更稳妥的做法是手动加扰动：
GROUP BY dt, hash(user_id) % 100先做 100 路局部聚合，再外层GROUP BY dt汇总——这样既打散热点，又避免REPARTITION额外 shuffle
什么时候该放弃精确值？
真正卡住团队进度的，往往不是“怎么算得更快”，而是“要不要算得那么准”。
- 报表类、监控类场景，±1% 误差可接受：
Spark 3.0+ 用APPROX_COUNT_DISTINCT(user_id, 0.01)（HyperLogLog），内存恒定，速度提升 5–10 倍
ClickHouse 直接用uniq(user_id)，不膨胀；PostgreSQL 配合hll扩展 - 必须精确的场景，别硬扛实时查询：
提前物化：每天凌晨跑INSERT OVERWRITE TABLE uv_daily SELECT dt, COUNT(DISTINCT user_id) FROM raw_log GROUP BY dt
查询时只读SELECT uv FROM uv_daily WHERE dt = '2026-09-15'，毫秒级响应 - 最容易被忽略的一点：NULL 值本身也参与 hash 分区。如果
user_id有大量 NULL，它们全被发往同一个 reducer——务必在 WHERE 或子查询中提前过滤：WHERE user_id IS NOT NULL
