常見問題 - E-MapReduce

本文介紹E-MapReduce Druid使用過程中遇到的一些常見問題以及解決方案。

索引失敗問題分析思路

當發現索引失敗時，一般遵循如下排錯思路：

對於批量索引
1. 如果curl直接返回錯誤，或者不返回，檢查一下輸入檔案格式。或者curl加上-v參數，觀察REST API的返回情況。
2. 在Overlord頁面觀察作業執行情況，如果失敗，查看頁面上的logs。
3. 在很多情況下並沒有產生logs。如果是Hadoop作業，開啟YARN頁面查看是否有索引作業產生，並查看作業執行log。
4. 如果上述情況都沒有定位到錯誤，需要登入到E-MapReduce Druid叢集，查看overlord的執行日誌（位於/mnt/disk1/log/druid/overlord—emr-header-1.cluster-xxxx.log），如果是HA叢集，查看您提交作業的那個Overlord。
5. 如果作業已經被提交到Middlemanager，但是從Middlemanager返回了失敗，則需要從Overlord中查看作業提交到了哪個worker，並登入到相應的worker，查看Middlemanager的日誌（位於/mnt/disk1/log/druid/middleManager-emr-header-1.cluster-xxxx.log）。
對於Kafka Indexing Service和SLS Indexing Service
1. 首先查看Overlord的Web頁面：http://emr-header-1:18090，查看Supervisor的運行狀態，檢查payload是否合理。
2. 查看失敗task的log。
3. 如果不能從task log定位出失敗原因，則需要從Overlord log排查問題。
對於Tranquility即時索引
查看Tranquility log，查看訊息是否被接收到了或者是否被丟棄（drop）掉了。
其餘的排查步驟同批量索引的2～5。
錯誤多數情況為叢集配置問題和作業問題。叢集配置問題包括：記憶體參數是否合理、跨叢集聯通性是否正確、安全叢集訪問是否通過、principal是否正確等等，作業問題包括作業描述檔案格式是否正確、輸入資料是否能夠正常被解析，以及一些其他的作業相關的配置（例如ioConfig）。

問題匯總

組件啟動失敗
此類問題多數是由於組件JVM運行參數配置問題，例如機器可能沒有很大的記憶體，而配置了較大的JVM記憶體或者較多的線程數量。
解決方案：查看組件日誌並調整相關參數即可解決。JVM記憶體涉及堆記憶體和直接記憶體。具體可參見Basic cluster tuning。
索引時YARN task執行失敗，顯示諸如Error: class com.fasterxml.jackson.datatype.guava.deser.HostAndPortDeserializer overrides final method deserialize.(Lcom/fasterxml/jackson/core/JsonParser;Lcom/fasterxml/jackson/databind/DeserializationContext;)Ljava/lang/Object; 之類的 jar 包衝突錯誤。
解決方案：在indexing的作業設定檔中加入如下配置。
```
"tuningConfig" : {
     ...
     "jobProperties" : {
         "mapreduce.job.classloader": "true"
         或者
         "mapreduce.job.user.classpath.first": "true"
     }
     ...
 }
```
其中參數mapreduce.job.classloader 讓MR job用獨立的classloader，mapreduce.job.user.classpath.first是讓MapReduce優先使用使用者的JAR包，兩個配置項配置一個即可。請參見 Working with different versions of Apache Hadoop。
indexing作業的日誌中報reduce無法建立segments目錄。
解決方案：
- 注意檢查deep storage的設定，包括type和directory。當type為local時，注意directory的使用權限設定。當type為HDFS時，directory盡量用完整的HDFS路徑寫法，例如hdfs://hdfs_master:9000/path。hdfs_master最好用IP，如果用網域名稱，要用完整的網域名稱，例如emr-header-1.cluster-xxxxxxxx，而不是emr-header-1。
- 用Hadoop批量索引時，要將segments的deep storage設定為hdfs，local的方式會導致MR作業處於UNDEFINED狀態，這是因為遠端YARN叢集無法在reduce task下建立local的segments目錄。（此針對獨立E-MapReduce Druid叢集）。
錯誤提示Failed to create directory within 10000 attempts…
此問題一般為JVM設定檔中java.io.tmp設定的路徑不存在的問題。設定該路徑並確保E-MapReduce Druid賬戶有許可權訪問即可。
錯誤提示com.twitter.finagle.NoBrokersAvailableException: No hosts are available for disco!firehose:druid:overlord
此問題一般是ZooKeeper的串連問題。確保E-MapReduce Druid與Tranquility對於ZooKeeper有相同的連接字串。E-MapReduce Druid預設的ZooKeeper路徑為/druid，因此確保Tranquility設定中zookeeper.connect包含路徑/druid。
說明 Tranquility Kafka設定中有兩個ZooKeeper的設定，一個為zookeeper.connect，串連E-MapReduce Druid叢集的ZooKeeper，一個為kafka.zookeeper.connect，串連Kafka叢集的ZooKeeper。
索引時MiddleManager提示找不到類com.hadoop.compression.lzo.LzoCodec。
這是因為EMR的Hadoop叢集配置了lzo壓縮。
解決方案：拷貝EMR $HADOOP_HOME/lib下的JAR包和native檔案夾到E-MapReduce Druid的druid.extensions.hadoopDependenciesDir（預設為$DRUID_HOME/hadoop-dependencies）。

索引時提示如下錯誤：

2018-02-01T09:00:32,647 ERROR [task-runner-0-priority-0] com.hadoop.compression.lzo.GPLNativeCodeLoader - could not unpack the binaries
  java.io.IOException: No such file or directory
          at java.io.UnixFileSystem.createFileExclusively(Native Method) ~[?:1.8.0_151]
          at java.io.File.createTempFile(File.java:2024) ~[?:1.8.0_151]
          at java.io.File.createTempFile(File.java:2070) ~[?:1.8.0_151]
          at com.hadoop.compression.lzo.GPLNativeCodeLoader.unpackBinaries(GPLNativeCodeLoader.java:115) [hadoop-lzo-0.4.21-SNAPSHOT.jar:?]

這個問題是因為java.io.tmp路徑不存在的問題。設定該路徑並確保E-MapReduce Druid賬戶有許可權訪問。