hive工作中的一些优化策略

1、hive抓取策略

hive.fetch.task.conversion = more/none

more不走mr,none走mr

2、explain 显示执行计划

3、设置本地运行模式

set hive.exec.mode.local.auto = true

hive.exec.mode.local.inputbytes.max 默认128M,表示加载文件的最大值,若大于该配置仍会以集群方式运行

4、并行计算

Set hive.exec.parallel = true/falses

Set hive.exec.parallel.thread.number    默认8个

5、严格模式

set hive.mapred.mode = strict/nonstrict

限制查询:

  • 对于分区表,必须添加where对于分区字段的过滤条件
  • order by语句必须包含limit输出限制
  • 限制执行笛卡尔积的查询

6、hive排序

  • order by:对于查询结果做全排序,只允许一个reduce处理(当数据量较大时,慎用。严格模式下,必须结合limit来使用)
  • sort by:对于单个reduce的数据进行排序
  • distribute by:分区排序,经常和sort by结合使用
  • cluster by:相当于sort by+distribute by
    •   cluster by不能通过asc、desc的方式指定排序顺序,可通过distribute by column sort by column asc|desc的方式

7、hive join

  • join计算时,将小表(驱动表)放在join的左边
  • Map join:在map端完成join
    •   SQL方式:在sql语句中添加map join的标记(mapjoin hint)

      •   语法:select /* MAPJOIN(b) */ a.key, a.value from a join b on a.key = b.key
    •   自动的mapjion
      • 通过以后配置启用自动的mapjion

          •   set hive.auto.convert.join = true (为true时,hive自动对左边的表统计量,如果时小表就加入内存,即对小表启动mapjion)
          •   hive.mapjion.smalltable.filesize 默认25M
          •   Hive.ignore.mapjion.hint 是否忽略maojoin hint的标
  • 尽可能使用相同的连接键(转化为一个mr)
  • 大表join大表 (不一定有用)
    • 空key过滤:有时join超时是因为某些key对应的数据太多,而相同key对应的数据都会发送到相同的reducer上,从而导致内存不够。此时我们应该仔细分析这些异常的key,很多情况下,这些key对应的数据是异常数据,我们需要在SQL语句中进行过滤。
    • 空key转换:有时虽然某个key为空对应的数据很多,但是相应的数据不是异常数据,必须要包含在join的结果中,此时我们可以表a中key为空的字段赋一个随机的值,使得数据随机均匀地分不到不同的reducer上

8、map-side聚合

  • 通过设置参数开启map端的聚合:set hive.map.aggr=true
  • hive.groupby.mapaggr.checkinterval  —map端gourp by执行聚合时处理的多少行数据(默认100000)
  • hive.map.aggr.hash.min.reduction  —进行聚合的最小比例(预先对100000条数据做聚合,若聚合之后的数据量/100000的值大于配置的0.5,则不会聚合)
  • hive.map.aggr.hash.percentmemory —map端聚合使用的内存最大值
  • hive.map.aggr.hash.force.flush.memory.threshold —map端做聚合操作时hash表的最大可用内容,大于该值出发flush
  • hive.groupby.skewindata — 是否对groupby产生的数据倾斜做优化。默认false

9、合并小文件 文件数据小,容易在文件存储端造成压力,给hdfs造成压力,影响效率

  • 设置合并属性

    • 是否合并map输出文件:hive.merge.mapfiles=true
    • 是否合并reduce输出文件:hive.merge.mapredfiles=true
    • 合并文件的大小:hive.merge.size.per.task=256*1000*1000

10、去重统计:数据量小的时候无所谓,数据量大的情况下,由于COUNT DISTINCT操作需要用一个Reduce Task来完成,这一个Reduce需要处理的数据量太大,就会导致整个Job很难完成,一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换

11、控制hive中map以及reduce的数量

  • Map数量相关的参数

    • mapred.max.split.size 每个split的最大值,即每个map处理文件的最大值
    • mapred.min.split.size.per.node 一个节点上split的最小值
    • mapred.min.split.size.per.rack 一个机架上split的最小值
  • reduce数量相关的参数
    • mapred.reduce.tasks 强制指定reduce任务的数量
    • hive.exec.reducers.bytes.per.reduce 每个reduce任务处理的数据量
    • hive.exec.reduce.max 每个任务最大的reduce书

