正文
由 Alan Gates创建, 最终由 Andrew Sherman修改于2018年8月7日
原文链接：https://cwiki.apache.org/confluence/display/Hive/Hive+Transactions
翻译：Google Google翻译，金山软件 金山词霸
校对：南大通用 范振勇 (如有翻译问题，请多指教)
一、Hive 3的警告
升级到Hive 3.0时，由之前版本创建的任何事务性表都需要在每个分区上运行Major(主要/深度)级紧缩操作。更确切地说，自上一次Major级紧缩操作之后，在其上执行任何Update/Delete/Merge语句的分区，都必须再进行一次Major级紧缩操作。就是说，在Hive升级到Hive 3之前，此分区上不会发生任何Update/Delete/Merge操作。
二、什么是ACID，为什么要使用ACID呢？
ACID代表了数据库事务的四个特征：原子性(一个操作要么完全成功，要么失败，绝不会留下部分数据) 、一致性(一旦应用程序执行了一个操作，该操作的结果在它以后的每个操作中都是可见的)、隔离性(一个用户未完成的操作不会对其他用户造成意外影响)，以及持久性(一旦一个操作完成，它将保持下来，即便面对机器故障或系统故障)。一直以来，这些特性被认为是数据库系统事务功能的一部分。
截止到 0.13，Hive都只提供分区级别的原子性、一致性和持久性。可以通过打开一种可用的锁机制(Zookeeper或内存)来提供隔离性。随着在Hive 0.13中添加事务，现在可以在行级别提供完整的ACID语义，这样一个应用程序就可以在另一个应用程序读取同一个分区时添加行，而不会相互干扰。
Hive中添加ACID语义事务的特性，可以解决以下用例：
- 流数据的采集。许多用户使用如Apache Flume，Apache Storm，或Apache Kafka等工具，将数据流到自己的Hadoop集群。尽管这些工具可以每秒数百行或更多行的速度写入数据，但Hive只能每十五分钟到一小时的添加分区。更短间隔的添加分区会导致表中出现大量的分区。这些工具可以将数据流到现有的分区中，但这将导致读操作产生脏读(也就是说，能看到在启动查询后会写入的数据)，并在目录中留下许多小文件，这将给NameNode带来压力。使用此事务功能，将支持此场景，同时保证读操作获得一致的数据视图，并避免过多的文件。
- 缓慢变化的维度（表）。在典型的星型模型的数据仓库中，维度表随着时间的推移变化很缓慢。例如，零售商开设新的商店，这些商店需要添加到商店表中，或者现有的商店可能会改变面积或其他可跟踪的特性。这些更改会导致插入单个记录或更新记录(取决于所选择的策略)。从0.14开始，Hive能够支持这一点。
- 数据重述（译注：财务术语，类似“调帐”）。有时，收集的数据被认为是不正确的，需要修正。或数据的第一个实例可能是近似值（90％的服务报告），随后提供了完整数据。或业务规则可能要求因为随后的交易进行重述某些交易（例如，在购物之后，客户可以购买成员资格，因此有权享受折扣价格，包括在先前的购买记录）。或者用户可以根据合同约定在他们关系的结束时消除其客户的数据。从Hive0.14开始，这些用例可以通过INSERT，UPDATE和DELETE来支持。
- 使用SQL MERGE语句实现批量更新。
三、限制
- 所有DML操作都是自动提交，尚不支持BEGIN，COMMIT，和ROLLBACK，计划在将来的版本中支持这些特性。
- 在第一个版本中只支持ORC文件格式。构建事务特性的初衷是可以使用任何存储格式，只要这些存储格式可以确定如何更新或删除基本记录(基本上，具有显式或隐式的行id即可)，但到目前为止，仅完成针对ORC的集成工作。
- 默认情况下，事务被配置为OFF。有关配置值的讨论，请参见下面的配置部分。
- 要使用事务特性，表必须分桶。在同一系统中的不使用事务和ACID的表则无需分桶。外部表不能成为ACID表，因为外部表上的更改超出了紧缩器的控制范围(hive-13175)。
- 不允许从非ACID的会话中读取/写入ACID表。换句话说，要操作ACID表，必须将Hive事务管理器设置为org.apache.hadoop.hive.ql.lockmgr.DbTxnManager。
- 现在只支持快照隔离级别。当一个给定的查询启动时，它会提供该数据的一致快照。不支持脏读（READ UNCIMMITTED）、提交读（READ COMMITTED）、可重复读（REPEATABLE READ）或可序列化（SERIALIZABLE）。引入BEGIN的目的是在事务持续时间内支持快照隔离，而不仅仅是一个查询。根据用户请求，还可以添加其他隔离级别。
- 现有的ZooKeeper和内存锁管理器与事务不兼容。我们无意处理这个问题。有关如何为事务存储锁的讨论，请参阅下面的基本设计。
- 原来ACID表不支持使用ALTER TABLE更改Schema，参见Hive-11421。此缺陷于Hive 1.3.0/ Hive 2.0.0修复成功。
- 使用Oracle作为Metastore DB和“datanucleus.connectionPoolingType = BONECP”时，可能偶发性产生 “No such lock ...”和“No such transaction...”的错误。在这种情况下，建议设置“datanucleus.connectionPoolingType = DBCP”。
- LOAD DATA ...语句不支持事务性表，直到Hive-16732才能正确执行。
四、流式API
Hive提供了流数据采集和流式转换的API：
Hive流API（从Hive 3开始）
HCatalog流式转换API（在Hive2.0.0及更高版本）
API的比较可参考流式转换文档的背景部分。
五、语法变化
1.从Hive0.14开始,INSERT … VALUES，UPDATE和DELETE已被添加到SQL语法。详见 Language Manual DML。
2.一些新的命令已经添加到Hive的DDL中，以支持ACID和事务，另外一些修改了现有的DDL语句。
2.1加入一个新命令SHOW TRANSACTIONS，详见Show Transactions。
2.2加入一个新命令SHOW COMPACTIONS，详见 Show Compactions。
2.3改变了SHOW LOCKS命令，以便提供锁与事务相关的信息。如果您使用的是Zookeeper或内存锁管理器，你会发现这个命令的输出并无差别。详见Show Locks。
2.4 ALTER TABLE添加了一个新的选项，用于表或分区的紧缩。在一般情况下，用户不需要请求紧缩，因为系统会检测紧缩的需求并开始执行紧缩。但是，如果关闭了表的紧缩功能，或者用户希望在系统没选择的情况下紧缩表，则可以使用ALTER TABLE启动紧缩。详见 Alter Table/Partition紧缩，这将任务放到紧缩排队等待后返回。用户可以使用SHOW COMPACTIONS查看紧缩的进度。
3.添加一个新命令终止事务：ABORT TRANSACTIONS，详见Abort Transactions。
六、基本设计
HDFS不支持文件的就地更改.对于追加写的文件，它也不为用户不提供读取的一致性。为了在HDFS之上提供这些特性，我们遵循了在其他数据仓库工具中使用的标准方法。表或分区的数据存储在一组基本文件中。新记录、更新和删除的记录存储在增量文件中。每个事务(或者是流代理(如Flume或Storm)的每个批事务)都创建了一组新的增量文件，以更改表或分区。在读取时，合并基础文件和增量文件并应用更新和删除的变化。
6.1、 基础目录和增量目录
以前，分区(或者表，如果该表未分区的话)的所有文件都存放在一个目录中。现在更改后，任何使用ACID更改的分区(或表)都将有一个用于基本文件的目录和一个用于每个增量文件集的目录。对于未分区的表“t”，其目录布局如下所示：
表“T”在文件系统的布局
hive> dfs -ls -R /user/hive/warehouse/t; drwxr-xr-x - ekoifman staff 0 2016-06-09 17:03 /user/hive/warehouse/t/base_0000022 -rw-r--r-- 1 ekoifman staff 602 2016-06-09 17:03 /user/hive/warehouse/t/base_0000022/bucket_00000 drwxr-xr-x - ekoifman staff 0 2016-06-09 17:06 /user/hive/warehouse/t/delta_0000023_0000023_0000 -rw-r--r-- 1 ekoifman staff 611 2016-06-09 17:06 /user/hive/warehouse/t/delta_0000023_0000023_0000/bucket_00000 drwxr-xr-x - ekoifman staff 0 2016-06-09 17:07 /user/hive/warehouse/t/delta_0000024_0000024_0000 -rw-r--r-- 1 ekoifman staff 610 2016-06-09 17:07 /user/hive/warehouse/t/delta_0000024_0000024_0000/bucket_00000
6.2、 紧缩器
紧缩器是一套Metastore内运行，支持ACID系统的后台进程。它由Initiator（发起者），Worker，Cleaner，AcidHouseKeeperService和其他几部分组成。
6.2.1、 增量文件紧缩
随着表的修改操作，创建了越来越多的增量文件，就需要紧缩以保持足够的性能。有两种类型的紧缩，次要和主要：
次要/轻度/minor紧缩处理一组现有的增量文件，针对每个桶，将它们重写为单个的增量文件。
主要/深度/major紧缩处理一个或多个桶的增量文件和基本文件，并将它们重写为每个桶新的基本文件。主要紧缩成本更高，但更有效。
所有紧缩都是在后台完成的，不会阻止数据的并发读、写。紧缩后，系统将等待所有旧文件的读操作完成后，删除旧文件。
6.2.1.1、 Initiator（发起者）
这个模块负责发现哪些表或分区需要紧缩。需要在Metastore中配置参数hive.compactor.initiator.on启用该模块，在“事务的新配置参数”中有几个形式为*.threshold的属性，控制何时创建紧缩任务以及执行哪种类型的紧缩。每个紧缩任务处理一个分区(如果表未分区，则处理整个表)。如果给定分区的连续紧缩失败次数超过hive.compactor.initiator.failed.compacts.threshold，则该分区的自动紧缩调度将停止。有关更多信息，请参见配置参数表。
6.2.1.2、 Worker
每个Worker处理单个紧缩任务。紧缩任务是一个MapReduce的作业，其名称形式如下：<hostname>-compactor-<db>.<table>.<partition>。每个Worker向集群提交作业(如果定义了hive.compactor.jobs.queue)到Yarn队列，并等待作业完成。hive.compactor.worker.threads确定每个Metastore中的Worker数量。Hive数据仓库中的Worker总数决定了紧缩的最大并发数量。
6.2.1.3、 Cleaner
就是在紧缩后，确定不再需要增量文件之后删除增量文件的进程。
6.2.1.4、 AcidHouseKeeperService
此进程查找在hive.txn.timeout时间内没有心跳的事务，并中止它们。系统假设此时启动事务的客户端停止心跳、崩溃，而它锁定的资源应该被释放。
6.2.1.5、 SHOW COMPACTIONS
此命令显示有关当前正在运行的紧缩和紧缩的近期历史记录(可配置保留期限)信息。从hive-12353开始，可显示紧缩的历史记录信息。
关于此命令和输出的更多信息，可参阅 LanguageManual DDL#Show Compactions。影响该命令的输出的参数见“事务新的配置参数/紧缩历史记录”配置属性。系统保留每种类型的最后N个条目：失败、成功、尝试(其中N对每种类型都是可配置的)。
6.3、 事务/锁管理器
Hive添加了一个名为“事务管理器”的新逻辑概念，它包含了以前的“数据库/表/分区锁管理器”的概念(hive.lock.Manager，缺省值为org.apache.hadoop.hive.ql.lockmgr.zookeeper.ZooKeeperHiveLockManager)。事务管理器现在还负责管理事务锁。默认的DummyTxnManager模仿老Hive版本的行为：没有事务，并使用hive.lock.Manager属性为表、分区和数据库创建锁管理器。新添加的DbTxnManager使用DbLockManager管理Hive Metastore中的所有锁/事务(事务和锁在服务器故障时是持久的)。这意味着在启用事务时，不再存在以前锁定Zookeeper中的行为了。为了避免客户端死掉并使事务或锁悬而未决，定期从锁持有者和事务发起者向Metastore发送心跳。如果在配置的时间内未接收到心跳，则锁或事务将被中止。
从Hive 1.3.0开始，DbLockManger可以通过控制hive.lock.numretires和hive.lock.sleep.between.retries来设定尝试获取锁的时间。当DbLockManager无法获得锁(由于存在竞争锁)时，它将退出，并在某个时间段后再试。为了支持短时间运行的即席查询，而又不对Metastore压力太大，每次重试之后，DbLockManager将等待时间加倍。初始回退时间为100 ms，并以hive.lock.sleep.between.retries为上限。hive.lock.numretries是它将重试请求锁的总次数。因此，调用获取锁将阻塞的总时间(给定100次重试和60次睡眠时间)是(100 ms 200 ms 400 ms.51200 ms 60s ..60s)=91分钟：42秒：300毫秒。
锁管理器中使用的锁的详细信息见Show locks。
请注意，使用DbTxnManager的锁管理器将获取所有表上的锁，即使是那些没有设置“transactional=true”属性的表。默认情况下，对非事务性表的INSERT操作将获得独占锁，从而阻止其他插入和读取。虽然在技术上是正确的，但这与传统Hive的工作方式(例如，w/o 锁管理器)是不同的, 为了向后兼容，提供了hive.txn.strict.locking.mode(见下表)模式，这将使该锁管理器在非事务性表的插入操作上获取共享锁。这恢复了以前的语义，同时仍然提供了锁管理器的好处，例如在读取表时防止表被删除。
请注意，对于事务表，插入总是获取共享锁，因为这些表在存储层实现了MVCC架构，并且即使存在并发修改操作，也能提供读的强一致性（快照隔离）。
七、配置参数
必须设置这些配置参数的适当值，才能最低限度的打开Hive中的事务支持：
客户端
hive.support.concurrency - true
hive.enforce.bucketing - true（从Hive2.0不再需要）
hive.exec.dynamic.partition.mode - nonstrict
hive.txn.manager - org.apache.hadoop.hive.ql.lockmgr.DbTxnManager
服务器端（Metastore）
hive.compactor.initiator.on - true（参见下面表格有详细介绍）
hive.compactor.worker.threads -至少在一个metastore Thrift服务的实例设置为正数
以下部分列出了所有影响Hive事务和紧缩的配置参数。另见上方的“限制”和下面的“表属性”。
7.1、 事务的新配置参数
许多新的配置参数已经被添加到系统，用以支持事务。
| 配置关键 | 默认值 | 位置 | 注解 |
| 见注解 | 客户端/ |
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
