Hive一直使用ZooKeeper作為分布式鎖定管理器來支持HiveServer2中的并發(fā)。 基于ZooKeeper的鎖管理器在小型環(huán)境中運(yùn)行良好。 但是，隨著越來越多的用戶從HiveServer遷移到HiveServer2并開始創(chuàng)建大量并發(fā)會話，可能會出現(xiàn)問題。 主要問題是Hiveserver2和ZooKeeper之間打開的連接數(shù)一直在增加，直到從ZooKeeper服務(wù)器端達(dá)到連接限制為止。 此時，ZooKeeper開始拒絕新的連接，并且所有依賴ZooKeeper的流都變得不可用。 為了解決這個問題，已經(jīng)開放了多個Hive JIRA（例如HIVE-4132，HIVE-5853和HIVE-8135等），并且最近通過HIVE-9119對其進(jìn)行了修復(fù)。

讓我們仔細(xì)看一下Hive中的ZooKeeperHiveLockManager實現(xiàn)，看看它為什么以前引起問題，以及我們?nèi)绾谓鉀Q它。

ZooKeeperLockManager使用簡單的ZooKeeper API來實現(xiàn)分布式鎖。 下面列出了它使用的協(xié)議。

希望獲得共享鎖的客戶端應(yīng)執(zhí)行以下操作：

調(diào)用create（）創(chuàng)建一個路徑名稱為“ _lockresource_ / lock-shared-”且設(shè)置了序列標(biāo)志的節(jié)點。

在不設(shè)置監(jiān)視標(biāo)志的情況下，在節(jié)點上調(diào)用getChildren（）。

如果不存在路徑名稱以“ lock-exclusive-”開頭的子代，則客戶端將獲取該鎖并退出。

否則，調(diào)用delete（）來刪除它們在步驟1中創(chuàng)建的節(jié)點，休眠一個預(yù)定義的時間段，然后通過執(zhí)行步驟1直到達(dá)到最大重試次數(shù)來進(jìn)行重試。

希望獲得排他鎖的客戶應(yīng)執(zhí)行以下操作：

調(diào)用create（）創(chuàng)建一個路徑名稱為“ _lockresource_ / lock-exclusive-”且已設(shè)置序列標(biāo)志的節(jié)點。

在不設(shè)置監(jiān)視標(biāo)志的情況下，在節(jié)點上調(diào)用getChildren（）。

如果沒有序號比在步驟1中創(chuàng)建的節(jié)點低的子級，則客戶端獲取鎖并退出。

否則，調(diào)用delete（）來刪除它們在步驟1中創(chuàng)建的節(jié)點，休眠一個預(yù)定義的時間段，然后通過執(zhí)行步驟1直到達(dá)到最大重試次數(shù)來進(jìn)行重試。

希望釋放鎖的客戶端應(yīng)該只刪除他們在步驟1中創(chuàng)建的節(jié)點。此外，如果所有子節(jié)點都已刪除，則也要刪除父節(jié)點。

上面的鎖定和解鎖協(xié)議非常簡單明了。 但是，該協(xié)議的先前實現(xiàn)未正確使用ZooKeeper客戶端。 對于每個Hive查詢，都會創(chuàng)建一個新的ZooKeeper客戶端實例來獲取和釋放鎖。 這給ZooKeeper服務(wù)器處理新的連接帶來了很多開銷。 另外，在多會話環(huán)境中，如果并發(fā)查詢太多，很容易達(dá)到ZooKeeper服務(wù)器連接限制。 此外，當(dāng)用戶使用Hue進(jìn)行Hive查詢時，也會發(fā)生這種情況。 色相默認(rèn)情況下不會關(guān)閉Hive查詢，這意味著為該查詢創(chuàng)建的ZooKeeper客戶端永遠(yuǎn)不會關(guān)閉。 如果查詢量很大，則可以很快達(dá)到ZooKeeper連接限制。

我們是否真的需要為每個查詢創(chuàng)建一個新的ZooKeeper客戶端？ 我們發(fā)現(xiàn)沒有必要。 從上面的討論中，我們可以看到HiveServer2使用ZooKeeper客戶端與ZooKeeper服務(wù)器進(jìn)行通信，以便能夠獲取和釋放鎖。 主要工作量在ZooKeeper服務(wù)器端，而不是客戶端。 一個HiveKeeper客戶端可以由針對HiveServer2服務(wù)器的所有查詢共享。 使用Singleton ZooKeeper客戶端，可以消除處理連接的服務(wù)器開銷。 Hue用戶不再受ZooKeeper連接問題的困擾。

Singleton ZooKeeper客戶端能夠解決鎖定管理問題。 但是，我們?nèi)匀恍枰苯邮褂肸ooKeeper客戶端來處理一些額外的事情，例如：

• 初始連接：ZooKeeper客戶端和服務(wù)器握手需要一些時間。 ZooKeeperHiveLockManager使用的同步方法調(diào)用（例如create（），getChildren（），delete（））將在此握手尚未完成時引發(fā)異常。 在這種情況下，我們需要一個鎖存器來控制ZooKeeper客戶端何時開始向服務(wù)器發(fā)送方法調(diào)用。
• 斷開連接和故障轉(zhuǎn)移：如果Singleton ZooKeeper客戶端失去與服務(wù)器的連接，我們需要處理連接重試并將故障轉(zhuǎn)移到集群中的另一臺服務(wù)器。
• 會話超時：如果發(fā)生連接會話超時，則需要關(guān)閉單例ZooKeeper客戶端并重新創(chuàng)建。

Apache Curator是開源軟件，能夠透明地處理所有上述情況。 Curator是Netflix的ZooKeeper庫，它提供了簡化使用ZooKeeper的高級API-CuratorFramework。 通過在新的ZooKeeperHiveLockManager實現(xiàn)中使用單例CuratorFramework實例，我們不僅解決了ZooKeeper連接問題，而且使代碼易于理解和維護(hù)。

感謝Hive開源社區(qū)將此修復(fù)程序包含在Apache Hive 1.1中。 最新的Hive 0.12和Hive 0.13版本以及即將發(fā)布的MapR Distribution的 Hive 1.0版本中也包含此修復(fù)程序。

參考文獻(xiàn)：

• ZooKeeper：http： //zookeeper.apache.org/
• 策展人： http ： //curator.apache.org/

相關(guān)的JIRAS：

• HIVE-4132： https ： //issues.apache.org/jira/browse/HIVE-4132
• HIVE-5853： https ： //issues.apache.org/jira/browse/HIVE-5853
• HIVE-8135： https ： //issues.apache.org/jira/browse/HIVE-8135
• HIVE-9119： https ：//issues.apache.org/jira/browse/HIVE-9119

翻譯自: https://www.javacodegeeks.com/2015/02/refine-hive-zookeeper-lock-manager-implementation.html

總結(jié)

以上是生活随笔為你收集整理的如何：优化Hive ZooKeeper Lock Manager实施的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。