说实话， 只要在大数据岗位干过一年以上，应该都遇到过那种离谱的 Hive 查询：昨天 3 分钟能跑完的任务，今天突然 40 分钟还卡在 map 阶段；同一个 SQL 在测试环境飞快，到了生产连日志都刷不动；有时候 Tez 跑得稀碎，一切换回 MR 又灵了…，瞬间迷茫了，说白了就是...。

性能下降不是 SQL 老化， 而是小文件越来越多

平心而论... 后来啊一看 HDFS 文件，整整 1.8 亿个小文件。NameNode 的 CPU 直接干到 280% GC 开始上天整个任务调度都慢得要死。

我见过 NameNode 主要原因是小文件太多，重启耗时 47 分钟才恢复。

历史遗留项目

你资源够多自然快，资源不够也只能干着急。

不同引擎不是谁更牛，而是“谁更适合你的数据特征”

我以前也会随便写：

SELECT * FROM big_table WHERE event_type = 'login'

看上去很正常对吧？但这会导致：

• 没有命中分区
• full scan 全表扫描

改成：

SELECT , , FROM big_table WHERE event_type = 'login'

打个比方， 如果你要在仓库里找一把扳手，合理的方式不是“把整个仓库搬到办公室”， 我算是看透了。 而是“只把工具箱拿来”。列裁剪就是只读必要列。谓词下推就是尽可能提前过滤。

数据倾斜不常常体现在 code， 而是体现在业务数据的不均匀分布

很可能失败

适用场景

• 小并发、大表批处理

为什么 ORC 这么重要？

ORC格式和压缩方式的选择

真实有效的 SQL：

SELECT /*+ MAPJOIN */ , FROM dwduserlog aL 对吧，你看。 EFT JOIN dimusercity dimON _id = _id; .吃资源

Tez vs Spark vs MR

• MR :最稳
• Tez :稳得可怕
• Spark :可能更快

一次排查生产任务的案例

求锤得锤。 .某次排查生产任务，我看到 map 阶段卡了 7 分钟才开始处理数据。看日志一看，全是: INFO : number of splits: 13420 牛逼。 .13420 个 splits？好家伙，这是在用 Hive 群发邮件吗？从默认的 20 个 reduce → 8 个，避免小文件爆炸。到头来任务从 30 分钟回到 3 分钟。

一些魔幻的操作