hive性能优化模板

合集下载

HiveSQLcount（distinct）效率问题及优化

HiveSQLcount（distinct）效率问题及优化上周拿到了我的第⼀个⼯作任务，统计⼀个按天分区每天都有百亿条数据条的hive表中account字段的⾮重⽤户数（⼤概两千万）。

后来⼜更改为按id字段分别统计每个id的⽤户数。

按照我数据库⽼师的教导，我很轻易的跳出来了count（distinct account）这个句⼦。

然后写上了⼀⾏查询，等待了四个⼩时，然后map反着跑就知道没这么容易的任务。

然后想起来Hive SQL 基于的mapreduce是并⾏计算，百亿的数据可不是平时测试时的mysql⾥的⼏百条数据。

这么想来应该是map和reduce的内存不够，set mapreduce.map.memory.mb=48192;set mapreduce.reduce.memory.mb=48192;执⾏语句select count（distinct account）from...where...继续mapreduce，三个⼩时后报错error in shuffle in fetcher#3. shuffle过程⼜出问题了。

找呀找，reducer只有1？那还怎么并⾏？果断set mapred.reduce.tasks=1000；⼜进⾏查询，发现reducer 还是1。

只能求助于万能的Internet了。

原来因为加⼊distinct，map阶段不能⽤combine消重，数据输出为（key，value）形式然后在reduce阶段进⾏消重。

重点是，Hive在处理COUNT这种“全聚合(full aggregates)”计算时，它会忽略⽤户指定的Reduce Task数，⽽强制使⽤1。

⽰意图如下解决办法：转换为⼦查询，转化为两个mapreduce任务先select distinct的字段，然后在count（），这样去重就会分发到不同的reduce块，count依旧是⼀个reduce但是只需要计数即可。

Hive优化

Hive优化1 概述1.1 Hive的特征1.可以通过SQL轻松访问数据的工具，从而实现数据仓库的任务，报告和数据分析等。

2.可以使已经存储的数据结构化。

3.可以直接访问存储在HDFS或者其他数据存储系统中的文件。

4.Hive除了支持MapReduce计算引擎之外还支持Spark和Tez这两种分布式计算引擎。

5.提供了类似sql查询语句的HiveSql对数据进行分析。

6.存储格式多样化。

1.2 Hive优势Hive的强大之处不是在与将数据转换成特定格式，而是利用Hadoop本身的InputFormat API来从不同的数据源中读取数据，然后使用OutputFormat API将数据写成不同的格式。

所以对于不同的数据源，或者写出不同的格式就需要不同的对应的InputFormat和OutputFormat类的实现。

Hive拥有统一的元数据管理，所以和spark，impala等SQL引擎通用。

（通用指的是拥有了统一的Metastore之后，在Hive中创建一张表，在spark/impala中能通用，反之在spark中创建一张表，在Hive中也是能用的）只需要共用元数据，就可以切换SQL引擎了。

Hive使用SQL语法，提供快速开发能力，还可以通过用户定义的函数，用户定义的聚合和用户定义的表函数进行扩展，避免了去写MapReduce，减少开发人员学习成本。

Hive中不仅可以使用逗号和制表符分隔文本文件。

还可以使用sequence File、RC、ORC、Parquet。

Hive指在最大限度的提高可伸缩性，性能，可扩展性，容错性以及与其输出格式的松散耦合。

数据离线处理：日志分析，海量数据结构化分析。

2 Hive函数Hive的SQL可以通过用户定义的函数，用户定义的聚合和用户定义的表函数进行扩展当Hive提供的内置函数无法满足你的业务需求时，此时就可以考虑使用用户自定义函数UDF(用户定义函数)，UDAF(用户定义聚合函数)，UDTF(用户定义表函数)的区别：▪udf 一进一出▪udaf 聚集函数，多进一出▪udtf 一进多出3 Hive优化3.1 慎用api大数据场景下不害怕数据量大，但是害怕数据倾斜。

Hive的10种优化总结

Hive的10种优化总结Hive作为⼤数据领域常⽤的数据仓库组件，在平时设计和查询时要特别注意效率。

