爬出過的坑

大資料運維過程就是一個踩坑的過程。如下分享一些踩過的坑，以供參考。

Hive

* hive的udf使用全名如select mydatabase.myfun(id) from mytable
* hive.hadoop.supports.splittable.combineinputformat引數為true時在textfile的gzip壓縮下可以合併檔案。
* hive中export HIVE_OPTS=1G可以控制beeline的記憶體。 
* filesinkoperator在寫bucketfile時，如果相關安裝目錄許可權異常可能無法載入lib*.so檔案從而導致寫檔案時丟擲filesystem closed異常
java.lang.unsupporttedopeationException: Currently the writer can only accept ByteArrayWritable 通常是rc表的serde設定問題。可使用lazyBinaryCOlumnSerde或者ColumnarSerde
* 不經過回收站的刪除表 drop table mytable purge.
* select count(distinct id) from mytable只有一個reduce，可以考慮改為 select count(*)from select distinct id from mytable
* beeline出現operation cancelled的的原因有： 1） 客戶端full gc 2）　服務端ｆｕｌｌｇｃ　3)客戶端服務端網路斷開  4） 服務端縣城執行耗時超過客戶端的sockettimeout時間，出發客戶端主動關閉
* hivesql處理完後的資料的avgsize小於16M的情況下，會觸發mr的merge操作。
* hive的sql對hdfs的操作很重。單個load操作，可能觸發20次的操作。對效能影響大
* 在執行beeline時新增--verbose=true引數可列印更多資訊
* 執行sql時，hive.metastore.client.socketTimeout出現連線資料庫timeout，如果是表分割槽過多，可以考慮後設資料中手動刪除表：
    select *from tbls where TBL_NAME="tableToDelete" (取出表的"id")    delete from partition_key_values where part_id in select part_id from partitions where tbl_id = "id"
    delete from partition_params where partid in select part_id from partitions where tbl_id = "id"
    delete from partition where tbl_id = "id"* 執行union all的操作可能導致stackoverflow
* 處理資料時cant be cast的異常同城是資料異常導致

Spark

* driver節點需要配置所有hbase程式的hostname和ip對應關係，否則可能出現無法解析節點導致訪問異常 creating new stage failed due to exception 
* spark讀取parquet表時，每個檔案都需要和hdfs互動，先訪問到備namenode情況下對效能影響較大
* spark或者hbasetoken的使用者需要有hbase:meta表的exec許可權
* hivecontext不能重複建立
* spark的beeline則需要透過spark_driver_memory來設定
* 多個欄位的group by 易引發oom
* spark寫hdfs的應用應保證可重入
* kafka單挑訊息過大可能引發classnotfoundexception : kafka.common.failedtosendmessag或者sockettimeoutexception can't find leader offset for set 可考慮調整"socket.request.max.bytes"socket.receive.buffer.bytes, socket.send.buffer.bytes, replica.socket.receive.buffer.bytes
* spark應用打包時，不應包含除應用的包之前的jar包
* Thriftserver的預設handler執行緒是500* spark的單個task不能支援2G以上的
* 值為空的配置或者boolean型別（true或者false）時，單詞拼錯的情況下可能導致driver啟動異常
* 執行union all的操作可能導致stackoverflow
* 在eventlog指定的目錄寫滿時(hdfs單個目錄的檔案數限制在104萬)，可能導致spark應用無法提交
* 執行structed Streaming 丟擲異常 java.lang.classNotFoundException : kafka.DefaultSource，是由於缺少jar包，spark-sql-kafka-*_*.jar導致serviceloader載入時，找不到kafkasource，從而引發異常 
* Spark應用開發需要匯入import org.apache.spark.sql.functions._ 以及import spark.implicits._  否則在編譯／執行時可能丟擲各種異常（如： value $ is not a member of StringContext  ）
* 開源Spark在hdp的yarn叢集中執行原生頁面的executor頁面無法開啟，需要將HADOOP_CONF_DIR/YARN_CONF_DIR下的yarn-site.xml檔案中的yarn.timeline-service.enabled引數設定為false，可參考* 開源Spark在hdp的yarn叢集中執行找不到executorLauncher類， 可參考* Spark的安全配置(principal和keytab檔案)可以透過如下方式傳入:  1) --principal和--keytab的方式傳入  2)在spark-defaults.conf配置檔案中配置spark.yarn.principal和spark.yarn.keytab  3) 在提交命令列時，傳入--properties-file指定配置檔案，並配置spark.yarn.principal和spark.yarn.keytab
* Structed Streaming基於eventtime的訊息，需要該欄位是timestamp型別，格式應當是"yyyy-mm-dd HH:mm:ss" 如果設定微微“yyyymmdd HH:mm:ss” 可能導致接收到資料後無法完成後續處理，從而無法得到結果。
* Structed streaming 如果是從kafka消費資料，應用在多個writestream時，每個writestream分別從kafka獲取訊息
* Structed Streaming 應用在UI頁面顯示不連續的問題可參考()* 安全場景下提交Spark應用丟擲如下異常：
        org.apache.hadoop.yarn.exceptions.YarnException: Failed to submit     application_1524902307937_0021 to YARN : Failed to renew token: Kind: HDFS_DELEGATION_TOKEN, Service: ha-hdfs:paasjq, Ident: (HDFS_DELEGATION_TOKEN token 69 for spark) 此異常是rm在handlesubmitApplication時從nn中獲取token失敗，導致應用提交異常。可重啟yarn規避該問題
