当前位置:首页 » 编程语言 » sql优化hive
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql优化hive

发布时间: 2023-07-18 23:42:42

1. hive sql 优化的常用手段有哪些

1、join连接时的优化:当三个或多个以上的表进行join操作时,如果每个on使用相同的字段连接时只会产生一个maprece。
2、join连接时的优化:当多个表进行查询时,从左到右表的大小顺序应该是从小到大。原因:hive在对每行记录操作时会把其他表先缓存起来,直到扫描最后的表进行计算
3、在where字句中增加分区过滤器。
4、当可以使用left semi join 语法时不要使用inner join,前者效率更高。原因:对于左表中指定的一条记录,一旦在右表中找到立即停止扫描。

2. 数据分析课程笔记 - 19 - HiveSQL 常用优化技巧

大家好呀,这节课学习 HiveSQL 的常用优化技巧。由于 Hive 主要用来处理非常大的数据,运行过程由于通常要经过 MapRece 的过程,因此不像 MySQL 一样很快出结果。而使用不同方法写出来的 HiveSQL 语句执行效率也是不一样的,因此为了减少等待的时间,提高服务器的运行效率,我们需要在 HiveSQL 的语句上进行一些优化。

本节课的主要内容

引言
1、技巧一:列裁剪和分区裁剪
(1)列裁剪
(2)分区裁剪
2、技巧二:排序技巧——sort by代替order by
3、技巧三:去重技巧——用group by来替换distinct
4、技巧四:聚合技巧——grouping sets、cube、rollup
(1)grouping sets
(2)cube
(3)rollup
5、技巧五:换个思路解题
6、技巧六:union all时可以开启并发执行
7、技巧七:表连接优化
8、技巧八:遵循严格模式

Hive 作为大数据领域常用的数据仓库组件,在平时设计和查询时要特别注意效率。影响Hive效率的几乎从不是数据量过大,而是数据倾斜、数据冗余、job 或 I/O 过多、MapRece 分配不合理等等。对 Hive 的调优既包含对HiveSQL 语句本身的优化,也包含 Hive 配置项和 MR 方面的调整。

列裁剪就是在查询时只读取需要的列。当列很多或者数据量很大时,如果select 所有的列或者不指定分区,导致的全表扫描和全分区扫描效率都很低。Hive中与列裁剪优化相关的配置项是 hive.optimize.cp ,默认是 true 。

分区裁剪就是在查询时只读需要的分区。Hive中与分区裁剪优化相关的则是 hive.optimize.pruner ,默认是 true 。

HiveSQL中的 order by 与其他 SQL 语言中的功能一样,就是将结果按某个字段全局排序,这会导致所有map端数据都进入一个 rece 中,在数据量大时可能会长时间计算不完。

如果使用 sort by ,那么就会视情况启动多个 recer 进行排序,并且保证每个 recer 内局部有序。为了控制 map 端数据分配到 rece 的 key,往往还要配合 distribute by 一同使用。如果不加 distribute by 的话,map 端数据就会随机分配给 recer。

这里需要解释一下, distribute by 和 sort by 结合使用是如何相较于 order by 提升运行效率的。

假如我们要对一张很大的用户信息表按照年龄进行分组,优化前的写法是直接 order by age 。使用 distribute by 和 sort by 结合进行优化的时候, sort by 后面还是 age 这个排序字段, distribute by 后面选择一个没有重复值的均匀字段,比如 user_id 。

这样做的原因是,通常用户的年龄分布是不均匀的,比如20岁以下和50岁以上的人非常少,中间几个年龄段的人又非常多,在 Map 阶段就会造成有些任务很大,有些任务很小。那通过 distribute by 一个均匀字段,就可以让系统均匀地进行“分桶”,对每个桶进行排序,最后再组合,这样就能从整体上提升 MapRece 的效率。

取出 user_trade 表中全部支付用户:

原有写法的执行时长:

优化写法的执行时长:

考虑对之前的案例进行优化:

注意: 在极大的数据量(且很多重复值)时,可以先 group by 去重,再 count() 计数,效率高于直接 count(distinct **) 。

