Hive Tez reducers运行速度非常慢

Question

我连接了多个表，总行数约为250亿行。最重要的是，我正在做聚合。下面是我的配置单元设置，如下所示，我将使用这些设置来生成最终输出。我真的不确定如何调优查询并使其运行得更快。目前，我正在做试错，看看这是否能产生一些结果，但这似乎不是working.Mappers运行得更快，而是reducers需要永远完成。有没有人能分享你对此的看法？谢谢。

    SET hive.execution.engine=tez;
    SET hive.exec.dynamic.partition.mode=nonstrict;
    SET hive.qubole.cleanup.partial.data.on.failure=true;
    SET hive.tez.container.size=8192;
    SET tez.task.resource.memory.mb=8192;
    SET tez.task.resource.cpu.vcores=2;
    SET hive.mapred.mode=nonstrict;
    SET hive.qubole.dynpart.use.prefix=true;
    SET hive.vectorized.execution.enabled=true;
    SET hive.vectorized.execution.reduce.enabled =true;
    SET hive.cbo.enable=true;
    SET hive.compute.query.using.stats=true;
    SET hive.stats.fetch.column.stats=true;
    SET hive.stats.fetch.partition.stats=true;
    SET mapred.reduce.tasks = -1;
    SET hive.auto.convert.join.noconditionaltask.size=2730;
    SET hive.auto.convert.join=true;
    SET hive.auto.convert.join.noconditionaltask=true;
    SET hive.auto.convert.join.noconditionaltask.size=8053063680;
    SET hive.compute.query.using.stats=true;
    SET hive.stats.fetch.column.stats=true;
    SET hive.stats.fetch.partition.stats=true;
    SET mapreduce.job.reduce.slowstart.completedmaps=0.8;
    set hive.tez.auto.reducer.parallelism = true;
    set hive.exec.reducers.max=100;
    set hive.exec.reducers.bytes.per.reducer=1024000000;

SQL:

SELECT D.d
      ,D.b
      ,COUNT(DISTINCT A.x)  AS cnt
      ,SUM(c)               AS sum
 FROM A
LEFT JOIN
       B
ON A.a = B.b
LEFT JOIN
       C 
ON B.b = C.c
JOIN
       D
 ON A.a >= D.d
AND A.a <= D.d
GROUP BY 1,2
CLUSTER BY D.d;

Answer 1

还没有查询计划，所以可能还有其他东西，但这些设置肯定会限制reducers并行性：

set hive.exec.reducers.max=100;
set hive.exec.reducers.bytes.per.reducer=1024000000;

我建议增加允许的reducer的数量并减少每个reducer的字节数，这将增加reducer上的并行性：

set hive.exec.reducers.max=5000; 
set hive.exec.reducers.bytes.per.reducer=67108864;

此外，Hive 1.2.0+还提供自动重写optimization for count(distinct)。检查此设置，默认应为true：

hive.optimize.distinct.rewrite=true;

如果查询停留在最后一个reducer上，那么就有一个skew in join keys