0924-Hive on Tez性能调优

调优Hive on Tez查询没有一个通用的方法，查询的性能取决于数据的大小、文件类型、查询设计和查询模式。在做性能测试的时候，我们一般是通过调整配置参数或改写SQL来进行性能调优，建议在做测试的时候每次只进行一项更改，这样方便确认是哪个参数生效。

1 通用调优

有时从CDH升级到CDP后，会发现Hive on Tez作业会比老的MR或者Spark要慢，这往往是因为没有对Tez作业进行调优导致的，另外在老的CDH平台中，因为一般都持续稳定运行一段时间了，对老的MR作业或多或少调优了一些参数，但是这些参数又不能直接在Tez作业中生效，所以会让你觉得CDP新的Hive比CDH中老的Hive性能还不如。以下是可能引起性能下降的主要三方面：

1.确认YARN Capacity Scheduler配置，如果在queue中错误配置了用户可用资源的上限会影响到查询性能。所以需要重点关注user-limit factor, min-user-limit percent和maximum capacity。

2.检查 Hive 和 Hive on Tez 的safety valves（Hive 和 HiveServer2 配置的非默认值）， 删除所有旧的或者过期的配置。

3.辨别是哪里慢，比如map tasks，reduce tasks和join。

• • 检查Tez引擎的通用配置
• • 检查map任务的数量，增加或减少
• • 检查reduce任务的数量，增加或减少
• • 检查并发问题：
  • • 检查队列内用户的并发，比如YARN队列内的user limit factor
  • • Hive on Tez session的跨预热container的并发

2 学习Tez基础知识

在更改任何配置之前，我们必须了解 Tez 内部工作原理，比如Tez 如何确定map和reduce的数量。以下有几篇文章帮助了解和学习：

https://cwiki.apache.org/confluence/display/TEZ/How+initial+task+parallelism+works
https://cwiki.apache.org/confluence/display/TEZ/How+does+ShuffleVertexManager+%28Auto+Reduce+Parallelism%29+work

3 mapper数量

Tez 使用作业的初始输入数据确定mapper任务的数量。 在 Tez 中，任务的数量由grouping split 决定，相当于 MapReduce 作业中由input split 决定mapper数量。

1.tez.grouping.min-size 和 tez.grouping.max-size 确定mapper的数量，min-size 的默认值为 16 MB，max-size 的默认值为 1 GB。

2.Tez在确认mapper任务数量后，同时确保每个任务的数据与grouping max/min size一致，减少 tez.grouping.max-size 会增加mapper任务的数量，增加 tez.grouping.max-size 会减少任务数量。

3.举例如下：

• • 输入数据（input shards/splits） - 1000个文件，每个文件约1.5MB
• • 总数据大小为 – 1000*1.5 MB = ~ 1.5 GB
• • Tez会尝试使用两个任务来处理这些数据，因为每个任务的最大数据为1GB，这样Tez会将1000个输入文件合并到两个任务中，从而导致执行时间变慢。
• • 如果将tez.grouping.max-size 从 1 GB 减少到 100 MB，则mapper的数量可以增加到 15 个，从而提高并发并提高性能。

以上是一个简单的举例，生产环境中往往使用的是ORC或者Parquet格式文件，最终确定mapper的数量还会根据存储类型，split策略文件以及HDFS block边界。

注意：大量mapper或者reducer对应的高并发不一定代表更好的性能，因为它可能导致每个任务的资源更少，并且由于过多的任务开销而导致资源浪费。

4 reducer数量

Tez使用多种机制来确认reducer数量：

1.Tez根据要处理的数据量自动计算出reducer数量；

2.如果 hive.tez.auto.reducer.parallelism 设置为 true，hive 会预估数据大小并设置预估的并行度，Tez会对source vertice的输出大小进行采样，并根据需要在运行时调整预估。

3.默认情况下，最大的reduce数量为1009（hive.exec.reducers.max）

4.Hive on Tez使用以下公式估计Reducer 的数量，然后调度Tez DAG：

Max(1, Min(hive.exec.reducers.max [1009], ReducerStage estimate/hive.exec.reducers.bytes.per.reducer))  x  hive.tez.max.partition.factor [2]

5.可以调整以下三个参数来增加或减少reduce的数量：

• • hive.exec.reducers.bytes.per.reducer：每个reducer的size，缩小可以增加并行度，增加可以减少并行度，默认值为256MB，即如果input size是1GB，则会使用4个reducer。
• • tez.min.partition.factor，默认值为0.25
• • tez.max.partition.factor，默认值为2.0，增加则会更多reduce，减少则更少reduce

6.可以使用mapred.reduce.tasks手动设置reducer的数量，但不建议这样做。

建议：

• • 避免手动设置reducer
• • 添加更多reducer并不保证更好的性能。
• • 如果要增加或减少reducer的数量，可以根据reduce阶段的estimate，调低或调高hive.exec.reducers.bytes.per.reducer的值。

5 并发

本章介绍如何调整Hive on Tez会话的并发，例如运行多个Tez AM容器，可以调整以下属性：

• • hive.server2.tez.default.queues：逗号分隔值列表，对应要维护Tez会话池的YARN队列；
• • hive.server2.tez.sessions.per.default.queue：每个 YARN 队列在池中维护的 Tez 会话 (DAGAppMaster) 数量。
• • hive.server2.tez.initialize.default.sessions：如果启用，HiveServer2 在启动时将在指定的 default.queues 中启动所有必需的 Tez 会话，以满足sessions.per.default.queue 要求。