如果我们想知道用户的性别分布、城市分布、等级分布,你会怎么写?

通常写法:

缺点 :要分别写三次SQL,需要执行三次,重复工作,且费时。

那该怎么优化呢?

注意 :这个聚合结果相当于纵向地堆在一起了(Union all),分类字段用不同列来进行区分,也就是每一行数据都包含 4 列,前三列是分类字段,最后一列是聚合计算的结果。

GROUPING SETS() :在 group by 查询中,根据不同的维度组合进行聚合,等价于将不同维度的 group by 结果集进行 union all。聚合规则在括号中进行指定。

如果我们想知道用户的性别分布以及每个性别的城市分布,你会怎么写?

那该怎么优化呢?

注意: 第二列为NULL的,就是性别的用户分布,其余有城市的均为每个性别的城市分布。

cube:根据 group by 维度的所有组合进行聚合

注意 :跑完数据后,整理很关键!!!

rollup:以最左侧的维度为主,进行层级聚合,是cube的子集。

如果我想同时计算出,每个月的支付金额,以及每年的总支付金额,该怎么办?

那应该如何优化呢?

条条大路通罗马,写SQL亦是如此,能达到同样效果的SQL有很多种,要学会思路转换,灵活应用。

来看一个我们之前做过的案例:

有没有别的写法呢?

Hive 中互相没有依赖关系的 job 间是可以并行执行的,最典型的就是
多个子查询union all。在集群资源相对充足的情况下,可以开启并
行执行。参数设置: set hive.exec.parallel=true;

时间对比:

所谓严格模式,就是强制不允许用户执行3种有风险的 HiveSQL 语句,一旦执行会直接报错。

要开启严格模式,需要将参数 hive.mapred.mode 设为 strict 。

好啦,这节课的内容就是这些。以上优化技巧需要大家在平时的练习和使用中有意识地去注意自己的语句,不断改进,就能掌握最优的写法。

3. hive优化方法

1、列裁剪和分区裁剪

2、谓词下推

3、sort by 替换order by 

4、group by 代替distinct

5、group by 配置调整

map 端预聚合:set hive.map.aggr=true ; set hive.groupby.mapaggr.checkinterval=100000

倾斜均衡配置项:set hive.groupby.skewindate=true

6、join优化

6.1 大小表,小表前置

6.2 多表Join时key相同

6.3 利用mapjoin特性

6.4 分桶表 mapjoin

6.5 倾斜均衡配置项:

设置hive.optimize.skewjoin=true,开启后,在join过程中hive会将计数超过阈值hive.skewjoin.key(默认100000)的倾斜key对应的行临时写进文件中,然后再启动另一个job做map join生成结果。通过hive.skewjoin.mapjoin.map.task参数还可以控制第二个job的mapper数量,默认10000.

6.7 优化sql处理join数据倾斜

6.7.1、空值或无意义的值:若不需要空值数据,就提前写到where语句过滤掉,如果需要保留的话,将空值key用随机方式打散。

6.7.2、单独处理倾斜key

6.7.3、不同数据类型,join的关联字段类型不一样,导致耗时长,所以需要注意做类型转换(join关联字段,一个是int,一个是string,,计算key的hash值时默认时int类型做的,这样导致所有真正的string类型的key都分配到一个recer上了)

6.7.4、mapjoin的小表比较大的时候,,无法直接使用mapjoin,则 select/*+mapjoin(b)*/  from  a left join ( select /*+mapjoin (b)*/ from b inner join a )

6.8、maprece 优化

6.8.1、调整mapper数

mapper数量与输入文件的split数息息相关。如果想减少mapper数,就适当提高mapred.min.split.size,split数就减少了;如果想增大mapper数,除了降低maperd.min.split.size之外,也可以提高mapred.map.task;一般来讲,如果输入文件是少量大文件,就减少mapper数;如果是大量非小文件,就增大mapper数,如果是小文件,就喝吧小文件

6.8.2 调整recer数

使用参数mapred.rece.task可以直接设定recer数量,如果不设置的话,hive会自行推测,推测逻辑如下:

