flume整合sparkStreaming問題

• (1)、如何實現sparkStreaming讀取flume中的數據

  • 可以這樣說：

    • 前期經過技術調研，查看官網相關資料，發現sparkStreaming整合flume有2種模式，一種是拉模式，一種是推模式，然後在簡單的聊聊這2種模式的特點，以及如何部署實現，需要做哪些事情，最後對比兩種模式的特點，選擇那種模式更好。

      • 推模式：Flume將數據Push推給Spark Streaming

      • 拉模式：Spark Streaming從flume 中Poll拉取數據

• (2)、在實際開發的時候是如何保證數據不丟失的

  • 可以這樣說：

    • flume那邊採用的channel是將數據落地到磁盤中，保證數據源端安全性（可以在補充一下，flume在這裏的channel可以設置爲memory內存中，提高數據接收處理的效率，但是由於數據在內存中，安全機制保證不了，故選擇channel爲磁盤存儲。整個流程運行有一點的延遲性）

    • sparkStreaming通過拉模式整合的時候，使用了FlumeUtils這樣一個類，該類是需要依賴一個額外的jar包（spark-streaming-flume_2.10）

    • 要想保證數據不丟失，數據的準確性，可以在構建StreamingConext的時候，利用StreamingContext.getOrCreate（checkpoint, creatingFunc: () => StreamingContext）來創建一個StreamingContext,使用StreamingContext.getOrCreate來創建StreamingContext對象，傳入的第一個參數是checkpoint的存放目錄，第二參數是生成StreamingContext對象的用戶自定義函數。如果checkpoint的存放目錄存在，則從這個目錄中生成StreamingContext對象；如果不存在，纔會調用第二個函數來生成新的StreamingContext對象。在creatingFunc函數中，除了生成一個新的StreamingContext操作，還需要完成各種操作，然後調用ssc.checkpoint(checkpointDirectory)來初始化checkpoint功能，最後再返回StreamingContext對象。 這樣，在StreamingContext.getOrCreate之後，就可以直接調用start()函數來啓動（或者是從中斷點繼續運行）流式應用了。如果有其他在啓動或繼續運行都要做的工作，可以在start()調用前執行。

    • 流式計算中使用checkpoint的作用：

      • 保存元數據，包括流式應用的配置、流式沒崩潰之前定義的各種操作、未完成所有操作的batch。元數據被存儲到容忍失敗的存儲系統上，如HDFS。這種ckeckpoint主要針對driver失敗後的修復。

      • 保存流式數據，也是存儲到容忍失敗的存儲系統上，如HDFS。這種ckeckpoint主要針對window operation、有狀態的操作。無論是driver失敗了，還是worker失敗了，這種checkpoint都夠快速恢復，而不需要將很長的歷史數據都重新計算一遍（以便得到當前的狀態）。

    • 設置流式數據checkpoint的週期

      • 對於一個需要做checkpoint的DStream結構，可以通過調用DStream.checkpoint(checkpointInterval)來設置ckeckpoint的週期，經驗上一般將這個checkpoint週期設置成batch週期的5至10倍。

    • 使用write ahead logs功能

      • 這是一個可選功能，建議加上。這個功能將使得輸入數據寫入之前配置的checkpoint目錄。這樣有狀態的數據可以從上一個checkpoint開始計算。開啓的方法是把spark.streaming.receiver.writeAheadLogs.enable這個property設置爲true。另外，由於輸入RDD的默認StorageLevel是MEMORY_AND_DISK_2，即數據會在兩臺worker上做replication。實際上，Spark Streaming模式下，任何從網絡輸入數據的Receiver（如kafka、flume、socket）都會在兩臺機器上做數據備份。如果開啓了write ahead logs的功能，建議把StorageLevel改成MEMORY_AND_DISK_SER。修改的方法是，在創建RDD時由參數傳入。

    • 使用以上的checkpoint機制，確實可以保證數據0丟失。但是一個前提條件是，數據發送端必須要有緩存功能，這樣才能保證在spark應用重啓期間，數據發送端不會因爲spark streaming服務不可用而把數據丟棄。而flume具備這種特性，同樣kafka也具備。

• (3)Spark Streaming的數據可靠性

  • 有了checkpoint機制、write ahead log機制、Receiver緩存機器、可靠的Receiver（即數據接收並備份成功後會發送ack），可以保證無論是worker失效還是driver失效，都是數據0丟失。原因是：如果沒有Receiver服務的worker失效了，RDD數據可以依賴血統來重新計算；如果Receiver所在worker失敗了，由於Reciever是可靠的，並有write ahead log機制，則收到的數據可以保證不丟；如果driver失敗了，可以從checkpoint中恢復數據重新構建。