spark streaming 踩過的那些坑

 

• 系統背景

 

 

 

1. spark streaming + Kafka高級API receiver
2. 目前資源分配（如今系統比較穩定的資源分配），獨立集羣

   --driver-memory 50G
   --executor-memory 8G
   --num-executors 11
   --executor-cores 5

 

 

 

 

• 廣播變量

 

1. 廣播變量的初始化

    1.1.executor端，存放廣播變量的對象使用非靜態，由於靜態變量是屬於類的，不能使用構造函數來初始化。在executor端使用靜態的時候，它只是定義的時候的一個狀態，而在初始化時設置的值取不到。而使用非靜態的對象，其構造函數的初始化在driver端執行，故在集羣能夠取到廣播變量的值。

2. 廣播變量的釋放

    2.1.當filter增量爲指定大小時，進行廣播，雖然廣播的是同一個對象，可是，廣播的ID是不同的，並且ID號愈來愈大，這說明對於廣播來講，它並非一個對象，而只是名字同樣的不一樣對象，若是不對廣播變量進行釋放，將會致使executor端內存佔用愈來愈大，而一直沒有使用的廣播變量，被進行GC，會致使GC開銷超過使用上線，致使程序失敗。
    2.2.解決方案：這廣播以前，先調用unpersist()方法，釋放不用的廣播變量

 

 

• 使用Kafka 的高級API receiver

 

1. 在使用receiver高級API時，因爲receiver、partition、executor的分配關係，常常會致使某個executor任務比較繁重，進而影響總體處理速度

    1.1.最好是一個receiver對應一個executor

2. 因爲前段時間數據延遲比較嚴重，就想，能不能讓全部executor的cores都去處理數據？因此調整receiver爲原來的四倍，結果系統啓動時，就一下衝上來很是大的數據量，致使系統崩潰，可見，receiver不只跟partition的分配有關，還跟數據接收量有關

3. 在實際處理數據中，因爲消息延遲，能夠看到，有的topic處理速度快有的慢，緣由分析以下：

    3.1.跟消息的格式有關，有的是序列化文件，有的事json格式，而json的解析相對於比較慢
    3.2.有時候拖累整個集羣處理速度的，除了大量數據，還跟單條數據的大小有關

 

如下是程序跑掛的一些異常，和緣由分析

 

 

​

 

​

 

​

 

​

 

​

 

 

問題矯正：

第一張圖片的，解決方案的倒數第二個，
spark.memory.storageFraction（動態內存的百分比設置），應該爲spark.storage.memoryFraction（靜態內存分配的設置）   （因爲原文檔丟失，致使沒法修改文檔。） 

若是有什麼問題，歡迎你們指出，共同探討，共同進步