收集hive优化解决方案

hive的优化问题
1。启动一次JOB尽可能多做事,尽量减少job的数量。能重用就重用,要设计好的模型。
2。合理设置reduce个数,reduce个数过多,会造成大量小文件问题。
3。使用hive.exec.parallel参数控制在同一个sql中的不同的job是否可以同时运行,提高作业的并发
4。注意join的使用,表小用map join,否则用普通reduce join,hive会将前面的表数据装入内存,因此可将数据少的表放在数据多的表之前,减少内存资源消耗。
5。注意小文件的问题
    在hive里有两种比较常见的处理办法
    第一是使用Combinefileinputformat,将多个小文件打包作为一个整体的inputsplit,减少map任务数
    set mapred.max.split.size=256000000;
    set mapred.min.split.size.per.node=256000000
    set  Mapred.min.split.size.per.rack=256000000
    set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
    第二是设置hive参数,将额外启动一个MR Job打包小文件
    hive.merge.mapredfiles = false 是否合并 Reduce 输出文件,默认为 False
    hive.merge.size.per.task = 256*1000*1000 合并文件的大小
    
6。注意数据倾斜问题
  在hive里比较常用的处理办法
  第一种方法
  通过hive.groupby.skewindata=true控制生成两个MR Job,第一个MR Job Map的输出结果随机分配到reduce做次预汇总,减少某些key值条数过多某些key条数过小造成的数据倾斜问题
  第二种方法
  通过hive.map.aggr = true(默认为true)
  在Map端做combiner,假如map各条数据基本上不一样, 聚合没什么意义,做combiner反而画蛇添足,
  hive里也考虑的比较周到
  通过参数 hive.groupby.mapaggr.checkinterval = 100000 (默认)
  hive.map.aggr.hash.min.reduction=0.5(默认),
  预先取100000条数据聚合,如果聚合后的条数/100000>0.5,则不再聚合

7。善用multi insert,union all
  multi insert适合基于同一个源表按照不同逻辑不同粒度处理插入不同表的场景,做到只需要扫描源表一次,job个数不变,减少源表扫描次数
  union all用好,可减少表的扫描次数,减少job的个数,通常预先按不同逻辑不同条件生成的查询union all后,再统一group by计算,不同表的union all相当于multiple inputs,同一个表的union all,相当map一次输出多条
 
8。参数设置的调优
  集群参数种类繁多,举个例子比如
  可针对特定job设置特定参数,比如jvm重用,reduce copy线程数量设置(适合map较快,输出量较大)
  如果任务数多且小,比如在一分钟之内完成,减少task数量以减少任务初始化的消耗。可以通过配置JVM重用选项减少task的消耗
 
#索引在 Hive 中有一些限制。如何克服这个问题呢?
  您可以使用 org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler 函数在 Hive 中创建索引。Hive 和缓慢变化的维度并不总是可能实现。但是如果构建暂存表和使用一定量的连接(而且计划添加一个新表,转储旧表,并且只保留最新、更新表用于比较),则可能实现它们。

数据倾斜的解决方案

1.参数调节:

hive.map.aggr=true

Map 端部分聚合,相当于Combiner

hive.groupby.skewindata=true

有数据倾斜的时候进行负载均衡,当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。

2. SQL语句调节:

如何Join

关于驱动表的选取,选用join key分布最均匀的表作为驱动表

做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。

大小表Join

使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.

大表Join大表:

把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。

count distinct大量相同特殊值

count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。

group by维度过小:

采用sum() group by的方式来替换count(distinct)完成计算。

特殊情况特殊处理:

在业务逻辑优化效果的不大情况下,有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。

摘录博文:http://www.cnblogs.com/ggjucheng/archive/2013/01/03/2842860.html

时间: 2024-08-10 05:49:11

收集hive优化解决方案的相关文章

Hive优化总结

优化时,把hive sql当做map reduce程序来读,会有意想不到的惊喜. 理解hadoop的核心能力,是hive优化的根本.这是这一年来,项目组所有成员宝贵的经验总结. 长期观察hadoop处理数据的过程,有几个显著的特征: 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.map reduce作业初始化的时间是比较长的. 3.对sum,count来说,不存在数据倾斜问题.

