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

本文涉及的产品
大数据开发治理平台 DataWorks,不限时长
实时数仓Hologres,5000CU*H 100GB 3个月
实时计算 Flink 版,5000CU*H 3个月
简介: 在Tez上优化Hive查询,包括配置参数调整、理解并行化机制以及容器管理。关键步骤包括YARN调度器配置、安全阀设置、识别性能瓶颈(如mapper/reducer任务和连接操作),理解Tez如何动态调整mapper和reducer数量。例如,`tez.grouping.max-size` 影响mapper数量,`hive.exec.reducers.bytes.per.reducer` 控制reducer数量。调整并发和容器复用参数如`hive.server2.tez.sessions.per.default.queue` 和 `tez.am.container.reuse.enabled`

在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查询的指南

相关文章
|
1月前
|
SQL 存储 分布式计算
Hive数据仓库设计与优化策略:面试经验与必备知识点解析
本文深入探讨了Hive数据仓库设计原则(分区、分桶、存储格式选择)与优化策略(SQL优化、内置优化器、统计信息、配置参数调整),并分享了面试经验及常见问题,如Hive与RDBMS的区别、实际项目应用和与其他组件的集成。通过代码样例,帮助读者掌握Hive核心技术,为面试做好充分准备。
|
1月前
|
SQL 分布式计算 资源调度
Hive 优化总结
Hive优化主要涉及HDFS和MapReduce的使用。问题包括数据倾斜、操作过多和不当使用。识别倾斜可通过检查分区文件大小或执行聚合抽样。解决方案包括整体优化模型设计,如星型、雪花模型,合理分区和分桶,以及压缩。内存管理需调整mapred和yarn参数。倾斜数据处理通过选择均衡连接键、使用map join和combiner。控制Mapper和Reducer数量以避免小文件和资源浪费。减少数据规模可调整存储格式和压缩,动态或静态分区管理,以及优化CBO和执行引擎设置。其他策略包括JVM重用、本地化运算和LLAP缓存。
35 4
Hive 优化总结
|
1月前
|
SQL 存储 大数据
Hive的查询、数据加载和交换、聚合、排序、优化
Hive的查询、数据加载和交换、聚合、排序、优化
49 2
|
1月前
|
SQL 分布式计算 资源调度
一文看懂 Hive 优化大全(参数配置、语法优化)
以下是对提供的内容的摘要,总长度为240个字符: 在Hadoop集群中,服务器环境包括3台机器,分别运行不同的服务,如NodeManager、DataNode、NameNode等。集群组件版本包括jdk 1.8、mysql 5.7、hadoop 3.1.3和hive 3.1.2。文章讨论了YARN的配置优化,如`yarn.nodemanager.resource.memory-mb`、`yarn.nodemanager.vmem-check-enabled`和`hive.map.aggr`等参数,以及Map-Side聚合优化、Map Join和Bucket Map Join。
|
1月前
|
SQL 存储 分布式计算
【Hive】Hive优化有哪些?
【4月更文挑战第16天】【Hive】Hive优化有哪些?
|
1月前
|
SQL 分布式计算 Hadoop
Hive SQL 优化
Hive SQL 优化
66 1
|
1月前
|
SQL 数据采集 数据挖掘
大数据行业应用之Hive数据分析航班线路相关的各项指标
大数据行业应用之Hive数据分析航班线路相关的各项指标
132 1
|
1月前
|
SQL 存储 大数据
【大数据技术Hadoop+Spark】Hive基础SQL语法DDL、DML、DQL讲解及演示(附SQL语句)
【大数据技术Hadoop+Spark】Hive基础SQL语法DDL、DML、DQL讲解及演示(附SQL语句)
123 0
|
1月前
|
SQL 分布式计算 数据库
【大数据技术Spark】Spark SQL操作Dataframe、读写MySQL、Hive数据库实战(附源码)
【大数据技术Spark】Spark SQL操作Dataframe、读写MySQL、Hive数据库实战(附源码)
143 0
|
1月前
|
SQL 存储 分布式计算
【大数据技术Hadoop+Spark】Hive数据仓库架构、优缺点、数据模型介绍(图文解释 超详细)
【大数据技术Hadoop+Spark】Hive数据仓库架构、优缺点、数据模型介绍(图文解释 超详细)
506 0