* Structed Streaming 應用執行時，丟擲異常
  “Exception in thread "main" java.lang.NoSuchMethodError: net.jpountz.lz4.LZ4BlockInputStream.<init>(Ljava/io/InputStream;Z)V
at org.apache.spark.io.LZ4CompressionCodec.compressedInputStream(CompressionCodec.scala:122)”原因是應用在執行時對資料解碼（反序列化）時，使用了預設的lz4解壓縮演算法，在spark-core中依賴的lz4版本是1.4，而kafka-client中依賴的lz4版本是1.3版本，在生成解壓器時，版本不相容異常。 解決方法可參考網上修改原始碼解決，也可透過設定"spark.io.compression.codec","snappy"或其他壓縮演算法規避。鑑於修改原始碼重新打包替換較為繁瑣，建議設定其他壓縮演算法規避。
* Sparkstreaming應用在jobgenerator階段丟擲如下異常：“Error generating jobs for time”會呼叫到reprotError方法，進而設定error=e,將導致streamingContext.awaitTermination方法退出，進而結束應用
* SparkStreaming應用在job異常時，jobScheduler的handleJobCompletion方法，呼叫reportError方法，進而設定error=e,將導致streamingContext.awaitTermination方法退出，進而結束streaming應用。
* spark應用在遇到磁碟異常的情況下，預設會將task的retry同樣傳送到該container程式內執行，連續失敗後，將導致task失敗次數超限進而退出。在1.*版本可以透過設定spark.scheduler.executorTaskBlacklistTime禁止task的在一定時間內重新分配在之前執行異常的container內。在2.*版本中可透過設定spark.blacklist.enabled開啟黑名單機制並配置相關引數即可（可參考）* 編譯高版本Spark原始碼（2.*以上版本），丟擲異常“Failed to execute goal net.alchim31.maven:scala-maven-plugin:3.2.2:compile (scala-compile-first)”，需要將本地scala版本從2.10版本調整至2.11版本

Flink

 * flink開發過程中需要匯入org.apache.flink.streaming.api.scala._ 否則可能執行時某些轉換異常

Yarn

* Yarn透過配置獲取叢集總資源（cpu/mem／網路／io）資訊（與實際無關）
* Yarn叢集的資源狀態(cpu/mem使用)和主機的cpu/mem消耗無直接關係(Yarn只負責分配資源給應用，不*
  管應用如何使用)
* yarn透過app申請資源，根據使用者，以及剩餘資源判斷是否接受和執行app
*  Yarn根據配置的粒度以及app的申請分配資源
* Yarn只負責分配資源給應用，不管應用如何使用
*  yarn監控container程式的memory來判斷container使用資源是否超限
* Yarn排程策略考慮vcore和不考慮vcore的策略
*  score的概念只是用來劃分粒度，控制叢集能啟動的container數目
* Yarn只負責分配資源給應用（container），無法管控container如何使用資源（Yarn管理記憶體的使用，但無法直接cpu。cpu可透過cgroup控制）

