由 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、 事務的新配置參數
許多新的配置參數已經被添加到系統，用以支持事務。
| 配置關鍵 |
默認值 |
位置 |
注解 |
| 見注解 |
客戶端/ |
默認值： org.apache.hadoop.hive.ql.lockmgr.DummyTxnManager 支持事務所需的值： org.apache.hadoop.hive.ql.lockmgr.DbTxnManager 而DummyTxnManager實現Hive 0.13前的行為，並且不提供事務支持。 |
|
| true |
客戶端/ HiveServer2 |
在嚴格模式非ACID資源使用標准的R / W鎖語義，例如INSERT將獲得排他鎖；在非嚴格模式，對於非ACID資源，INSERT將只獲取共享鎖，它允許兩個並發寫入到相同的分區，但仍讓鎖管理器在表被寫入時阻止DROP TABLE等（從Hive 2.2.0）。 |
|
| 300 |
客戶端/ |
如果客戶沒有發送心跳，多長時間（單位秒）之后宣布事務中止。對於所有組件/服務，至關重要的是此屬性要有相同的值。（注5） |
|
| 5 |
客戶端/ HiveServer2 |
用於心跳的線程數（從Hive 1.3.0和2.0.0開始）。 |
|
| 100秒 |
Metastore |
Metastore啟動后，啟動第一個收割器(中止超時事務的進程)的延遲時間（從Hive 0.13開始）。用於控制上述的AcidHouseKeeperServcie。 |
|
| 180秒 |
Metastore |
描述收割程序(中止超時事務的進程)運行頻率的時間間隔。（從Hive 0.13開始）。用於控制上述的AcidHouseKeeperServcie。 |
|
| 1000 |
客戶 |
可以在調用一次open_txns（）獲取到事務的最大數量。（注1） |
|
| 100000 |
HiveServer2 /Metastore |
打開的事務的最大數量。如果當前打開的事務達到此限制，則將來打開的事務請求將被拒絕，直到該數目低於限制為止。(從Hive 1.3.0和2.1.0) |
|
| 1秒 |
HiveServer2 /Metastore |
檢查打開事務計數的時間間隔（單位秒）(從Hive 1.3.0和2.1.0開始)。 |
|
| “”（空字符串） |
HiveServer2 /Metastore |
由逗號分隔的一組用於描述SQL狀態，錯誤代碼，可重試的SQLExceptions錯誤信息的正則表達式，這是適合於Hive Metastore數據庫（從Hive 1.3.0和2.1.0）。 例子見配置屬性。 |
|
| false |
Metastore |
缺省值為false，支持事務的話需要為true。 是否在此Metastore實例上運行啟動器（initiator）和清理（cleaner）的線程。在Hive1.3.0之前，關鍵是要正好在一個獨立的Metastore服務實例上啟用它(尚未強制執行)。從Hive1.3.0開始，可以在任意數量的獨立Metastore實例上啟用此屬性。 |
|
| 0 |
Metastore |
在這個metastore實例上運行多少個緊縮工作線程。（注2） 默認值為0，支持事務時至少在一個Metastore實例上大於0。 |
|
| 86400 |
Metastore |
緊縮作業運行多長時間（秒）后會被宣告失敗，並重新排隊。 |
|
| 5000 |
Metastore |
運行清理線程的間隔（毫秒）。（Hive 0.14.0和更高版本）。 |
|
| 300 |
Metastore |
檢查表或分區是否需要緊縮的時間間隔（單位秒）。（注3） |
|
| 10 |
Metastore |
在表或分區引發次要/輕度/minor緊縮的差量目錄數目。 |
|
| 0.1 |
Metastore |
觸發一個主要/深度/major緊縮任務的增量文件相對基礎文件大小的百分比。1 = 100％，默認0.1 = 10％。 |
|
| 1000 |
Metastore |
觸發一個主要/深度/major緊縮任務的涉及給定表或分區的中止事務數。 |
|
| 500 |
Metastore |
在單個緊縮作業中試圖處理增量文件的最大數量(從Hive1.3.0開始)。（注4） |
|
| “”（空字符串） |
Metastore |
用於指定將提交緊縮作業到Hadoop隊列的名稱。設置為空字符串，則由Hadoop選擇隊列(從Hive1.3.0開始)。 |
|
| 緊縮的歷史記錄 |
|||
| hive.compactor.history.retention.succeeded |
3 |
Metastore |
要在歷史記錄中保留的成功緊縮條目的數量(每個分區)。 |
| hive.compactor.history.retention.failed |
3 |
Metastore |
要在歷史記錄中保留的緊縮失敗條目的數量(每個分區)。 |
| hive.compactor.history.retention.attempted |
2 |
Metastore |
要在歷史記錄中保留的嘗試緊縮條目的數量(每個分區)。 |
| hive.compactor.initiator.failed.compacts.threshold |
2 |
Metastore |
對給定分區緊縮連續失敗的數目，在此之后，啟動器（Initiator）將停止自動調度緊縮。此時，仍然可以使用ALTER TABLE來啟動緊縮。一旦手動啟動的緊縮成功，就恢復自動啟動的緊縮。 請注意，這個值必須小於hive.compactor.history.retention.failed。 |
| hive.compactor.history.reaper.interval |
2M |
Metastore |
控制清除compactions歷史記錄的進程多久運行一次。 |
注1： hive.txn.max.open.batch控制流代理(如Flume或Storm)同時打開的事務。然后，流代理將該數量的條目寫入單個文件(每個Flume代理或Storm bolt)。因此，增加此值會減少流代理創建的增量文件的數量。但它也會增加Hive在任何給定時間必須跟蹤的已打開事務的數量，這可能會對讀取性能產生負面影響。
注2：工作線程生成MapReduce作業以執行緊縮。它們自己不執行緊縮。增加工作者線程的數量將減少需要緊縮的表或分區的時間。它也將增加Hadoop集群上的后台負載，因為更多MapReduce作業要在后台運行。每次緊縮都可以處理一個分區(如果沒有分區，則是整個表)。
注3： 減小該值將減少需要緊縮的表或分區啟動緊縮所需的時間。然而，檢查是否需要緊縮需要對每個表或分區調用NameNode，以確認每個表或分區自上一次主要/深度/major緊縮以來是否進行了事務處理。因此，降低此值將增加NameNode的負載。
注4： 如果緊縮程序檢測到有非常多的增量文件，它就首先運行幾個小的部分緊縮(在當前順序中)，然后執行實際請求的緊縮。
注5： 如果該值不是相同的，則活動事務可能被確定為“timed out（超時）”並因此中止。這還將導致諸如“沒有這樣的事務（No such transaction）...”、“沒有這樣的鎖（No such lock）...”之類的錯誤。
7.2、 為INSERT，UPDATE，DELETE設置的參數
除了上面列出的新參數，現有的一些為支持INSERT ... VALUES，UPDATE 和 DELETE需要而設置的參數。
hive.support.concurrency true（默認為false）
hive.enforce.bucketing true（默認為false）（從Hive2.0不再需要）
hive.exec.dynamic.partition.mode nonstrict不嚴格的（默認為strict嚴格的）
7.3、 為緊縮設置的參數
如果您的系統中的數據不屬於Hive用戶(即運行Hive Metastore的用戶)，那么Hive需要以數據擁有者的身份運行才能執行緊縮操作。如果您已經設置了HiveServer 2模擬用戶，那么唯一要做的額外工作就是確保Hive在運行Hive Metastore的主機上有模擬用戶的權利。這是通過將主機名添加到Hadoop的core-site.xml文件中的hadoop.proxyuser.hive.host實現的，如果您還沒有這樣做，那么需要配置Hive作為代理用戶，這要求您為運行Hive Metastore的用戶設置keytab，並將hadoop.proxyuser.hive.host和hadoop.proxyuser.hive.group添加到Hadoop的core-site.xml文件中。
請參閱您的Hadoop版本中關於安全模式的Hadoop文檔(例如，對於Hadoop2.5.1，請參閱Hadoop的安全模式)。
八、表屬性
從Hive 0.14.0開始，如果一個表用於ACID寫入（INSERT、UPDATE、DELETE），那么必須在該表中設置表屬性“transactional=true”。注意，一旦表已被經由TBLPROPERTIES（“transactional=true”）定義為ACID表，它不能被轉換回非ACID表，即不允許改變為TBLPROPERTIES（“transactional=false”）。此外，在運行任何查詢之前，必須在hive-site.xml或會話開始時將hive.txn.Manager設置為org.apache.hadoop.hive.ql.lockmgr.DbTxnManager。如果不這樣的話，插入將以舊的樣式進行；更新和刪除將在hive-11716之前被禁止。因為不允許在沒有DbTxnManager的ACID表上進行Hive-11716操作。無論如何，這也不適用於Hive 0.13.0。
如果表所有者不希望系統自動確定何時緊縮，則可以設置表屬性“NO_AUTO_COMPACTION”。這將阻止所有自動緊縮。仍然可以使用ALTER Table /Partition Compact語句進行手動緊縮。
在創建或更改表時，使用TBLPROPERTIES子句設置表屬性，如Hive數據定義語言的CREATE Table和ALTER Table PROPERTIES部分所述。在Hive版本0.x和1.0中，表屬性“transactional”和“NO_AUTO_COMPACTION”區分大小寫，但從版本1.1.0(hive-8308)開始，它們是不區分大小寫的。
更多的與緊縮相關的選項可以通過與Hive 1.3.0和2.1.0的TBLPROPERTIES來設置。它們可以通過CREATE TABLE設置在表級別屬性，也可以通過ALTER TABLE/Partition COMPACT在請求級別上設置。
這些用於覆蓋倉庫/表范圍的設置。例如，要覆蓋MR屬性以影響緊縮作業，可以在CREATE TABLE語句中或通過ALTER TABLE顯式啟動緊縮時，添加"compactor.<mr property name>=<value>"。這里所述的" <mr property name>=<value>"將設置在緊縮MR作業的Jobconf上。類似地," tblprops.<prop name>=<value>"可用於設置/覆蓋集群上所能解釋的任何表屬性代碼。最后," compactorthreshold.<prop name>=<value>"可用於替代來自"新的事務配置參數"中以".threshold"結尾的屬性，在由系統觸發compact時進行控制。
示例：
例如：在TBLPROPERTIES中設置表級別的緊縮選項
CREATE TABLE table_name ( id int, name string ) CLUSTERED BY (id) INTO 2 BUCKETS STORED AS ORC TBLPROPERTIES ("transactional"="true", "compactor.mapreduce.map.memory.mb"="2048", -- 指定緊縮map作業的屬性 "compactorthreshold.hive.compactor.delta.num.threshold"="4", -- 如果有超過4個增量目錄，則觸發輕度緊縮 "compactorthreshold.hive.compactor.delta.pct.threshold"="0.5" -- 如果增量文件的大小與基礎文件的大小的比率大於50%，則觸發深度緊縮 );
例如：在TBLPROPERTIES中設置請求級別的緊縮選項
ALTER TABLE table_name COMPACT 'minor' WITH OVERWRITE TBLPROPERTIES ("compactor.mapreduce.map.memory.mb"="3072"); -- 指定緊縮map作業的屬性 ALTER TABLE table_name COMPACT 'major' WITH OVERWRITE TBLPROPERTIES ("tblprops.orc.compress.size"="8192"); -- 更改任何其他Hive表屬性