参数hive.exec.recers.bytes.per.recer.设定每个recer能够处理的最大的数据量,默认时1G

参数hive.exec.recers.max设定每个job的最大的recer数量,默认时999或者1009

得到recer数:recers_num=min(total_input_size/recers.bytes.per.recer,recers.max)

recer数量与输出文件的数量相关,如果recer数太多,会产生大量小文件,对hdfs造成压力,如果recer数太少,每个recer要处理很多数据,容易拖慢运行时间或造成oom

6.8.3 合并小文件

输入阶段合并:需要更改hive的输入文件格式,即参数hive.input.format,默认值是org.apache.hadoop.hive.ql.io.hiveiputformat,我们该成org.apache.hadoop.hive.ql.io.combinehiveinputformat.

这样比调整mapper数时,又多出两个参数,分别是mapred.min.split.size.per.node和mapred.min.split.size.per.rack,含义是单节点和单机架上的最小split大小。如果发现又split大小小于这两个默认值100MB,则会进行合并

输出阶段合并:直接将hive.merge.mapfiles和hive.merge.mapredfiles都设置为true即可。

hive.merge.mapfiles表示将map-only任务的输出合并

hive.merge.mapredfiles表示将map-rece任务的输出合并

另外hive.merge.size.per.task可以指定每个task输出后合并文件大小的期望值

hive.merge.size.smallfiles.avgsize可以指定所有输出文件大小的均值阈值,默认时1G

6.9 启用压缩

压缩job的中间结果数据和输出数据,可以少量CPU时间节省出很多空间。压缩方式一般选择snappy,效率最高,要启用中间压缩,需要设定:

hive.exec.compress.intermediate为true,同时指定压缩方式hive.intermediate.compression.code为org.apache.hadoop.io.compress.snappycode.

另外,参数hive.intermediate.compression.type可以选对块block还是对记录record压缩,block压缩率比较高,输出压缩的配置基本相同:打开hive.exec.compress.output

6.10 jvm重用

在mr job中,默认时每执行一个task就会启动一个jvm,如果task非常小而且碎,那么jvm启动和关闭耗时都会比较长。可以通过调节参数mapred.job.reuse.jvm.num.task来重用。例如将这个参数设置为5,那么久代表同一个mr job中顺序执行的5各task可以重复使用一个jvm,减少启动和关闭开销,但是他对不同mr job的task无效

6.11 采用合适的存储格式

6.12 数据倾斜

数据倾斜原因:1、join 倾斜 2、聚合倾斜

group by 倾斜: group by 字段中某个字段的值过多,导致处理这个值得rece耗时很久

解决方法:set hive.map.aggr=true;  -- 表示开启map端聚合

set hive.groupby.skewindata=true;  注意:只能对单个字段聚合 , 生成两个map job ,第一个map job中map输出结果随机分布到rece中,每个rece做部分聚合操作,并输出结果,这样相同的groub key有可能被分发到不同的rece中,从而达到负载均衡的目的;第二个map job再根据预处理的数据结果按照group by key分布到rece中,这个过程可以保证相同的key被分到同一个rece中,最后完成最终的聚合操作

6.13 优化in、exists语句

使用left semi join 替换in 、exists

6.14 合并 maprece操作

multi-group by 是hive的一个非常好的特性,它使得hive中利用中间结果变更非常方便

例如:

from ( select a.status,b.school from status_update a join profilees b on (a.userid=b.suerid)) subq1

insert overwirte table a1 partition(ds='2021-03-07') 

select subq1.school,count(1) group by subq1.school

insert overwrite table b1 partition(ds='2021-03-07')

select subq1.status,count(1) group by subq1.status

上述语句使用了multi-group by特性联系group by 2次数据,使用不同的group by key,这一特性可以减少一次maprece操作

4. Hive优化的十大方法

Hive用的好,才能从数据中挖掘出更多的信息来。用过hive的朋友,我想或多或少都有类似的经历:一天下来,没跑几次hive,就到下班时间了。Hive在极大数据或者数据不平衡等情况下,表现往往一般,因此也出现了presto、spark-sql等替代品。这里重点讲解hive的优化方式,例如

一. 表连接优化

