Hive 的事務支援

hive 開始支援事務，是在 hive 0.14 之後。hdfs 的檔案，只能允許新建，刪除，對檔案中的內容進行更新，不允許單條修改。hive 的檔案儲存是基於 hdfs 檔案存在的，所以原則上不會直接對 hdfs 做檔案內容的事務更新，只能是採取另外的手段來完成。即用 hdfs 檔案作為原始資料，用 delta 檔案作為操作日誌的記錄。當訪問 hive 資料時，根據 hdfs 檔案和 delta 檔案做合併，查詢最新的資料。

綜上，hive 支援事務的前提是，初始化資料和增量操作，分開儲存。

這種儲存方案導致的最終結果是，hive 儲存的 delta 檔案日益增多，增加 namenode 的管理難度，namenode 是設計來管理大容量小數量檔案，每乙個 hdfs 的檔案目錄以及檔案都會增大namenode 的記憶體消耗。

hive 支援事務所需要的前提配置：

1. 配置六個屬性

2. 在 hive 元資料中增加對事務支援所需的表（這一點不知道有沒有改善，理論上太複雜）

3. 重新啟動 hive 服務

4. 建表需要使用 orc儲存

配置六個支援事務所需的屬性：

在 hive-site.xml 中配置：


hive.support.concurrencyname>
truevalue>
property>
hive.exec.dynamic.partition.modename>
nonstrictvalue>
property>
hive.txn.managername>
org.apache.hadoop.hive.ql.lockmgr.dbtxnmanagervalue>
property>
hive.compactor.initiator.onname>
truevalue>
property>
hive.compactor.worker.threadsname>
1value>
property>
hive.enforce.bucketingname>
truevalue>
property>

對幾個重要的屬性做闡述：

hive.exec.dynamic.partition.mode:

可選值有：strict, nonstric.

strict 模式下，必須制定乙個partition做為更新的目的地，目的是為了防止誤操作其他partition.

在乙個事務中，可能不止會更新乙個partition, 而且更新時也無法控制到底哪些partition會被操作到，因此為了支援事務，必須使用 nonstrict.

hive.compactor.initiator.on

預設值是 false, 因為預設的情況連事務都不開啟。

這個屬性很重要的原因是回答之前我們的乙個問題，如果 delta 檔案過多，對namenode造成了影響，我們改如何改善系統效能？（在thrift metaserver 上）開啟了這個屬性之後，會使得在 metastore 例項上執行 initiator, cleaner 程序。initiator 程序負責查詢哪些表或者分割槽的 delta 檔案需要被壓縮，cleaner 程序負責刪除已經不再需要的 delta 檔案。

2 在 hive 元資料中增加對事務支援所需的表（這一點不知道有沒有改善，理論上太複雜）

之前搭建 hive 環境的時候，用的 metadata 是儲存在 mysql 之上的，所以在這一步，只需要通過在 mysql 中增加3 個表即可：

mysql>insert into next_lock_id values(1);
mysql>insert into next_compaction_queue_id values(1)
mysql>insert into next_txn_id values(1)
mysql> commit ;

沒有更新這三張表的後果是，可能會報錯： error in acquiring locks: error communicating with the metastore.

metastore, thrift server, hive service 這些概念如果還有模糊，《 programming hive》再看看。

Hive 的事務支援

hive 支援更新

Hive支援的計算引擎

Hive支援的計算引擎

Hive 的事務支援

hive 支援更新

Hive支援的計算引擎

Hive支援的計算引擎

相關推薦