HiveSpark优化案例

Posted lingluo2017

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HiveSpark优化案例相关的知识,希望对你有一定的参考价值。

一.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,导致性能非常差

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

以上是关于HiveSpark优化案例的主要内容,如果未能解决你的问题,请参考以下文章

详细实例说明+典型案例实现 对动态规划法进行全面分析 | C++

对比HiveSpark和Impala,为什么选HAWQ | HAWQ实战系列

优化 C# 代码片段、ObservableCollection 和 AddRange

使用 C++ 反转句子中的每个单词需要对我的代码片段进行代码优化

如何优化C ++代码的以下片段 - 卷中的零交叉

突破性能瓶颈!ElasticSearch百亿级数据检索优化案例