深入剖析 HIVE 的锁和事务机制

深入剖析 HIVE 的锁和事务机制

1 从调度系统对 HIVE 作业的调度策略聊起

大家知道，依托 HIVE 构建数据仓库时，我们一般会通过调度系统精心编排 HIVE SQL 作业，以避免多个作业并发写同一张表或同一个表分区；同时 AD HOC 的数据查询操作，在时间上一般也会尽量避开常规的 ETL 数据写操作，以避免对同一张表或同一个表分区的并发读写操作。

调度系统之所以对 HIVE SQL 作业采取上述调度策略，究其原因，是因为多作业并发读写同一个表或同一个表分区时，底层会因为 HIVE 的锁机制导致大量锁竞争和等待，此时作业运行效率极低，所以业务应用只能通过调度系统规避掉对同一张表或表分区的并发读写。

2. 一个因为调度系统配置不当导致的 HIVE 作业运行效率低下的线上例子

笔者最近排查的某证券客户的线上应用运行效率低下的原因，就是上述 HIVE SQL 作业调度策略不当，在此跟大家分享下。

• 问题现象：在进行 HIVE 作业的性能分析时，从 HIVE ON SPARK 作业的 SPARK WEB UI 上，我们观察到，某个 SQL 作业对应的一系列 SPARK 任务执行完毕后，大部分 EXECUTORs 都被动态释放归还给了 YARN，但是后续过了七八分钟又动态地申请了新的一批 EXECUTORS，以执行后续的 SQL 作业，这是不正常的，因为虽然我们开启了 SPARK ON YARN 的动态资源分配机制，但是前后两个 SQL 作业是在同一个 SESSION 会话中顺序提交的，理想状况下，SPARK EXECUTORS 不应该动态释放又重新申请，除非前后两个 SQL 的提交/执行间隔时长，大于参数 spark.dynamicAllocation.executorIdleTimeout 的值（该参数默认值 60s）
• 问题原因：经过排查应用日志和YARN 日志，发现前后两个 SQL 确实是顺序提交的,其提交间隔并没有大于60s，同时 YARN 集群中对应的资源队列，当时也是有充足的资源的；进一步排查 HIVESERVER2 日志，发现 HS2 虽然在上一个 SQL 执行完毕后，及时收到了客户端提交的新的 SQL 并成功完成了解析和编译，但真正生成 SPARK 任务并提交执行，却是在七八分钟之后！正是由于这七八分钟的时间间隔，触发了SPARK ON YARN 动态资源分配机制下的 executor 的动态释放和申请；
• 问题根本原因：仔细分析 HS2 中详细的日志，结合业务方编写的 HIVE SQL 业务代码，发现上述 SQL 的解析和对应 SPARK 作业的执行之间的七八分钟的时间间隔，正是由于 HIVE 表分区的锁竞争引起的: 业务方编写了多个 HIVE SQL 作业，这些 SQL 作业通过 insert into 插入到了同一张表的同一个分区，在配置调度系统时，这些 HIVE SQL 作业被配置在了不同的流程中并被并发地调度执行，所以此时这些被并发调度的多个 HIVE SQL 作业在底层会因为对同一个表