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

4次阅读

共计 3592 个字符，预计需要花费 9 分钟才能阅读完成。

大家好，在此分享一个某业务零碎的线上 hive on spark 作业在高并发下频现作业失败问题的起因剖析和解决办法，心愿对大家有所帮忙。

某业务零碎中，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 指定；

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 秒；

解决办法能够从三个角度来考量：

缩小资源需要：能够在调度零碎中缩小作业并发度，也能够在作业级别缩小单个作业的资源需要；
减少资源供应：能够减少相应 YARN 队列的资源，必要时也能够对 YARN 集群进行扩容；
调整超时参数，减少超时工夫，以冀望在期待过程中能取得（其余作业开释的）资源，从而胜利执行作业；

缩小资源需要，能够在调度零碎中减小作业并发度，即缩小同时提交的 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 等异样，所以还是须要依据作业的数据量和业务逻辑，在作业级别针对具体作业给出不同的资源参数）；

减少资源供应，能够减少作业执行时应用的 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

启动 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.）

正文完