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