正文

二.hive问题排查及调优思路(代码片段)

白日梦想东  白日梦想东  2023-03-28  329

关键词：

1.使用explain查看HiveSQL的执行计划

2.学习大数据分布式计算的基本原理

其实不仅仅是MapReduce在数据处理时将所有的数据简化成业务无关的键-值对模式，大部分的大数据数计算引擎在底层实现上也是如此，如Spark、Tez和Storm。在进行数据处理时先将计算发往数据所在的节点，将数据以键-值对作为输入，在本地处理后再以键-值对的形式发往远端的节点，这个过程通用叫法为Shuffle，远端的节点将接收的数据组织成键-值对的形式作为输入，处理后的数据，最终也以键-值对的形式输出。

3.学习使用YARN提供的日志

想要知道HiveSQL所有阶段的运行信息，可以查看日志。查看日志的链接，可以在每个作业执行后，在控制台打印的信息中找到。

4.干预SQL的运行方式

4.1．通过改写SQL实现对计算引擎执行过程的干预
4.2. 通过SQL-Hint语法实现对计算引擎执行过程的干预
4.3．通过数据库开放的一些配置开关，来实现对计算引擎的干预

5.调优须知：

调优讲究适时调优，过早进行调优有可能做的是无用功甚至产生负效应，在调优上投入的工作成本和回报不成正比。调优需要遵循一定的原则。

6.代码优化原则：

理透需求原则，这是优化的根本；
把握数据全链路原则，这是优化的脉络；
坚持代码的简洁原则，这让优化更加简单；
没有瓶颈时谈论优化，是自寻烦恼。

7.Hive程序相关规范

一份拥有良好代码风格的程序，有助于开发者发现性能问题，缩短调优的时间，降低维护成本，同时也能促进程序员的自我提高。
规范分为3类：开发规范、设计规范和命名规范。

7.1．开发规范

单条SQL长度不宜超过一屏。 ·SQL子查询嵌套不宜超过3层。
少用或者不用Hint，特别是在Hive
2.0后，增强HiveSQL对于成本调优（CBO）的支持，在业务环境变化时可能会导致Hive无法选用最优的执行计划。
避免SQL代码的复制、粘贴。如果有多处逻辑一致的代码，可以将执行结果存储到临时表中。
尽可能使用SQL自带的高级命令做操作。例如，在多维统计分析中使用cube、grouping
set和rollup等命令去替代多个SQL子句的union all。
使用set命令，进行配置属性的更改，要有注释。
代码里面不允许包含对表/分区/列的DDL语句，除了新增和删除分区。
HiveSQL更加适合处理多条数据组合的数据集，不适合处理单条数据，且单条数据之间存在顺序依赖等逻辑关系。例如，有A、B、C 3行数据，当A符合某种条件才能处理B行时，只有A、B符合某种条件，才能处理C行。
保持一个查询语句所处理的表类型单一。例如，一个SQL语句中的表都是ORC类型的表，或者都是Parquet表。
关注NULL值的数据处理。
SQL表连接的条件列和查询的过滤列最好要有分区列和分桶列。
存在多层嵌套，内层嵌套表的过滤条件不要写到外层，例如：

select a.* from a
left join b
on a.id=b.id
where a.no=1

应当写为：

select a.* from (
select * from a where a.no=1
) a left join b
on a.id=b.id

7.2．设计规范

表结构要有注释。
列等属性字段需要有注释。
尽量不要使用索引。在传统关系型数据库中，通过索引可以快速获取少部分数据，这个阀值一般是10%以内。但在Hive的运用场景中，经常需要批量处理大量数据，且Hive索引在表和分区有数据更新时不会自动维护，需要手动触发，使用不便。如果查询的字段不在索引中，则会导致整个作业效率更加低下。索引在Hive 3.0后被废弃，使用物化视图或者数据存储采用 ORC格式可以替代索引的功能。
创建内部表（托管表）不允许指定数据存储路径，一般由集群的管理人员统一规划一个目录并固化在配置中，使用人员只需要使用默认的路径即可。创建非接口表，只允许使用Orc或者Parquet，同一个库内只运行使用一
种数据存储格式。接口表指代与其他系统进行交互的数据表，例如从其他系
统导入Hive时暂时存储的表，或者数据计算完成后提供给其他系统使用的输
出表。
Hive适合处理宽边（列数多的表），适当的冗余有助于Hive的处理性能。
表的文件块大小要与HDFS的数据块大小大致相等。
分区表分桶表的使用。

7.3．命名规范

库/表/字段命名要自成一套体系：

·表以tb_开头。
·临时表以tmp_开头。
·视图以v_开头。
·自定义函数以udf_卡头。
·原始数据所在的库以db_org_开头，明细数据所在库以db_detail_开头，数据仓库以db_dw_开头。

