收集hive优化解决方案
2015-03-04 15:50
190 查看
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 和缓慢变化的维度并不总是可能实现。但是如果构建暂存表和使用一定量的连接(而且计划添加一个新表,转储旧表,并且只保留最新、更新表用于比较),则可能实现它们。
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 中),最后完成最终的聚合操作。
关于驱动表的选取,选用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
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=trueMap 端部分聚合,相当于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
相关文章推荐
- Hive优化之小文件问题及其解决方案
- 大数据Spark “蘑菇云”行动第101课:Hive性能调优之企业级数据倾斜解决方案及对Job数目的优化
- Hive优化之小文件问题及其解决方案
- hive结合hbase数据处理解决方案测评二(优化篇)
- JDK5.0垃圾收集优化之--Don't Pause
- 内存不能"read""written"的解决方案大收集
- 收集网站优化的相关资料点滴
- 优化 Java 垃圾收集器改进系统性能
- 内存不能“read” “written”的解决方案大收集
- 微软高级软件研发主管研修计划(Architect 2000)之:解决方案的设计之信息的收集和分析
- 最新的JDK5.0垃圾收集算法优化
- 自己收集的各种优化策略
- 优化 Java 垃圾收集器改进系统性能
- 选择可优化软件质量的最佳解决方案
- 收集来的出错问题的解决方案!
- JDK5.0垃圾收集优化之--Don't Pause
- 优化 Java 垃圾收集器改进系统性
- ASP.NET中常用的优化性能的方法(转贴,Icyer收集整理)
- 内存不能“read” “written”的解决方案大收集
- C#优化字符串操作(5)--url传递中文的解决方案