影响Hive效率的⼏乎从不是数据量过⼤，⽽是数据倾斜、数据冗余、job或I/O过多、MapReduce分配不合理等等。

对Hive的调优既包含对HiveSQL语句本⾝的优化，也包含Hive配置项和MR⽅⾯的调整。

列裁剪和分区裁剪最基本的操作。

所谓列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。

以我们的⽇历记录表为例：select uid,event_type,record_datafrom calendar_record_logwhere pt_date >= 20190201 and pt_date <= 20190224and status = 0;当列很多或者数据量很⼤时，如果select *或者不指定分区，全列扫描和全表扫描效率都很低。

Hive中与列裁剪优化相关的配置项是hive.optimize.cp，与分区裁剪优化相关的则是hive.optimize.pruner，默认都是true。

在HiveSQL解析阶段对应的则是ColumnPruner逻辑优化器。

谓词下推在关系型数据库如MySQL中，也有谓词下推（Predicate Pushdown，PPD）的概念。

它就是将SQL语句中的where谓词逻辑都尽可能提前执⾏，减少下游处理的数据量。

例如以下HiveSQL语句：select a.uid,a.event_type,b.topic_id,b.titlefrom calendar_record_log aleft outer join (select uid,topic_id,title from forum_topicwhere pt_date = 20190224 and length(content) >= 100) b on a.uid = b.uidwhere a.pt_date = 20190224 and status = 0;对forum_topic做过滤的where语句写在⼦查询内部，⽽不是外部。

大数据性能优化之Hive优化

大数据性能优化之Hive优化一、引言Hive是建立在Hadoop之上的数据仓库基础设施，用于处理大规模数据集。

然而，在处理大数据时，Hive的性能可能会受到一些因素的影响，如数据倾斜、查询优化等。

因此，本文将介绍一些Hive性能优化的方法，以提高查询效率和减少执行时间。

二、数据倾斜处理1. 了解数据倾斜的原因：数据倾斜是指在某些列或者分区中，数据的分布不均匀，导致某些任务的执行时间明显延长。

2. 使用随机数分桶：通过在表中添加一个随机数列，并使用该列进行分桶，可以将数据均匀分布到不同的桶中，从而减少数据倾斜的影响。

3. 使用动态分区：动态分区可以根据数据的值自动创建分区，避免了手动创建分区时可能浮现的数据倾斜问题。

三、查询优化1. 使用合适的数据存储格式：选择合适的存储格式可以提高查询性能。

例如，使用列式存储格式（如Parquet或者ORC）可以减少I/O操作，提高查询效率。

2. 使用分区和索引：通过将数据分成多个分区，并在常用的查询列上创建索引，可以减少扫描的数据量，提高查询速度。

3. 避免全表扫描：尽量避免使用SELECT *的方式查询数据，而是明确指定需要查询的列，减少不必要的数据读取。

4. 使用合适的连接方式：在Hive中，可以使用JOIN操作连接多个表。

为了提高查询性能，应尽量避免使用大表与大表的JOIN，可以考虑使用MAPJOIN或者BUCKET JOIN等方式来优化连接操作。

四、资源配置和调优1. 调整内存参数：根据集群的硬件资源和数据规模，合理配置Hive的内存参数，如mapreduce.map.memory.mb、mapreduce.reduce.memory.mb等，以充分利用集群资源。

2. 并行度调整：通过调整mapreduce.job.reduces参数，控制并行度，使得任务能够充分利用集群资源，提高数据处理速度。

3. 合理设置数据压缩：使用数据压缩可以减少磁盘占用和I/O操作，但过多的压缩会增加CPU负载。

hive优化总结

hive优化总结Hive是一个基于Hadoop的数据仓库基础设施工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的SQL查询功能。

然而，由于Hive处理大规模数据集时的复杂性，其性能可能不够理想。

因此，在实际应用中，我们需要对Hive进行优化，以提高其查询性能和效率。

首先，我们可以使用合适的存储格式来存储数据。

Hive支持多种存储格式，例如文本、Parquet和ORC。

