Hive性能优化总结
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查询性能的几种方法
提高Hive查询性能的几种方法Hive是一种在Hadoop上运行的数据仓库工具，用于处理大规模数据集。
尽管Hive的强大之处在于它能够处理大数据量，但在某些情况下，查询性能可能会变得缓慢。
为了提高Hive查询的执行速度，下面将介绍几种方法。
1. 数据分区数据分区是提高Hive查询性能的重要方法之一。
通过将数据按照特定的列进行分区，可以使查询仅限于需要的数据分区，从而减少查询开销。
数据分区还能够增加查询的并行性，从而进一步加快查询速度。
在创建表时，可以根据数据特点选择合适的分区方式，例如按照日期、地理位置等进行分区。
2. 分桶表分桶是将表中的数据按照一定的规则划分到不同的桶中，以便查询时可以只读取特定的桶，而无需扫描整个数据集。
分桶表可以大大减少查询的数据量，提高查询性能。
在创建表时，可以指定分桶的数量和分桶所依据的列，以便更好地适应查询需求。
3. 数据压缩数据压缩是提高Hive查询性能的另一个关键点。
通过使用压缩算法，可以减少磁盘上的存储空间，并减少数据在网络上传输的大小。
压缩后的数据可以更快地加载和读取，从而加快查询速度。
在创建表时，可以选择合适的压缩格式，如Snappy、Gzip等，根据数据类型和查询需求进行选择。
4. 数据索引在Hive中，使用索引可以加快特定列的查询，尤其是在大数据集上进行过滤操作。
在常规的Hive版本中，尚未支持内置的索引功能，但可以使用其他方法来实现类似的效果。
一种方法是使用HBase作为Hive的存储后端，并在HBase中创建索引。
另一种方法是使用外部索引工具，如Elasticsearch或Solr。
通过使用合适的索引机制，可以显著提高查询性能。
5. 数据分档数据分档是一种将大数据集划分为逻辑上相关的分区的方法。
通过根据查询需求将数据分为不同的分区级别，可以减少不必要的数据读取和处理。
例如，可以根据数据的时间戳进行分档，将数据按照年、月、日等进行分区，从而只选择需要的时间范围进行查询。
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优化要点总结电脑资料再好的硬件没有充分利用起来，都是白扯淡，比方:通常来说前面的任务启动可以稍带一起做的事情就一起做了,以便后续的多个任务重用,与此严密相连的是模型设计,好的模型特别重要. 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实验报告心得体会在Hive实验中，我深入学习了Hive的基本概念、操作以及实际应用，从中积累了丰富的经验和心得体会。
以下是我对Hive实验的心得总结。
一、Hive的基本概念在Hive实验中，我了解到Hive是建立在Hadoop上的数据仓库工具，它提供了类似于SQL的查询语言HiveQL，使得开发人员能够通过类似于SQL的方式来操作存储在Hadoop中的结构化数据。
Hive将结构化数据映射为表，并将表之间的关系描述为元数据，这使得数据的管理和查询更加方便。
二、Hive的操作在实验中，我学习了如何在Hive中创建表、加载数据以及执行查询。
首先，通过创建表的语句，我定义了表的结构，包括字段名和数据类型。
然后，我使用LOAD命令将数据加载到Hive表中。
最后，通过编写HiveQL查询语句，我可以对数据进行分析和查询。
三、Hive的实际应用在实验中，我还了解到Hive在大数据处理和分析方面的重要性。
由于Hive提供了类SQL的查询语言，使得非专业开发人员也能够通过简单的语法来进行数据分析。
此外，Hive还支持自定义函数（UDF）和自定义聚合函数（UDAF），可以帮助我们更加灵活地处理数据。
因此，Hive在数据仓库、数据分析和数据挖掘等领域有着广泛的应用。
四、心得体会通过进行Hive实验，我深刻认识到了大数据处理和分析的重要性。
Hive作为一种高层次的查询语言，可以让开发人员更加专注于业务逻辑的实现，而不需要过多关注底层的数据存储和操作。
同时，Hive的可扩展性和容错性也使得其在大规模数据处理场景中表现出色。
此外，在进行实验的过程中，我也意识到了数据质量和性能的重要性。
在设计Hive表的时候，合理选择字段类型和分区方式可以提高查询性能。
同时，合理地使用Hive提供的优化技术，如分桶、索引等，也可以提高查询效率。
因此，对于大规模数据处理和分析的任务，我们需要不断优化表结构和查询语句，以提高数据的处理速度和准确性。
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优化总结在大数据处理领域中，Hadoop已经成为主流的框架之一。
Hadoop 的一个重要组件是Hive，这是一个基于Hadoop的数据仓库基础工具。
Hive的目标是提供一个类SQL查询的接口，以便于对存储于Hadoop集群中的数据进行分析和查询。
然而，在实际使用中，Hive的性能和效率往往会受到限制。
本文将介绍一些提高Hive性能和优化的技巧和方法。
首先，要注意数据分区。
在Hive中，数据分区可以将数据以更细粒度的方式进行组织和存储，从而提高查询效率。
通过将数据分区存储在不同的目录中，Hive可以避免扫描整个数据集，并仅从感兴趣的分区中读取数据。
因此，正确地定义和使用数据分区是提高Hive性能的重要步骤之一。
其次，使用合适的表格式也是优化Hive的关键。
Hive支持多种表格式，例如文本、序列文件和列式存储等。
每种表格式都有自己的特点和适用场景。
在选择表格式时，需要考虑数据大小、查询类型以及存储需求等因素。
例如，对于需要频繁进行聚合操作的场景，列式存储格式通常更加高效。
另外，可以使用分桶技术来改善Hive的性能。
分桶是将表按照某个列的值进行分组，使得具有相同分桶值的数据存储在相同的桶中。
通过使用分桶技术，Hive可以更快地进行连接操作和过滤操作，从而提高查询效率。
在选择分桶列时，应选择具有较高的基数和较为均匀分布的列。
此外，使用Hive的索引功能也能够加速查询。
Hive支持对表中的列创建索引，从而可以更快地定位和访问数据。
通过使用索引，Hive可以减少全表扫描的开销，并且在一些特定的查询场景下，索引的使用可以显著提高查询性能。
然而，需要注意的是，索引会增加数据的存储空间和更新的成本，因此在使用索引时需要进行权衡。
最后，合理地配置Hive参数也是优化Hive性能的一项重要工作。
Hive的性能受到许多配置参数的影响，例如内存大小、并行度和任务调度等。
根据具体的场景和需求，可以对这些参数进行调整，以获得更好的性能和效率。
hive优化总结
hive优化总结Hive优化总结Hive是一种建立在Hadoop之上的开源数据仓库解决方案，它可以使用类似SQL的查询语言来处理大规模数据集。
然而，由于数据集的规模越来越庞大，并且查询的复杂度也在增加，Hive的性能可能会受到影响。
因此，对Hive进行优化是提高查询效率和性能的关键。
一、数据分区在Hive中，数据分区是一种将数据按照特定的列进行划分存储的方式。
通过合理地选择分区列，可以提高查询性能。
例如，在时间序列数据中，通过将数据按照时间列进行分区，可以将查询仅限于需要的时间范围，提高查询效率。
二、数据压缩Hive支持多种数据压缩格式，如Gzip、Snappy和LZO等。
使用数据压缩可以显著减少存储空间，并且对于IO密集型操作，如数据扫描，也可以显著提高性能。
在选择数据压缩格式时，需要综合考虑存储空间和查询性能之间的权衡。
三、分桶类似于数据分区，分桶也是一种将数据进行划分的方式。
不同的是，分桶是将数据按照某一列的哈希值进行划分，可以提高数据的均衡性。
通过通过使用分桶，可以提高数据的访问效率，尤其是对于某些需要经常进行随机访问的操作。
四、合理使用索引在Hive中，可以使用B树索引来加速查询。
合理地创建索引可以显著提高查询性能。
然而，索引也会带来额外的存储开销和维护成本，因此需要权衡是否使用索引。
通常情况下，索引适用于数据量较小、查询频繁的情况下。
五、数据倾斜处理在大规模数据集中，数据倾斜是一个不可避免的问题。
数据倾斜会导致查询性能不均衡，某些任务的执行时间远远超出了预期。
针对数据倾斜问题，可以使用一些优化技术，如数据倾斜的处理和随机均匀分布。
六、并行执行并行执行是提高Hive查询性能的一个关键技术。
在Hive中，可以通过设置合适的查询并行度，将一个复杂的查询分解为多个子任务并行执行。
这样可以加快查询速度，提高整体的性能。
七、动态分区动态分区是一种在查询时根据查询条件动态创建分区的技术。
通过使用动态分区，可以避免在每次插入数据时都需要手动创建分区的操作，简化了操作流程，提高了数据的管理效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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的运行角度来考虑优化性能，从更底层思考如何优化运算性能，而不仅仅局限于逻辑代码的替换层面。
RAC（Real Application Cluster）真正应用集群就像一辆机动灵活的小货车，响应快；Hadoop就像吞吐量巨大的轮船，启动开销大，如果每次只做小数量的输入输出，利用率将会很低。
所以用好Hadoop的首要任务是增大每次任务所搭载的数据量。
Hadoop的核心能力是parition和sort，因而这也是优化的根本。
观察Hadoop处理数据的过程，有几个显著的特征：⏹数据的大规模并不是负载重点，造成运行压力过大是因为运行数据的倾斜。
⏹jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联对此汇总，产生几十个jobs，将会需要30分钟以上的时间且大部分时间被用于作业分配，初始化和数据输出。
M/R作业初始化的时间是比较耗时间资源的一个部分。
⏹在使用SUM，COUNT，MAX，MIN等UDAF函数时，不怕数据倾斜问题，Hadoop在Map端的汇总合并优化过，使数据倾斜不成问题。
⏹COUNT(DISTINCT)在数据量大的情况下，效率较低，如果多COUNT(DISTINCT)效率更低，因为COUNT(DISTINCT)是按GROUP BY字段分组，按DISTINCT字段排序，一般这种分布式方式是很倾斜的；比如：男UV，女UV，淘宝一天30亿的PV，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。
数据倾斜是导致效率大幅降低的主要原因，可以采用多一次Map/Reduce 的方法，避免倾斜。
最后得出的结论是：避实就虚，用job 数的增加，输入量的增加，占用更多存储空间，充分利用空闲CPU 等各种方法，分解数据倾斜造成的负担。
优化性能配置角度优化map阶段优化Map阶段的优化，主要是确定合适的map数。
那么首先要了解map数的计算公式,另外要说明的是，这个优化只是针对Hive 0.9版本。
num_map_tasks =max[${mapred.min.split.size},min(${dfs.block.size},${mapred.max.split .size})]⏹mapred.min.split.size: 指的是数据的最小分割单元大小；min的默认值是1B⏹mapred.max.split.size: 指的是数据的最大分割单元大小；max的默认值是256MB⏹dfs.block.size: 指的是HDFS设置的数据块大小。
个已经指定好的值，而且这个参数默认情况下hive是识别不到的通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。
需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。
reduce阶段优化这里说的reduce阶段，是指前面流程图中的reduce phase（实际的reduce计算）而非图中整个reduce task。
Reduce阶段优化的主要工作也是选择合适的reduce task数量, 与map优化不同的是，reduce优化时，可以直接设置mapred.reduce.tasks参数从而直接指定reduce的个数num_reduce_tasks =min[${hive.exec.reducers.max},(${input.size}/${hive.exec.reducers.byt es.per.reducer})]hive.exec.reducers.max：此参数从Hive 0.2.0开始引入。
在Hive 0.14.0版本之前默认值是999；而从Hive 0.14.0开始，默认值变成了1009，这个参数的含义是最多启动的Reduce个数hive.exec.reducers.bytes.per.reducer：此参数从Hive 0.2.0开始引入。
在Hive0.14.0版本之前默认值是1G(1,000,000,000)；而从Hive 0.14.0开始，默认值变成了256M(256,000,000)，可以参见HIVE-7158和HIVE-7917。
这个参数的含义是每个Reduce处理的字节数。
比如输入文件的大小是1GB，那么会启动4个Reduce来处理数据。
也就是说，根据输入的数据量大小来决定Reduce的个数，默认Hive.exec.Reducers.bytes.per.Reducer为1G，而且Reduce个数不能超过一个上限参数值，这个参数的默认取值为999。
所以我们可以调整Hive.exec.Reducers.bytes.per.Reducer来设置Reduce个数。
需要注意的是：1.Reduce的个数对整个作业的运行性能有很大影响。
如果Reduce设置的过大，那么将会产生很多小文件，对NameNode会产生一定的影响，而且整个作业的运行时间未必会减少；如果Reduce设置的过小，那么单个Reduce处理的数据将会加大，很可能会引起OOM异常。
2.如果设置了mapred.reduce.tasks/mapreduce.job.reduces参数，那么Hive会直接使用它的值作为Reduce的个数；3.如果mapred.reduce.tasks/mapreduce.job.reduces的值没有设置（也就是-1），那么Hive会根据输入文件的大小估算出Reduce的个数。
根据输入文件估算Reduce的个数可能未必很准确，因为Reduce的输入是Map的输出，而Map的输出可能会比输入要小，所以最准确的数根据Map的输出估算Reduce的个数。
列裁剪Hive 在读数据的时候，可以只读取查询中所需要用到的列，而忽略其它列。
例如，若有以下查询：SELECT a,b FROM q WHERE e<10;在实施此项查询中，Q 表有 5 列（a，b，c，d，e），Hive 只读取查询逻辑中真实需要的 3 列 a、b、e，而忽略列 c，d；这样做节省了读取开销，中间表存储开销和数据整合开销。
裁剪所对应的参数项为：hive.optimize.cp=true（默认值为真）补充：在我实习的操作过程中，也有用到这个道理，也就是多次join的时候，考虑到只需要的指标，而不是为了省事使用select * 作为子查询分区裁剪可以在查询的过程中减少不必要的分区。
例如，若有以下查询：SELECT* FROM(SELECTTa1,COUNT(1) FROM T GROUP BY a1)subq # 建议贴边写，这样容易检查是否是中文括号！WHERE subq.prtn=100; #（多余分区）SELECT* FROMT1 JOIN(SELECT*FROM T2)subq ON (T1.a1=subq.a2) WHERE subq.prtn=100;查询语句若将“subq.prtn=100”条件放入子查询中更为高效，可以减少读入的分区数目。
Hive 自动执行这种裁剪优化。
分区参数为：hive.optimize.pruner=true（默认值为真）补充：实际集群操作过程中，加分区是重中之重，不加分区的后果非常可能把整个队列资源占满，而导致io读写异常，无法登陆服务器及hive！切记切记分区操作和limit操作JOIN操作在编写带有 join 操作的代码语句时，应该将条目少的表/子查询放在 Join 操作符的左边。
因为在 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，载入条目较少的表可以有效减少 OOM（out of memory）即内存溢出。
所以对于同一个 key 来说，对应的 value 值小的放前，大的放后，这便是“小表放前”原则。
若一条语句中有多个 Join，依据 Join 的条件相同与否，有不同的处理方法。
JOIN原则在使用写有 Join 操作的查询语句时有一条原则：应该将条目少的表/子查询放在 Join 操作符的左边。
原因是在 Join 操作的Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生 OOM 错误的几率。
对于一条语句中有多个 Join 的情况，如果 Join 的条件相同，一句话就是小表在左边比如查询：INSERT OVERWRITE TABLE pv_users SELECTpv.pageid,u.age FROM page_view p JOIN user u ON (erid = erid) JOIN newuser x ON (erid = erid);∙如果Join 的key 相同，不管有多少个表，都会则会合并为一个Map-Reduce∙一个Map-Reduce 任务，而不是‘n’ 个∙在做OUTER JOIN 的时候也是一样如果 Join 的条件不相同，比如：INSERT OVERWRITE TABLE pv_users SELECTpv.pageid,u.age FROM page_view p JOIN user u ON (erid = erid) JOIN newuser x on (u.age = x.age);Map-Reduce 的任务数目和 Join 操作的数目是对应的，上述查询和以下查询是等价的：INSERT OVERWRITE TABLE tmptable SELECT* FROM page_view p JOIN user u ON (erid = erid);INSERT OVERWRITE TABLE pv_users SELECTx.pageid,x.age FROM tmptable x JOINnewuser y ON (x.age = y.age);MAP JOIN操作如果你有一张表非常非常小，而另一张关联的表非常非常大的时候，你可以使用mapjoin此Join 操作在 Map 阶段完成，不再需要Reduce，也就不需要经过Shuffle过程，从而能在一定程度上节省资源提高JOIN效率前提条件是需要的数据在 Map 的过程中可以访问到。