hive在E-MapReduce集群的實踐（一）hive異常排查入門

hive是hadoop集群最常用的數據分析工具，只要運行sql就可以分析海量數據。初學者在使用hive時，經常會遇到各種問題，不知道該怎麼解決。

本文是hive實踐系列的第一篇，以E-MapReduce集群環境為例，介紹常見的hive執行異常，定位和解決方法，以及hive日誌查看方法。

本文同步到雲棲社區，其他轉載需要先聯繫我。

一.常見異常表現

主要是執行hive sql時卡住，提示異常信息。

如執行sql時直接提示異常信息，執行sql時卡住，顯示mapreduce進度一直0%，mapreduce進度長時間不變化，執行一半提示異常退出，等等。

二.異常定位和解決

2.1.執行sql直接提示異常信息

一般是語法問題，資源問題或hive服務異常。

2.1.1 語法解析錯誤

sql寫的有問題。如ParseException

hive> show table;FAILED: ParseException line 1:10 mismatched input <EOF> expecting EXTENDED near table in show statement

提示table語法錯誤，正確的是show tables。遇到查閱hive語法確定正確寫法。

hive> select * from test;FAILED: SemanticException [Error 10001]: Line 1:14 Table not found test

表test不存在。檢查表名是否拼寫錯誤，大小寫是否正確，等等。

2.1.2.MetaException

一般是metastore有問題。如

hive> show tables;FAILED: SemanticException MetaException(message:Could not connect to meta store using any of the URIs provided. Most recent failure: org.apache.thrift.transport.TTransportException: java.net.ConnectException: Connection refused (Connection refused)

連不上metastore，說明metastore服務有問題，如oom，被操作系統kill，等。先檢查metastore進程是否存在，看進程啟動時間是否有重啟。再來看metastore的日誌，是否有oom，操作系統kill。查看metastore日誌的方式第三章介紹。

如果有oom，一般需要配大metastore的內存。如果有被操作系統kill，說明機器使用的總內存比物理內存大了，要麼升級機器配置，要麼合理規劃主節點內存，尤其是要注意限制在主節點上提交作業的進程數，避免佔用過多內存。

2.2.執行卡住

要看hive日誌分析原因，一般是hive客戶端遇到某種可重試異常一直在重試，未返回異常信息。

有一次遇到，查看hive客戶端日誌，反覆有報錯說不能識別一個機器域名。確定問題是因為使用的hive on tez，hive client要通過【集群內域名：埠】來訪問tez作業的appmaster，而執行hive命令的伺服器沒有配置集群內域名的解析，所以無法識別該域名。在/etc/hosts下增加域名配置，拷貝主節點的/etc/hosts域名配置，解決了該問題。

2.3.mapreduce進度一直0%

一般是集群或者作業所屬的yarn資源池隊列沒有資源，導致作業狀態一直pending。

可以打開yarn ui，默認是主節點的8088埠(EMR控制台可以在開源組件快捷入口進入)，查看該hive作業是不是一直在pending。

pending首先確定是否配置了yarn資源池，資源池配置有無問題，如配置的資源太少，運行的作業太多。如有問題要修改資源池配置，根據配置修改情況刷新資源隊列或重啟resourcemanager。

如果排除了資源池問題，還有可能是運行的hadoop作業太多，那麼要等待其他作業完成釋放資源，或者直接殺掉其他不重要的作業。

2.4. 所有job的mapreduce進度長時間不變化

極有可能有死鎖。常見場景是集群或yarn資源池隊列資源有限，同時運行了好多作業job。各作業appmaster，提前啟動的reduce用光了資源，沒資源繼續啟動map了，於是死鎖。

解決方案是避免reduce提前啟動佔用資源，設置reduce在map都執行完後再啟動。修改maped-site.xml的mapreduce.job.reduce.slowstart.completedmaps參數，改為0.98，或者1，殺掉所有作業重新執行。這樣只有98%或100%的map都執行完，才會啟動reduce進程。

要注意修改該參數會延長單個job的運行總時間，只有同時運行很多job，瞬時資源需要遠大於集群/資源隊列規模，才有必要調整該參數。

2.5. 執行一半異常退出

常見map/reduce oom。

查看job client運行日誌，並用yarn ui查看sql任務的map，reduce task日誌，是否有oom信息。如果有，根據實際需要，調大內存。可以在執行的sql前，通過set mapreduce.map.memory.mb =4096;(該數值僅為舉例，以實際需要來確定)修改map，set mapreduce.reduce.memory.mb = 4096;修改reduce的內存來避免oom。

還有其他一些造成oom的原因和解決辦法，下篇文章再來介紹。

三.hive日誌位置

近期的版本更新會支持在EMR控制台上查看各服務的日誌，敬請期待。當前可以登錄集群查看hive的日誌。

服務進程日誌

hive日誌默認是 /tmp/[user]/hive.log，由於tmp目錄機器重啟後會清空，所以在EMR集群里，hiveserver和metastore進程在啟動時配置了額外的日誌參數，日誌輸出在/var/log/hive/目錄，分別為hiveserver2.log和metastore.log。每天會滾動生成一個帶日期的新文件，最多保留30天。

服務進程日誌一般用來調查異常日誌信息，是否有oom，操作系統kill，元數據訪問錯誤，等等。

作業運行日誌

運行hive的client日誌依然在 /tmp/[user]/hive.log里，例如用root用戶運行sql，日誌會在/tmp/root/hive.log文件里。

hive job的mapreduce task跟其他hadoop job的mapreduce task一樣，日誌分散在集群的各個節點上，可以通過yarn ui點擊job信息跳轉查看。