优化Hive on Tez查询永远不能以一种万能的方法来完成。查询的性能取决于数据的大小、文件类型、查询设计和查询模式。在性能测试期间,要评估和验证配置参数和任何 SQL 修改。建议在工作负载的性能测试期间一次进行一项更改,并且最好在生产环境中使用它们之前评估调整更改在您的开发和 QA 环境中的影响。Cloudera WXM可以帮助评估性能测试期间查询更改的好处。
下面先介绍常见的调优组合。
Try using TEZ execution engine and then hive.merge.tezfiles. You might also want to specify the size as well.
set hive.execution.engine=tez; -- TEZ execution engine
set hive.merge.tezfiles=true; -- Notifying that merge step is required
set hive.merge.smallfiles.avgsize=128000000; --128MB
set hive.merge.size.per.task=128000000; -- 128MB 最好是HDFS BLOCK 大小的整数倍
set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
set hive.exec.max.dynamic.partitions=3000;
set hive.exec.max.dynamic.partitions.pernode=500;
sethive.tez.container.size=6656; -- container大小,一直跑不出来
set hive.tez.java.opts=-Xmx5120m; --java heap space内存溢出
set hive.merge.tezfiles=true;
set hive.merge.smallfiles.avgsize=128000000;--128M
set hive.merge.size.per.task=128000000;--128M
set hive.execution.engine=tez;
set tez.am.task.max.failed.attempts=10; -- 重试失败,资源竞争激烈
set tez.am.max.app.attemps=5; -- 重试失败,资源竞争激烈如果map阶段划分过多,可以设置为合并小文件格式化org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
hive.tez.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat
hive.tez.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
#对于非分区表
alter table tablename concatenate;
#对于分区表
alter table tablename partition(dt=20201224) concatenate;
insert overwrite table tableName partition(dt=2022031100)
select column1,column2 from tableName
where dt = 2022031100
# 只支持 RCFILE 和 ORC 文件类型,需要执行多次,才能把文件合并为1个
# impala里面 set num_nodes=1; 可以强行合并程1个
# 参考
Hive 命令
hive.merge.mapredfiles=true;
hive.merge.mapfiles=true
hive.merge.rcfile.block.level=true
hive.merge.size.per.task=256000000
hive.merge.smallfiles.avgsize=16000000spark 命令 :
hive.merge.sparkfiles=true
开始干货,相关调优指南~
在从 CDH 发行版到 CDP 私有云的多次迁移中观察到,与 MR 或 Spark 等较旧的执行引擎相比,Hive on Tez查询往往执行得更慢。这通常是由不同执行引擎之间的开箱即用的调整行为的差异引起的。此外,用户可能已经完成了对旧版分发的调整,这不会自动反映在 Hive on Tez转换中。对于从 HDP 发行版升级的用户,此讨论还有助于查看和验证是否正确配置了属性以实现 CDP 中的性能。
以下步骤可帮助您确定可能会降低性能的重点领域。
第 1 步:核实和验证 YARN 容量调度器的配置。由于错误配置的队列配置(用户可用资源的任意上限)可能会影响查询性能。验证用户限制因子、最小用户限制百分比和最大容量。(请参阅YARN – 容量调度器博客以了解这些配置设置。)
第 2 步:查看 Hive on Tez和 Hive 的任何安全阀(Hive 和 HiveServer2 配置的非默认值)的相关性。删除任何遗留和过时的属性。
第 3 步:识别缓慢的区域,例如 map 任务、reduce 任务和Join。
在更改任何配置之前,您必须了解 Tez 内部工作的机制。例如,这包括了解 Tez 如何确定正确的Map和Reduce数量。查看 Tez 架构设计以及有关初始任务并行性和自动减少并行性如何工作的详细信息将帮助您优化查询性能。
Tez 使用作业的初始输入数据来确定Map任务的数量。在 Tez 中,任务的数量由分组拆分决定,这相当于 map reduce 作业中由输入拆分确定的Map数量。
以上是一个示例场景,但是在使用 ORC 或 parquet 等二进制文件格式的生产环境中,根据存储类型、拆分策略文件或 HDFS 块边界确定Map的数量可能会变得复杂。 注意:更高程度的并行性(例如大量Map/Reduce)并不总是转化为更好的性能,因为它可能导致每个任务的资源更少,并且由于任务开销而导致更高的资源浪费。
Tez 使用多种机制和设置来确定完成查询所需的 reducer 数量。
可以调整以下三个参数来增加或减少Map的数量:
用户可以使用mapred.reduce.tasks 手动设置 reducer 的数量。
不建议这样做,您应该避免使用它。
建议:
本部分旨在帮助理解和调整 Hive on Tez 的并发会话,例如运行多个 Tez AM【AppMaster】 容器。以下属性有助于理解默认队列和会话数行为。
(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。
容器重用:
这是一种限制启动时间对容器的影响的优化。这是通过将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
在处理 Tez 查询上 Hive 的性能下降时,请查看下面列出的属性作为第一级检查。您可能需要根据您的查询和数据属性设置或调整其中一些属性。最好在开发和 QA 环境中评估配置属性,然后根据结果将其推送到生产环境。
此博客介绍了有关 CDP 的 Hive on Tez 查询的一些基本故障排除和调整指南。作为查询性能分析的第一步,您应该验证并验证在 Hive 和 Hive on Tez 服务上设置的所有配置。所做的每一项更改都应进行测试,以确保其做出可衡量且有益的改进。查询调优是一项专门的工作,并非所有查询都可以通过更改 Tez 配置属性来更好地执行。您可能会遇到需要深入研究 SQL 查询以优化和提高执行和性能的场景。如果您需要有关性能调整工作的更多帮助,请联系您的 Cloudera 帐户和专业服务团队以提供指导。
原文作者:Jay Desai 原文链接:https://blog.cloudera.com/optimizing-hive-on-tez-performance/
下一篇:计算机入门基础知识大全