【大数据之Hive】二十四、HQL语法优化之任务并行度

1 优化说明

  Hive的计算任务由MapReduce完成，并行度调整分为Map端和Reduce端。

1.1 Map端并行度

  Map端的并行度及Map的个数，由输入文件的切片数决定，一般情况下Map端并行度不需要手动调整。
  在特殊情况下（查询的表中存在大量小文件、map端有复杂的查询逻辑）可以考虑手动调整。
1、查询的表中存在大量小文件
  Hadoop默认切片策略，一个小文件会单独启动一个map task负责计算。如果查询表中存在大量小文件，会启动大量map task，造成资源浪费。
解决：
  使用HIve提供的CombineHiveInputFormat，把多个小文件合并为一个切片，控制map task个数。
相关参数：

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

2、map端有复杂的查询逻辑
  当SQL语句中有正则替换、json解析等复杂耗时的查询逻辑时，map端的计算会相对慢一些。
解决：
  在计算资源充足的情况下，可考虑增大map端的并行度，令map task多一些，每个map task计算的数据少一些。
相关参数：

--一个切片的最大值
set mapreduce.input.fileinputformat.split.maxsize=256000000;

1.2 Reduce端并行度

  Reduce端的并行度即Reduce个数可由用户自己决定，也可由Hive自行根据MR Job输入的文件大小估算。
相关参数：

--指定Reduce端并行度，默认值为-1，表示用户未指定
set mapreduce.job.reduces;

--Reduce端并行度最大值
set hive.exec.reducers.max;

--单个Reduce Task计算的数据量，用于估算Reduce并行度
set hive.exec.reducers.bytes.per.reducer;

Reduce端并行度的确定逻辑如下：
  若指定参数mapreduce.job.reduces的值为一个非负整数，则Reduce并行度为指定值。否则，Hive自行估算Reduce并行度，估算逻辑如下：
  （1）假设Job输入的文件大小为totalInputBytes；
  （2）参数hive.exec.reducers.bytes.per.reducer的值为bytesPerReducer；
  （3）参数hive.exec.reducers.max的值为maxReducers；
  则Reduce端的并行度为：

  Hive自行估算Reduce并行度时，是以整个MR Job输入的文件大小作为依据的。因此，在某些情况下其估计的并行度很可能并不准确，此时就需要用户根据实际情况来指定Reduce并行度了。

2 案例

1、示例SQL语句

select
    province_id,
    count(*)
fromorder_detail
groupby province_id;

2、优化前
在不指定Reduce并行度时，Hive自行估算并行度的逻辑如下：

totalInputBytes=1136009934
bytesPerReducer=256000000
maxReducers=1009

Reduce并行度为:

3、优化思路
  在默认情况下，是会进行map-side聚合的，也就是Reduce端接收的数据，实际上是map端完成聚合之后的结果。
  观察yarn中任务的执行过程，会发现，每个map端输出的数据只有34条记录，共有5个map task。也就是说Reduce端实际只会接收170（34*5）条记录，故理论上Reduce端并行度设置为1就足够了。这种情况下，用户可通过以下参数，自行设置Reduce端并行度为1。

--指定Reduce端并行度，默认值为-1，表示用户未指定
set mapreduce.job.reduces=1;