对于大规模数据集，使用列式存储格式（如ORC）比行式存储格式（如文本）更高效。

列式存储格式可以减少I/O操作，提高查询性能。

其次，我们可以使用分区表和分桶表来优化查询。

分区表是将数据按照一定的规则分成多个分区存储的表，可以根据查询的条件只读取特定的分区，减少了不必要的数据读取和处理。

分桶表则是将数据分成多个桶存储，可以根据查询的条件只读取特定的桶，同样可以提高查询的效率。

另外，我们可以通过合理的数据压缩方式来减少存储空间，提高查询性能。

Hive支持多种数据压缩算法，如Snappy、LZO和Gzip。

选择合适的压缩算法可以在保证数据准确性的前提下减少存储空间，从而加快查询速度。

此外，我们还可以通过适当的索引使用来提高查询性能。

Hive 支持B树索引和位图索引。

B树索引适用于范围查询，而位图索引适用于离散值查询。

根据实际的查询场景，选择适合的索引类型可以加快查询速度。

另外，我们可以使用合适的硬件和网络配置来提高查询性能。

Hive的主要性能瓶颈包括CPU、内存和磁盘I/O。

通过增加硬件资源，如增加CPU核心数和内存容量，可以提高查询的并发能力和计算速度。

另外，优化网络传输的带宽和延迟也可以减少数据传输的时间，缩短查询的响应时间。

最后，我们可以使用MapReduce、Spark或Tez等并行计算框架来加快查询速度。

Hive支持多种执行引擎，可以根据具体的需求选择合适的执行引擎。

并行计算框架可以将查询任务并行化处理，并利用集群中的多台机器同时进行计算，从而加快查询速度。

Hive调优及优化的12种方式

Hive调优及优化的12种⽅式Hive调优及优化的12种⽅式请记住：在数据处理中，不怕数据量⼤，就怕数据倾斜！针对于Hive内部调优的⼀些⽅式01.请慎重使⽤COUNT(DISTINCT col);原因：distinct会将b列所有的数据保存到内存中，形成⼀个类似hash的结构，速度是⼗分的块；但是在⼤数据背景下，因为b列所有的值都会形成以key值，极有可能发⽣OOM解决⽅案：所以，可以考虑使⽤Group By 或者 ROW_NUMBER() OVER(PARTITION BY col)⽅式代替COUNT(DISTINCT col)02.⼩⽂件会造成资源的多度占⽤以及影响查询效率原因：众所周知，⼩⽂件在HDFS中存储本⾝就会占⽤过多的内存空间，那么对于MR查询过程中过多的⼩⽂件⼜会造成启动过多的Mapper Task, 每个Mapper都是⼀个后台线程，会占⽤JVM的空间在Hive中，动态分区会造成在插⼊数据过程中，⽣成过多零碎的⼩⽂件（请回忆昨天讲的动态分区的逻辑）不合理的Reducer Task数量的设置也会造成⼩⽂件的⽣成，因为最终Reducer是将数据落地到HDFS中的解决⽅案：在数据源头HDFS中控制⼩⽂件产⽣的个数，⽐如采⽤Sequencefile作为表存储格式，不要⽤textfile，在⼀定程度上可以减少⼩⽂件（常见于在流计算的时候采⽤Sequencefile格式进⾏存储）减少reduce的数量(可以使⽤参数进⾏控制)慎重使⽤动态分区，最好在分区中指定分区字段的val值最好数据的校验⼯作，⽐如通过脚本⽅式检测hive表的⽂件数量，并进⾏⽂件合并合并多个⽂件数据到⼀个⽂件中，重新构建表03.请慎重使⽤SELECT *原因：在⼤数据量多字段的数据表中，如果使⽤ SELECT * ⽅式去查询数据，会造成很多⽆效数据的处理，会占⽤程序资源，造成资源的浪费解决⽅案：在查询数据表时，指定所需的待查字段名，⽽⾮使⽤ * 号04.不要在表关联后⾯加WHERE条件原因：⽐如以下语句：SELECT * FROM stu as tLEFT JOIN course as t1ON t.id=t2.stu_idWHERE t.age=18;请思考上⾯语句是否具有优化的空间？如何优化？解决⽅案：采⽤谓词下推的技术，提早进⾏过滤有可能减少必须在数据库分区之间传递的数据量谓词下推的解释：所谓谓词下推就是通过嵌套的⽅式，将底层查询语句尽量推到数据底层去过滤，这样在上层应⽤中就可以使⽤更少的数据量来查询，这种SQL技巧被称为谓词下推(Predicate pushdown)那么上⾯语句就可以采⽤这种⽅式来处理：SELECT * FROM (SELECT * FROM stu WHERE age=18) as tLEFT JOIN course AS t1on t.id=t1.stu_id05.处理掉字段中带有空值的数据原因：⼀个表内有许多空值时会导致MapReduce过程中,空成为⼀个key值,对应的会有⼤量的value值, ⽽⼀个key的value会⼀起到达reduce造成内存不⾜解决⽅式：1、在查询的时候，过滤掉所有为NULL的数据，⽐如：create table res_tbl asselect n.* from(select * from res where id is not null ) nleft join org_tbl o on n.id = o.id;2、查询出空值并给其赋上随机数,避免了key值为空（数据倾斜中常⽤的⼀种技巧）create table res_tbl asselect n.* from res nfull join org_tbl o oncase when n.id is null then concat('hive', rand()) else n.id end = o.id;06.设置并⾏执⾏任务数通过设置参数 hive.exec.parallel 值为 true，就可以开启并发执⾏。

