首页 > 其他分享 >hive优化

hive优化

时间：2024-06-13 19:21:54浏览次数：15  
标签：join reduce 模式 hive Hive 优化 id

复制粘贴到md中查看

Hive优化

1.1 hive的随机抓取策略

理论上来说，Hive中的所有sql都需要进行mapreduce，但是hive的抓取策略帮我们
省略掉了这个过程，把切片split的过程提前帮我们做了。
set hive.fetch.task.conversion=none;
(一旦进行这么设置，select字段名也是需要进行mapreduce的过程，默认是more)

Fetch抓取的模式
可以通过 set hive.fetch.task.conversion查看，有以下3种模式：

none：所有涉及hdfs的读取查询都走mapreduce任务；
mininal：在进行简单的select *，简单的过滤或涉及分区字段的过滤时走mr；
more:在mininal模式的基础上，增加了针对查询语句字段进行一些别名的计算操作。
以下HQL，mininal模式与more模式下都不会走mr任务:
SELECT
	sale_ord_id,
	store_id
FROM
	test_table
where 
	dt = '2021-01-01'
 limit 10;
 
以下HQL,mininal模式会走mr任务，more模式不会：
SELECT
	sale_ord_id,
	store_id,
	if(store_id > 20,1,0) as store_id_new
FROM
	test_table
where 
	dt = '2021-01-01'
 limit 10;

查看怎么将一个sql转化成一个MR任务的
explain sql语句
例如：
explain select count() from stu_dy1_1;
更加详细的查看，例如：
**explain extended select count() from students2;**
当你输入一个sql语句的时候，hive会将对其关键字进行截串，截完串之后，变成
都是一些TOK开头的一些东西，然后经过这样的抽象语法树，再转成具体的查询块，
最后变成逻辑查询计划

1.2 本地运行模式

大多数的 Hadoop Job 是需要 Hadoop 提供的完整的可扩展性来处理大数据集的。不过，
有时 Hive 的输入数据量是非常小的。在这种情况下，为查询触发执行任务消耗的时间可能
会比实际 job 的执行时间要多的多。对于大多数这种情况， Hive 可以通过本地模式在单台机
器上处理所有的任务。对于小数据集，执行时间可以明显被缩短。
用户可以通过设置 hive.exec.mode.local.auto 的值为 true ，来让 Hive 在适当的时候自动
启动这个优化。

本地模式运行比集群模式块很多，33秒的任务降到2秒
更改为本地模式：
hive> set hive.exec.mode.local.auto=true
注意：
hive> set hive.exec.mode.local.auto.inputbytes.max=134217728     ---> 128M
（默认值就是128）
表示加载文件的最大值，若大于该配置仍然会以集群的方式去运行。
97万行数据，50MB
当我们开发或者测试阶段，可以去使用本地模式进行运行，默认是集群模式
但是，这里有个问题，当我们去更改为本地模式的时候，在8088的页面上就看不到
任务的执行情况了。

测试：select count(*) from emp group by deptno;

1.3 并行计算

通过设置以下参数开启并行模式（默认是false）
set hive.exec.parallel=true;

注意：hive.exec.parallel.thread.number
(一次SQl计算中允许并行执行的job个数最大值，默认是8个)

举例：
select t1.n1,t2.n2 from (select count(ename) as n1 from emp) t1,(select count(dname) as n2 from dept) t2;
注意，有时候开启并行计算运行时间并没有不开启的快，那是因为，资源的问题。
需要两套资源，资源申请会浪费点时间，最多可以并行8个，默认是8个。
所以，并行的越多，不一定是越快，因为它涉及到一个资源申请的策略。

1.4 严格模式(理解为增加一些限制)

​ 1.什么是Hive的严格模式
​ hive中的一种模式,在该模式下禁止一些不好SQL的执行。

​ 2.Hive的严格模式不允许哪些SQL执行
​ 2.1 禁止分区表全表扫描
分区表往往数据量大,如果不加分区查询会带来巨大的资源消耗 。例如以下分区表
SELECT DISTINCT(planner_id) FROM fracture_ins WHERE planner_id=5;

