hive中count(distinct)强制单reduce因全聚合语义要求全局去重，map端无法预合并；hive 3的优化仅适用于group by场景，纯全表统计无效；有效解法是两阶段mapreduce或改用近似算法。
COUNT(DISTINCT) 在 Hive 里慢，不是写法错，是它必须把所有非 NULL 值全拉进 Reduce 阶段去重——而 Hive 强制只用 1 个 Reduce 做这事，数据一多就卡死。
为什么 Hive 强制用 1 个 Reduce 执行 COUNT(DISTINCT)
Hive 把 COUNT(DISTINCT) 视为“全聚合（full aggregate）”，不管你怎么设 mapred.reduce.tasks，它都会忽略并硬编码为 1 个 Reduce。原因很直接：去重必须看到全部值才能确认唯一性，Map 端无法提前合并（Combiner 失效），所有中间结果都得发到同一个 Reduce 去建哈希表。
- 百亿行数据 → 全部 key-value 对 shuffle 到单个 Reduce → 网络打满、内存爆掉、
error in shuffle in fetcher#3是常态 - 哪怕你只查一个字段（如
account），只要基数高（比如千万级唯一值），哈希表就占几 GB 内存 - 如果还带
WHERE dt BETWEEN ...却没分区裁剪，就会扫全表，雪上加霜
Hive 3 的 hive.optimize.countdistinct 真的有用吗
有用，但有前提：它只在“能拆分”的场景下自动改写 SQL，比如 COUNT(DISTINCT x) GROUP BY y 会被转成子查询 + JOIN；但对纯 SELECT COUNT(DISTINCT x) FROM t 这种全表统计，它不生效。
- 开启方式：
SET hive.optimize.countdistinct=true; - 它依赖统计信息和执行计划分析，如果表没 ANALYZE，或字段无直方图，优化器可能不敢动
- 别指望它救急——它不解决单 Reduce 瓶颈，只是帮你避开某些明显低效写法
真正有效的绕过方式：两阶段 MapReduce
手动把“去重”和“计数”拆开，让去重分散到多个 Reduce，计数再汇总。本质是用两个 Job 换取可扩展性。
- 全量去重：
SELECT COUNT(*) FROM (SELECT DISTINCT account FROM table_name WHERE dt='2026-08-26') t - 按维度统计（如按
id分组）：INSERT OVERWRITE TABLE tmp_uv SELECT id, account FROM table_name GROUP BY id, account，之后SELECT id, COUNT(*) FROM tmp_uv GROUP BY id - 关键点：第一阶段
GROUP BY id, account利用了 Map 端预聚合（hash group by），大幅减少 shuffle 数据量
容易被忽略的陷阱：数据倾斜 + 多字段 COUNT(DISTINCT)
当你要同时算 COUNT(DISTINCT user_id), COUNT(DISTINCT order_no)，Hive 不会复用哈希结构，而是为每个字段单独维护一个——相当于中间数据膨胀 N 倍。
- 别写成一行：
SELECT COUNT(DISTINCT a), COUNT(DISTINCT b) - 要拆成两个独立子查询，再
JOIN，否则 shuffle 量翻倍，OOM 风险激增 - 如果
user_id本身分布极不均（比如 90% 是测试账号），即使拆开，GROUP BY阶段仍可能倾斜，得配合rand()加盐或过滤空值
最麻烦的从来不是语法怎么写，而是你有没有在跑之前确认：这个 COUNT(DISTINCT) 是真要精确值，还是可以接受近似（比如 APPROX_COUNT_DISTINCT）；以及，这张表的分区字段、数据分布、基数范围，你是否真的看过。
