1. 这不是调参手册，而是生产环境里踩出来的SQL优化地图
“Hivesql优化&sparksql优化梳理”——看到这个标题，我第一反应不是打开官方文档，而是翻出自己三年前在某电商中台项目里凌晨三点改SQL的日志截图。那时候每提交一次任务，心里都像在摇骰子：运气好，12分钟跑完；运气差，OOM直接杀掉，重跑又得等队列排到两小时后。后来我们把整个数仓的SQL全过了一遍，不是为了炫技，是业务方天天追着问“昨天的GMV报表怎么还没出来”，而DBA同事已经把我们的SQL加进了“重点观察名单”。
这标题里的两个关键词，Hivesql和Sparksql，表面看只是执行引擎不同，但背后是两套完全不同的计算哲学。Hive走的是“稳字当头”的MPP老路，依赖HDFS块级读取+MapReduce分阶段调度，适合大吞吐、低频次、可容忍延迟的离线批处理；SparkSQL则是“内存优先”的DAG新派，靠RDD血统和Tungsten引擎做极致内存计算，对小文件敏感、对Shuffle怕得要命、对数据倾斜零容忍。很多人一上来就抄“set spark.sql.adaptive.enabled=true”，结果发现线上任务更慢了——因为没搞清这是给宽表Join用的，而你的场景是单表聚合。
这篇梳理不讲抽象理论，只说我在真实生产环境里验证过的、能立刻见效的路径。它适合三类人：刚从传统数仓转来的大数据工程师，需要快速建立优化直觉；每天被业务催报表的数仓开发，想少挨几次骂；还有带团队的技术负责人，需要一套可落地、可检查、可传承的优化checklist。下面所有内容，都来自某中型互联网公司近200个核心ETL任务的实操沉淀，包括具体参数值、阈值判断依据、监控指标抓取方式，以及——最关键的是，为什么这个参数在这个场景下必须这么设。
2. 整体设计思路：从“救火式调优”到“预防性建模”
2.1 为什么不能只盯着SQL本身？
我见过太多人把优化等同于“加hint”或“改写SQL”。比如把SELECT * FROM A JOIN B ON A.id = B.id改成SELECT /*+ MAPJOIN(B) */ * FROM A JOIN B ON A.id = B.id，确实快了，但问题没根除。B表今天10万行，明天涨到500万行，MAPJOIN就失效了，甚至引发Driver OOM。真正的优化起点，永远不在SQL语法层，而在数据建模层和任务调度层。
我们团队后来定了一条铁律：任何新上线的SQL，必须附带三张表——
- 数据分布表：目标表的
id字段的Cardinality（去重数）、空值率、最大最小值范围； - 分区健康表：按天分区的表，各分区文件数、平均大小、小文件占比（>10%即预警）；
- 血缘影响表：该SQL上游依赖的3个关键表，其最近7天的
input_bytes波动率（标准差/均值），超过30%需人工确认是否上游ETL异常。
这三张表不是形式主义。去年Q3，一个用户行为宽表的月度汇总任务突然变慢40%，SQL没动，参数没改。查血缘影响表发现上游的event_log表当天有2个分区input_bytes暴涨300%，进一步查发现是埋点SDK版本升级导致日志体积暴增。我们立刻通知客户端团队回滚，而不是在SQL里加一堆filter硬扛。这就是“预防性建模”的价值：把优化动作前置到数据产生环节。
2.2 HiveSQL与SparkSQL的优化策略分野
很多人以为SparkSQL是HiveSQL的“升级版”，可以无脑迁移。错。它们的瓶颈点根本不同：
| 维度 | HiveSQL典型瓶颈 | SparkSQL典型瓶颈 | 根本原因 |
|---|---|---|---|
| I/O瓶颈 | 小文件过多（<128MB），NameNode压力大 | 大量Shuffle Write，磁盘IO打满 | Hive走HDFS顺序读，Spark Shuffle默认写本地磁盘 |
| 内存瓶颈 | Mapper/Reducer堆内存不足（mapreduce.map.memory.mb） | Executor Off-Heap内存溢出（spark.memory.offHeap.size） | Hive JVM内存模型固定，Spark Tungsten用堆外内存存序列化数据 |
| 计算瓶颈 | Reduce端Sort/GroupBy耗时长（hive.groupby.skewindata=true治标不治本） | Task Skew导致个别Task卡死（spark.sql.adaptive.skewJoin.enabled需配合spark.sql.adaptive.localShuffleReader.enabled） | Hive Reduce是黑盒排序，Spark可动态切分Skew Key |
所以我们的优化路径从来不是“统一方案”，而是双轨并行：
- HiveSQL轨道：聚焦数据治理——合并小文件、调整分区粒度、预计算维度表；
- SparkSQL轨道：聚焦运行时自适应——开启AQE（Adaptive Query Execution）、精细控制Shuffle分区数、用Broadcast Join替代Shuffle Join。
提示：不要迷信“一键开启AQE”。我们在测试环境开
spark.sql.adaptive.enabled=true后，发现某些含LATERAL VIEW explode()的SQL反而变慢。查源码发现AQE的CoalesceShufflePartitions规则会错误合并shuffle分区，导致后续Stage数据倾斜。最终方案是：对含explode的SQL，关闭spark.sql.adaptive.coalescePartitions.enabled，仅保留skewJoin和localShuffleReader。
2.3 为什么必须区分“开发态优化”和“生产态优化”？
开发阶段，你用10GB测试数据跑得飞快，上线后面对1TB真实数据直接跪倒。这是因为开发态优化只解决“能不能跑”，生产态优化解决“能不能稳跑”。我们强制要求所有SQL上线前通过两项测试：
- 数据量放大测试：用
INSERT OVERWRITE TABLE test_table SELECT * FROM prod_table TABLESAMPLE(0.1)抽样10%数据，再用DISTRIBUTE BY rand()打散分区，模拟数据倾斜场景； - 并发压测：同一SQL提交5个实例，观察YARN队列资源争抢情况，重点看
AM Container内存使用率是否超80%。
去年有个订单履约状态同步任务，在开发环境跑5分钟，上线后平均耗时42分钟。压测发现：5个并发实例同时申请spark.executor.memory=8g，YARN集群总内存仅64g，导致频繁GC。解决方案不是加内存，而是把并发数从5降到2，同时开启spark.dynamicAllocation.enabled=true，让Executor按需伸缩。实测下来，总耗时降到28分钟，集群负载更平稳。
3. 核心细节解析：从参数原理到实操阈值
3.1 HiveSQL优化：绕不开的三个生死线
3.1.1 小文件合并：不是“能合就合”，而是“该合才合”
Hive小文件问题常被简单归结为“用ALTER TABLE ... CONCATENATE”。但concatenate有硬伤：它只能合并同一个分区内的小文件，且要求表是非事务表（ORC格式）。而生产环境90%的表都是ACID事务表，concatenate直接报错。
我们采用的方案是Insert Overwrite + 动态分区合并：
-- 步骤1：创建临时表，指定大文件输出 CREATE TABLE tmp_orders_merge PARTITIONED BY (dt STRING) STORED AS ORC TBLPROPERTIES ("orc.compress"="ZLIB", "orc.stripe.size"="268435456"); -- 256MB stripe -- 步骤2：用DISTRIBUTE BY强制写入大文件 INSERT OVERWRITE TABLE tmp_orders_merge PARTITION(dt) SELECT /*+ DISTRIBUTE BY dt, floor(rand()*10) */ order_id, user_id, status, amount, dt FROM orders_dwd WHERE dt >= '2024-01-01'; -- 步骤3：原子替换原表 ALTER TABLE orders_dwd DROP IF EXISTS PARTITION(dt='2024-01-01'); ALTER TABLE orders_dwd ADD PARTITION(dt='2024-01-01'); INSERT OVERWRITE TABLE orders_dwd PARTITION(dt='2024-01-01') SELECT * FROM tmp_orders_merge WHERE dt='2024-01-01';关键点在于DISTRIBUTE BY dt, floor(rand()*10)：dt保证分区路由正确，floor(rand()*10)把同一分区数据打散到10个Reducer，每个Reducer输出一个约256MB的ORC文件（由orc.stripe.size控制）。实测10TB订单表，单日分区小文件数从2300个降到12个，NameNode压力下降70%。
注意：
rand()函数在Hive中是非确定性函数，会导致MapReduce作业无法启用Map-side Combine，所以必须确保输入数据已按dt做过预排序（如上游ETL用SORT BY dt），否则Reducer输入数据乱序，DISTRIBUTE BY效果打折。
3.1.2 分区裁剪失效：别怪SQL，先查元数据
WHERE dt='2024-01-01'明明写了分区字段，却扫全表？八成是元数据没刷新。Hive的分区信息存在Metastore DB里，而HDFS上的实际目录可能已删除或重命名，导致SHOW PARTITIONS table_name显示的分区和物理路径不一致。
诊断命令：
# 查Metastore中记录的分区路径 beeline -u "jdbc:hive2://metastore:9083" -e "DESCRIBE FORMATTED orders_dwd PARTITION(dt='2024-01-01');" # 查HDFS上实际路径是否存在 hdfs dfs -ls /user/hive/warehouse/orders_dwd/dt=2024-01-01如果DESCRIBE返回的Location和hdfs dfs -ls结果不匹配，说明元数据脏了。修复方案不是MSCK REPAIR TABLE（它只补新增分区，不修路径），而是手动ALTER TABLE ... PARTITION(...) SET LOCATION：
ALTER TABLE orders_dwd PARTITION(dt='2024-01-01') SET LOCATION '/user/hive/warehouse/orders_dwd/dt=2024-01-01_new';我们把这套检查逻辑封装成Python脚本，每天凌晨自动扫描所有核心表，发现不一致立即告警。上线后，因分区裁剪失效导致的全表扫描事故归零。
3.1.3 数据倾斜：GROUP BY的终极解法不是加hive.groupby.skewindata
hive.groupby.skewindata=true的原理是：先跑一轮Map，统计Key的频次，把高频Key（如user_id='0'）单独拎出来，用独立Reduce处理，其他Key走常规Reduce。但它有两个致命缺陷：
- 无法识别复合倾斜（如
GROUP BY city, gender中，city='北京' AND gender='男'组合倾斜）； - 高频Key判定阈值固定（默认10万），无法动态适配不同量级数据。
我们用更可控的两段式聚合替代：
-- 第一段：对疑似倾斜Key打标记（用业务知识预判） WITH marked_data AS ( SELECT CASE WHEN city IN ('北京','上海','深圳') THEN concat(city, '_SKEW') ELSE city END as city_key, gender, amount FROM orders_dwd WHERE dt='2024-01-01' ), -- 第二段：分组聚合，Skew Key单独处理 agg_result AS ( SELECT city_key, gender, sum(amount) as total_amount FROM marked_data GROUP BY city_key, gender ) -- 最终合并：把Skew Key的结果和普通Key结果union SELECT CASE WHEN city_key LIKE '%_SKEW' THEN substr(city_key, 1, length(city_key)-5) ELSE city_key END as city, gender, total_amount FROM agg_result;这个方案的优势在于：业务语义可控。你知道哪些城市是流量洼地，就提前标记，而不是等运行时才发现。实测某促销活动期间，city='杭州'的订单量突增5倍，用此方案后GROUP BY耗时稳定在8分钟内，而skewindata方案波动在5~15分钟。
3.2 SparkSQL优化：AQE不是银弹，而是手术刀
3.2.1 Shuffle分区数：spark.sql.adaptive.coalescePartitions.enabled的开关逻辑
Spark默认Shuffle分区数是200（spark.sql.shuffle.partitions），但这个值对10GB和1TB数据毫无意义。AQE的coalescePartitions功能会根据Shuffle Write数据量动态合并分区，但它的触发条件很苛刻：
- 每个Shuffle Partition的Write数据量 <
spark.sql.adaptive.coalescePartitions.enabledThreshold（默认10MB）； - 合并后分区数 ≥
spark.sql.adaptive.coalescePartitions.minPartitionNum（默认1）； - 合并后分区数 ≤ 原分区数 ×
spark.sql.adaptive.coalescePartitions.initialPartitionNum（默认1.0）。
问题来了：如果一个Stage写了200个分区，每个分区写8MB，总Shuffle数据1.6GB，AQE会把它合并成16个分区（1.6GB / 10MB）。但下游Stage的map操作可能需要更高并发，16个分区导致CPU利用率不足。
我们的实践是：对IO密集型Stage开coalesce，对CPU密集型Stage关coalesce。如何判断？看Spark UI的Stage Details页：
- 如果
Shuffle Write时间占Stage总耗时 > 60%，且Input Size / Records比值 < 1MB/record，属于IO密集型，开coalesce； - 如果
Executor CPU Time占Stage总耗时 > 70%，且Input Size / Records比值 > 5MB/record，属于CPU密集型，关coalesce。
实操心得：我们曾有一个用户画像特征计算任务，上游Shuffle Write 2.1GB，AQE自动合并为21个分区。但下游
map操作要做大量UDF计算，21个分区导致4台Executor中2台CPU跑满，另2台闲置。手动设spark.sql.adaptive.coalescePartitions.enabled=false，并把spark.sql.shuffle.partitions调到128，任务耗时从38分钟降到22分钟。
3.2.2 广播Join：spark.sql.autoBroadcastJoinThreshold的精准计算
autoBroadcastJoinThreshold默认10MB，意思是右表大小≤10MB时自动转Broadcast Join。但这个“大小”是序列化后大小，不是HDFS上文件大小。ORC表压缩率可达80%，100MB的ORC文件序列化后可能只有20MB。
我们用以下SQL精确估算右表序列化大小：
-- 步骤1：查ORC文件原始大小 DESCRIBE FORMATTED dim_user LIMIT 1; -- 步骤2：查ORC压缩率（需开启ORC stats） ANALYZE TABLE dim_user COMPUTE STATISTICS FOR COLUMNS user_id, name, city; -- 步骤3：估算序列化大小（经验公式） -- 序列化大小 ≈ (ORC文件大小 × 1.2) ÷ 压缩率 -- 压缩率 = (未压缩大小 - ORC大小) / 未压缩大小 -- 未压缩大小可通过`orcfiledump --schema`获取更简单的方法：在Spark Shell里直接测：
val df = spark.read.table("dim_user") println(s"Estimated serialized size: ${df.queryExecution.optimizedPlan.stats.sizeInBytes}")如果估算值是12MB，就把spark.sql.autoBroadcastJoinThreshold设为15MB，并加/*+ BROADCAST(dim_user) */hint强制广播。避免AQE误判——它有时会因统计信息过期，把12MB表当成1MB表广播，结果Driver OOM。
3.2.3 自适应Shuffle：spark.sql.adaptive.localShuffleReader.enabled的底层逻辑
这个参数解决的是Shuffle数据本地性问题。默认Spark Shuffle数据写到Executor本地磁盘，下游Task拉取时可能跨节点网络传输。开启localShuffleReader后，AQE会尝试让下游Task优先读取同一节点的Shuffle数据，减少网络IO。
但它有个隐藏前提：Shuffle数据必须足够小，能放进Executor本地磁盘缓存。我们集群Executor本地磁盘是200GB SSD，但spark.local.dir默认只用50%空间（100GB）。如果一个Stage Shuffle Write 150GB，localShuffleReader会失效，退化为网络拉取。
诊断方法：看Spark UI的Shuffle Read指标：
- 如果
Remote Blocks Fetched>Local Blocks Fetched，说明本地性失败； - 如果
Fetch Wait Time>Shuffle Read Time的30%，说明网络等待严重。
解决方案不是关参数，而是控制Shuffle数据量：在Join前加filter，或用sample预估数据量，超阈值则改用SortMergeJoin。我们设定的阈值是：Shuffle Write > 50GB时，强制禁用localShuffleReader，并调高spark.sql.adaptive.localShuffleReader.maxDiskUsage到150GB。
4. 实操过程：一个订单宽表生成任务的全链路优化
4.1 任务背景与原始SQL
某电商平台每日需生成orders_wide宽表，关联5张维度表（用户、商品、店铺、地址、优惠券），原始SQL如下（简化版）：
INSERT OVERWRITE TABLE orders_wide PARTITION(dt='2024-01-01') SELECT o.order_id, o.user_id, u.name as user_name, u.city as user_city, o.item_id, i.item_name, i.category, o.shop_id, s.shop_name, o.amount, o.discount, o.create_time FROM orders_dwd o LEFT JOIN dim_user u ON o.user_id = u.user_id LEFT JOIN dim_item i ON o.item_id = i.item_id LEFT JOIN dim_shop s ON o.shop_id = s.shop_id WHERE o.dt = '2024-01-01';上线初期耗时：58分钟，YARN资源消耗：12个Executor，每个8G内存，全程CPU利用率<40%，磁盘IO打满。
4.2 优化步骤拆解与效果对比
4.2.1 步骤1：数据探查与瓶颈定位（耗时2小时）
用Spark UI分析Stage：
| Stage | Duration | Shuffle Write | Input Size | 主要耗时 |
|---|---|---|---|---|
| 0 (Scan orders_dwd) | 3m20s | 0 | 12.4GB | HDFS读取 |
| 1 (Join u) | 18m15s | 8.2GB | 12.4GB | Shuffle Write + SortMerge |
| 2 (Join i) | 22m40s | 15.6GB | 8.2GB | Shuffle Write + SortMerge |
| 3 (Join s) | 10m50s | 3.1GB | 15.6GB | Shuffle Write + SortMerge |
关键发现：
- Stage 1和2的Shuffle Write巨大，且
Input Size / Records比值仅0.8MB/record，属IO密集型； dim_user表HDFS大小1.2GB，但ANALYZE TABLE显示user_idCardinality仅800万，远低于订单表的2.4亿，符合Broadcast条件；dim_item表有热点商品（SKU='1000001'销量占30%），dim_shop表无明显倾斜。
4.2.2 步骤2：针对性优化实施（耗时4小时）
优化1：dim_user强制Broadcast
-- 修改SQL，加hint SELECT /*+ BROADCAST(u) */ ... FROM orders_dwd o LEFT JOIN /*+ BROADCAST(u) */ dim_user u ON o.user_id = u.user_id ...同时设spark.sql.autoBroadcastJoinThreshold=20971520（20MB），因dim_user序列化后约18MB。
优化2：dim_item预过滤+分桶
-- 创建分桶表（按item_id分100桶） CREATE TABLE dim_item_bucketed CLUSTERED BY (item_id) INTO 100 BUCKETS AS SELECT * FROM dim_item; -- Join时用bucket join SELECT ... FROM orders_dwd o JOIN dim_item_bucketed i ON o.item_id = i.item_id分桶后，Spark可跳过不匹配的桶，Shuffle数据量从15.6GB降至6.3GB。
优化3：dim_shop用Map Join（小表）dim_shop仅12万行，HDFS大小85MB，序列化后约35MB，小于20MB阈值，无需hint，AQE自动处理。
优化4：Shuffle分区数动态调整
-- 关闭coalesce（因Stage 2 CPU密集） SET spark.sql.adaptive.coalescePartitions.enabled=false; -- 手动设分区数为128（基于15.6GB Shuffle数据 / 128MB per partition ≈ 122，向上取整） SET spark.sql.shuffle.partitions=128;4.2.3 步骤3：上线验证与监控（耗时1天）
优化后任务耗时：19分钟，下降67%。资源消耗：8个Executor，每个6G内存，CPU利用率提升至65%，磁盘IO下降50%。
关键监控指标变化：
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
Shuffle Write Total | 26.9GB | 9.4GB | ↓65% |
Shuffle Read Remote | 18.2GB | 1.3GB | ↓93% |
GC Time | 4m12s | 1m08s | ↓72% |
Executor Idle Time | 32% | 8% | ↓75% |
实操心得：优化不是一蹴而就。我们第一次上线后，发现
dim_item_bucketed表的Bucket数100不够，热点SKU仍集中在几个Bucket里。于是把Bucket数调到200，并加DISTRIBUTE BY item_id, hash(item_id)二次打散，最终Shuffle数据量再降12%。记住：没有银弹，只有迭代。
5. 常见问题与排查技巧实录
5.1 HiveSQL常见问题速查表
| 问题现象 | 根本原因 | 排查命令 | 解决方案 |
|---|---|---|---|
FAILED: SemanticException [Error 10004]: Line x:x Invalid table alias or column reference 'xxx' | 列名在子查询中未显式别名，或Hive版本<3.0不支持CTE中的列引用 | EXPLAIN EXTENDED SQL看AST树 | 升级Hive到3.1+，或给子查询列加别名SELECT a.id as id FROM (...) a |
java.lang.OutOfMemoryError: Java heap spaceat Map phase | Mapper内存不足，常因mapreduce.map.memory.mb设置过小，或输入数据单行过大（如JSON字段超10MB） | yarn logs -applicationId <app_id> | grep "heap space" | 调大mapreduce.map.memory.mb至4096，同时设mapreduce.input.lineinputformat.linespermap=10000控制Mapper处理行数 |
org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: FAILED: ParseException line x:x mismatched input 'order' expecting EOF | order是Hive保留关键字，用作列名未加反引号 | SHOW CREATE TABLE table_name | 所有保留关键字列名加反引号：`order` |
5.2 SparkSQL典型故障排查路径
5.2.1 Task卡死在Shuffle Read：不是网络问题，是数据倾斜
现象：Spark UI显示某个Task的Shuffle Read耗时>30分钟，Input Size远大于其他Task（如其他Task 200MB，该Task 8GB）。
排查步骤：
- 看
Stage Details→Tasks页，找到卡死Task的Attempt ID； - 在YARN UI中定位该Task对应的Container日志；
- 搜索
Found skewed keys，如果AQE已开启，会打印倾斜Key； - 如果没开启AQE，用
SELECT key, count(*) c FROM table GROUP BY key ORDER BY c DESC LIMIT 10查Top10 Key。
解决方案：
- 对已知倾斜Key，用
SALT法：SELECT concat(key, '_', floor(rand()*10)) as salted_key, value FROM table，Join时两边都加Salt； - 对未知倾斜Key，用
skewJoin：SET spark.sql.adaptive.skewJoin.enabled=true; SET spark.sql.adaptive.skewJoin.skewBuildThreshold=1000000;（100万行阈值）。
5.2.2 Driver OOM：90%是因为广播表太大
现象：Driver日志报java.lang.OutOfMemoryError: GC overhead limit exceeded，且spark.driver.memory已设至8G。
排查方法：
// 在Spark Shell中执行 val df = spark.read.table("dim_user") println(s"Size in bytes: ${df.queryExecution.optimizedPlan.stats.sizeInBytes}") println(s"Number of rows: ${df.count()}")如果sizeInBytes> 500MB，基本就是Driver OOM元凶。
解决方案：
- 降低
spark.sql.autoBroadcastJoinThreshold，避免AQE自动广播； - 用
broadcast函数显式控制：val broadcastUser = spark.sparkContext.broadcast(df.collect())，但仅限<100MB表； - 终极方案：把大维度表转成
Map侧缓存，用lookup函数替代Join（需自定义UDF）。
5.2.3 任务启动慢：不是集群问题，是Hive Metastore连接池耗尽
现象：任务提交后，ACCEPTED状态持续2分钟以上，YARN RM日志报Connection refused。
原因：Spark Thrift Server或HiveServer2的JDBC连接池默认100，被大量并发查询占满。
检查命令：
# 查Metastore连接数 mysql -h metastore -u hive -p -e "show processlist;" \| wc -l # 查Spark Thrift Server配置 cat $SPARK_HOME/conf/hive-site.xml \| grep "datanucleus.connectionPool.maxPoolSize"解决方案：
- 调大
datanucleus.connectionPool.maxPoolSize至500； - 在Spark SQL中加
SET hive.server2.thrift.client.socket.timeout=300;防连接超时； - 最重要：业务方查询必须加
LIMIT，禁止SELECT * FROM huge_table。
5.3 我踩过的三个深坑
坑1：spark.sql.adaptive.enabled=true后，COUNT(DISTINCT)结果不准
原因：AQE的AdaptiveSparkPlanExec在CoalesceShufflePartitions时，会把多个分区的PartialDistinct结果合并，但HyperLogLog++算法的合并精度有损。
避坑：对精度要求高的COUNT(DISTINCT)，关AQE或改用approx_count_distinct（误差<1%）。
坑2：INSERT OVERWRITE分区表，新数据没覆盖旧数据
原因：Hive ACID表的INSERT OVERWRITE本质是INSERT INTO+DELETE FROM，如果DELETE失败（如权限不足），旧数据残留。
避坑：先MSCK REPAIR TABLE，再TRUNCATE TABLE ... PARTITION，最后INSERT INTO。
坑3：DISTRIBUTE BY和SORT BY混用，数据乱序
现象：DISTRIBUTE BY user_id SORT BY create_time DESC，期望每个user_id内按时间倒序，但实际是乱序。
原因：SORT BY只保证单个Reducer内有序，DISTRIBUTE BY把相同user_id分到同一Reducer，但不同Reducer的输出文件是并行写的，最终HDFS文件无序。
避坑：用CLUSTER BY user_id（等价于DISTRIBUTE BY + SORT BY），或用ORDER BY（全局排序，但性能差）。
6. 优化不是终点，而是新循环的起点
写完这篇梳理，我打开自己电脑里的sql_optimization_checklist.md，又添了两条：
- “检查
spark.sql.adaptive.localShuffleReader.maxDiskUsage是否随磁盘扩容同步调整”； - “对所有含
LATERAL VIEW explode()的SQL，加入spark.sql.adaptive.coalescePartitions.enabled=false的注释”。
优化从来不是一劳永逸的事。上周我们刚把orders_wide任务从19分钟压到14分钟，靠的是把dim_item表的ORC压缩从ZLIB换成ZSTD，压缩率提升22%，Shuffle数据再降8%。而业务方今天又提了个新需求：把用户实时地理位置加进宽表，这意味着要接入Kafka流，引入新的延迟和一致性挑战。
所以，别把“Hivesql优化&sparksql优化梳理”当成一份静态文档，它应该是一本活的笔记——每次SQL变更、每次数据量跃升、每次集群升级，都要往里填一行新的观察。我见过最优秀的数仓工程师，他们的笔记本首页写着：“没有最优SQL，只有最适合此刻数据、此刻集群、此刻业务的SQL。”
最后分享个小技巧：把所有核心SQL的EXPLAIN EXTENDED结果存成文本，每周用diff对比，哪怕只多了一行Exchange，也值得你花10分钟查清楚——因为那可能就是下一个性能拐点。
