hive0.13数据库锁问题fix

之前同事处理的一个case,记录下

hive升级到0.13之后,在创建表时,发现报锁竞争的问题,信息如下:

conflicting lock present for vipdw mode EXCLUSIVE

hive中有锁是没有问题,但是这里的锁却是数据库层面的锁!而且是排他锁!这个锁的粒度就太大了,这个锁会导致所有的关于这个库的hive操作都要等待这个锁的释放.

这个应该是去拿表的锁啊。。怎么可以拿库的锁。。

根据之前的分析,hive的锁由DummyTxnManager类实现:

在DummyTxnManager类中,关于EXCLUSIVE锁的获取如下

代码路径:

ql/src/java/org/apache/hadoop/hive/ql/lockmgr/DummyTxnManager.java

原始代码:

    for (WriteEntity output : plan.getOutputs()) {
      LOG.debug("Adding " + output.getName() + " to list of lock outputs");
      List<HiveLockObj> lockObj = null;
      if (output.getType() == WriteEntity.Type.DATABASE) {
        lockObjects.addAll(getLockObjects(plan, output.getDatabase(), null,
            null,
            output.isComplete() ? HiveLockMode.EXCLUSIVE : HiveLockMode.SHARED));
      } else if (output.getTyp() == WriteEntity.Type.TABLE) {
        lockObj = getLockObjects(plan, null, output.getTable(), null,
            output.isComplete() ? HiveLockMode.EXCLUSIVE : HiveLockMode.SHARED);
      } else if (output.getTyp() == WriteEntity.Type.PARTITION) {
        lockObj = getLockObjects(plan, null, null, output.getPartition(),
            HiveLockMode.EXCLUSIVE);
      }
      // In case of dynamic queries, it is possible to have incomplete dummy partitions
      else if (output.getTyp() == WriteEntity.Type.DUMMYPARTITION) {
        lockObj = getLockObjects(plan, null, null, output.getPartition(),
            HiveLockMode.SHARED);
      }
      if(lockObj != null) {
        lockObjects.addAll(lockObj);
        ctx.getOutputLockObjects().put(output, lockObj);
      }
    }

更改源码,把数据库的排它锁这一段去掉:

for (WriteEntity output : plan.getOutputs()) {
    LOG.debug("Adding " + output.getName() + " to list of lock outputs");
    List<HiveLockObj> lockObj = null;
    if (output.getType() == WriteEntity.Type.DATABASE) {
      LOG.debug("Output has database:" +output.getDatabase());
      LOG.debug("Removing unnecessary output lock aquirement on "+output .getDatabase()+" database" );
      // lockObjects.addAll(getLockObjects(plan, output.getDatabase(), null,
      // null,
      // output.isComplete() ? HiveLockMode.EXCLUSIVE : HiveLockMode.SHARED));
    } else if (output.getTyp() == WriteEntity.Type.TABLE) {
      lockObj = getLockObjects( plan, null, output.getTable(), null,
          output.isComplete() ? HiveLockMode.EXCLUSIVE : HiveLockMode .SHARED);
    } else if (output.getTyp() == WriteEntity.Type.PARTITION) {
      lockObj = getLockObjects( plan, null, null, output.getPartition(),
          HiveLockMode.EXCLUSIVE);
    }
    // In case of dynamic queries, it is possible to have incomplete dummy partitions
    else if (output.getTyp() == WriteEntity.Type.DUMMYPARTITION) {
      lockObj = getLockObjects( plan, null, null, output.getPartition(),
          HiveLockMode.SHARED);
    }
    if(lockObj != null) {
      lockObjects.addAll(lockObj);
      ctx.getOutputLockObjects().put(output , lockObj);
    }
  }
时间: 2025-01-06 15:41:14

hive0.13数据库锁问题fix的相关文章

hive0.13权限bug fix

最近线上的hive升级到了0.13,遇到不少问题.权限上面,设置了hive.security.authorization.createtable.owner.grants 在hive0.13中,用户自己创建的表也没有权限.通过对源码的分析和debug找到了rc并fix,下面记录下. 1.首先在hive0.11中和hive0.13中分别做建表测试,通过查看数据库中的元数据,发现在hive0.11中如果设置了owner的参数在表创建之后,用户会有这个表的all的权限(具体可以分析db_privs ,

hive0.13 rows loaded为空问题源码分析及fix

升级hive0.13之后发现job运行完成后Rows loaded的信息没有了. rows loaded的信息在hive0.11中由HiveHistory类的printRowCount输出.HiveHistory类的主要用途是记录job运行的信息,包括task的counter等.默认的目录在/tmp/$user中. hive0.11在SessionState 的start方法中会初始化HiveHistory的对象  if (startSs. hiveHist == null) {       s

【转】数据库锁机制

1 前言 数据库大并发操作要考虑死锁和锁的性能问题.看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程.T3,T4以此类推.下面以SQL Server(2005)为例. 2 锁的种类 共享锁(Shared lock). 例1: ---------------------------------------- T1: select * from table (请想象它需要执行

数据库锁机制

1 前言 数据库大并发操作要考虑死锁和锁的性能问题.看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程.T3,T4以此类推.下面以SQL Server(2005)为例. 2 锁的种类 共享锁(Shared lock). 例1: ---------------------------------------- T1: select * from table (请想象它需要执行

hive0.13.1安装-mysql server作为hive的metastore

hive0.13.1在hadoop2.4.1伪分布式部署上安装过程 环境:redhat enterprice 6.5 +hadoop2.4.1+hive0.13.1+mysql单节点伪分布式部署 相关网址: hive官网安装指导:https://cwiki.apache.org/confluence/display/Hive/GettingStarted#GettingStarted-InstallingHivefromaStableRelease hive之metastore的三种保存方式:h

数据库锁简析(转载)

一.前言 数据库大并发操作要考虑死锁和锁的性能问题.这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程.T3,T4以此类推.下面以SQL Server为例. 二.锁的种类 共享锁(Shared lock). 例1: ---------------------------------------- T1: select * from table (请想象它需要执行1个小时之久,后面的sql语句请都这么想象) T2:

基于Mysql的Hive0.13单机安装

一,安装环境 硬件:虚拟机 操作系统:Centos 6.4 64位 IP:10.51.121.10 主机名:datanode-4 安装用户:root Hadoop:Hadoop2.6,Hadoop2.6的单机安装请见:http://www.cnblogs.com/zouzhongfan/p/4309405.html 二,安装Mysql 1,到http://dev.mysql.com/downloads/repo/yum/ 下载mysql-community-release-el6-5.noarc

Hadoop-2.2.0 + Hbase-0.96.2 + Hive-0.13.1(转)

From:http://www.itnose.net/detail/6065872.html # 需要软件 Hadoop-2.2.0(目前Apache官网最新的Stable版本) Hbase-0.96.2(这里就用这个版本,跟Hadoop-2.2.0是配套的,不用覆盖jar包什么的) Hive-0.13.1(目前是最新版本) Zookeepr-3.4.6(这里推荐使用 3.4.5) Jdk1.7.0_60(这里推荐使用1.7.0_45) Mysql-5.5.31 # 集群结构图 NN : Nam

数据库锁机制(转发)

1 前言 数据库大并发操作要考虑死锁和锁的性能问题.看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程.T3,T4以此类推.下面以SQL Server(2005)为例. 2 锁的种类 共享锁(Shared lock). 例1: ---------------------------------------- T1: select * from table (请想象它需要执行