Hive SQL 慢起来真是要命。跑一分钟还能忍，一跑十几分钟甚至更久，业务方过来问「你的数据怎么还没出来」，那种感觉，懂的都懂。
最近就遇到这么个真实案例——一个 Hive SQL 脚本，短的时候一分多钟，长的时候能跑到十几分钟，而且极其不稳定。查了一圈，最终只调了两个参数，把 447 秒干到了 39 秒，提升了整整 11 倍。
讲真，这事儿没有多高深，但背后的思路值得聊聊。
别上来就瞎调。第一步永远是看慢在哪里。
Hive 在 Tez 引擎下的执行链路大致是：编译 SQL → 生成物理计划 → 向 YARN 申请资源 → 提交 DAG → 执行 DAG。绝大多数时间都耗在最后一步「Run DAG」上，这是正常的，毕竟计算就在这一步发生。
但有个坑——有时候 YARN 资源紧张，申请 AM 就卡半天。如果不看总体执行日志，你可能会以为是 SQL 本身的问题，实则是在排队等资源。
所以先看日志，确认瓶颈到底在哪一层。
找到瓶颈：MAP1 只开了 8 个 task
我这边的 SQL 主要是一张事实表关联多张维表，union 后写入目标表。通过 explain 拿到执行计划，发现三段子查询分别对应 MAP1、Reducer8 和 Reducer16。
一看运行日志，问题一目了然：
MAP1 耗时 439 秒，但只开了8 个 task。而 Reducer8 和 Reducer16 分别只有 4 秒和 3 秒就跑完了。
所以瓶颈就是 MAP1，原因很简单——并行度不够。说白了，8 个人干的活，你让 8 个人干，你让一堆人等着，能快才怪。
为什么只有 8 个 task？
查了一下主表的元数据：89 个分区，522 个小文件，总行数 2170 万，总数据量约 4.6 GB。
关键问题是小文件太多，522 个文件平均每个才 8MB 左右。虽然 Hive 的 CombineHiveInputFormat 会自动合并小文件，但 Tez 会重新打包数据切片动态调节 task 数量。默认情况下，它觉得这些文件够小了，不需要开太多 task。
解决方案是用和来控制单个切片的大小，从而间接调节 task 数：
调完之后，MAP1 的 task 数从8 个增加到 94 个，并行度直接拉满。
但注意别太贪心。切片太小、task 太多，意味着要申请大量 YARN 容器，不光你的任务自身有开销，还会挤占集群其他人的资源。64MB-128MB 这个区间是我测试下来比较合适的，具体根据你集群的情况来调整。
另一个关键优化：开启向量化
光增加并行度还不够，每个 task 内部的执行效率也要看。
这里就要聊到 Hive 的向量化执行了。传统的行式处理是一条一条地处理数据，CPU 利用率很低；向量化则是批量处理——默认每批 1024 行——能大幅提升 CPU 利用率。
开启方式很简单，加几行配置就行：
但有个坑要注意：向量化要求表格式是 ORC 或 Parquet 这种列式存储，而且有些函数不支持原生向量化。比如instr函数就是不支持的，它会迫使整个执行链路回退到行模式，导致你开了向量化也等于没开。
解决方案：把 instr 换成 like。比如 instr(col, 'something') > 0 可以等价替换成 col like '%something%'。因为 like 有对应的原生向量化版本，差别就在这里。
效果：447秒 → 39秒
两套优化打下去，最终效果：
- 优化前：447 秒
- 优化后：39 秒
- 提速：约11 倍
讲道理，这个优化思路不复杂，但很多同学遇到 Hive SQL 慢的时候第一反应是「是不是数据量太大了？」或者「是不是要上 Spark 了？」——其实不一定。先看看并行度够不够、向量化开没开、有没有函数不支持向量化，这几个点排查下来，大多数场景不用换引擎也能解决问题。
几个可以记在小本本上的点
这次优化过程中还有一些额外的收获，一并分享了：
- 裁剪—— 别 select *，只取需要的列，减少 IO
- 分区裁剪——where 条件尽量用分区字段，不然全表扫描谁也救不了
- 尽早过滤——子查询或 CTE 里先把数据过滤掉，减少中间数据量
- 了解你的函数——有些看着无害的函数，可能让你的向量化执行白开了
当然，除了上面这些，还有数据倾斜、Reducer 并行度自动调节等方向可以深入。但以上几点是性价比最高的，花最少的时间拿最大的收益。
你手头的 Hive SQL 遇到过这种情况吗？有没有什么奇技淫巧分享一下？评论区聊聊。
热门跟贴