目录

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毫秒。

　　锁管理