3　总结调优的一般性过程
首先，要明白所有的优化是相对的，例如程序运行需要2个小时，看似
很慢，但如果需求的目标是3个小时，即可正常作业，无特别情况，可以不
进行优化。
优化的基本流程如下：

第一，选择性能评估项及各自目标，常见的评估性能指标有程序的时延和吞吐量；
第二，如果系统是由多个组件和服务构成，需要分组件和服务定义性能目标；
第三，明确当前环境下各个组件的性能；
第四，分析定位性能瓶颈；
第五，优化产生性能瓶颈的程序或者系统；
第六，性能监控和告警。
上面的流程是优化的基本流程，前面三点可以结合各自的实际应用场
景，结合运维意见及业务的要求自行设定，本书焦点在后面三点。

分析定位性能瓶颈：在Hive中最常见的是磁盘和网络I/O的瓶颈，其次是内存会成为一个性能瓶颈。CPU一般比I/O资源相对富余。为什么是前面三点最有可能出现瓶颈？要解释这个问题，需要了解Hive执行计划，以及计算引擎的基本原理，并借助作业监控工具优化产生性能瓶颈的程序或者系统。

在Hive中，优化方式可以归结为3点，即优化存储、优化执行过程和优化作业的调度。·性能监控和告警：建立性能监控和告警，在操作系统和硬件层面可以借助Linux或UNIX系统提供的系统工具，也可以借助一些开源的工具，例如Zabbix和Ganglia；可以记录服务器运行时的历史过程，也可以定制化监控很多细粒度指标。软件层面，大数据组件可以借助cloudera或者Ambari监控工具，或者借助开源工具Prometheus和Grafana定制监控大数据组件。作业层面借助YARN Timeline提供的查看作业信息的服务信息进行监控。虽然本书的焦点在后面三点，但需要强调一点，对当前服务或者组件所在的环境有一个良好的认知，对业务有一定的理解是优化的前提。
为了强调这一点，我们引入下面的说明。
有这样一个案例，在同步数据的讨论会议上，业务方说有些数据库表每日都有数据更新，怎么同步更新的数据？程序员A认为目前数据日志解析工具可以捕捉数据更新。程序员B认为还有一个比较简单的方法，可以用支持事务机制的表，只是这些表使用起来有特殊限制，需要升级系统环境。资历较老的程序员会问到每日更新的数据有多少，表数据总共有多少，这些数据从开始同步到最后的数据使用，可以支持多久的等待时间。业务方说数据每日更新增量1万以内，最大的表数据量不超过10万，整体数据量不到100MB，这些数据从同步到使用允许24小时的等待时间。程序员C认为简单数据量总量不多，可以全量同步，不会对现有的系统造成太大的压力，也不会对同步作业造成多大压力，如果不需要历史数据，可以每日覆盖对应的表，如果需要历史数据，就采用表分区的方式，按日分区，每个分区同步当日所有的数据。比较3个程序员的方案，程序员A需要引入更多的同步组件，且解析工具的部署维护是一个问题，在数据库的日志格式变更后，同步又是一个问题，并且耗时长，后期维护难度较高。程序员B需要对生产环境的软件进行升级，需要评估软件是否对现有生产环境有影响，稳定情况如何。而程序员C解了业务的整体情况后，采用的就是一般的方式——全量同步。在业务要求范围内也能快速完成业务需求。很显然，程序员C的方案对程序员A和程序员B的方案来说都是一个极大的优化，而且从源头尽可能地掐断了因一个小需求引入众多操作所带来的性能问题。

tidb查询优化及调优系列慢查询诊断监控及排查(代码片段)

...除了上一章节介绍的通过EXPLAIN语句来查看诊断查询计划问题外，本章节主要会介绍通过TiDBSlowQuery慢查询内存表，以及TiDBDashboard的可视化Statements功能来监控和诊断慢查询。下载TiDB社区版咨询TiDB企业版免费试用TiDBCloud适... 查看详情

day701.jvmgc原理及调优的基本思路-深入拆解tomcat&jetty(代码片段)

JVMGC原理及调优的基本思路Hi，我是阿昌，今天学习记录学习是关于JVMGC原理及调优的基本思路。和Web应用程序一样，Tomcat作为一个Java程序也跑在JVM中，因此如果我们要对Tomcat进行调优，需要先了解JVM调优的原... 查看详情

jvmgc原理及调优的基本思路(代码片段)

若观察到Tomcat进程CPU使用率较高，并在GC日志中发现GC次数比较频繁、GC停顿时间长，说明需优化GC。CMS和G1是时下使用率比较高的两款垃圾收集器，从Java9开始，G1是默认垃圾收集器。CMSvsG1CMS收集器将Java堆分为新生... 查看详情

