性能调优首先要发现问题，找到性能瓶颈点，然后根据瓶颈所处层级选择优化的方法。

调优分析思路如下：

对于服务端的问题，需要重点定位的硬件指标包括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日志

主要分为以下过程：
1. 分析SQL待处理的表及文件。统计待处理的表的文件数、数据量、条数、文件格式、压缩格式，分析是否有更适合的文件存储格式、压缩格式，是否能够使用分区或分桶，是否有大量小文件需要map前合并。如果有优化空间，则执行优化。
  1. 如何判断是否有更合适的文件存储格式。
    当前TPC-DS测试，使用的文件存储格式为orc，当前测试性能最优，推荐使用该存储格式。
  2. 如何判断是否有更合适的压缩格式。
    当前TPC-DS测试，在map/reduce阶段，使用的数据压缩格式为SNAPPY，当前测试性能最优，推荐使用该压缩格式。
  3. 如何判断是否能够使用分区或分桶。
    庞大的数据集可能需要耗费大量的时间去处理。在许多场景下，可以通过分区或切片的方法减少每一次扫描总数据量，这种做法可以显著地改善性能。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，不同于分区对列直接进行拆分，桶往往使用列的哈希值进行数据采样。
    
    在分区数量过于庞大以至于可能导致文件系统崩溃时，建议使用桶。
  4. 如何判断是否有大量小文件需要map前合并。
    查看每张表的下文件的大小，如果小文件（文件大小小于blocksize）很多，那么建议在map前将小文件进行合并，合并语句如下。
    1
    ALTER TABLE $table_name CONCATENATE.
2. 根据nmon抓取的数据分析性能瓶颈，根据CPU以及内存的使用情况，修改hive.tez.container.size等参数。

文件名	日志内容
hiveserver2.log	HiveServer运行日志
hiveserver2-gc-2019-12-30_22-27-02.log.0.current	HiveServer GC日志

调优思路