Kafka

* 某些groupid的consumer無法消費資料，而其它groupid的consumer可以消費，可能是Kafka內部的consumer_offset的topic出現異常
* 消費kafka小時時，consumer端一直丟擲如下異常“NetworkClient: Bootstrap broker ***:6667 disconnected”異常，此時服務端丟擲異常如下：“ERROR Closing socket for *****:6667-******:53026 because of error (kafka.network.Processor)kafka.network.InvalidRequestException: Error getting request for apiKey: 3 and apiVersion: 2”，通常出現改現象端原因是消費端和kafka服務端端版本不匹配 。如客戶端使用0.10.1.10服務端時0.10.0.1.
* 安全叢集下消費kafka訊息 Error while fetching metadata for correlation Id ** [UNKNOWN_TOPIC_OR_PARTITION] 原因可能是使用的使用者沒有想過topic的讀取許可權
* 客戶端訪問kafka丟擲如下異常：“Couldn't find leader offsets for Set([topictest,1]))”，該異常是在獲取leader後衝leader獲取offset失敗，通常是kafka叢集不穩定（如長時間gc，網路異常等）導致，可參考調整如下引數：KAFKA_HEAP_OPTS、socket.request.max.bytes、socket.receive.buffer.bytes、socket.send.buffer.bytes、replica.socket.receive.buffer.bytes這些引數值的大小（例如配置KAFKA_HEAP_OPTS值為“-Xmx4G -XX:MaxDirectMemorySize=128m”）

HDFS

* hdfs datanode節點掛在磁碟資料或者規格不一致的情況下，hdfs的讀寫效能相差可能很大從而影響某些sql或者其他操作的效能
* HDFS效能可透過檢視檢視平均wait和processing時間來檢視hdfs是否存在效能瓶頸

Zookeeper相關

* zookeeper單獨掛盤或者調整-Dzookeeper.snapCount=3000減少zk寫入資料時間
* rm啟動異常時丟擲無法載入某個app檔案，需要再zk上刪除該app資訊
* 元件與zk連線出現異常（經常性斷鏈），可透過增大zksessiontimeout設定來提高服務可靠性

Hbase

* hbase沒有指定startkey endkey時，會全表掃描（rpc server kerberos principal name for service ***），效能較差
* rs節點的hostname和ip的一對多關係會引發rs個數的顯示和真實的個數不一致
* 在處理hbase表資料時，出現如下異常“hbaserowkey can't be null error while processing *******”，說明有value為空，此時可透過select* from tablename  a where a.rowkey is null or a.rowkey=""* 透過hive查詢相關表時，出現查詢失敗（許可權不足異常），部分region查詢成功，可能是部分節點的nscd/sssd服務異常。

codis/redis

* 客戶端訪問codis-proxy時，丟擲異常“ERR router is not online” 表示此時codis-proxy已經完成在zk上註冊zNode但是還未能完成上線，但無法提供服務。如果是在sparkstreaming應用中，該異常將導致executor退出，應用結束。 應用層需要再此場景下catch異常並處理（等待/丟棄）。

Others

* 應用出現讀檔案掛死，發訊息無返回，應用執行忙，各種timeout（connect,socket,read）等，需要考慮排查網路定保，full gc，死鎖，cpu異常，cpu節能，磁碟慢的硬體原因
* unknow  compression method等型別的異常通常是檔案損壞導致。
* impala和hive使用不同的parquet來，二者的parquet格式的表互相讀取可能引發型別轉換異常
* hue需要reset操作才能使某些配置生效或者變更生效
* 出現Distributed filesyste can't be cast to filesystem的情況下，一般都是classloader載入異常。
* /usr/lib64下的so檔案替換可能引發jvm啟動異常
* 儲存leveldb資料的磁碟異常，目錄許可權異常可能導致nm啟動異常
* nscd服務服務異常時處理方法：
    nscd -i password 
    nscd -i group
    nscp -i services
    nscd -i hosts 
    service nscd/sssd restart
*  執行shell指令碼時，丟擲異常, line 73: syntax error: unexpected end of file導致指令碼執行

作者：WestC
連結：