一、背景
由於公司的老集羣對於現有的開發工作者來說並不是特別的友好，數據模型也不是特別適用。所以爲了讓使用者更友好、數據更可靠，建立新集羣、構建數倉，新集羣搭建到使用，基於spark引擎自己構建ETL框架，在大量數據下，期間難免會遇到各種各樣的問題。於是找幾個踩過的比較經典的坑來說一下。
二、採坑過程
個人感覺單純開發SparkStreaming的過程不叫經驗，所以直接略過，來到測試環節，SparkApp進行開發測試，遇到了第一個頭疼個人也感覺比較經典的問題就是消費kafka偏移量越界問題
1、OffsetOutofRangeException
越界原因以及避免思路在我前面幾篇博客都有些，可以瞭解一下（代碼並不是最優，可以自己理解思路，找出解決方案）
https://blog.csdn.net/qq_41922058/article/details/86545270
2、基本這個時候已經是到年末了，所以將所有job全部啓動，回來看測試結果，由於是開發集羣，結果等全部任務啓動時，發現資源已經不夠。有的容器已經處於待定狀態此時可以查看集羣確定是否yarn配置導致資源不足，還是集羣本身資源已經不足，如果由於配置原因可以適量調大yarn.nodemanager.resource.memory-mb參數
3、放假回來之後發現任務已經過了大半，查看原因發現磁盤已經被寫滿，nodemanager由於空間原因被認爲不可使用，不去進行任務調度。
解決方案：進行磁盤擴容
https://blog.csdn.net/qq_41922058/article/details/87984205
4、集羣擴容之後繼續啓動任務，任務隨機出現如下錯誤
java.io.IOException: No space left on device
可以看出來明顯的還是磁盤空間不足
問題原因：由於是擴容磁盤導致單節點內數據不均勻
解決方案（官網）：
http://hadoop.apache.org/docs/current3/hadoop-project-dist/hadoop-hdfs/HDFSDiskbalancer.html
5、還有一個比較有意思的問題（並不是錯誤）
我在spark ui界面觀看任務執行過程時，會出現有的executor dead現象，觀看executor日誌報如下錯誤ERROR executor.CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM，通過查詢發現：此問題爲spark1.5之後的executor的動態管理機制spark.dynamicAllocation.executorIdleTimeout可以修改此參數，達到固定執行器，但此機制提高了集羣資源的利用率，所以可以不作處理；也可以直接關閉spark.dynamicAllocation.enabled
6、此外還可能會出現hdfs小文件問題（按照業務要求是否合併）
思路：可以定時啓動mapreduce進行小文件合併，具體實現方案自行查詢