Hive怎么调整优化Tez引擎的查询?在Tez上优化Hive查询的指南

hive,tez · 浏览次数 : 0

小编点评

本文主要介绍了在Tez框架上优化Hive查询的指南和调优技巧。文章首先概述了优化Hive查询的一般步骤,包括验证YARN容量调度器配置、识别缓慢区域、审查Tez引擎和平台的通用调优属性等。接着,文章详细讨论了如何理解Tez中的并行化、mapper和reducer数量的设定,以及如何调整这些参数以提高性能。最后,文章提供了并发管理的指南和建议,包括如何配置队列名称、预热容器和容器复用等。 1. **优化步骤**: - 验证YARN容量调度器配置 - 识别缓慢区域 - 审查Tez引擎和平台的通用调优属性 - 审查mapper任务和reducer任务 - 审查并发相关问题 2. **Tez中的并行化**: - 了解Tez如何确定正确的mapper和reducer数量 - 审查Tez架构设计 - 理解mapper数量和reducer数量的设定方法 3. **mapper和reducer数量的设定**: - tez.grouping.min-size 和 tez.grouping.max-size - hive.tez.auto.reducer.parallelism - hive.exec.reducers.bytes.per.reducer - tez.min.partition.factor - tez.max.partition.factor - mapred.reduce.tasks 4. **并发管理**: - hive.server2.tez.default.queues - hive.server2.tez.sessions.per.default.queue - hive.server2.tez.initialize.default.sessions - 容器复用和预热 - 并发会话的管理 总的来说,优化Hive查询的性能需要综合考虑多个因素,包括数据的特性、查询的设计以及系统配置。通过上述指南和技巧,用户可以更好地理解和调整Tez引擎,从而提高Hive查询的性能。

正文

在Tez上优化Hive查询的指南

在Tez上优化Hive查询无法采用一刀切的方法。查询性能取决于数据的大小、文件类型、查询设计和查询模式。在性能测试过程中,应评估和验证配置参数及任何SQL修改。建议在工作负载的性能测试过程中一次只进行一项更改,并最好在开发环境中评估调优更改的影响,然后再在生产环境中使用。

这里分享一些关于Tez上Hive查询的基本故障排除和调优指南。

调优指南

不同的hive版本,不同执行引擎之间的调优行为有所差异,所以同一条sql可能会有不一样的速度。

一般情况下,我们可以通过以下步骤有助于识别可能导致性能下降的地方。

  1. 验证和确认YARN容量调度器配置

队列配置错误可能会由于对用户可用资源的任意限制而影响查询性能。验证用户限制因子、最小用户限制百分比和最大容量。

  1. 检查Hive和HiveServer2配置中的任何安全阀(非默认值)是否相关

移除任何遗留的和过时的属性。

  1. 识别缓慢的区域,例如mapper任务、reducer任务和连接操作
  • 审查Tez引擎和平台的通用调优属性。
  • 审查mapper任务并根据需要增加/减少任务数。
  • 审查reducer任务并根据需要增加/减少任务数。
  • 审查任何并发相关的问题——并发问题分为两种,如下所述:
    • 队列内用户间的并发。这可以通过调整YARN队列的用户限制因子进行调优(详细信息参考容量调度器博客)。
    • Hive on Tez会话的预热容器之间的并发,详见下文。

理解Tez中的并行化

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

理解mapper数量

Tez使用作业的初始输入数据确定mapper任务的数量。在Tez中,任务数量由分组拆分决定,这相当于MapReduce作业中输入拆分确定的mapper数量。

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

例如:

  • 输入数据(输入碎片/拆分) – 1000个文件(约1.5 MB大小)
  • 总数据量约为 – 1000*1.5 MB = ~1.5 GB
  • Tez可能尝试使用至少两个任务处理这些数据,因为每个任务的最大数据量可能为1 GB。最终,Tez可能强制将1000个文件(拆分)组合到两个任务中,导致执行时间变慢。
  • 如果将 tez.grouping.max-size 从1 GB减少到100 MB,mapper数量可能增加到15,从而提供更好的并行性。性能因此提高,因为改进的并行性将工作分散到15个并发任务中。

以上是一个示例场景,然而在生产环境中使用ORC或Parquet等二进制文件格式时,根据存储类型、拆分策略文件或HDFS块边界确定mapper数量可能会变得复杂。

注意:更高程度的并行性(如mapper/reducer数量多)并不总是意味着更好的性能,因为它可能导致每个任务的资源减少以及由于任务开销而导致的资源浪费。

理解reducer数量

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

  • Tez根据要处理的数据(字节数)自动确定reducer。
  • 如果 hive.tez.auto.reducer.parallelism 设置为true,Hive会估算数据大小并设置并行性估算值。Tez将在运行时采样源顶点的输出大小并根据需要调整估算值。
  • 默认情况下,最大reducer数量设置为1009(hive.exec.reducers.max)。
  • Hive/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]

以下三个参数可以调整以增加或减少mapper数量:

  • hive.exec.reducers.bytes.per.reducer:每个reducer的大小。更改为较小值以增加并行性,或更改为较大值以减少并行性。默认值为256 MB(即如果输入大小为1 GB,则使用4个reducer)。
  • tez.min.partition.factor:默认值为0.25。
  • tez.max.partition.factor:默认值为2.0。增加以增加reducer数量,减少以减少reducer数量。

用户可以使用 mapred.reduce.tasks 手动设置reducer数量。这不推荐使用,应避免使用。

建议:

  • 避免手动设置reducer数量。
  • 增加reducer数量并不总是能保证更好的性能。
  • 根据reducer阶段估算,如果要增加或减少reducer数量,可以调整 hive.exec.reducers.bytes.per.reducer 参数到较小或较大值。

并发

