銘文一級：
第二章：初識實時流處理
需求：統計主站每個(指定)課程訪問的客戶端、地域信息分布
地域：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！S4、LinkedIn kafka、Flink（可離線可實時）
實時流處理流程=>
Webapp->WebServer->Flume->Kafka->Spark/Storm->RDBMS/NoSQL->可視化展示
產生 采集 清洗 分析 入庫 可視化
實時流處理在企業中的應用： 電信行業（實時監控流量是否超出） 電商行業
第三章：分布式日志收集框架Flume
傳統從Server到Hadoop處理上存在的問題=>
1.難以監控 2.IO的讀寫開銷大 3.容錯率高，負載均衡差 4.高延時，需隔一段時間啟動