写在前面

难得周末，整理了一下一周的工作，发现最近被数据倾斜问题折腾的不轻，还是静下心来总结一下，所谓雁过留痕。其实这个问题之前也碰到过，只是当时处理的数据量不大，换种方式就可以绕开这个问题，而现在TB级的数据，再也绕不开躲不过了，痛定思痛。

数据倾斜

将碰到的场景总结为以下三类

• group by 单key的数据量过大
• 表连接时小表连接大表
• 表连接字段null值/边界值处理

group by 单key的数据量过大

这种情况看具体场景，可细分为如下问题

• 日期热点问题
  举个具体的例子，例如618大促，双11购物节，必然导致当天的数据量是平常的N倍,这种场景其实有迂回的办法，对于这种可以预见的场景，在做表的时候，可以先行建立二级分区或细分分区，在根源上把数据先行打散掉
• 不可避免的单key数据量过大
  其实Hive对这种场景已有一种优化方式，需要手动开启一个配置，如下

hive.map.aggr = true
hive.groupby.skewindata=true

具体原理就不再赘述了，mapreduce的几个过程，相当于Combiner阶段，map端部分聚合

表连接时小表连接大表

这种场景经常发生在维表的连接，小表(10000条一下的纪录条数),直接塞内存吧，map join大法可解。某些特殊场景，例如排查问题时，拿到几个ID要去海量的数据里捞行为日志，也可用map jion大法解。

表连接字段null值/边界值处理

这种情况需要case by case了，总结了几点：

• 连接字段双方类型是否一致
• null值/边界值是否占了绝大部分
• 跟踪Hive物理执行计划具体分析各stage的执行情况

数据膨胀

• 好吧，这个名词其实也是最近才收纳的。现象是因为两表连接之后，数据量远超两表只和，极端情况可能是笛卡尔积。原因可能来自如下几点：
  • 手误，写错连接条件(保持清醒，保证睡眠时间，提高工作效率才是正解，洗洗睡吧)
  • 在分析一个上层指标时，连接了N张表，越垒越大，这种情况就是时候构建中间层，构建数据Cube，先行聚合，在聚合的基础上再聚合,这样既可以复用中间钻取的数据表，减少了数据量，又加速了关联查询

好吧，记个流水账，到写的时候才发现根本就没文笔，阅读量亟待增加。