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,导致性能非常差
解决:设置核心字段参数默认值