关于hive:分享一个-hive-on-spark-模式下使用-HikariCP-数据库连接池造成的资源泄露问题

最近在针对某零碎进行性能优化时，发现了一个 hive on spark 模式下应用 HikariCP 数据库连接池造成的资源泄露问题，该问题具备普适性，故顺便拿进去跟大家分享下。

1 问题形容

• 在微服务中，咱们广泛会应用各种数据库连接池技术以放慢获取数据库连贯并执行数据查问的速度，这实质是一种空间换工夫的无效的性能优化的思路。
• 推而广之，在大数据场景下通过 JDBC 拜访 HiveServer2 并提交数据查问 SQL 语句时，也很容易想到同样应用数据库连接池技术以放慢作业速度。
• 然而相比一般的 RDBMS，Hive 的 JDBC 连贯更重，以 HIVE ON SPARK 模式运行作业时更是如此，因为当连贯底层须要执行 SQL 时，HS2 会向 YARN 申请 CONTAINER 资源，而后启动分布式的 SPARK ON YARN 集群并分布式地执行编译好的 SQL，当该 SQL 执行结束后并不会立刻开释 SAPRK ON YANR 资源，而是会期待一段时间以复用这些 SPARK ON YARN 资源执行客户端通过该连贯提交的新的 SQL，只有当该 JDBC 连贯敞开时，或者达到了配置的超时工夫而客户端仍没有提交新的 SQL 时，才会彻底开释这些 SPARK ON YARN 资源。
• 当业务代码应用了数据库连接池技术时，因为其敞开 JDBC 连贯时实质上只是将连贯归还给了连接池而没有真是敞开底层的 JDBC 连贯，所以连贯背地的 SPARK ON YARN 资源并不会被及时开释也就是造成了资源泄露，此时其它作业向 YARN 申请资源时就须要排队期待，从而影响了其它作业的执行。
• 本案列中该零碎应用了 HikariCP 数据库连接池，且没有配置数据库连贯的闲暇超时时长（idletimeout)，真正失效的闲暇超时时长是 Hikari 源码层面配置的默认值 10 分钟，所以每个连贯底层的 SQL 作业执行结束后都须要 10 分钟才真正开释了背地的 SPARK ON YARN 资源，从而造成了其它作业对 YANR 资源的排队和期待。（话说你占着资源却不应用，不就是站着那个啥不干那个啥么~_~）

2 问题解决方案

针对该问题进行剖析，解决方案有多个，如下别离进行形容。

2.1 解决方案 1

该计划的思路是彻底摒弃数据库连接池，因为一般而言，大数据作业善于的是大数据量和简单逻辑的解决，其作业执行速大都在分钟级别以上，数据库连接池节俭的 1 到 2 秒钟简直微不足道，所以思考到这些应用上的弊病罗唆弃之不必。

2.2 解决方案 2

• 该计划的思路是配置 HS2 背地 SPARK ON YARN 集群的 SESSION 超时工夫，从而更快地开释 SPARK ON YARN 资源。
• 然而通过测试并查看源码发现该超时工夫的最小值是 30 分钟不能设置更小值，所以起不了成果。

• 相干参数有：

  • hive.spark.session.timeout: 默认值 30m 最小值 30m；
  • hive.spark.session.timeout.period: 默认值 60s 最小值 60s;

2.3 解决方案 3

• 该计划的思路是配置 Spark on yarn 的动静资源分配机制，从而使得 spark on yarn 集群在没有 SQL 作业须要执行时并不会占用太多 YARN 资源。
• 然而因为 SPARK 集群至多须要 1 个 CONTAINER 以执行 DRIVER，所以该计划只能缓解问题不能彻底解决问题。

• 相干参数有：

  • spark.dynamicAllocation.enabled, 须要配置为 true;
  • spark.dynamicAllocation.minExecutors: 默认为 1 能够进一步调整为 0；

2.4 解决方案 4

• 该计划的思路是配置客户端和 HS2 之间的 SESSION 超时工夫，从而让 HS2 被动断开客户端的 JDBC 连贯并开释背地的 Spark ON YARN 资源。
• 经测试该计划可行，但批改相干参数须要重启 hs2 服务过程且该参数的批改会影响所有用户作业，个别集群管理员可能会有异议；

• 相干参数有：

  • hive.server2.session.check.interval: 不同版本默认值不同，比方 15m/6h;
  • hive.server2.idle.session.timeout: 不同版本默认值不同，比方 4h/12h/7d;
  • hive.server2.idle.operation.timeout: 不同版本默认值不同，比方 2h/6h;
  • hive.server2.idle.session.check.operation：true

如下日志可见，session timeout 被敞开后，spark session 也别清理了：

2.5 解决方案 5

• 该计划的思路是调整数据库连接池的相干参数尤其是最小连接数和闲暇超时工夫，从而更快地更踊跃地被动敞开闲暇的数据库连贯，比方将 IdleTimeout 配置为 30 秒，将最小连接数 MinimumIdle 配置为 0，则 SQL 作业运行结束 30 秒后就会敞开所有连贯，也就会开释所有 SPARK ON YARN 资源，从而解决了资源泄露问题；

• 相干 hikariConfig 参数有：

  • MinimumIdle：最小连接数；
  • MaximumPoolSize：最大连接数；
  • IdleTimeout：闲暇超时工夫；
  • ConnectionTimeout：获取连贯超时工夫；
  • ValidationTimeout：连贯无效行验证超时工夫；
  • KeepaliveTime：闲暇连贯保活间隔时间；
  • MaxLifetime：连贯最大工夫；
• 示例代码如下：

3 知识点总结

• 大数据作业善于的是大数据量和简单逻辑的解决，其作业执行速大都在分钟级别以上，数据库连接池节俭的 1 到 2 秒钟简直微不足道，所以大数据作业个别不应用数据库连接池；
• 当应用数据库连接池时，因为相比一般的 RDBMS，Hive 的 JDBC 连贯更重，以 HIVE ON SPARK 模式运行作业时更是如此，所以肯定要及时开释 JDBC 连贯从而及时开释背地的 YARN 资源，从而防止资源泄露问题引起其它作业长时间期待 YARN 资源；
• 应用数据库连接池时，为及时开释 JDBC 连贯从而及时开释背地的 YARN 资源，个别能够调整数据库连接池的相干参数，尤其是最小连接数和闲暇超时工夫，从而更快地更踊跃地被动敞开闲暇的数据库连贯，比方将 IdleTimeout 配置为 30 秒，将最小连接数 MinimumIdle 配置为 0，则 SQL 作业运行结束 30 秒后就会敞开所有连贯，也就会开释所有 SPARK ON YARN 资源，从而解决了资源泄露问题。