我们需要理解和调整Tez上的Hive并发会话,如运行多个Tez AM容器。以下属性有助于理解默认队列和会话数量行为。

  • hive.server2.tez.default.queues:与YARN队列对应的以逗号分隔的值列表,用于维护Tez会话池。
  • hive.server2.tez.sessions.per.default.queue:每个YARN队列中保持在池中的Tez会话(DAGAppMaster)数量。
  • hive.server2.tez.initialize.default.sessions:如果启用,HiveServer2(HS2)在启动时将启动所有必要的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(queue1两个,queue2两个)。

注意:池中的Tez会话总是运行,即使在空闲集群上。

如果HiveServer2连续使用,这些Tez AM将继续运行,但如果HS2空闲,这些Tez AM将根据 tez.session.am.dag.submit.timeout.secs 定义的超时被终止。

案例1:未指定队列名称

如果查询未指定队列名称(tez.queue.name),则只会使用池中的Tez AM(如上所述初始化)。在这种情况下,HiveServer2将选择一个空闲/可用的Tez AM(队列名称可能是随机选择的)。如果未指定队列名称,则查询将保持在HiveServer2中的挂起状态,直到池中有一个可用的默认Tez AM来处理查询。在JDBC/ODBC客户端或HiveServer2日志文件中不会有任何消息。由于没有消息生成,当查询挂起时,用户可能会认为JDBC/ODBC连接或HiveServer2已断开,但实际上它在等待一个Tez AM执行查询。

案例2:指定队列名称

如果查询指定了队列名称,无论有多少初始化的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。

容器复用和预热容器

容器复用

这是一个优化,可以减少容器的启动时间影响。通过设置 tez.am.container.reuse.enabled 为true来启用此功能。这节省了与YARN交互的时间。还可以保持容器组活跃,快速旋转容器,并跳过YARN队列。

预热容器

容器数量与将附加到每个Tez AM的YARN执行容器数量相关。即使Tez AM空闲(未执行查询),每个AM也会保留相同数量的容器。在某些情况下,这可能会导致太多容器空闲且未释放,因为这里定义的容器将被Tez AM保留,即使它是空闲的。这些空闲容器将继续占用YARN中的资源,其他应用程序可能会利用这些资源。

以下属性用于配置预热容器:

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

一般Tez调优参数

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

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

  • hive.auto.convert.join
    将此属性设置为true允许Hive根据输入文件大小启用将常见连接转换为mapjoin的优化。

  • hive.auto.convert.join.noconditionaltask.size
    您将希望在查询中尽可能多地执行mapjoin。此大小配置使用户可以控制表的大小以适应内存。该值表示可以转换为适合内存的哈希表的表的大小总和。建议将其设置为 hive.tez.container.size 的1/3。

  • 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。

文章来源:Hive怎么调整优化Tez引擎的查询?在Tez上优化Hive查询的指南

与Hive怎么调整优化Tez引擎的查询?在Tez上优化Hive查询的指南相似的内容:

Hive怎么调整优化Tez引擎的查询?在Tez上优化Hive查询的指南

在Tez上优化Hive查询无法采用一刀切的方法。查询性能取决于数据的大小、文件类型、查询设计和查询模式。在性能测试过程中,应评估和验证配置参数及任何SQL修改。建议在工作负载的性能测试过程中一次只进行一项更改,并最好在开发环境中评估调优更改的影响,然后再在生产环境中使用。

Hive 和 Spark 分区策略剖析

随着技术的不断的发展,大数据领域对于海量数据的存储和处理的技术框架越来越多。在离线数据处理生态系统最具代表性的分布式处理引擎当属Hive和Spark,它们在分区策略方面有着一些相似之处,但也存在一些不同之处。

MySQL到TiDB:Hive Metastore横向扩展之路

本文介绍了vivo在大数据元数据服务横向扩展道路上的探索历程,由实际面临的问题出发,对当前主流的横向扩展方案进行了调研及对比测试,通过多方面对比数据择优选择TiDB方案。其次分享了整个扩展方案流程、实施遇到的问题及解决方案,对于在大数据元数据性能上面临同样困境的开发者本篇文章具有非常高的参考借鉴价值...

[转帖]【技术剖析】12. 毕昇 JDK 8 中 AppCDS 实现介绍

https://bbs.huaweicloud.com/forum/thread-169622-1-1.html 作者:伍家华 > 编者按:笔者通过在 Hive 的场景发现 AppCDS 技术存在的价值,然后分析了 AppCDS 的工作原理,并将 JDK 11 中的特性移植到毕昇 JDK 8,在移植

DataArts Studio实践丨通过Rest Client 接口读取RESTful接口数据的能力

本文POST接口典型场景为例,为您示例如何使用Rest Client,从RESTful地址中读取数据并同步到hive表中。

[转帖]datax安装+配置+使用文档

1 DataX离线同步工具DataX3.0介绍 DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS

在Apache Hudi数据湖上实现近乎实时的数据分析

介绍 在数据处理领域,数据分析师在数据湖上运行其即席查询。数据湖充当分析和生产环境之间的接口,可防止下游查询影响上游数据引入管道。为了确保数据湖中的数据处理效率,选择合适的存储格式至关重要。 Vanilla数据湖解决方案构建在具有 Hive 元存储的云对象存储之上,其中数据文件以 Parquet 格

云小课|MRS基础原理之Hue组件介绍

阅识风云是华为云信息大咖,擅长将复杂信息多元化呈现,其出品的一张图(云图说)、深入浅出的博文(云小课)或短视频(云视厅)总有一款能让您快速上手华为云。更多精彩内容请单击此处。 摘要:Hue是一组WEB应用,用于和MRS大数据组件进行交互,能够帮助用户浏览HDFS,进行Hive查询,启动MapRedu