hive on spark僵死问题分析

Posted 2023-03-17

参考技术A 背景：

最近大数据平台为租户经分系统提供运算及存储能力，经分的资源需求如下

Memory:  6T

CPU:     1600 c

存储：   600T

文件系统：HDFS

运算组件: hive on spark

权限管理：sentry

问题描述：

       为经分系统分配完租户在运行SPARK作业的时候，会重现任力僵死的情况，后台hiveserver2登录，一直卡在登录命令行，查看hive日志发现过多的GC 等待

  通过jstat  查看FGC记录（ 注，这是更改后的图，更改前的GC图未保存，当时FGC 一分钟达到200多次,E,O区一直在100% ）。

再通过jmap 查看下heap信息（此图也是更改后的图，当时原图未保留，原MaxHeapSize=512M）。

通过以上分析可以定们到JVM的堆信息太小，但当时部署时更改了hive-env.sh中的JVM信息了

但我们通过jmap查看只分到了512M内存，问题在哪儿呢。

通过jinfo看下加载的命令信息。

看到加载了xmx=512M,但为何是512M呢，经分析，是hive做为hadoop的客户端加载hadoop的配置文件，hadoop-env.sh,如下图

[

在hivesiver2加载的时候会先加载hive-env.sh再加载hadoop-env.sh 的客户端参数HADOOP_CLIENT_OPTS，即然我们知道是加载的HADOOP_CLIENT_OPTS参数。我们只要更改hive-env.sh

增加如下配置。

重启hiveserver2可以看到hiveserver2的heap大小已变为8192M,前台作业及hive

on spark作业正常（经15天的运行再未出出僵死的情况。）

线上 hive on spark 作业执行超时问题排查案例分享

线上 hive on spark 作业执行超时问题排查案例分享

大家好，在此分享一个某业务系统的线上 hive on spark 作业在高并发下频现作业失败问题的原因分析和解决方法，希望对大家有所帮助。

1 问题现象

某业务系统中，HIVE SQL 以 hive on spark 模式运行在 yarn上指定的资源队列下，在业务高峰期发现部分 SQL 会报错，但重试有时又能够成功。作业具体报错信息，和示例截图如下：

SQL
failed to create spark client for spark session xx: java.util.concurrent.TimeoutException: client xx timed out waiting for connection from the remote spark driver

备注：

• hive 作业的执行引擎通过参数 hive.execution.engine 指定，可选值为 mr/spark/tez；
• CDP/HIVE3.0等新版本不再支持 hive on mr/spark, 只支持 hive on tez;
• HIVE 作业在 YARN 上的队列使用参数mapreduce.job.queuename/mapred.job.queue.name 指定；

2 问题原因

HIVE ON SPARK 作业在高并发下运行失败报超时错误，但是重试有时又能够成功，绝大多数都是因为 yarn 中对应的资源队列上没有足够的资源以启动 spark集群，所以客户端连无可连报了超时错误。

具体的超时时间，有两个相关参数进行控制：

• hive.spark.client.server.connect.timeout：该参数是服务端配置，用来控制 hive 客户端跟远程 spark 集群中的 spark driver 建立连接的超时时间，默认90秒（这里的 hive客户端是启动 spark 集群的客户端，个人认为其实就是 hs2);
• hive.spark.client.connect.timeout： 该参数是客户端配置，用来控制远程 spark 集群中的 spark driver 跟 hive 客户端建立连接的时间，默认1秒；

3 解决方法

解决方法可以从三个角度来考量：

• 减少资源需求：可以在调度系统中减少作业并发度，也可以在作业级别减少单个作业的资源需求；
• 增加资源供给：可以增加相应YARN队列的资源，必要时也可以对YARN集群进行扩容；
• 调整超时参数，增加超时时间，以期望在等待过程中能获得（其他作业释放的）资源，从而成功执行作业；

3.1 减少资源需求