12、hive-JVM重用

    • 适用场景

      • 小文件个数过多
      • task个数过多
    • 通过set mapred.job.reuse.jvm.num.tasks=n来设置
      •   缺陷:设置开启之后,task插槽会一直占用资源,无论是否有task运行,直到所有的task即整个job全部执行完成时,才会释放所有的task插槽的资源

原文地址:https://www.cnblogs.com/liufei-yes/p/11518338.html

时间: 2024-07-29 05:39:12

hive工作中的一些优化策略的相关文章

在工作中遇到数据优化的一点感想

一,前言 先做一下场景描述:在mongodb中,我们维护了一个A表,保留近2日的点击信息.A表数据增长很快,每天300万左右.这样即使每日凌晨清理前天数据,到了晚上仍然会有近600万数据. 有个业务需求:需要在不到1s的时间内根据uid查出A表对应的记录. 问题:刚开始时每天也就几十万数据量,没什么问题.现在一到晚上数据量渐增到600万时,经常报查找超时. 二,我能想到的优化 很简单,1,针对uid建立索引.uid是一个36位长的字符串.2,mongo的有一种查找叫 find_one .即查找到

HBase工作中的一些优化方法

1.表的设计 Pre-creating Regions(预分区) 默认情况下,在创建Hbase表的时候会自动创建一个region分区,当导入数据的时候,所有的Hbase客户端都向这一个region写数据,直到这个region足够大了才进行切分.一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入Hbase时,会按照region分区情况,在集群内做数据的负载均衡. rowkey:Hbase中rowkey用来检索表中的记录,支持一下三种方式 通过单个rowkey访问:即

Hive优化策略介绍

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

Hive优化策略

Hive的优化策略大致分为:配置优化(hive-site.xml和hive-cli执行前配置).表优化.hive数据倾斜解决方案. 回答的时候需要,需要准确的说出具体的配置参数,准确的说出具体的配置参数,这是一个深刻的教训. 配置优化 1-Fetch抓取配置 Fetch抓取是指,Hive中对某些情况的查询可以不必使用MapReduce计算.例如:SELECT * FROM employees;在这种情况下,Hive可以简单地读取employee对应的存储目录下的文件,然后输出查询结果到控制台.

[工作中的设计模式]策略模式stategy

一.模式解析 策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换.策略模式让算法独立于使用它的客户而独立变化. 策略模式的关键点为: 1.多种算法存在 2.算法继承同样的接口,执行同样的行为,为可以替代的 3.算法调用者唯一,算法调用者可以灵活改变自己需要调用的算法,从而实现计算. 二.模式代码 算法接口: /** * 算法统一接口,所有算法继承此接口 * @author zjl * @time 2016-1-24 * */ public interface IStra

.Net中的并行编程-6.常用优化策略

            本文是.Net中的并行编程第六篇,今天就介绍一些我在实际项目中的一些常用优化策略.      一.避免线程之间共享数据 避免线程之间共享数据主要是因为锁的问题,无论什么粒度的锁,最好的线程之间同步方式就是不加锁,这个地方主要措施就是找出数据之间的哪个地方需要共享数据和不需要共享数据的地方,再设计上避免多线程之间共享数据. 在以前做过的某项目,开始时设计的方案: 开始设计时所有的数据都放入到了公共队列,然后队列通知多个线程去处理数据,队列采用互斥锁保证线程同步,造成的结果就

工作中遇到的Android内存优化问题(1)

最近工作中,遇到了几个内存优化的问题,1.应用退出后,此应用进程保持了不少内存得不到释放,用工具强制gc也无法释放.2.应用进入某些页面瞬间请求分配内存过大.此两个问题对于有经验的开发者很容易猜测一个是内存泄露,一个是图片之类的资源问题.下面来写一个例子分析一下这两个问题 第一个例子是Volley加载图片的app,当此app退出时缓存释放问题 Application类 package demo.memory.com.memorydemo; import android.app.Applicati

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对于表的操作大部分都是转换为MR作业的形式,为了提高OLAP[online analysis process 在线分析处理]的效率,Hive自身给出了很多的优化策略 1. explain[解释执行计划] 通过explain命令,可以查看Hive语句的操作情况,是否为慢查询,是否走索引,一目了然 explain select sum(...) from table_name; 2. 动态分区调整 hive.exec.dynamic.partition.mode = strict // 默认