上個月通過email，幫朋友的朋友解決了乙個cloudera的spark-sql無法訪問hbase做資料分析的問題，記錄一下。
首先，對方已經做好了hive訪問hbase，所以spark-sql原則上可以通過呼叫hive的元資料來訪問hbase。但是執行極慢，而且日誌無報錯。中間都是郵件溝通，先問了幾個問題，是否啟用了kerberos，是否hive訪問hbase正常，hbase shell訪問資料是否正常等等，回答說沒有用kerberos，hive訪問hbase正常，spark-sql讀取hive元資料也正常，hbase shell也正常，就是spark-sql跑不了。
其次，對方有兩套環境，實驗室環境可以跑，但是生產環境不能跑，然後實驗室和生產環境版本和各種xml配置都完全一樣，所以實在找不到不能跑的原因了。
前期看日誌，由於沒有任何warn或error，所以很難排查，初步推斷是由於配置錯誤造成的，但是**配置錯誤，因為都是郵件，無法確定。後來對方又發過來乙個日誌，說約3小時後報錯，顯示如下。
job aborted due to stage failure: task 0 in stage 0.0 failed 4 times, most recent failure: lost task 0.3 in stage 0.0 (tid 3, bdata-h2): org.apache.hadoop.hbase.client.noserverforregionexception: unable to find region for in ******xx after 35 tries.spark介面中的這段報錯證明了確實是配置錯誤的這個推斷，這個報錯通常是由於spark無法通過api訪問hbase的region造成的。那麼，如果是cloudera版的，都是預先就已經做好相容性了，所以可以排除因相容性問題導致的無法訪問，那麼只能有乙個原因就是配置錯誤。
接著對比了一下實驗室環境和生產環境的spark啟動日誌，發現兩邊所載入的jar包不一致，推斷是spark-env或者是hbase-env配置有出入導致的，將這一推斷告知對方，並建議將hbase/lib/*和hbase-site.xml等檔案寫入到spark的spark_dist_classpath中。於是對方將hbase/lib和/etc/hbase/conf路徑新增到spark_dist_classpath中，問題解決。
這個排錯是個特別小的問題，但是本著可能會對他人有幫助，同時自己別忘了的原則，還是記錄一下。
Hadoop運維記錄系列 九
linux作業系統針對hadoop的引數和命令調優。對於hadoop本身的引數調優，寫的已經不少了，作業系統方面的不多，記錄一下我用的系統引數。先寫一點，想起哪個再往裡面加。一 系統核心引數調優sysctl.conf net.ipv4.ip forward 0 net.ipv4.conf.defau...
Hadoop運維記錄系列 九
linux作業系統針對hadoop的引數和命令調優。對於hadoop本身的引數調優，寫的已經不少了，作業系統方面的不多，記錄一下我用的系統引數。先寫一點，想起哪個再往裡面加。一 系統核心引數調優sysctl.conf net.ipv4.ip forward 0 net.ipv4.conf.defau...
Hadoop運維記錄系列 二十二
今天抽空解決了乙個hadoop集群的乙個非常有意思的故障，之所有有意思，是這個故障既可以稱之為故障，又不算是故障，說不算問題吧，作業跑的特慢，說算問題吧，作業不但都能跑出來，還沒有任何報錯，所以還比較難查。故障表象是一幫人嚷嚷作業太慢了，跑不動，但是基本上嚷嚷一會就能跑出來，但相對於原來還是慢。我看...