SparkStreaming專案實戰系列——實時流概述

Spark官網關於Spark2.2.0需要以下條件:
maven3.3.9+
Java8+
Spark2.2.0

​

1.初識實時流處理

1.1業務現狀分析

• 需求：統計主站每個(制定)課程訪問的客戶端、地域資訊分佈
  
  • 地域:ip轉換 SparkSQL專案實戰
  • 客戶端：useragent獲取 Hadoop基礎課程
  • 如上兩個操作：採用離線操作(Map/Reduce操作)的方式進行統計
• 實現步驟
  
  • 課程編號。ip資訊，useragent
  • 進行相應的統計分析操作：MapReduce、Spark
• 專案架構
  
  • 日誌收集：Flume
  • 離線分析：MapReduce/Spark
  • 圖形化展示結果
• 問題
  
  • 小時級別
  • 10小時-秒級別，由於MR都是程序級別的，要產生和銷燬，需要佔用時間空間，不能實時處理
• 如何解決？即是實時流處理引入的目標。

1.2 實時流處理產生背景

• 時效性高
• 資料量大(必須以實時的方式處理原始的資料)

1.3 實時流處理概述

• 實時計算(響應時間比較短，離線批處理沒有時間的限制)
• 流式計算(在不斷產生的資料流上進行的計算)
• 實時流式計算

1.4 離線計算與實時計算對比

• 資料來源
  
  • 離線：HDFS上的歷史資料，資料量比較大
  • 實時：訊息佇列(kafka)，實時新增/修改記錄過來的某一筆資料
• 處理過程
  
  • 離線：MapReduce:map+reduce
  • 實時：Spark(DStream/SS)
• 處理速度
  
  • 離線：慢
  • 實時：快速
• 程序
  
  • 離線：啟動+銷燬
  • 實時：7*24

1.5實時流處理框架對比

• Apache Storm
• Apache Spark Streaming(並不會像Storm每一次處理一條資料更新，而是按照時間間隔拆分為小的批處理，嚴格意義上是一個微小時間間隔的批處理)
• IBM Stream
• Yahoo S4
• LinkedIn Kafka (一個分散式的流平臺)
• flink

1.6實時流處理架構與技術選型

 Web:
  app:
  ---------------------
 
  WebServer:
  /var/log/access.log
  ---------------------
  Flume:日誌收集
  Kafka：加一層訊息佇列應付資料高峰期
  Spark/Storm: 
  RDBMS/NoSQL:
  視覺化顯示：

1.7實時流處理適用場景在企業的應用

• 電信行業
• 電商行業