【慕課網實戰】Spark Streaming實時流處理項目實戰筆記二之銘文升級版

銘文一級：

第二章：初識實時流處理

需求：統計主站每一個(指定)課程訪問的客戶端、地域信息分佈
地域：ip轉換 Spark SQL項目實戰
客戶端：useragent獲取 Hadoop基礎課程
==> 如上兩個操做：採用離線(Spark/MapReduce)的方式進行統計

實現步驟：
課程編號、ip信息、useragent
進行相應的統計分析操做：MapReduce/Spark

項目架構
日誌收集：Flume
離線分析：MapReduce/Spark
統計結果圖形化展現

問題
小時級別
10分鐘
5分鐘
1分鐘
秒級別

如何解決？？？ ==》 實時流處理框架

離線計算與實時計算的對比
1) 數據來源
離線： HDFS 歷史數據 數據量比較大
實時： 消息隊列(Kafka)，實時新增/修改記錄過來的某一筆數據

2）處理過程
離線： MapReduce： map + reduce
實時： Spark(DStream/SS)

3) 處理速度
離線： 慢
實時： 快速

4）進程
離線： 啓動+銷燬
實時： 7*24

 

第三章：分佈式日誌收集框架Flume

現狀分析：見圖

如何解決咱們的數據從其餘的server上移動到Hadoop之上？？？
shell cp hadoop集羣的機器上， hadoop fs -put ..... /

===> Flume

 

銘文二級：

第二章：初識實時流處理

實時流處理框架的產生背景：時效性高 數據量大

實時流處理與離線處理的對比=>

1.數據來源 2.處理過程 3.處理速度 4.進程（MapReduce進程啓動與銷燬 須要消耗大量資源 並且實時性跟不上）

實時流框架對比=>

Storm（真正的來一個處理一個）、Spark Streaming（時間間隔小批次處理）、IBM Stream、Yahoo！S四、LinkedIn kafka、Flink（可離線可實時）

實時流處理流程=>

Webapp->WebServer->Flume->Kafka->Spark/Storm->RDBMS/NoSQL->可視化展現

　　　 產生　　       採集     清洗      分析                入庫                  可視化

實時流處理在企業中的應用： 電信行業（實時監控流量是否超出） 電商行業

 

第三章：分佈式日誌收集框架Flume

傳統從Server到Hadoop處理上存在的問題=>

1.難以監控 2.IO的讀寫開銷大 3.容錯率高，負載均衡差 4.高延時，需隔一段時間啓動