純乾貨推薦

下面文字是hive專家一篇純乾貨的實戰問題解決過程。

看到這種總結文章，還是非常激動，這種類似解決問題過程我也經常有。特別能感受到作者開始碰到問題的一籌莫展 到 最後解決之後酣暢伶俐的心情。

強烈推薦！！！也希望更多的同學也來一起分享問題解決過程。

問題背景

Hive 0.13可能算是相對古老一點的Hive版本，但仍然在我們有些生產集群上使用。因為版本較老，bug自然相對會多一點。我這一次接到的問題是這樣，現場的簡單一句話就是“Hive beeline卡頓”，具體表象：“Hive服務跑著跑著一段時間後，大約幾個小時到是幾個小時不等，出現beeline建連接卡頓連接不上情況，一般需要等待一段時間，長短不等，幾分鐘，或是半小時以上”。為了臨時緩解使用上的問題，現場開發了一些電子巡檢的腳本，一旦發現這樣的問題自動重啟Hive的服務，當然對現有在運行的作業是會產生影響，因此又在ETL調度層面做了重處理的機制。我們部署有一套數據開發工具供應用開發人員使用，由於也是JDBC方式訪問Hive服務，白天也會收到大量的類似投訴，因此平臺的用戶感知不是很好。進一步瞭解，該問題由來已久，持續了一兩年，客戶自己和廠家的專家也都參與折騰過，消耗精力巨大，儘管上從技術上乍一看是一個小問題，但影響面卻是非常大，生產的問題都不是小問題。

集群環境

分析過程

我們首先按慣例跟蹤了服務在資源消耗、連接釋放等方面的問題，如：用netstat跟蹤服務被連接的計數、用jmap查看服務內存的gc情況、用jstack去儘可能發現一些死鎖的片段，並做出一些參數的調整，效果都不理想。要命的是，該問題出來的週期長，每一輪的調參看效果動輒十幾個小時，時間是有限的，要求我們有更大的定力。

在排除掉參數配置上的失誤之外，其它比較疑難問題最直接的解決辦法是版本升級，但升級工作遇到如下情況。

• 客戶要求：客戶認為，目前集群中的存量數據大，升級又是手動操作，存在較大風險。近階段基調是基於現有版本保障正常運行，組件級的升級是允許的，但不考慮Hadoop核心層面的大升級

• Hive大版本的升級可行性：下一個CDH中包含穩定版本是1.1.0，套件是CDH5.4 , Hadoop2.6, 目前集群是Hadoop2.5，在這樣的條件下能不能單獨升級呢？我曾寄希望於這樣的升級，能夠直接的修復當前的問題，這樣大家都輕鬆。猜想大家也做過一些通過偷樑換柱更換版本的經歷，而我們驗證確實是不行，主要問題出在MapReduce框架相關的JAR兼容性上，大家如有興趣可以去下嘗試

• Hive小版本升級，做了過一輪hive0.13.3-CDH5.3.3到hive0.13.3-CDH5.3.10的升級，解決了Hive metastore連接釋放的bug（很明顯的可以觀察到metastore服務對於連接是產生和釋放是存在缺陷的），但驗證過後發現問題沒有解決，而且需要同步做一個Sentry組件的小升級，考慮到生產影響因此做了回退

Hive服務是HiveServer2和Hivemetastore一整套服務，按照二分法的原則來排查。找準一個卡頓時間點，僅將Hivemetastore服務做一個重啟而不是都重啟兩個服務，發現可以連接。由此是否可以斷定是metastore端產生的問題呢？陸陸續續，我們找到一些這樣的資料：

大體意思是講因為元數據中表或分區過多，對於metastore服務的影響。對元數據庫表做了一個統計，分區數在2000以上的表對象不在少數，該集群是一個Hive被重度使用的環境，人員建模和開發水平層次不齊，出現一些狀況在所難免。由此，我們堅信metastore端的問題來得更顯著。為了規避分區表查詢的壓力，我們嘗試添加hive.limit.query.max.table.partition參數來做限定，限定起到作用了，糟糕的是帶來了新的部分語句的語法解析問題，為了不影響現有業務，不得不再次回退。此刻有點沮喪。

解決方案

既然是metastore的問題，能不能在它上面做點文章。說幹就幹。

方案描述：部署多個metastore服務，實際上現網中已經有兩個，但是以uri配置多個的方式來實現的HA，問題在於這種配置方式只要端口在實際用的還是固定的一個。給出調整方案：針對兩個metastore服務做一個反向代理，在hiveserver2服務中配置代理的服務地址，在metastore後向做一個端口的掃描，發現有點不正常就快速做一個重啟操作。能這樣做的前提是：hiveserver2對metastore的連接是短連接，即用即申請，而不需要維持一個長久連接，這是從日誌層面進行的推測。這樣就有平滑過渡的可能。而在hive-site.xml中有hive.metastore.client.socket.timeout，hive.metastore.connect.retries相關的重試配置。對應用而言只看得到HiveServer服務，Hive metastore在後向不可見，因而重啟沒有影響。

對hiveserver2服務通過jdbc程序或beeline命令探測大家可能比較熟悉，實際上metastore服務的探測編程也是非常容易的，通過短短的幾行代碼也可以做到：

為了準確的瞭解到服務的可連接情況，額外編寫了一套crontab腳本，按照每分鐘探測metastore、每兩分鐘探測hiveserver，記錄詳細的時間信息和探測結果。另外針對JDBC連接的探測，增加連接的超時將會起到很好的效果，API是DriverManager.setLoginTimeout(timeout)，否則程序將會長久卡住並啟動多份。

解決效果

我們重點關注的是hiveserver2服務的探測情況，因為這就是我們前端用戶需要關注的，通過24小時的觀察，除了1~2次的短時停頓（約在1分鐘左右，時間點處在metastore服務卡死而未恢復好時間點上），其它均表現正常。大膽預測，這樣的穩定水平已經能足夠滿足業務使用要求。當然還是需要補充說明的，這仍然是截止到我在整理這個文檔的運行情況，後面還指不定出來新情況。

總結

坦率講，hive服務層面並未根治，是時間問題，更多是個人能力問題，目前評估需要源代碼層面調整，局部的小補丁總會引出新問題，要麼做大版本升級。但通過變通手段緩解生產的實際問題，個人也有收穫。希望上述過程給大家一點啟發。

閱讀更多 大數據和雲計算技術 的文章

關鍵字: 雲計算 科技 卡頓