【編者按】近日發布的Hive 0.13中採用了ACID語義的事務機制，在分區層保證事務原子性、一致性和持久性，並通過開啟ZooKeeper或內存中的鎖機制保證事務隔離性。數據流攝取、緩慢變化維、數據重述這些新的用例在新版本中成為了可能，當然新版Hive中也還存在一些不足，Hive新版本具體帶來哪些改變呢？作者Alan Gates為我們帶來了精彩分析。
以下為原文：
什麼是ACID，有什麼作用？
ACID代表資料庫事務中的4個特性，原子性（任何一個資料庫操作要麼被完整執行，要麼完全不執行）、一致性（一旦應用程式執行了一個操作，操作的結果對於每一個之後的操作都是可見的）、隔離性（一個用戶的操作不會對其他用戶產生意料之外的副作用）、持久性（一旦一個操作被完成，這些操作也將被記錄下來，即使機器或者系統出現故障，也要保證這些記錄的完整性）。這些特性一直被認為是事務功能的重要組成部分。
在最近發布的Hive 0.13中，事務的原子性、一致性和持久性在分區層得到保證，隔離性則通過開啟ZooKeeper或內存中可用的鎖機制來保證。通過在Hive 0.13中加入事務，實現在行級提供全部的ACID語義，這樣的話，一個應用程式可以添加行，而另一個應用程式可以從同一分區中讀取數據，互相之間不會產生幹擾。
採用ACID語義的事務機制被添加到Hive中來處理以下的用例：
數據流攝取（ streaming ingest of data）。許多用戶都會使用Apache Flume、Apache Storm或Apache Kafka之類的工具，這些工具可以將數據寫入到Hadoop集群，寫入數據的速率達到每秒數百行，而Hive可以每隔15分鐘到1個小時添加一個分區，然而，添加太多分區也經常會造成表的混亂。這些工具也可以將數據寫入到現有分區中，但這又可能會導致讀取數據時產生髒讀（他們讀取的數據在執行查詢之後被修改了），而且在他們的目錄中會產生的許多小文件，對NameNode造成壓力。有了數據流攝取這一新功能，用例將允許讀者得到數據的一致視圖，同時避免產生過多的文件。緩慢變化維（slow changing dimensions）。在一個典型星型架構的數據倉庫中，隨著時間推移，維度表變化的很慢。例如，一家零售商新開一個商店時，那這個商店就需要添加「商店表」中，但也有可能只是對現有商店進行擴充，也許還會添加一些新的服務。這些變化會導致向數據倉庫中插入一些新的記錄或者對已有記錄進行更改（具體取決於選擇的策略）。Hive目前無法支持這些操作，只要INSERT ... VALUES、UPDATE和DELETE這些操縱被支持，緩慢變化維將成為可能。數據重述（data restatement）。有時候收集到的數據不正確，需要一些修正，有可能數據的第一個實例已經近似（90%的伺服器報告）稍後提供的完整數據，有可能某些事務由於後續事務還需要被重述（例如：在一次交易中，客戶可能會購買會員資格，並因此有權享受折扣價，包括之前的交易也需要享受這個折扣價），還有可能用戶會在他們交易關係終止時，會根據合同要求刪除他們的用戶數據。只要INSERT ... VALUES、UPDATE和DELETE這些操作被支持，數據重述也將成為可能。不足：
在Hive 0.13中，還不支持INSERT……VALUES、UPDATE和DELETE等操作，BEGIN、COMMIT和ROLLBACK等操作也還沒有得到支持，這些功能計劃在下一個版本中實現。在Hive 0.13的第一版本中還只能支持ORC文件格式。事務能否被任何存儲格式使用決定了更新或刪除操作如何應用於基礎記錄（實際上，基礎記錄中有顯式或隱式的行id），但到目前為止，整合工作還只能用ORC格式完成。流攝取接口（見下文）還不能與Hive中已有的INSERT INTO操作很好的整合。如果表使用流攝取接口，那通過INSERT INTO添加的任何數據都會丟失。不過INSERT OVERWRITE仍然可用，而且能用於流攝取，它通過流攝取刪除插入數據就像是通過其他方式將數據寫入到該分區一樣。在Hive 0.13中，事務默認是被關閉的。請參閱下面的配置部分，Hive中的一些關鍵項需要進行手動配置。表必須被bucketed以更好地利用這些功能。同一個系統中沒有使用事務和ACID的表不需要被bucket。僅能支持快照級別隔離。當給定的查詢啟動後，將會產生一致的數據快照。不支持髒讀、已提交讀取、可重複讀取，以及串行化。引入BEGIN後，將支持快照隔離事務，為的是保證事務持久性，而不僅僅為了完成一次查詢。其他隔離級別可以根據用戶要求添加。現有的Zookeeper和內存鎖管理器與事務不兼容。目前還沒有打算解決這一問題，要想了解如何為事務存儲鎖，請參見下面的基礎設計。流攝入接口
有關使用流數據攝入的詳細信息，請參閱StreamingDataIngest。
語法變化
多個新命令被添加到Hive的DDL中以支持ACID和事務，一些現有的DDL也被做了一些修改。
例如：新加入的SHOW TRANSACTIONS命令，有關該命令的詳細信息，請參閱ShowTransactions。
SHOW COMPACTIONS也是一個新加入的命令，詳細信息請參閱ShowCompactions。
原有的SHOW LOCKS命令被修改，以提供與事務相關的新鎖信息。如果你正在使用ZooKeeper或者內存鎖命令，你會注意到這條命令在輸出上並沒有多大改變，詳細信息請參閱ShowLocks。
ALTER TABLE中添加了一個新的選項，用來壓縮表或分區。一般用戶不需要去請求壓縮，因為系統會檢測到他們的需求，然後自動啟動壓縮。但是，如果一個表壓縮被意外終止或者一個用戶想要去手動壓縮表，ALTER TABLE可以滿足用戶，提供手動啟動壓縮，有關詳細信息，請參閱AlterTable/PartitionCompact。ALTER TABLE會將請求排入隊列、壓縮並返回請求，如果用戶想看到壓縮的進展情況，可以使用SHOW COMPACTIONS命令。
基礎設計
HDFS不支持對文件進行更改。在寫入者向文件進行寫入操作，同時文件被其他用戶讀取這種情況下，它無法保證讀取的一致性。為了在HDFS上提供這一功能，我們採用在其他數據倉庫工具使用的標準方法，將表或分區數據存儲在一組基礎文件中，將新記錄、更新和刪除操作存儲在delta文件中。 為每個事務創建一組新delta文件（或者在流代理如：Flume或Storm中，為每一批事務創建一組新delta文件），更改表或分區。在讀取時，讀取器將基礎文件和delta文件合併，應用更新和刪除操作。
有時這些變化需要合併成基礎文件，一組線程必須添加到Hive metastore中。他們確定什麼時候需要壓縮，然後執行壓縮，最後進行清理（刪除舊文件）。壓縮的類型分兩種，次要的和主要的。次要壓縮採用一組現有的delta文件，並為每一次bucket重寫一個delta文件。主要壓縮則要為每個bucket寫一個或多個delta文件，為每一次bucket重寫一個新基礎文件。所有壓縮都在後臺完成，並不妨礙數據的並發讀取和寫入。在一次壓縮後，系統會等待直到所有舊文件的讀取結束，然後刪除舊的文件。
以前一個分區（或如果沒有分區表的表）的所有文件都放在單個目錄中。因為這些變化，所有採用ACID思想寫入的分區都將有一個基礎文件的目錄，以及delta文件集目錄。
新鎖管理器DbLockManager也添加到了Hive中。該鎖管理器將所有鎖信息存儲在metastore中，此外所有事務也存儲在metastore中。這意味著事務和鎖即使在伺服器出現故障時也能保證持久性，為了避免客戶端死機、離開或者鎖掛起，鎖持有者和事務啟動器需要向metastore發出心跳信號（heartbeat），如果在給定的時間內伺服器沒有收到客戶端發出的心跳信號，該鎖或事務將被中止。
配置
許多新配置關鍵項被添加到系統用以支持事務。
配置關鍵項
默認值
事務啟動值
注釋
hive.txn.manager
org.apache.hadoop.
hive.ql.lockmgr.
DummyTxnManager
org.apache.hadoop.
hive.ql.lockmgr.
DbTxnManager
DummyTxnManager延用了Hive 0.13之前的做法，不提供事務。
hive.txn.timeout
300
如果在這段時間內，客戶端沒有發出心跳信號，事務就會被宣告終止。
hive.txn.max.
open.batch
1000
事務的最大數量，可以用open_txns（）獲取。
hive.compactor.
initiator.on
false
true (for exactly one instance of the Thrift metastore service)
是否在該metastore實例上運行啟動器和垃圾清理線程。
hive.compactor.
worker.threads
0
> 0 on at least one instance of the Thrift metastore service
有多少工作線程在該metastore實例上運行。
hive.compactor.
worker.timeout
86400
壓縮作業在該時間內未完成將被宣布失敗，壓縮操作被重新排入隊列。
hive.compactor.
check.interval
300
檢查是否有分區需要被壓縮。
hive.compactor.
delta.num.threshold
10
delta目錄的數目，達到該數後將觸發次要壓縮。
hive.compactor.
delta.pct.threshold
0.1
與基礎文件中delta文件的百分比，達到該值會觸發主要壓縮。（1 = 100%）
hive.compactor.
abortedtxn.threshold
1000
給定分區中已中止事務的數目，達到該數會也會觸發主要壓縮。
hive.txn.max.open.batch控制多個事務流代理，如Flume或Storm。流代理將多個詞條寫到單個文件中（每個Flume代理或每個Storm螺栓）。因此，增加該值可以減少流代理創建的文件數，但增加此值也增加了開放事務的數目（Hive需要追蹤），這可能會影響讀取的性能。
工作線程為壓縮操作產生了許多MapReduce作業，而它們自身並沒有做壓縮。確定進行表壓縮後，增加工作線程的數目會減少表壓縮的時間。隨著更多的MapReduce作業在後臺運行，Hadoop集群的後臺負載也在增加。
減小此值將減少壓縮表或分區的時間。當然，首先得檢查壓縮是否必要，這需要為每個表或分區調用多個NameNode，降低此值可以減少NameNode的負載。
表屬性
如果表的所有者不希望系統自動確定何時要壓縮，那麼可以手動設置表屬性NO_AUTO_COMPACTION，用來阻止所有的自動壓縮操作。
原文連結：
ACID and Transactions in Hive （翻譯/毛夢琪 責編/魏偉）以「 雲計算大數據 推動智慧中國 」為主題的 第六屆中國雲計算大會 將於5月20-23日在北京國家會議中心隆重舉辦。產業觀察、技術培訓、主題論壇、行業研討，內容豐富，乾貨十足。票價優惠，馬上 報名 ！
本文為CSDN原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)