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

Posted 2022-12-03 明哥的IT随笔

线上 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.）