大數據學習系列----基於Spark Streaming流式計算

個性化的需求

隨着互聯網知識信息指數級膨脹，個性化的需求對於用戶來講愈來愈重要，經過推薦算法和用戶點擊行爲的流式計算能夠很簡單的作出一個商用的推薦系統。

流程

1. java
2. spark streaming
3. kafka
4. redis
5. mysql

spark streaming從kafka讀取用戶行爲數據，過濾數據後從redis中拉取物品類似度矩陣，從db或緩存中獲取用戶歷史行爲，經過協同過濾進行興趣/ctr候選集計算，將結果緩存到redis，異步持久化到db，經過接口進行數據展現。

開發包使用KafkaUtils類

設置消費者offset

數據從kafka拉取時，可能由於程序異常，形成數據丟失或不一致，能夠經過kafka把數據從新拉取，能夠指定offset讀取。

從kafka拉取數據，轉換爲spark streaming中的數據結構DStream。 接收數據有兩種：

1. 利用receiver接收數據；
2. 直接從kafka讀取數據；

receiver方式

基本的使用kafka高階api，接收的全部數據存儲在spark的executor中，以後spark streaming提交的job會處理這些數據。

reveiver方式，spark中partiton和kafka的partition並非相關的，若是加大每一個topic的partition數量，僅僅增長線程來處理由單一receiver消費的主題，但並無增長spark在處理數據上的並行度。

對於不一樣的group和topic，可使用多個receiver建立不一樣的DStream來提高並行度，以後利用union來統一成一個DStream。

直接讀取方式

Direct方式，沒有receiver這一層，會週期性的獲取kafka中每一個topic的每一個partition中新的offset，以後根據設定的maxRatePerPartition來處理每一個batch。

相較於receiver方式的優點是：

1. 簡化的並行：direct方式中，kafka的partiton與rdd的partition是一一對應的，並行讀取kafka數據，這種映射關係利於優化和理解。
2. 高效：receiver方式中，爲了達到0數據丟失，將數據存入Write ahead log中，這樣kafka和日誌中就保存了兩份數據，浪費；direct方式不存在這個問題。
3. 精確：receiver方式，使用的是kafka的高階api從zk中獲取offset值，也是傳統的同kafka中讀取的方式，但spark streaming消費數據和zk中記錄的offset不一樣步，偶爾形成數據重複消費；direct方式直接使用低階kafka api，offset利用spark streaming的checkpoints記錄，消除不一致。

receiver方式，是從zk獲取offset值，zk保存了當前消費的offset值，若是從新啓動開始消費會接着上次offset繼續消費。 direct方式中，直接從kafka來讀取數據，offset要本身記錄，能夠經過checkpoint，數據庫，文件記錄，或者寫回到zk。

調優

若是批處理時間設置短，產生的job並不能在這期間完成，就會形成數據不斷累積，致使spark streaming阻塞。

spark streaming中的DStream若是被反覆利用，最好使用cache()，將數據流緩存起來，防止過分調度形成網絡開銷。

設置合理的GC，並行垃圾回收。