web网站性能测试分析及调优实例(代码片段)

...主要包括了如何使用性能测试的压测工具，压测前的性能问题评估，以及压测执行后的性能问题分析、瓶颈定位。&em 查看详情

es集群部署及调优(代码片段)

系统：Centos6ES版本：6.4.0服务器三台172.16.0.8172.16.0.6172.16.0.22部署jdk解压jdk放在/data目录，/data/jdk配置环境变量，/etc/proifle里面加入如下exportJAVA_HOME=/data/jdkexportPATH=$PATH:$JAVA_HOME/binexportCLASSPATH=.:$JAVA_HOME/lib/t 查看详情

jvm参数及调优(代码片段)

JVM控制参数服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小参数含义说明-XX:InitialHeapSize=100M初始化堆大小简写-Xms100M-XX:MaxHeapSize=100M最大堆大小，默认是物理内存的1/4简写-Xmx100M-XX:NewSize=20... 查看详情

elasticsearch分布式安装及调优(代码片段)

三台ubuntuServer的ip:192.168.0.4，192.168.0.5，192.168.0.6从官网下载elasticsearch版本2.2.1解压到/opt/目录下sudotar-zxvfelasticsearch-2.2.1.tar.gz-C/opt对ip为192.168.0.4的主机进入/opt/elasticsearch-2.2.1/config/并查看详情

性能测试常见瓶颈分析及调优方法(代码片段)

在性能测试过程中，最重要的一部分就是性能瓶颈定位与调优。而引发性能瓶颈的原因是多种多样的，在之前的博客：常见的性能测试缺陷有进行介绍。这篇博客，来聊聊性能测试过程中的一些注意事项，以及常见的一些性能缺... 查看详情

大数据之hive：hive调优全方位指南(代码片段)

目录一、HiveSQL语法二、Hive性能优化三、Hive性能优化之数据倾斜专题四、HiveSQL优化十二板斧五、Hive面试题(一)六、Hive/Hadoop高频面试点集合(二)本文基本涵盖以下内容：一、HiveSQL语法hive的DDL语法对数据库的操作创建数据库:cr... 查看详情

tidb查询优化及调优系列tidb查询计划简介(代码片段)

「TiDB查询优化及调优」系列文章将通过一些具体的案例，向大家介绍TiDB查询及优化相关的原理和应用，在上一篇文章中我们简要介绍了TiDB查询优化器的优化流程。查询计划（executionplan）展现了数据库执行SQL语句... 查看详情

zabbix监控模板修改及调优（不完整版）(代码片段)

简介监控一直在不同的层面为我们的运维工作发挥着重要的作用：网络层监控，及时发现网络间的访问质量（如我们之前介绍的全国maps网络监控）；服务器监控，了解服务器各项性能参数（如常见的zabbix、cacti、nagios、ganglia等... 查看详情

day704.tomcat内存溢出的原因分析及调优-深入拆解tomcat&jetty(代码片段)

Tomcat内存溢出的原因分析及调优Hi，我是阿昌。今天学习记录的是关于Tomcat内存溢出的原因分析及调优。作为Java程序员，我们几乎都会碰到java.lang.OutOfMemoryError异常，但是你知道有哪些原因可能导致JVM抛出OutOfMemoryError... 查看详情

typesdk服务端设计思路与架构之六：性能及调优初步

经过本系列前几篇文字的分析和设计，我们成功地开发出了自己的SDK服务端。在我们自己的调试环境下运行一切正常，但是当然我们不能就这样把这套SDK服务端部署上线到正式生产环境，稍有正式大型项目经验的同学应该都知道... 查看详情

hive提交到yarn的任务一直在running问题排查-v2(代码片段)

文章目录一、问题描述二、HiveServer中的SparkSession启动和关闭时机SparkSession的启动时机SparkSession的关闭时机三、问题分析四、解决方案第一套方案（不推荐）第二套方案（推荐）一、问题描述具体表现和Hive提交到ya... 查看详情

hive提交到yarn的任务一直在running问题排查-v2(代码片段)

day801.内存问题排查方案-java性能调优实战(代码片段)

内存问题排查方案Hi，我是阿昌，今天学习记录的是关于内存问题排查方案。碰到内存持续上升的情况，其实很难从业务日志中查看到具体的问题，那么面对多个进程以及大量业务线程，该如何精准地找到背后... 查看详情

大数据线上问题排查系列-hive踩坑记(代码片段)

大数据线上问题排查系列-HIVE踩坑记前言大家好，我是明哥！本片博文是“大数据线上问题排查系列”大类别之一，讲述前段时间我司某产品在某券商遇到的一个问题及解决方案，其背后涉及到hive的一个BUG,在hive3.... 查看详情