Hive on Tez性能优化

升级到 CDP 后Hive on Tez 性能调整和故障排除指南

优化Hive on Tez查询永远不能以一种万能的方法来完成。查询的性能取决于数据的大小、文件类型、查询设计和查询模式。在性能测试期间，要评估和验证配置参数和任何 SQL 修改。建议在工作负载的性能测试期间一次进行一项更改，并且最好在生产环境中使用它们之前评估调整更改在您的开发和 QA 环境中的影响。Cloudera WXM可以帮助评估性能测试期间查询更改的好处。

1. 调优指南

在从 CDH 发行版到 CDP 私有云的多次迁移中观察到，与 MR 或 Spark 等较旧的执行引擎相比，Hive on Tez查询往往执行得更慢。这通常是由不同执行引擎之间的开箱即用的调整行为的差异引起的。此外，用户可能已经完成了对旧版分发的调整，这不会自动反映在 Hive on Tez转换中。对于从 HDP 发行版升级的用户，此讨论还有助于查看和验证是否正确配置了属性以实现 CDP 中的性能。

1.1. 确定问题步骤

以下步骤可帮助您确定可能会降低性能的重点领域。
第 1 步：核实和验证 YARN 容量调度器的配置。由于错误配置的队列配置（用户可用资源的任意上限）可能会影响查询性能。验证用户限制因子、最小用户限制百分比和最大容量。（请参阅YARN – 容量调度器博客以了解这些配置设置。）
第 2 步：查看 Hive on Tez和 Hive 的任何安全阀（Hive 和 HiveServer2 配置的非默认值）的相关性。删除任何遗留和过时的属性。
第 3 步：识别缓慢的区域，例如 map 任务、reduce 任务和Join。
1) 查看通用的 Tez 引擎和平台的可调整的属性。
2) 查看Map任务并调整-根据需要增加/减少任务计数。
3) 查看Reduce任务并调整-根据需要增加/减少任务计数。
4) 查看任何与并发相关的问题——这里有两种并发问题，如下所示：

• 队列内用户之间的并发。这可以使用 YARN 队列的用户限制因子进行调整（请参阅容量调度器博客中的详细信息）。

• Hive on Tez 会话的预热容器之间的并发性，如下文详细讨论。

  2. 了解 Tez 中的并行化

  在更改任何配置之前，您必须了解 Tez 内部工作的机制。例如，这包括了解 Tez 如何确定正确的Map和Reduce数量。查看 Tez 架构设计以及有关初始任务并行性和自动减少并行性如何工作的详细信息将帮助您优化查询性能。

  3. 了解Map的数量

  Tez 使用作业的初始输入数据来确定Map任务的数量。在 Tez 中，任务的数量由分组拆分决定，这相当于 map reduce 作业中由输入拆分确定的Map数量。

• tez.grouping.min-size和tez.grouping.max-size确定Map的数量。min-size的默认值为16 MB， max-size为 1 GB。
• Tez 确定任务的数量，以使每个任务的数据符合分组最大/最小大小。
• 减小tez.grouping.max-size会增加Map/Reduce的数量。
• 增加tez.grouping.max-size会减少任务的数量。

• 考虑以下示例：

  • 输入数据（输入分片/分割）– 1000 个文件（大约 1.5 MB 大小）
  • 总数据大小为 – 1000*1.5 MB = ~ 1.5 GB
  • Tez 可以尝试使用至少两个任务处理此数据，因为最大数据/任务可能是 1 G。最终，Tez 可以强制将 1000 个文件（拆分）合并为两个任务，从而导致执行时间变慢。

  • 如果tez.grouping.max-size从 1 GB 减少到 100 MB，则Map的数量可以增加到 15 个，从而提供更好的并行性。然后性能会提高，因为改进的并行性将工作从两个并发任务扩展到 15 个。
    以上是一个示例场景，但是在使用 ORC 或 parquet 等二进制文件格式的生产环境中，根据存储类型、拆分策略文件或 HDFS 块边界确定Map的数量可能会变得复杂。
    注意：更高程度的并行性（例如大量Map/Reduce）并不总是转化为更好的性能，因为它可能导致每个任务的资源更少，并且由于任务开销而导致更高的资源浪费。

    4. 了解Reduce的数量

    Tez 使用多种机制和设置来确定完成查询所需的 reducer 数量。

• Tez 根据要处理的数据（字节数）自动确定 reducer。
• 如果hive.tez.auto.reducer.parallelism设置为true，hive会估计数据大小并设置并行度估计。Tez 将对源顶点的输出大小进行采样，并根据需要在运行时调整估计值。
• 默认情况下，最大Reduce数量设置为 1009 ( hive.exec.reducers.max )
• Hive/Tez 使用以下公式估计 reducer 的数量，然后调度 Tez DAG：
  Max(1, Min(hive.exec.reducers.max [1009], ReducerStage 估计/hive.exec.reducers.bytes.per.reducer)) x hive.tez.max.partition.factor [2]
• 可以调整以下三个参数来增加或减少Map的数量：
• hive.exec.reducers.bytes.per.reducer
  每个 reducer 的大小。将其更改为较小的值以增加并行度，或将其更改为较大的值以降低并行度。默认值 = 256 MB [即如果输入大小为 1 GB，则将使用 4 个Reduce]
• tez.min.partition.factor 默认值 = 0.25
• tez.max.partition.factor 默认值 = 2.0
  增加更多Reduce。减少Reduce的数量。
