2019獨角獸企業重金招聘Python工程師標準>>>

個性化的需求

隨著互聯網知識信息指數級膨脹，個性化的需求對于用戶來說越來越重要，通過推薦算法和用戶點擊行為的流式計算可以很簡單的做出一個商用的推薦系統。

流程

java

spark streaming

kafka

redis

mysql

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

開發包使用KafkaUtils類

設置消費者offset

數據從kafka拉取時，可能因為程序異常，造成數據丟失或不一致，可以通過kafka把數據重新拉取，可以指定offset讀取。

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

利用receiver接收數據；

直接從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方式的優勢是：

簡化的并行：direct方式中，kafka的partiton與rdd的partition是一一對應的，并行讀取kafka數據，這種映射關系利于優化和理解。

高效：receiver方式中，為了達到0數據丟失，將數據存入Write ahead log中，這樣kafka和日志中就保存了兩份數據，浪費；direct方式不存在這個問題。

精確：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，并行垃圾回收。

轉載于:https://my.oschina.net/u/1000241/blog/1619063

總結

以上是生活随笔為你收集整理的大数据学习系列----基于Spark Streaming流式计算的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。