二. 用insert into替换union all
如果union all的部分个数大于2,或者每个union部分数据量大,应该拆成多个insert into 语句,实际测试过程中,执行时间能提升50%。示例参考如下:

可以改写为:

三. order by & sort by
order by : 对查询结果进行全局排序消耗时间长,需要set hive.mapred.mode=nostrict
sort by : 局部排序,并非全局有序,提高效率。

四. transform+python
一种嵌入在hive取数流程中的自定义函数,通过transform语句可以把在hive中不方便实现的功能在python中实现,然后写入hive表中。示例语法如下:

如果除python脚本外还有其它依赖资源,可以使用ADD ARVHIVE。

五. limit 语句快速出结果
一般情况下,Limit语句还是需要执行整个查询语句,然后再返回部分结果。有一个配置属性可以开启,避免这种情况—对数据源进行抽样

缺点:有可能部分数据永远不会被处理到

六. 本地模式
对于小数据集,为查询触发执行任务消耗的时间>实际执行job的时间,因此可以通过本地模式,在单台机器上(或某些时候在单个进程上)处理所有的任务。

可以通过设置属性hive.exec.mode.local.auto的值为true,来让Hive在适当的时候自动启动这个优化,也可以将这个配置写在$HOME/.hiverc文件中。
当一个job满足如下条件才能真正使用本地模式:

七. 并行执行
Hive会将一个查询转化为一个或多个阶段,包括:MapRece阶段、抽样阶段、合并阶段、limit阶段等。默认情况下,一次只执行一个阶段。 不过,如果某些阶段不是互相依赖,是可以并行执行的。

会比较耗系统资源。

八. 调整mapper和recer的个数

假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和1个12m的块),从而产生7个map数
假设input目录下有3个文件a,b,c,大小分别为10m,20m,130m,那么hadoop会分隔成4个块(10m,20m,128m,2m),从而产生4个map数。
即如果文件大于块大小(128m),那么会拆分,如果小于块大小,则把该文件当成一个块。
map执行时间:map任务启动和初始化的时间+逻辑处理的时间。

减少map数
若有大量小文件(小于128M),会产生多个map,处理方法是:

前面三个参数确定合并文件块的大小,大于文件块大小128m的,按照128m来分隔,小于128m,大于100m的,按照100m来分隔,把那些小于100m的(包括小文件和分隔大文件剩下的)进行合并。

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; – 执行前进行小文件合并。

增加map数
当input的文件都很大,任务逻辑复杂,map执行非常慢的时候,可以考虑增加Map数,来使得每个map处理的数据量减少,从而提高任务的执行效率。
set mapred.rece.tasks=?

一般根据输入文件的总大小,用它的estimation函数来自动计算rece的个数:rece个数 = InputFileSize / bytes per recer

九. 严格模式

十. 数据倾斜
表现:
任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)rece子任务未完成。因为其处理的数据量和其他rece差异过大。单一rece的记录数与平均记录数差异过大,通常可能达到3倍甚至更多。 最长时长远大于平均时长。

原因:

解决方案:参数调节

5. Hive优化之Hive的配置参数优化

Hive是大数据领域常用的组件之一,主要用于大数据离线数仓的运算,关于Hive的性能调优在日常工作和面试中是经常涉及的一个点,因此掌握一些Hive调优是必不可少的一项技能。影响Hive效率的主要因素有数据倾斜、数据冗余、job的IO以及不同底层引擎配置情况和Hive本身参数和HiveSQL的执行等。本文主要从建表配置参数方面对Hive优化进行讲解。

1. 创建一个普通表

table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED  BY ',';

2. 查看这张表的信息

DESCRIBE FORMATTED  test_user1;

我们从该表的描述信息介绍建表时的一些可优化点。

2.1 表的文件数

numFiles表示表中含有的文件数,当文件数过多时可能意味着该表的小文件过多,这时候我们可以针对小文件的问题进行一些优化,HDFS本身提供了解决方案:

(1)Hadoop Archive/HAR:将小文件打包成大文件。

(2)SEQUENCEFILE格式:将大量小文件压缩成一个SEQUENCEFILE文件。

