Hive 开始支持事务，是在 Hive 0.14 之后。用 HDFS 文件作为原始数据，用 delta 文件作为操作日志的记录。当访问 Hive 数据时，根据 HDFS 文件和 delta 文件做合并，查询最新的数据。
综上，Hive 支持事务的前提是，初始化数据和增量操作，分开存储。 这种存储方案导致的最终结果是，Hive 存储的 delta 文件日益增多，增加 NameNode 的管理难度，NameNode 是设计来管理大容量小数量文件，每一个 HDFS 的文件目录以及文件都会增大NameNode 的内存消耗。
Hive 支持事务所需要的前提配置：
1. 配置六个属性 2. 在 Hive MetaStore 中增加对事务支持所需的元数据（这一点不知道有没有改善，理论上太复杂） 3. 重新启动 Hive 服务 4. 建表需要使用 ORC存储
1 配置六个支持事务所需的属性： 在 hive-site.xml 中配置：
hive.support.concurrency
true
hive.exec.dynamic.partition.mode
nonstrict
hive.txn.manager
org.apache.hadoop.hive.ql.lockmgr.DbTxnManager
hive.compactor.initiator.on
true
hive.compactor.worker.threads
1
hive.enforce.bucketing
true
对几个重要的属性做阐述：
hive.exec.dynamic.partition.mode: 可选值有：strict, nonstric. strict 模式下，必须制定一个partition做为更新的目的地，目的是为了防止误操作其他partition. 在一个事务中，可能不止会更新一个Partition, 而且更新时也无法控制到底哪些partition会**作到，因此为了支持事务，必须使用 Nonstrict.
hive.compactor.initiator.on 默认值是 false, 因为默认的情况连事务都不开启。 这个属性很重要的原因是回答之前我们的一个问题，如果 delta 文件过多，对namenode造成了影响，我们改如何改善系统性能？（在thrift metaserver 上）开启了这个属性之后，会使得在 metaStore 实例上运行 Initiator, cleaner 进程。initiator 进程负责查找哪些表或者分区的 delta 文件需要被压缩，cleaner 进程负责删除已经不再需要的 delta 文件。
2 在 Hive 元数据中增加对事务支持所需的表（这一点不知道有没有改善，理论上太复杂） 之前搭建 Hive 环境的时候，用的 metaData 是存储在 MySQL 之上的，所以在这一步，只需要通过在 MySQL 中增加3 个表即可：
mysql>insert into next_lock_id values(1);mysql>insert into next_compaction_queue_id values(1)mysql>insert into next_txn_id values(1)mysql> commit ;
没有更新这三张表的后果是，可能会报错： error in acquiring locks: error communicating with the metastore.
metastore, thrift server, hive service 这些概念如果还有模糊，《 Programming Hive》再看看。