Spark SQL distinct优化原理与实践指南

1. 为什么需要关注Spark SQL的distinct优化

第一次在千万级数据表上执行distinct操作时，我盯着那个卡住不动的进度条整整十分钟。作为从传统数据库转战大数据平台的老DBA，这种性能落差让我意识到：在分布式环境下，看似简单的去重操作背后藏着完全不同的游戏规则。

Spark SQL的distinct操作本质上是一个特殊的聚合运算，它需要将所有数据按目标字段重新洗牌（shuffle）到相同节点进行比较。当处理GB级以上的数据时，这种全局排序去重的代价会呈指数级增长。去年我们团队就遇到过生产事故：一个本该30分钟完成的报表任务，因为开发人员随意使用了多个distinct，最终导致集群资源耗尽超时失败。

2. distinct操作的执行原理剖析

2.1 物理执行计划解析

用EXPLAIN EXTENDED观察一个简单查询：

sql复制SELECT DISTINCT department FROM employees

在Spark 3.2的执行计划中会显示：

code复制HashAggregate(keys=[department#20], functions=[])
+- Exchange hashpartitioning(department#20, 200)
   +- HashAggregate(keys=[department#20], functions=[])
      +- FileScan parquet [department#20]...

这个计划揭示了两阶段处理：

1. 先在各个executor本地做初步去重（内层HashAggregate）
2. 通过Exchange操作进行全局shuffle
3. 最后在reduce端完成全局去重

2.2 内存消耗模型

假设我们处理1亿条记录，每条记录的去重字段平均占用16字节：

• 原始数据量：100,000,000 × 16B ≈ 1.6GB
• HashSet内存开销：考虑到Java对象头开销和哈希表负载因子，实际内存占用可达3-4GB
• 如果并发200个task，峰值内存需求可能突破800GB

这就是为什么在spark-defaults.conf中需要配置：

properties复制spark.sql.shuf