Hive优化

Hive常见优化一、数据倾斜1、什么是数据倾斜？Hadoop框架的特性决定最怕数据倾斜•由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。

节点间数据分布不均衡，会造成map端每个map任务的工作量不同，即map端数据倾斜。

Map-reduce，把相同key提交给同一个reduce，如果key不均衡就会造成不同的reduce的工作量不同。

以京东首页活动为例，曝光率大的是大活动，曝光率小的是小活动：假如reduce1处理的是小活动，reduce2处理大活动，reduce2干的活比其他reduce多很多，会出现其他reduce执行完毕了，reduce2还在缓慢执行。

症状：map阶段快，reduce阶段非常慢；某些map很快，某些map很慢；某些reduce很快，某些reduce奇慢。

如下情况：A、数据在节点上分布不均匀B、join时on关键词中个别值量很大（如null值）C、count(distinct),在数据量大的情况下，容易数据倾斜，因为count(distinct)是按group by字段分组，按distinct字段排序。

其中A无法避免。

B见后边的Join章节。

C语法上有时无法避免如何解决数据倾斜？实际上是没办法避免的，这里的解决只是个别情况起效：有数据倾斜的时候进行负载均衡set hive.groupby.skewindata=false;当选项设定为true，生成的查询计划会有两个MR Job。

第一个MR Job中，Map 的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MR Job再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作。

Hive常用优化技巧

Hive常⽤优化技巧Hive优化最体现程序员的技术能⼒，⾯试官在⾯试时最喜欢问的就是Hive的优化技巧。

技巧1.控制reducer数量下⾯的内容是我们每次在hive命令⾏执⾏SQL时都会打印出来的内容：In order to change the average load for a reducer (in bytes):set hive.exec.reducers.bytes.per.reducer=<number>In order to limit the maximum number of reducers:set hive.exec.reducers.max=<number>In order to set a constant number of reducers:set mapreduce.job.reduces=<number>很多⼈都会有个疑问，上⾯的内容是⼲什么⽤的。

我们⼀⼀来解答，先看set hive.exec.reducers.bytes.per.reducer=<number>，这个⼀条Hive命令，⽤于设置在执⾏SQL的过程中每个reducer处理的最⼤字节数量。

可以在配置⽂件中设置，也可以由我们在命令⾏中直接设置。

如果处理的数据量⼤于number，就会多⽣成⼀个reudcer。

例如，number = 1024K，处理的数据是1M，就会⽣成10个reducer。

我们来验证下上⾯的说法是否正确：1. 执⾏set hive.exec.reducers.bytes.per.reducer=200000;命令，设置每个reducer处理的最⼤字节是200000。