• 用户可以使用mapred.reduce.tasks 手动设置 reducer 的数量。不建议这样做，您应该避免使用它。

• 建议：

  • 避免手动设置Reduce。
  • 添加更多Reduce并不总能保证更好的性能。

  • 如果要增加或减少 reducer 的数量，请根据 reduce 阶段的估计值将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 (HS2) 在启动时将在指定的default.queues内启动所有必要的 Tez会话以满足 session.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 定义的超时被终止。

• 情况一：未指定队列名称

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

• 情况二：指定队列名称

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

  并发指南/建议：

  • 对于不希望用户限制在同一个 Tez AM 池中的用例或查询，将此hive.server2.tez.initialize.default.sessions设置为 false。禁用此功能可以减少 HiveServer2 上的争用并提高查询性能。
  • 此外，增加会话数量hive.server2.tez.sessions.per.default.queue
  • 如果有需要为每组用户使用单独或专用的 Tez AM 池的用例，则需要有专用的 HiveServer2 服务，每个服务都有各自的默认队列名称和会话数，并要求每组用户使用他们各自的 HiveServer2。

  6. 容器重用和预热容器

• 容器重用：
  这是一种限制启动时间对容器的影响的优化。这是通过将tez.am.container.reuse.enabled设置为true来打开的。这节省了与 YARN 交互的时间。我还让容器组保持活力，更快地旋转容器，并跳过Yarn队列。

• 预热容器：
  容器的数量与默认情况下将附加到每个 Tez AM 的 YARN 执行容器的数量有关。每个 AM 将持有相同数量的容器，即使 Tez AM 空闲（不执行查询）也是如此。
  如果有太多容器处于空闲状态且未释放，则会出现这种情况，因为此处定义的容器将由 Tez AM 持有，即使它处于空闲状态。这些空闲容器将继续占用 YARN 中其他应用程序可能使用的资源。
  以下属性用于配置 Prewarm Containers：

  • hive.prewarm.enabled
  • hive.prewarm.numcontainers

  7. 通用的 Tez 调整参数

  在处理 Tez 查询上 Hive 的性能下降时，请查看下面列出的属性作为第一级检查。您可能需要根据您的查询和数据属性设置或调整其中一些属性。最好在开发和 QA 环境中评估配置属性，然后根据结果将其推送到生产环境。

• hive.cbo.enable
  将此属性设置为 true可启用基于成本的优化 (CBO)。CBO 是 Hive 查询处理引擎的一部分。它由 Apache Calcite 提供支持。CBO 通过检查查询中指定的表和条件来生成高效的查询计划，最终减少查询执行时间并提高资源利用率。
• hive.auto.convert.join
  将此属性设置为 true 允许 Hive 启用关于根据输入文件大小将 common join 转换为 mapjoin 的优化。
• hive.auto.convert.join.noconditionaltask.size
  您将希望在查询中执行尽可能多的 mapjoin。这种大小配置使用户能够控制什么大小的表可以适合内存。该值表示可以转换为适合内存的哈希图的表大小的总和。建议将其设置为hive.tez.container.size 大小的 ⅓。
• tez.runtime.io.sort.mb
  输出排序时排序缓冲区的大小。建议将其设置为hive.tez.container.size的40%， 最大为 2 GB。它很少需要超过这个最大值。
• tez.runtime.unordered.output.buffer.size-mb
  这是输出不需要排序时的内存。如果不直接写入磁盘，则它是要使用的缓冲区大小。建议将其设置为hive.tez.container.size的10% 。
• hive.exec.parallel
  此属性启用 Hive 查询阶段的并行执行。默认情况下，此设置为 false。将此属性设置为 true 有助于并行化独立查询阶段，从而提高整体性能。
• hive.vectorized.execution.enabled
  矢量化查询执行是 Hive 的一项功能，可大大降低扫描、过滤器、聚合和连接等典型查询操作的 CPU 使用率。默认情况下，这设置为 false。将此设置为true。
• hive.merge.tezfiles
  默认情况下，此属性设置为 false。将此属性设置为 true 将合并 Tez 文件。使用此属性可能会增加或减少查询的执行时间，具体取决于数据的大小或要合并的文件数。在使用此属性之前，请评估您在较低环境中的查询性能。
• hive.merge.size.per.task
  此属性描述作业结束时合并文件的大小。

• hive.merge.smallfiles.avgsize
  当作业的平均输出文件大小小于此数字时，Hive 将启动额外的 map-reduce 作业以将输出文件合并为更大的文件。默认情况下，此属性设置为 16 MB。

  8. 总结

  此博客介绍了有关 CDP 的 Hive on Tez 查询的一些基本故障排除和调整指南。作为查询性能分析的第一步，您应该验证并验证在 Hive 和 Hive on Tez 服务上设置的所有配置。所做的每一项更改都应进行测试，以确保其做出可衡量且有益的改进。查询调优是一项专门的工作，并非所有查询都可以通过更改 Tez 配置属性来更好地执行。您可能会遇到需要深入研究 SQL 查询以优化和提高执行和性能的场景。如果您需要有关性能调整工作的更多帮助，请联系您的 Cloudera 帐户和专业服务团队以提供指导。
  原文作者：Jay Desai
  原文链接：https://blog.cloudera.com/optimizing-hive-on-tez-performance/

关注微信公共号了解更多信息：

本文由mdnice多平台发布