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