2. 执⾏sql:select user_id,count(1) as cntfrom orders group by user_id limit 20;执⾏上⾯的sql时会在控制台打印出信息：Number of reduce tasks not specified. Estimated from input data size: 159In order to change the average load for a reducer (in bytes):set hive.exec.reducers.bytes.per.reducer=<number>In order to limit the maximum number of reducers:set hive.exec.reducers.max=<number>In order to set a constant number of reducers:set mapreduce.job.reduces=<number>Starting Job = job_1538917788450_0020, Tracking URL = http://hadoop-master:8088/proxy/application_1538917788450_0020/Kill Command = /usr/local/src/hadoop-2.6.1/bin/hadoop job -kill job_1538917788450_0020Hadoop job information for Stage-1: number of mappers: 1; number of reducers: 159控制台打印的信息中第⼀句话：Number of reduce tasks not specified. Estimated from input data size: 159。

Hive（十）Hive性能调优总结

Hive（⼗）Hive性能调优总结⼀、Fetch抓取1、理论分析Fetch抓取是指，Hive中对某些情况的查询可以不必使⽤MapReduce计算。

例如：SELECT * FROM employees;在这种情况下，Hive可以简单地读取employee对应的存储⽬录下的⽂件，然后输出查询结果到控制台。

在hive-default.xml.template⽂件中hive.fetch.task.conversion默认是more，⽼版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit查找等都不⾛mapreduce。

<property><name>hive.fetch.task.conversion</name><value>more</value><description>Expects one of [none, minimal, more].Some select queries can be converted to single FETCH task minimizing latency.Currently the query should be single sourced not having any subquery and should not haveany aggregations or distincts (which incurs RS), lateral views and joins.0. none : disable hive.fetch.task.conversion1. minimal : SELECT STAR, FILTER on partition columns, LIMIT only2. more : SELECT, FILTER, LIMIT only (support TABLESAMPLE and virtual columns)</description></property>2、案例实操（1）把hive.fetch.task.conversion设置成none，然后执⾏查询语句，都会执⾏mapreduce程序。

Hive实战高级优化

Hive高级优化一、前言毫不夸张的说，有没有掌握hive调优，是判断一个数据工程师是否合格的重要指标hive调优, 涉及到压缩和存储调优，参数调优，sql的调优，数据倾斜调优，小文件问题的调优等。

二、数据的压缩与存储格式1)map阶段输出数据压缩在这个阶段，优先选择一个低CPU开销的算法。

set press.intermediate=trueset pression.codec=press.SnappyCset pression.codec=pression.lzo.LzoCodec;2)结果压缩set press.output=trueset pression.codec=press.SnappyCodec结论，一般选择orcfile/parquet + snappy 方式三、合理利用分区分桶分区是将表的数据在物理上分成不同的文件夹，以便于在查询时可以精准指定所要读取的分区目录，从来降低读取的数据量，分桶是将表数据按指定列的hash散列后分在了不同的文件中，将来查询时，hive可以根据分桶结构，快速定位到一行数据所在的分桶文件，从来提高读取效率四、hive参数优化1) 并行度优化// 让可以不走mapreduce任务的，就不走mapreduce任务hive> set hive.fetch.task.conversion=more;// 开启任务并行执行set hive.exec.parallel=true;// 解释：当一个sql中有多个job时候，且这多个job之间没有依赖，则可以让顺序执行变为并行执// 同一个sql允许并行任务的最大线程数set hive.exec.parallel.thread.number=8;2)JVM重用// JVM重用对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多set mapred.job.reuse.jvm.num.tasks=10;// 合理设置reduce的数目// 方法1：调整每个reduce所接受的数据量大小set hive.exec.reducers.bytes.per.reducer=500000000; （500M）// 方法2：直接设置reduce数量set mapred.reduce.tasks = 20// map端聚合，降低传给reduce的数据量set hive.map.aggr=trueset hive.groupby.skewindata=true五、SQL优化1) Where条件优化优化前（关系数据库不用考虑会自动优化）select m.cid,u.id from order m join customer u on( m.cid =u.id )wherem.dt='20180808';优化后(where条件在map端执行而不是在reduce端执行）select m.cid,u.id from （select * from order where dt='20180818'）m join customer u on( m.cid =u.id);2) Union优化尽量不要使用union （union 去掉重复的记录）而是使用union all 然后在用group by 去重3)Count distinct优化不要使用count (distinct cloumn) ,使用子查询select count(1) from (select id from tablename group by id) tmp;4)In代替join如果需要根据一个表的字段来约束另为一个表，尽量用in来代替join . in 要比join 快select id,name from tb1 a join tb2 b on(a.id = b.id);select id,name from tb1 where id in(select id from tb2);5)优化子查询消灭子查询内的group by 、COUNT(DISTINCT)，MAX，MIN。