(3)CombineFileInputFormat:在map和rece处理之前组合小文件。

(4)HDFS Federation:HDFS联盟,使用多个namenode节点管理文件。

除此之外,我们还可以通过设置hive的参数来合并小文件。

(1)输入阶段合并

需要更改Hive的输入文件格式,即参数hive.input.format,默认值是org.apache.hadoop.hive.ql.io.HiveInputFormat,我们改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。这样比起上面对mapper数的调整,会多出两个参数,分别是mapred.min.split.size.per.node和mapred.min.split.size.per.rack,含义是单节点和单机架上的最小split大小。如果发现有split大小小于这两个值(默认都是100MB),则会进行合并。具体逻辑可以参看Hive源码中的对应类。

(2)输出阶段合并

直接将hive.merge.mapfiles和hive.merge.mapredfiles都设为true即可,前者表示将map-only任务的输出合并,后者表示将map-rece任务的输出合并,Hive会额外启动一个mr作业将输出的小文件合并成大文件。另外,hive.merge.size.per.task可以指定每个task输出后合并文件大小的期望值,hive.merge.size.smallfiles.avgsize可以指定所有输出文件大小的均值阈值,默认值都是1GB。如果平均大小不足的话,就会另外启动一个任务来进行合并。

2.2 表的存储格式

通过InputFormat和OutputFormat可以看出表的存储格式是TEXT类型,Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式,可以通过两种方式指定表的文件格式:

(1)CREATE TABLE ... STORE AS <file_format>:在建表时指定文件格式,默认是TEXTFILE

(2)ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具体表的文件格式

如果要改变创建表的默认文件格式,可以使用set

hive.default.fileformat=<file_format>进行配置,适用于所有表。同时也可以使用set

hive.default.fileformat.managed = <file_format>进行配置,仅适用于内部表或外部表。

扩展:不同存储方式的情况

TEXT,

SEQUENCE和

AVRO文件是面向行的文件存储格式,不是最佳的文件格式,因为即便只查询一列数据,使用这些存储格式的表也需要读取完整的一行数据。另一方面,面向列的存储格式(RCFILE,

ORC, PARQUET)可以很好地解决上面的问题。关于每种文件格式的说明,如下:

(1)TEXTFILE

创建表时的默认文件格式,数据被存储成文本格式。文本文件可以被分割和并行处理,也可以使用压缩,比如GZip、LZO或者Snappy。然而大部分的压缩文件不支持分割和并行处理,会造成一个作业只有一个mapper去处理数据,使用压缩的文本文件要确保文件不要过大,一般接近两个HDFS块的大小。

(2)SEQUENCEFILE

key/value对的二进制存储格式,sequence文件的优势是比文本格式更好压缩,sequence文件可以被压缩成块级别的记录,块级别的压缩是一个很好的压缩比例。如果使用块压缩,需要使用下面的配置:set

hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK

(3)AVRO

二进制格式文件,除此之外,avro也是一个序列化和反序列化的框架。avro提供了具体的数据schema。

(4)RCFILE

全称是Record Columnar File,首先将表分为几个行组,对每个行组内的数据进行按列存储,每一列的数据都是分开存储,即先水平划分,再垂直划分。

(5)ORC

全称是Optimized Row Columnar,从hive0.11版本开始支持,ORC格式是RCFILE格式的一种优化的格式,提供了更大的默认块(256M)

(6)PARQUET

另外一种列式存储的文件格式,与ORC非常类似,与ORC相比,Parquet格式支持的生态更广,比如低版本的impala不支持ORC格式。

配置同样数据同样字段的两张表,以常见的TEXT行存储和ORC列存储两种存储方式为例,对比执行速度。

TEXT存储方式

总结: 从上图中可以看出列存储在对指定列进行查询时,速度更快, 建议在建表时设置列存储的存储方式 。

2.3 表的压缩

对Hive表进行压缩是常见的优化手段,一些存储方式自带压缩选择,比如SEQUENCEFILE支持三种压缩选择:NONE,RECORD,BLOCK。Record压缩率低,一般建议使用BLOCK压缩;