小菜鸟mysql优化解决方案

根据小菜鸟的个人习惯,自己的编写的一套MYSQL优化方案,感觉还是有点儿菜,望大家谅解,不足之处,请大神们互动! #mysql优化解决方案 #公共参数默认值: max_connections = 151 #同事处理多大连接数,推荐设置最大连接数是上限连接数的80%左右 sort_buffer_size = 2M #查询排序时缓冲区大小,只对order by和group by起作用,可增大此值为16M open_files_limit = 1024 #打开文件数限制,如果show global s

Hive 12、Hive优化

要点:优化时,把hive sql当做map reduce程序来读,会有意想不到的惊喜. 理解hadoop的核心能力,是hive优化的根本. 长期观察hadoop处理数据的过程,有几个显著的特征: 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.map reduce作业初始化的时间是比较长的. 3.对sum,count来说,不存在数据倾斜问题. 4.对count(distinct )

AssetBundle打包优化解决方案

第一阶段:AssetBundle出一套解决方案 1.解决现在同一个资源打2个bundle的冗余问题 2.测试验证节省资源的比率是多少 问题拆分 一.bundle重复 问  题  :相同资源拆分问题? 解决方案:1.制作场景时将相同部分分开 制作方法:将每个场景相同部分放到同一个目录,不同部分保留在场景中 打包方法:a.打成独立的bundle,不同部分放到每个场景中打成bundle b.用xml记录下每个场景中公共部分的transform,bundle名称.资源名称.父节点信息 优    点:打包

java处理大数据的一个优化解决方案

之前和大家提过我们公司现在在做一个手机应用商店的项目,之前测过平均每分钟有2000条请求,每秒就是50左右,现在肯定更多,数据量大的时候每秒有400~500条sql插入操作(记录用户行为,每个请求都会将信息写入log表),然后我们目前是还没有用hadoop之类的分布式,服务器好像内存是8G,CPU是16核的,这些差不多就是现在的情况,经常导致连接超时,之前也做过一些优化点击查看 大数据优化,今天又优化了下.之前是从配置和服务器层面,这次是代码层面. 上面我说过每条请求进来我们都会将用户信息插入到

Hive优化策略介绍

作为企业Hadoop应用的核心产品之一,Hive承载着公司95%以上的离线统计,甚至很多企业里的离线统计全由Hive完成: Hive在企业云计算平台发挥的作用和影响越来越大,如何优化提速已经显得至关重要: Hive作业的规模决定着优化层级,一个Hive作业的优化和一万个Hive作业的优化截然不同: 后续文章将从如下三个方面进行hive的优化介绍: 1)  架构方面(高效.全局.局部)----最有效的优化,好的架构能让作业性能提高很多 a)  分表:(日志表量大而且作业访问次数多,造成耗时较长:将

HIVE优化提示-如何写好HQL

一.     Hive join优化 1.     尽量将小表放在join的左边,我们这边使用的hive-0.12.0,所以是自动转化的,既把小表自动装入内存,执行map side join(性能好), 这是由参数hive.auto.convert.join=true 和hive.smalltable.filesize=25000000L)参数控制(默认是25M),如果表文件大小在25M左右,可以适当调整此参数,进行map side join,避免reduce side join. 也可以显示声

hive优化之——控制hive任务中的map数和reduce数

一.    控制hive任务中的map数: 1.    通常情况下,作业会通过input的目录产生一个或者多个map任务.主要的决定因素有: input的文件总个数,input的文件大小,集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到,该参数不能自定义修改): 2.    举例:a)    假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和1个12m的块),从而产生7个map数

hive 优化 (转)

Hive优化 Hive优化目标 在有限的资源下,执行效率更高 常见问题 数据倾斜 map数设置 reduce数设置 其他 Hive执行 HQL --> Job --> Map/Reduce 执行计划 explain [extended] hql 样例 select col,count(1) from test2 group by col; explain select col,count(1) from test2 group by col; Hive表优化 分区 静态分区 动态分区 set