0


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

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

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

1 问题现象

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

SQL
failed tocreate 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.)
标签: hive spark hadoop

本文转载自: https://blog.csdn.net/MichaelLi916/article/details/127744154
版权归原作者 明哥的IT随笔 所有, 如有侵权,请联系我们删除。

“线上 hive on spark 作业执行超时问题排查案例分享”的评论:

还没有评论