ORC支持三种压缩选择:NONE,ZLIB,SNAPPY。我们以TEXT存储方式和ORC存储方式为例,查看表的压缩情况。

配置同样数据同样字段的四张表,一张TEXT存储方式,另外三张分别是默认压缩方式的ORC存储、SNAPPY压缩方式的ORC存储和NONE压缩方式的ORC存储,查看在hdfs上的存储情况:

TEXT存储方式

默认压缩ORC存储方式

SNAPPY压缩的ORC存储方式

NONE压缩的ORC存储方式

总结 :可以看到ORC存储方式将数据存放为两个block,默认压缩大小加起来134.69M,SNAPPY压缩大小加起来196.67M,NONE压缩大小加起来247.55M,TEXT存储方式的文件大小为366.58M,且默认block两种存储方式分别为256M和128M,ORC默认的压缩方式比SNAPPY压缩得到的文件还小,原因是ORZ默认的ZLIB压缩方式采用的是deflate压缩算法,比Snappy压缩算法得到的压缩比高,压缩的文件更小。 ORC不同压缩方式之间的执行速度,经过多次测试发现三种压缩方式的执行速度差不多,所以建议采用ORC默认的存储方式进行存储数据。

2.4 分桶分区

Num Buckets表示桶的数量,我们可以通过分桶和分区操作对Hive表进行优化:

对于一张较大的表,可以将它设计成分区表,如果不设置成分区表,数据是全盘扫描的,设置成分区表后,查询时只在指定的分区中进行数据扫描,提升查询效率。要注意尽量避免多级分区,一般二级分区足够使用。常见的分区字段:

(1)日期或者时间,比如year、month、day或者hour,当表中存在时间或者日期字段时,可以使用些字段。

(2)地理位置,比如国家、省份、城市等

(3)业务逻辑,比如部门、销售区域、客户等等

与分区表类似,分桶表的组织方式是将HDFS上的一张大表文件分割成多个文件。分桶是相对分区进行更细粒度的划分,分桶将整个数据内容按照分桶字段属性值得hash值进行区分,分桶可以加快数据采样,也可以提升join的性能(join的字段是分桶字段),因为分桶可以确保某个key对应的数据在一个特定的桶内(文件),所以巧妙地选择分桶字段可以大幅度提升join的性能。通常情况下,分桶字段可以选择经常用在过滤操作或者join操作的字段。

创建分桶表

create

table test_user_bucket(id int, name string,code string,code_id string )

clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED 

BY ',';

查看描述信息

DESCRIBE FORMATTED test_user_bucket

多出了如下信息

查看该表的hdfs

同样的数据查看普通表和分桶表查询效率

普通表

分桶表

普通表是全表扫描,分桶表在按照分桶字段的hash值分桶后,根据join字段或者where过滤字段在特定的桶中进行扫描,效率提升。

本文首发于: 数栈研习社

数栈是云原生—站式数据中台PaaS,我们在github上有一个有趣的开源项目: FlinkX

FlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,比如MySQL,HDFS等,也可以采集实时变化的数据,比如MySQL

binlog,Kafka等,是全域、异构、批流一体的数据同步引擎,大家如果有兴趣,欢迎来github社区找我们玩~

6. 大数据开发工程师Hive(Hive如何进行优化)

1数据存储及压缩优化

针对hive中表的存储格式通常有textfile和orc,压缩格式一般使用snappy。相比于 textfile格式存储,orc占有更少的存储。因为hive底层使用MR计算架构,数据流是hdfs到磁盘再到hdfs,而且会有很多次IO读写操作,所以使用orc数据格式和snappy压缩策略可以降低IO读写,还能降低网络传输量,这样在一定程度上可以节省存储空间,还能提升hql的执行效率;

2 Hive Job优化

①调节Jvm参数,重用Jvm;

②合理设置Map个数;

③合理设置Rece个数;

3 Sql语法优化

建表优化

1) Hive创建表的时候,可以建分区表,分桶表;

2) Hive创建表的时候,可以指定数据存储格式:TextFile、SequenceFile、RCfile 、ORCfile;

查询时优化

