Spark Streaming使用Receiver接收數據的話，會將數據存儲在Executor內存中。
預寫日誌機制
預寫日誌機制，簡寫爲WAL，全稱爲Write Ahead Log。從Spark 1.2版本開始，就引入了基於容錯的文件系統的WAL機制。如果啓用該機制，Receiver接收到的所有數據都會被寫入配置的checkpoint目錄中的預寫日誌。這種機制可以讓driver在恢復的時候，避免數據丟失，並且可以確保整個實時計算過程中，零數據丟失。 要配置該機制，首先要調用StreamingContext的checkpoint()方法設置一個checkpoint目錄。然後需要將spark.streaming.receiver.writeAheadLog.enable參數設置爲true。 然而，這種極強的可靠性機制，會導致Receiver的吞吐量大幅度下降，因爲單位時間內，有相當一部分時間需要將數據寫入預寫日誌。如果又希望開啓預寫日誌機制，確保數據零損失，又不希望影響系統的吞吐量，那麼可以創建多個輸入DStream，啓動多個Rceiver。 此外，在啓用了預寫日誌機制之後，推薦將複製持久化機制禁用掉，因爲所有數據已經保存在容錯的文件系統中了，不需要在用複製機制進行持久化，保存一份副本了。只要將輸入DStream的持久化機制設置一下即可，persist(StorageLevel.MEMORY_AND_DISK_SER)。（之前講過，默認是基於複製的持久化策略，_2後綴）。
設置Receiver接收速度和反壓機制
如果集羣資源有限，並沒有大到，足以讓應用程序一接收到數據就立即處理它，Receiver可以被設置一個最大接收限速，以每秒接收多少條單位來限速。
spark.streaming.receiver.maxRate和spark.streaming.kafka.maxRatePerPartition參數可以用來設置，前者設置普通Receiver，後者是Kafka Direct方式。
Spark 1.5中，對於Kafka Direct方式，引入了backpressure機制，從而不需要設置Receiver的限速，Spark可以自動估計Receiver最合理的接收速度，並根據情況動態調整。只要將spark.streaming.backpressure.enabled設置爲true即可。 在企業實際應用場景中，通常是推薦用Kafka Direct方式的，特別是現在隨着Spark版本的提升，越來越完善這個Kafka Direct機制。優點：1、不用receiver，不會獨佔集羣的一個cpu core；2、有backpressure自動調節接收速率的機制。
應用程序升級
由於Spark Streaming應用程序都是7 * 24小時運行的。因此如果需要對正在運行的應用程序，進行代碼的升級，那麼有兩種方式可以實現：
1、升級後的Spark應用程序直接啓動，先與舊的Spark應用程序並行執行。當確保新的應用程序啓動沒問題之後，就可以將舊的應用程序給停掉。但是要注意的是，這種方式只適用於，能夠允許多個客戶端讀取各自獨立的數據，也就是讀取相同的數據。
2、小心地關閉已經在運行的應用程序，使用StreamingContext的stop()方法，可以確保接收到的數據都處理完之後，才停止。然後將升級後的程序部署上去，啓動。這樣，就可以確保中間沒有數據丟失和未處理。因爲新的應用程序會從老的應用程序未消費到的地方，繼續消費。但是注意，這種方式必須是支持數據緩存的數據源纔可以，比如Kafka、Flume等。如果數據源不支持數據緩存，那麼會導致數據丟失。
注意：配置了driver自動恢復機制時，如果想要根據舊的應用程序的checkpoint信息，啓動新的應用程序，是不可行的。需要讓新的應用程序針對新的checkpoint目錄啓動，或者刪除之前的checkpoint目錄。
監控應用程序
當Spark Streaming應用啓動時，Spark Web UI會顯示一個獨立的streaming tab，會顯示Receiver的信息，比如是否活躍，接收到了多少數據，是否有異常等；還會顯示完成的batch的信息，batch的處理時間、隊列延遲等。這些信息可以用於監控spark streaming應用的進度。
Spark UI中，以下兩個統計指標格外重要：
1、處理時間——每個batch的數據的處理耗時
2、調度延遲——一個batch在隊列中阻塞住，等待上一個batch完成處理的時間
如果batch的處理時間，比batch的間隔要長的話，而且調度延遲時間持續增長，應用程序不足以使用當前設定的速率來處理接收到的數據，此時，可以考慮增加batch的間隔時間。