• 减少资源需求，可以在调度系统中减小作业并发度，即减少同时提交的 HIVE SQL 作业的个数，相应地整个业务系统整体的资源需求也就降低了；（当然整个作业流程的运行时长可能会增大);
• 减少资源需求，也可以减少单个作业的资源需求,主要是spark 集群的 driver/executor 的 cores/memory 和 executor 的个数，以及动态资源分配的相关参数，如参数 spark.executor.cores/spark.executor.memory/spark.executor.instances/spark.driver.memory/spark.driver.cores，以及 spark.dynamicAllocation.enabled/spark.dynamicAllocation.minExecutors/spark.dynamicAllocation.maxExecutors 等。（需要注意的是，如果 executor 的 memory 调得太小，大作业可能会发生 oom 等异常，所以还是需要根据作业的数据量和业务逻辑，在作业级别针对具体作业给出不同的资源参数）；

3.2 增加资源供给

• 增加资源供给，可以增加作业执行时使用的YARN队列的资源，该操作一般需要集群管理员在服务端进行配置；
• 在整个大数据集群资源不够时，也可以通过增加节点等方式对 YARN 集群进行扩容，该操作一般也是由集群管理员进行的操作；
• 需要注意的是，调整 相应 YARN 队列的资源时，具体的资源调度器可能对资源还有进一步的限制，比如容量调度器对于正在运行的应用程序的最大数量，对于所有 Application Master 消耗的最大资源，都有限制；
• 容量调度器对于所有 application master 消耗的最大资源有限制，当大于该限制时，即使 YARN 集群还有资源，新提交的作业也无法获得资源启动 application master,当然也就不能运行了，一个这种情况下yarn webui中相关作业的截图如下： (capacity scheduler 之所以对 am 占用资源的百分比进行限制，是为了避免出现整个集群中由于 am 消耗了绝大部分的 yarn资源，yarn 无法再分配新的资源给 mapper/reducer 等进行具体任务的处理)；
  
• 在容量调度器下，具体的资源管控参数，有以下这些：

##作业并行度相关参数
yarn.scheduler.capacity.maximum-applications/yarn.scheduler.capacity.<queue-path>.maximum-applications
yarn.scheduler.capacity.max-parallel-apps/yarn.scheduler.capacity.<queue-path>.max-parallel-apps
yarn.scheduler.capacity.user.max-parallel-apps/yarn.scheduler.capacity.user.<username>.max-parallel-apps

##资源相关参数
yarn.scheduler.capacity.<queue-path>.capacity/yarn.scheduler.capacity.<queue-path>.maximum-capacity
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb/yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores
yarn.scheduler.capacity.<queue-path>.user-limit-factor
## am 资源相关参数
yarn.scheduler.capacity.maximum-am-resource-percent/yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent

3.3 调整超时参数

启动 spark 集群时，具体的超时时间，有两个相关参数进行控制：

• hive.spark.client.server.connect.timeout：该参数是服务端配置，用来控制 hive 客户端跟远程 spark 集群中的 spark driver 建立连接的超时时间，默认90秒（这里的 hive客户端是启动 spark 集群的客户端，个人认为其实就是 hs2);
• hive.spark.client.connect.timeout： 该参数是客户端配置，用来控制远程 spark 集群中的 spark driver 跟 hive 客户端建立连接的时间，默认1秒；
• 需要注意的是，hive.spark.client.server.connect.timeout 是服务端参数，所以需要在服务端更改配置并重启服务端（hs2)后才能生效，单纯在客户端修改该参数，虽然修改时不会报错但修改并不会生效，比如下图客户端修改该参数为100 秒后，实际使用的仍是修改前默认的90秒：
  

注意：

• 有的集群中，默认情况下不允许对上述两个超时参数进行调整：

• 为了调整上述两个超时参数，需要在服务端更改黑名单和白名单相关参数: hive.conf.restricted.list/hive.security.authorization.sqlstd.confwhitelist/hive.security.authorization.sqlstd.confwhitelist.append；
• 配置白名单时，推荐使用参数 hive.security.authorization.sqlstd.confwhitelist.append，该参数配置的内容会追加到参数 hive.security.authorization.sqlstd.confwhitelist 配置的内容之后；
• 黑名单参数 hive.conf.restricted.list 也需要配置，因为即使通过了白名单的校验，也仍会对黑名单进行校验；（Note that the hive.conf.restricted.list checks are still enforced after the white list check.）