1) 列裁剪,在查询时只读取需要的列,避免全列扫描,不要使用select * from table;

2) 分区裁剪:在查询时只读取需要分区的数据,避免全表扫描;

3) 开启谓词下推:set hive.optimize.ppd = true,默认是true:

a. 将Sql语句中的where谓词逻辑都尽可能提前执行,减少下游处理的数据量;

4) 大表join小表:

a. 开启MapJoin:set hive.auto.convert.join=true:

b. MapJoin是将Join双方比较小的那个表直接分发到各个Map进程的内存中,在 Map进程中进行Join操作, 这样就不用进行Rece步骤 ,从而提高了速度( 大表left join小表才有效 ,小表left join大表会失效);

5) 大表join大表:

a. SMB Join :Sort Merge Bucket Join(数据不仅分桶了,而且每个桶数据是排好序了);

b. 开启SMB Join之后,底层是根据两个表join字段进行分桶存储,这样的话,两张表就变为了基于桶之间join关联查询,而不是基于整张表的join,减少了笛卡尔积;

6) 少用in,用left semi join替代in:

a. 原始写法:select a.id, a.name from a where a.id in (select b.id from b);

b. 用join改写:select a.id, a.name from a join b on a.id = b.id;

c. left semi join改写:select a.id, a.name from a left semi join b on a.id = b.id;

7) 用union all代替union,因为union all不需要去重,也不需要排序,效率高于union;

(每天1小题,进步1点点)

7. hive运行sql rece 为1 ,跑不动怎么处理

1.jpg 优化可以从几个方面着手:1. 好的模型设计事半功倍。2. 解决数据倾斜问题。3. 减少job数。4. 设置合理的map rece的task数,能有效提升性能。(比如,10w+级别的计算,用160个rece,那是相当的浪费,1个足够)。5. 自己动手写sql解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化,但算法优化总是漠视业务,习惯性提供通用的解决方法。 Etl开发人员更了解业务,更了解数据,所以通过业务逻辑解决倾斜的方法往往更精确,更有效。6. 对count(distinct)采取漠视的方法,尤其数据大的时候很容易产生倾斜问题,不抱侥幸心理。自己动手,丰衣足食。7. 对小文件进行合并,是行至有效的提高调度效率的方法,假如我们的作业设置合理的文件数,对云梯的整体调度效率也会产生积极的影响。8. 优化时把握整体,单个作业最优不如整体最优。

8. hive sql cpu消耗大怎么优化

经常出现CPU占用100%的情况,主要问题可能发生在下面的某些方面: 

CPU占用率高的九种可能 

1、防杀毒软件造成故障 

由于新版的KV、金山、瑞星都加入了对网页、插件、邮件的随机监控,无疑增大了系统负担。处理方式:基本上没有合理的处理方式,尽量使用最少的监控服务吧,或者,升级你的硬件配备。 

2、驱动没有经过认证,造成CPU资源占用100% 

大量的测试版的驱动在网上泛滥,造成了难以发现的故障原因。 处理方式:尤其是显卡驱动特别要注意,建议使用微软认证的或由官方发布的驱动,并且严格核对型号、版本。 

3、病毒、木马造成 

大量的蠕虫病毒在系统内部迅速复制,造成CPU占用资源率据高不下。解决办法:用可靠的杀毒软件彻底清理系统内存和本地硬盘,并且打开系统设置软件,察看有无异常启动的程序。经常性更新升级杀毒软件和防火墙,加强防毒意识,掌握正确的防杀毒知识。 

4、控制面板—管理工具—服务—RISING REALTIME MONITOR SERVICE点鼠标右键,改为手动。 

5、开始->;运行->;msconfig->;启动,关闭不必要的启动项,重启。 

6、查看“svchost”进程。 

svchost.exe是Windows XP系统的一个核心进程。svchost.exe不单单只出现在Windows XP中,在使用NT内核的Windows系统中都会有svchost.exe的存在。一般在Windows 2000中svchost.exe进程的数目为2个,而在Windows XP中svchost.exe进程的数目就上升到了4个及4个以上。 

7、查看网络连接。主要是网卡。