hive优化要点总结电脑资料

hive优化要点总结电脑资料再好的硬件没有充分利用起来，都是白扯淡，比方:通常来说前面的任务启动可以稍带一起做的事情就一起做了,以便后续的多个任务重用,与此严密相连的是模型设计,好的模型特别重要. reduce个数过少没有真正发挥hadoop并行计算的威力，但reduce 个数过多，会造成大量小文件问题，数据量、资源情况只有自己最清楚，找到个折衷点,比方:假设其中有一个表很小使用map join，否那么使用普通的reduce join，注意hive会将join前面的表数据装载内存,所以较小的一个表在较大的表之前,减少内存资源的消耗在hive里有两种比较常见的处理方法第一是使用Combinefileinputformat，将多个小文件打包作为一个整体的inputsplit，减少map任务数set mapred.max.split.size=256000000;set mapred.min.split.size.per.node=256000000set Mapred.min.split.size.per.rack=256000000sethive.input.format=bineHiveI nputFormat第二是设置hive参数，将额外启动一个MR Job打包小文件hive.merge.mapredfiles = false 是否合并Reduce输出文件，默认为Falsehive.merge.size.per.task = 256*1000*1000 合并文件的大小在hive里比较常用的处理方法第一通过hive.groupby.skewindata=true控制生成两个MR Job,第一个MR Job Map的输出结果随机分配到reduce做次预汇总,减少某些key值条数过多某些key条数过小造成的数据倾斜问题第二通过hive.map.aggr = true(默认为true)在Map端做biner,假设map各条数据根本上不一样, 聚合没什么意义，做biner反而画蛇添足,hive里也考虑的比较周到通过参数hive.groupby.mapaggr.checkinterval = 100000 (默认)hive.map.aggr.hash.min.reduction=0.5(默认),预先取100000条数据聚合,如果聚合后的条数/100000>0.5，那么不再聚合multi insert适合基于同一个源表按照不同逻辑不同粒度处理插入不同表的场景，做到只需要扫描源表一次，job个数不变，减少源表扫描次数union all用好，可减少表的扫描次数，减少job的个数,通常预先按不同逻辑不同条件生成的查询union all后，再统一group by计算,不同表的union all相当于multiple inputs,同一个表的union all,相当map一次输出多条集群参数种类繁多,举个例子比方可针对特定job设置特定参数,比方jvm重用,reduce copy线程数量设置(适合map较快，输出量较大)如果任务数多且小，比方在一分钟之内完成，减少task数量以减少任务初始化的消耗，：blog.csdn./u011750989/article/details/12024301。

Hive参数优化

Hive参数优化
在mapper端执⾏join：
set hive.auto.convert.join=true;
启⽤本地模式：
set hive.exec.mode.local.auto=true;
启⽤并⾏执⾏：
set hive.exec.parallel=true;
启⽤严格模式/⾮严格模式：
set hive.mapred.mode=strict;
set hive.mapred.mode=nonstrict;
严格模式可以禁⽌以下三种查询：
1、对于分区表的查询必须限定where条件；
2、order by语句的查询必须使⽤limit；
3、限制笛卡尔积的查询。

