Hive 官方手冊翻譯 -- Hive Transactions (Hive 事務)
由 Alan Gates建立, 最終由 Andrew Sherman修改於2018年8月7日
原文連結：Hive/Hive+Transactions" rel="nofollow,noindex" target="_blank">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 staff0 2016-06-09 17:03 /user/hive/warehouse/t/base_0000022 -rw-r--r--1 ekoifman staff602 2016-06-09 17:03 /user/hive/warehouse/t/base_0000022/bucket_00000 drwxr-xr-x- ekoifman staff0 2016-06-09 17:06 /user/hive/warehouse/t/delta_0000023_0000023_0000 -rw-r--r--1 ekoifman staff611 2016-06-09 17:06 /user/hive/warehouse/t/delta_0000023_0000023_0000/bucket_00000 drwxr-xr-x- ekoifman staff0 2016-06-09 17:07 /user/hive/warehouse/t/delta_0000024_0000024_0000 -rw-r--r--1 ekoifman staff610 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、 事務的新配置引數
許多新的配置引數已經被新增到系統，用以支援事務。
配置關鍵 |
預設值 |
位置 |
註解 |
|
見註解 |
客戶端/ HiveServer2 |
預設值： 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 |
客戶端/ HiveServer2 /Metastore |
如果客戶沒有傳送心跳，多長時間（單位秒）之後宣佈事務中止。對於所有元件/服務，至關重要的是此屬性要有相同的值。（注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 (
idint,
namestring
)
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表屬性