如果定义了上面列出的属性时，HiveServer2 将为每个默认队列创建一个 Tez Application Master (AM)，乘以 HiveServer2 服务启动时的会话数，因此：

(Tez Sessions)total = HiveServer2instances x (default.queues) x (sessions.per.default.queue)

举例：

• • hive.server2.tez.default.queues=”queue1,queue2”
• • hive.server2.tez.sessions.per.default.queue=2

Hiveserver2 将创建 4 个 Tez AM（2 个用于queue1，2 个用于queue2）。

注意：池化 Tez 会话会一直运行，即使在空闲集群上也是如此。如果HiveServer2一直在被使用，这些 Tez AM 将一直运行，但如果HS2 空闲，Tez AM会在tez.session.am.dag.submit.timeout.secs 定义的超时时间满足时被终止。

Case 1：未指定队列名称

• • 如果未指定队列名称 (tez.queue.name)，查询将仅使用池中之前初始化的Tez AM，在这种情况下，HiveServer2 将选择空闲的或者可用Tez AM，随机选择队列。
• • 如果未指定队列名称，则查询将在 HiveServer2 中保持待处理（pending）状态，直到初始化池中的默认 Tez AM 之一可以为查询提供服务。JDBC/ODBC 客户端或 HiveServer2 日志文件中不会有任何消息，由于查询挂起时不会生成任何消息，用户可能会认为 JDBC/ODBC 连接或 HiveServer2 有问题，但其实是它正在等待 Tez AM 执行查询。

Case 2：指定队列名称

• • 如果指定了队列名称，则无论有多少个初始化的 Tez AM 正在使用或空闲，HiveServer2 都会为此连接创建一个新的 Tez AM，并且可以执行查询，前提是队列有可用资源。

建议：

• • 如果不希望将用户查询限制在同一个 Tez AM 池，可以将hive.server2.tez.initialize.default.sessions 设置为 false，这样可以减少HiveServer2上的争用并提高查询性能。
• • 调大hive.server2.tez.sessions.per.default.queue以增加session数量。
• • 如果需要为每组用户提供单独或专有Tez AM 池，则需要专有的HiveServer2服务，每个服务都有各自的default queue name和session数，并要求每组用户使用各自的HiveServer2。

6 容器重用和预热容器

• • Container reuse：可以将tez.am.container.reuse.enabled 设置为 true以解决容器每次启动都要耗时的问题，节省了与YARN交互的时间，这样容器一直保持在线，并跳过了YARN queue。
• • Prewarm containers：指每个Tez AM绑定的YARN执行容器的默认数量，即使 Tez AM 空闲（不执行查询），每个 AM 也将持有相同数量的容器。因为此处定义的容器即使在闲置时也会由 Tez AM 持有，如果有太多容器闲置且未释放，则会导致资源浪费。由以下两个属性控制：
  • • hive.prewarm.enabled
  • • hive.prewarm.numcontainers

7 通用Tez调优参数

在处理Hive on Tez查询性能问题时，可以优先检查以下参数：

1.hive.cbo.enable

设置为true则启用基于成本的优化 (CBO)，CBO 是 Hive 查询处理引擎的一部分，由Apache Calcite 提供支持。CBO 通过检查查询中指定的表和条件来生成高效的查询计划，最终减少查询执行时间并提高资源利用率。

2.hive.auto.convert.join

设置为 true 允许 Hive 启用根据输入文件大小将join 转换为 mapjoin 的优化。

3.hive.auto.convert.join.noconditionaltask.size

希望在查询中执行尽可能多的mapjoin，用户通过设置该大小控制内存中可以容纳的表大小，这个值表示表转换为hashmap存到内存中的总大小，建议将其设置为 hive.tez.container.size 大小的 ⅓。

4.tez.runtime.io.sort.mb

输出排序时sort buffer的大小，建议将此值设置为 hive.tez.container.size 的 40%，最大为 2 GB，一般不会高于此值。

5.tez.runtime.unordered.output.buffer.size-mb

输出不需要排序时的内存，如果不直接写入磁盘，它会使用的缓冲区的大小。 建议将其设置为 hive.tez.container.size 的 10%。

6.hive.exec.parallel

此属性支持 Hive query stage的并行执行，默认为false，设置为 true 有助于并行独立的查询stage，从而提高整体性能。

7.hive.vectorized.execution.enabled

向量化查询执行可大大降低scan、filter、aggregate和join等典型查询操作的 CPU 使用率。 默认为false，可以考虑设置为true。

8.hive.merge.tezfiles

默认为 false，设置为 true 将合并 Tez 文件。该属性可能会增加或减少查询的执行时间，具体取决于数据大小或要合并的文件数量。

9.hive.merge.size.per.task

指作业结束时合并文件的大小。

10.hive.merge.smallfiles.avgsize

当作业的平均输出文件大小小于此数字时，Hive会启动额外的 MapReduce 作业将输出文件合并为更大的文件，该值默认为为16MB。

8 总结

Hive on Tez查询性能分析的第一步是检查Hive 和 Hive on Tez 服务的一些关键配置，然后对于一些SQL查询作业一般需要set一些参数来进行特定的性能调优，大部分参数在本文都列出来了，可以用作参考。对于一些复杂SQL的调优，或者运行故障往往还需要对SQL的写法进行调整。

原文参考：

https://blog.cloudera.com/optimizing-hive-on-tez-performance/