关于机器学习: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 多平台公布