Hive、Spark优化案例

一.Join原则

• 将条目少的表/子查询放在Join的左边。原因：在Join的reduce阶段，位于Join左边的表的内容会被加载进内存，条目少的表放在左边，可以减少发生内存溢出的几率。
• 小表关联大表：用MapJoin把小表全部加载到内存在map端Join，避免reducer处理。如：

  select /*+ MapJoin(user)*/ l.session_id,u.username 
  from user u
  join page_views l
  on u.id  = l.user_id

二.控制map数量

　　例：input目录下有一个文件a，大小780M。分成7块（6*128+12M），产生七个map

　　减少map:合并小文件（对数据源来讲）

　　增加map:控制上一个job的reducer数

三.设置合理的reducer个数

　　reducer过多：生成很多小文件，作为下一个任务的输入

　　reducer过少：执行效率低

四.注意事项

• 只支持insert/load操作，无update/del
• Hive 0.10之前版本无索引
• 不支持having
• 不支持where子句的子查询
• join只支持等值关联
• String类型没有长度限制

案例一.脚本运行太慢

　　原因：表太大，使用了count(distinct)来统计，造成了数据倾斜，大量数据在一个reduce进行运算

　　优化：使用group by 替换，将大表根据指标条件，拆分成8个表

案例二.关联顺序不同导致数据缺失

　　问题：测试报表时，发现周/月的累计用户小于同日期的7/30天数据相加的和

　　原因：关联顺序写错了

　　解决：累计用户 left 活跃用户 /新增用户（即使用数据较全的表在最左边进行左关联）或使用union all

　　说明：当某个应用当天不活跃时，在活跃表中该应用ID为空或者不存在，就无法关联累计用户所在的表。

案例三.Spark偶尔遇到Full GC，任务会执行很久

　　原因：默认Full GC 30min一次

　　解决：调整参数 spark.cleaner.periodGC.interval = 270min

案例四.Spark-submit 部分参数没设置，导致spark执行过慢

　　原因：核心字段内容为null，导致性能非常差

　　解决：设置核心字段参数默认值