调整每个reducer处理的数据⽂件⼤⼩：
set hive.exec.reducers.bytes.per.reducer=750000000;//单位为B
调整reducer的个数：
set mapred.reduce.tasks=4;
设置允许启⽤的最⼤reducer个数：
set hive.exec.reducers.max=8;
取消动态分区的严格模式（严格模式下，必须⾄少保证⼀个分区是静态的）：
set hive.exec.dynamic.partition.mode=nonstrict;
解决数据倾斜：
set hive.map.aggr=true；//在mapper端聚合
set hive.groupby.skewindata=true;//相同的key也能随机分发给不同的reducer
set hive.optimize.skewjoin=true;//解决join类倾斜
待补充。

Hive性能优化总结

Hive性能优化总结Hive性能优化总结介绍首先，我们来看看Hadoop的计算框架特性，在此特性下会衍生哪些问题？数据量大不是问题，数据倾斜是个问题。

jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。

原因是map reduce作业初始化的时间是比较长的。

sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。

count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。

举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。

面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段：好的模型设计事半功倍。

解决数据倾斜问题。

减少job数。

设置合理的map reduce的task数，能有效提升性能。

(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。

了解数据分布，自己动手解决数据倾斜问题是个不错的选择。

sethive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。

数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。

对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。

优化时把握整体，单个作业最优不如整体最优。

而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？性能低下的根源hive性能优化时，把HiveQL当做M/R程序来读，即从M/R的运行角度来考虑优化性能，从更底层思考如何优化运算性能，而不仅仅局限于逻辑代码的替换层面。

Hive调优参数配置

Hive调优参数配置Hive进⾏⼤数据处理的过程中经常遇到⼀个任务跑⼏个⼩时或者内存溢出等问题，平时会任务执⾏的遇到的问题进⾏参数的调整配置，收集整理的配置参考如下：set node.handler.count=20;set mapred.task.timeout=36000000;set hive.cbo.enable=true;set ing.stats=true;set hive.stats.fetch.column.stats=true;set hive.stats.fetch.partition.stats=true;set hive.exec.parallel.thread.number=8;set hive.auto.convert.join=true;set hive.mapjoin.smalltable.filesize=25000;set hive.merge.mapfiles=true;set hive.merge.mapredfiles=true;set hive.merge.size.per.task=256000000;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=bineHiveInputFormat;set hive.merge.size.per.task=256000000;set hive.merge.smallfiles.avgsize=256000000;set hive.map.aggr.hash.percentmemory=0.25;set mapred.map.tasks.speculative.execution=true;set mapred.reduce.tasks.speculative.execution=true;set hive.mapred.reduce.tasks.speculative.execution=true;set node.handler.count=20;nameNode有⼀个⼯作线程池⽤来处理客户端的远程过程调⽤及集群守护进程的调⽤。

hive性能调优的几种方式

hive性能调优的⼏种⽅式关于hive数据仓库的调优⽅式有很多种，留篇博客⽤来⽅便记忆...1、设置本地模式在hive0.7版本之后就开始⽀持任务执⾏选择本地模式(local mode)，尽管hive是基于hadoop集群来做⼤数据处理的，但是有时会出现输⼊的数据量⾮常⼩，其查询出发执⾏任务的消耗时间远远⼤于job执⾏时间，这种情况下，本地执⾏任务是不是更加效率？设置⽅式：set hive.exec.mode.local.auto=true2、并⾏执⾏对于某个job，若存在许多阶段可以并⾏执⾏，则集群利⽤率会变⾼，提⾼了查询的效率（系统资源空闲情况下）设置⽅式：set hive.exec.parallel=true set hive.exec.parallel.thread.number=16; //同⼀个sql运⾏最⼤并⾏度，默认为83、严格模式（默认为⾮严格模式）严格模式的作⽤，是为了防⽌⽤户执⾏的危险查询，如下：对于分区表，⽤户不允许扫描所有分区；对于使⽤了order by语句的查询，要求必须使⽤limit语句；限制笛卡尔积的查询设置⽅式：修改配置信息hive.mapred.mode为strict(永久设置) | 命令 set hive.mapred.mode=strict(⾮永久⽅式)4、JVM的重⽤虚拟机的重⽤同样适⽤于⼤量的⼩⽂件的场景，尤其对于job种包含⾮常多的task任务时设置⽅式：修改hadoop的mapred-site.xml⽂件设置 mapred.job.reuse.jvm.num.tasks(永久配置) | set mapred.job.reuse.jvm.num.tasks=n5、Fetch抓取对于某些查询可以直接跳过MR计算，查询table对应存储⽬录下的⽂件效率更⾼(全局查找,字段查找,filter查找,limit查找)设置⽅式：修改hive/conf/hive-default.xml⽂件设置 hive.fetch.task.conversion 为more6、数据倾斜的解决⽅法之前有过相关博客：https:///afeiiii/p/13582276.html7、explain执⾏计划通过执⾏计划来查看sql8、合理设置map/reduce的数量合理设置数量，可以提⾼效率，过多则会占⽤资源设置⽅式：set dfs.block.size=n(n默认为128MB,合理降低可以增加map) set mapred.reduce.tasks=n。

Hive性能调优指南

Hive性能调优指南目录目录 (2)第一章 Hive调优的总体原则 (4)1.1 计算性能的优化 (4)1.2 I/O的优化 (5)第二章 Hive优化的相关原理 (5)2.1关于Join (6)Ø 2.1.1 Reduce Side Join (6)Ø 2.1.2 Map Side Join (7)Ø 2.1.3 Semi Join (9)Ø 2.1.4 Reduce Side Join + Bloom Filter (10)Ø 2.1.5 Hive提供的Join方式 (10)Shuffle Join (10)Broadcast Join (11)Bucket Map Join (11)Sort-Merge-Bucket Join(SMJ) (12)Skew Join (13)Left Semi Join (14)2.2关于排序 (15)Ø 2.2.1 Order By (15)Ø 2.2.2 Sort By (15)Ø 2.2.3 Distribute By (16)Ø 2.2.4 Cluster By (16)2.3数据倾斜问题 (17)Ø什么是数据倾斜 (17)Ø数据倾斜的常见场景 (17)l空值数据倾斜 (17)l不同数据类型关联产生数据倾斜 (18)l大表Join的数据偏斜 (18)Ø数据倾斜的解决方案 (19)l参数调节 (19)l SQL语句调节 (20)2.4关于Shuffle (20)ØShuffle概述 (20)ØMap端Shuffle过程 (21)ØReduce端Shuffle过程 (22)第三章Hive调优方案及分析 (24)Ø 3.1 Hadoop计算框架的特点 (24)Ø 3.2 Hadoop调优策略 (25)应用程序级别调优 (25)作业级别调优 (26)任务级别调优 (27)管理员级别调优 (30)操作系统级别调优 (30)JVM级别调优 (31)Ø 3.3 Hive调优项目checklist (32)Ø 3.4 Hive优化的常用案例 (32)l优化Join连接 (32)ØJoin的原则 (32)Ø使用Map Join (33)l合理设置map task数 (35)l怎么设置reduce的任务数 (37)l exist in子句 (39)l合并小文件 (39)l开启本地Map任务 (39)l优化limit (40)l JVM重用 (40)l推测式执行（Speculative Execution） (41)l Group By (41)l使用Multi-group by合并MR数 (41)l Bucket and Samping (42)l Partition (42)l Strict模式 (43)l避免笛卡尔积 (44)l慎用count(distinct) (44)l利用Hive中的union all特性减少Map/Reduce个数 (45)l Controlling data locality with Hive (46)l使用ORC File (47)l使用Tez (47)l数据加载场景的优化案例 (48)l多表关联的优化 (49)l使用并发 (51)l Urber模式 (51)l本地map 任务 (52)Ø 3.5 Hive调优参数 (53)第五章附录-参数 (58)第一章 Hive调优的总体原则 1.1 计算性能的优化原则：合理调整map/reduce的任务数量，充分利用集群中的CPUa)尽量保证每个map任务处理的数据量保持均衡b)Reduce任务数量=总任务槽*0.95：这样为一个推测式执行任务提供空闲机器。