调优思路
性能调优首先要发现问题，找到性能瓶颈点，然后根据瓶颈所处层级选择优化的方法。
调优分析思路如下：
- 对于服务端的问题，需要重点定位的硬件指标包括CPU、内存、硬盘、BIOS配置，利用监测得到的数据进行性能分析，查看性能瓶颈点。
- 对于网络问题，网卡中断绑核对于性能提升增益可观。
- 具体而言，在Hive优化时，主要是两方面影响了性能，一个是查询计划，一个是Tez的任务执行。
Hive调优需要看HiveServer的运行日志及GC日志。
HiveServer日志路径为：HiveServer节点的“/var/log/hive”。
文件名
日志内容
hiveserver2.log
HiveServer运行日志
hiveserver2-gc-2019-12-30_22-27-02.log.0.current
HiveServer GC日志
主要分为以下过程：
- 分析SQL待处理的表及文件。统计待处理的表的文件数、数据量、条数、文件格式、压缩格式，分析是否有更适合的文件存储格式、压缩格式，是否能够使用分区或分桶，是否有大量小文件需要map前合并。如果有优化空间，则执行优化。
- 如何判断是否有更合适的文件存储格式。
- 如何判断是否有更合适的压缩格式。
当前TPC-DS测试，在map/reduce阶段，使用的数据压缩格式为SNAPPY，当前测试性能最优，推荐使用该压缩格式。
- 如何判断是否能够使用分区或分桶。
庞大的数据集可能需要耗费大量的时间去处理。在许多场景下，可以通过分区或切片的方法减少每一次扫描总数据量，这种做法可以显著地改善性能。Hive的分区使用HDFS的子目录功能实现。每一个子目录包含了分区对应的列名和每一列的值。但是由于HDFS并不支持大量的子目录，这也给分区的使用带来了限制。我们有必要对表中的分区数量进行预估，从而避免因为分区数量过大带来一系列问题。Hive查询通常使用分区的列作为查询条件。这样的做法可以指定MapReduce任务在HDFS中指定的子目录下完成扫描的工作。HDFS的文件目录结构可以像索引一样高效利用。
如：
1 2 3 4 5
CREATE TABLE logs( timestamp BIGINT, line STRING ) PARTITIONED BY (date STRING,country STRING);
PARTITONED BY子句中定义的列是表中正式的列（分区列），但是数据文件内并不包含这些列。
Hive还可以把表或分区，组织成桶。将表或分区组织成桶有以下几个目的：
第一个目的是为看取样更高效，因为在处理大规模的数据集时，在开发、测试阶段将所有的数据全部处理一遍可能不太现实，这时取样就必不可少。
第二个目的是为了获得更好的查询处理效率。
桶为表提供了额外的结构，Hive在处理某些查询时利用这个结构，能够有效地提高查询效率。
桶是通过对指定列进行哈希计算来实现的，通过哈希值将一个列名下的数据切分为一组桶，并使每个桶对应于该列名下的一个存储文件。
在建立桶之前，需要设置hive.enforce.bucketing属性为true，使得Hive能识别桶。
以下为创建带有桶的表的语句：
1 2 3 4 5
CREATE TABLE bucketed_user( id INT, name String ) CLUSTERED BY (id) INTO 4 BUCKETS;
分区中的数据可以被进一步拆分成桶，bucket，不同于分区对列直接进行拆分，桶往往使用列的哈希值进行数据采样。
在分区数量过于庞大以至于可能导致文件系统崩溃时，建议使用桶。
- 如何判断是否有大量小文件需要map前合并。
查看每张表的下文件的大小，如果小文件（文件大小小于blocksize）很多，那么建议在map前将小文件进行合并，合并语句如下。
1ALTER TABLE $table_name CONCATENATE.
- 根据nmon抓取的数据分析性能瓶颈，根据CPU以及内存的使用情况，修改hive.tez.container.size等参数。
- 分析SQL待处理的表及文件。统计待处理的表的文件数、数据量、条数、文件格式、压缩格式，分析是否有更适合的文件存储格式、压缩格式，是否能够使用分区或分桶，是否有大量小文件需要map前合并。如果有优化空间，则执行优化。