​ 报错如下:
​ FAILED: Error in semantic analysis: No Partition Predicate Found for Alias “fracture_ins” Table "fracture_ins

​ 解决如下:
​ SELECT DISTINCT(planner_id) FROM fracture_ins WHERE planner_id=5 AND hit_date=20120101;

​ 2.2 禁止排序不加limit
​ 排序最终是要都进到一个Reduce中操作,防止reducer额外执行很长一段时间
​ SELECT * FROM fracture_ins WHERE hit_date>2012 ORDER BY planner_id;
​ 出现如下错误
​ FAILED: Error in semantic analysis: line 1:56 In strict mode,limit must be specified if ORDER BY is present planner_id
​ 解决方案就是增加一个limit关键字：
​ hive> SELECT * FROM fracture_ins WHERE hit_date>2012 ORDER BY planner_id LIMIT 100000;

​ 2.3 禁止笛卡尔积
​ 笛卡尔积是什么: A={a,b}, B={0,1,2}，则 A×B={(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}

​ SELECT * FROM fracture_act JOIN fracture_ads;
​ 解决方法
​ SELECT * FROM fracture_act JOIN fracture_ads WHERE fracture_act.planner_id = fracture_ads.planner_id;

3.Hive的严格模式怎样开启

// 查看当前严格模式的状态
set hive.mapred.mode;
// 设置为严格模式
set hive.mapred.mode=strict;
// 设置为非严格模式
set hive.mapred.mode=nonstrict;

注意，这里的严格模式和动态分区的那个严格模式半毛钱关系没有）
通过设置以下参数开启严格模式：
set hive.mapred.mode=strict;
(默认为：nonstrict非严格模式)

查询限制：
1、对于分区表，必须添加where对于分区字段的条件过滤
2、order by 语句必须包含limit输出限制
3、限制执行笛卡尔积的查询
这些限制是帮助我们提高查询效率的。

1.5 Hive排序(掌握distribute by和sort by) 回顾

order by 对于查询结果做全排序，只允许有一个reduce处理
（注意：它会把我们所有的字段或者查询结果全部放在一个reduce里进行处理
当数据量较大时候，有可能reduce执行不完，所以，我们以后把这个给弃用掉）



**   sort by 对于单个reduce进行排序 但是我们将每个reduce里面进行排序，没有考虑到
每个reduce之间的排序。所以我们引出下一个
**   distribute by 分区排序，通常结合sort by一起使用
（distribute by column sort by column asc|desc）

cluster by 相当于distribute by + sort by  (注意，虽然是两个结合，但是我们也不去用它
原因很简单，cluster by不能通过asc desc的方式指定排序方式规则)

1.6 Hive join数据倾斜(相当重要，记住这块，面试到hive数据倾斜稳过)

1、小表join小表 不管他

2、小表join大表 map-join

3、大表join大表 map-side

考虑会不会发生reduce,并且考虑reduce压力是否大（是否会出现某个reduce数据量庞大的情况）

join计算的时候，将小表（驱动表）放在join的左边
Map join：在Map端完成join
两种实现方式：
1、sql方式，在sql语句中添加Mapjoin标记（mapjoin hint）
语法糖
select /*+MAPJOIN(A)*/ * from A join B on (A.key=B.key);
>>语法：
select /*+MAPJOIN(smallTable)*/ smallTable.key bigTable.value from smallTable join bigTable on smallTable.key=bigTable.key;
2、自动开启mapjoin
通过修改以下配置启用自动的mapjoin：
set hive.auto.convert.join=true;
(注意：该参数为true的时候，Hive自动对左边的表统计量，如果
是小表，就加入到内存，即对小表使用Mapjoin)

相关配置参数
　　hive.mapjoin.smalltable.filesize;(默认25M,大表小表判断的阈值，如果表的大小小于该值则会被加载到内存中运行。)
　　hive.ignore,mapjoin.hint;(默认值：true;是否忽略mapjoin hint的标记)
　　hive.auto.convert.join.noconditionaltask;(默认值：true；将普通的join转换为mapjoin时，是否将多个mapjoin转化为一个mapjoin)
　　hive.auto.convert.join.noconditionaltask.size;(将多个mapjoin转化为一个mapjoin时，这个表的最大值)
3、尽可能使用相同的连接键，如果不同，多一个join就会多开启一个mapreduce，执行速度变得慢。
4、大表join大表（当两个都是大表的时候，只能发生reduce了，但是这里有两个优化策略）（面试的时候说，加分）
　　a: 空key过滤:
　　　　有时join超时是因为某些key对应的数据太多,而相同key对应的数据都会发送到相同的 reducer上,从而导致内存不够。
　　　　此时我们应该仔细分析这些异常的key,很多情况下,这些key对应的数据是异常数据,我们需要在SQL语句中进行过滤。
　　　　但是这个的前提条件是异常数据，但是我们一般拿到的数据都是经过ETL数据清洗过后的，一般影响不大，面试的时候可以说。
　　b: 空key转换:
　　　　有时虽然某个key为空对应的数据很多,但是相应的数据不是异常数据,必须要包含在join的结果中,
　　　　此时我们可以表a中key为空的字段赋随机的值,使得数据随机均匀地分不到不同的 reducer上。(加盐)
　　　　但是我们一般拿到的数据都是经过ETL数据清洗过后的，规则数据，一般影响不大，面试的时候可以说。
5、Map-Side聚合
通过设置以下参数开启在Map端的聚合
set hive.map.aggr=true;（一定要进行开启，虽然进行了两个mapreduce，但是当数据倾斜发生的时候，很多时候会根本跑不出结果，卡死在99%或者100%，慢总比出不来结果要好）！！！！！！！
相关配置参数
　　hive. groupby mapaggr. checkinterval;
　　map端 igroup by执行聚合时处理的多少行数据(默认:10000
　　hive.map.aggr.hash.min.reduction;比例(若聚合之后的数据100大该0.5,map端聚合使用的内存的最大值
　　hive.mapaggr.hashforce.flush.memory.threshold;map端做聚合操作是has表的最大可用内容,大于该值则会触发fush
　　hive.groupby.skewindata-是否对 GroupBy产生的数据倾斜做优化,默认为false(十分重要！！！)
6、数据倾斜，尽可能地让我们的数据散列到不同的reduce里面去,负载均衡（Hbase中热点数据）

1.7 合并小文件

1、hadoop不适合存储小文件
2、MR不适合处理小文件
3、Hive不适合处理小文件

Hive优化
合并小文件
文件数目小,容易在文件存储端造成压力,给hdfs造成压力,影响效率
设置合并属性
　　是否合并map输出文件: hive.merge.mapfiles=true
　　是否合并reduce输出文件: hive.merge.mapredfiles=true
　　合并文件的大小: hive.merge.size.per.task=256*1000*1000
去重统计
数据量小的时候无所谓,数据量大的情况下,由于 COUNT DISTINCT操作需要用一个 Reduce Task来完成,
这一个 Reduce需要处理的数据量太大,就会导致整个JOb很难完成,一般 COUNT DISTINCT使用先 GROUP BY再COUNT的方式替换

1.8 控制map和reduce的数量(一般情况下我们不去动它)

控制Hive中Map以及 Reduce的数量
Map数量相关的参数
mapred.max.split.size;一个split的最大值,即每个map处理文件的最大值
mapred.min.split.size.per.node个节点上split的最小值
mapred.min.split.size.per.rack一个机架上spit的最小值
Reduce数量相关的参数
mapred.reduce.tasks;强制指定reduce任务的数量
hive.exec.reducers.bytes.per.reducer每个reduce任务处理的数据量
hive.exec.reducers.max每个任务最大的reduce数

1.9 JVM重用

当我们的小文件个数过多，task个数过多，需要申请的资源过多的时候，我们可以先申请一部分资源，全部执行完毕后再释放，
比我们申请一个释放一个要快。
通过 set mapred.job.reuse.jvm.num.tasks=n;来设置
（n为task插槽个数）
缺点：
设置开启后，task插槽会一直占用资源，无论是否有task进行，直到所有的task,
即整个job全部执行完毕后，才会释放所有的task插槽，所以我们要合理地设置这个n
(比如，我们设置申请了10个，但是现在来了6个，剩下4个插槽会在job全部执行完毕之前一直占用资源)

mapreduce叫懒加载，当执行任务需要资源的时候再去申请资源

标签：join,reduce,模式,hive,Hive,优化,id
From： https://www.cnblogs.com/justice-pro/p/18246614

相关文章

  • 从ES的JVM配置起步思考JVM常见参数优化
    目录一、真实查看参数（一）-XX:+PrintCommandLineFlags（二）-XX:+PrintFlagsFinal二、堆空间的配置（一）默认配置（二）配置Elasticsearch堆内存时，将初始大小设置为物理内存的一半（重点理解）（三）堆外内存划分说明元空间（Metaspace）JIT编译后代码存放本地内存直接内存JNI内存（四）平常的......
  • BFS（广度优先搜索）优化技巧 — 双向遍历
    BFS优化技巧—双向遍历在之前我发过动态规划框架与动态规划的优化技巧—空间压缩，类似的，BFS框架也有相应的优化技巧双向遍历。从技巧的名字就可以看出，双向遍历指的就是从起点开始找终点的同时，也从终点开始找起点，一旦两个寻找过程出现交集，那么起点到终点的路径也就找出......
  • 多重背包 单调队列优化
    https://www.acwing.com/problem/content/6/#include<iostream>#include<memory.h>#include<deque>#include<stdio.h>usingnamespacestd;/*https://www.acwing.com/problem/content/6/有N种物品和一个容量是V的背包。第i种物品最多有si件，每件体积是vi，......
  • 文心一言Prompt优化：生成高质量的对话
    本文由ChatMoney团队出品随着人工智能技术的快速发展，对话生成系统已经成为人机交互的重要形式之一。作为百度研发的知识增强大模型，文心一言在对话生成领域展现出强大的潜力。然而，要实现高质量、高准确率的对话生成，除了模型本身的性能外，Prompt（提示词）的设计和优化同样至关重要。本......
  • redis自学（47）批处理优化
    大量数据的导入的方式    Redis提供的批处理方案   M操作比Pipeline快，因为M操作是内部操作，原子操作，而Pipeline不是。  集群下的批处理如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果redis是一个集群，那批处理命令的多个key必须......
  • MySQL从入门到高级 --- 15.优化 && 16.pymysql
    文章目录第十五章&&第十六章：15.优化15.1查询SQL执行效率15.2定位低效率执行SQL15.3explain分析执行计划-基本使用15.4explain分析执行计划-id15.5explain分析执行计划-select_type15.6explain分析执行计划-type15.7explain分析执行计划-其他指标字段15......
  • 通过元学习优化增益模型的性能：基础到高级应用总结
    在当今数据驱动的决策过程中，因果推断和增益模型扮演了至关重要的角色。因果推断帮助我们理解不同变量间的因果关系，而增益模型则专注于评估干预措施对个体的影响，从而优化策略和行动。然而，要提高这些模型的精确度和适应性，引入元学习器成为了一个创新的解决方案。元学习器通过将估计......
  • 博客构建性能优化笔记 | 提速 3 倍
    笔者的博客基于VitePress搭建的，使用其自定义主题能力完成博客主题@sugarat/theme的搭建。前段时间有群友反馈说使用主题构建后耗时增加非常明显。前后耗时大概增加了10倍，过于离谱了。断断续续的投入差不多1个月的时间完成了优化，效果还是很明显。至此写篇文章记录&......
  • OceanBase 金融项目优化案例
    领导让我帮忙支持下其他项目的SQL优化工作，呦西，是收集案例的好时机。......
  • 单目标应用：基于红嘴蓝鹊优化器RBMO的微电网优化（MATLAB代码）
    一、微电网模型介绍微电网多目标优化调度模型简介_vmgpqv-CSDN博客参考文献：[1]李兴莘,张靖,何宇,等.基于改进粒子群算法的微电网多目标优化调度[J].电力科学与工程,2021,37(3):7二、红嘴蓝鹊优化器求解微电网2.1算法简介红嘴蓝鹊优化器（Red-billedBlueMagpieOptimize......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99