需求

統計主站每個(指定)課程訪問的客戶端、地域信息分布
地域：IP轉換
客戶端： useragent獲取
===> 如上兩個操作：采用(Spark/MapReduce)的方式進行統計

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

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

問題

按小時級別統計沒問題 如果按秒級進行統計，MapReduce則不現實,MapReduce時效性不好，處理時間較長。因為MapReduce是適合做離線批處理的，對于數據量并不關心(只要硬盤容量夠用就可以), 但是MapReduce并不能快速的處理一個作業，并顯示結果。因為MapReduce分為Map Task和Reducer Task, 他們都是進程級別的，每一次都需要啟動進程，運行完之后銷毀進程，這一過程是占用一定的時間的。雖然可以通過JVM復用，讓多個Task跑在一個jvm上，但是他的計算模型導致了他并不適合做我們的實時計算(中間過程還需要寫磁盤)

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

實時流處理的產生背景

時效性高

數據量大。原始數據價值密度很低，但是數據量大

實時流處理概述

實時計算：響應時間比較短, 離線批處理沒有響應時間限制（只要把結果跑出來就可以，有時需要跑十幾個小時），實時計算往往需要精確到秒級或毫秒級

流式計算：在不斷產生的數據流上進行計算。數據是源源不斷進來，永遠沒有盡頭。猶如滔滔江水連綿不絕又如黃河泛濫一發不可收拾。

實時流式計算：在不斷產生數據流的過程中實時計算。

離線計算與實時計算對比

數據來源
離線：HDFS歷史數據 數據量比較大
實時：消息隊列(Kafka), 實施新增/修改記錄過來的某一筆數據。

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

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

進程
離線：啟動+銷毀
實時：7*24 運行

實時流處理框架對比

通常情況下, 一種業務場景有多個框架能夠滿足需求。

Apache Storm

Apache Spark Streaming：基于spark API做了一個擴展，并不會像Storm那樣每一次處理一個數據。而是把時間間隔內所有數據拆封成一個個小批處理。所以Spark Streaming嚴格意義上來說并不是實時處理框架，而是一個微批處理框架。

Flink

IBM Stream

Yahoo! S4

LinkedIn Kafka

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

為什么不能直接將Flume手機的日志直接丟給Spark/Storm中呢？因為一般的訪問行為會有高峰期和低谷期，如果在高峰期直接發送給Spark中后，spark有可能會扛不住這么大的數據量導致崩潰，所以一般將數據先存放至Kafka中去，然后spark/storm直接從Kafka中獲取數據，這里的Kafka就可以起到一個緩沖的作用，然后將處理后的結果存放在關系型數據庫中去，然后可視化展示。

實時流處理在企業中的應用

電信行業：當你手機流量快要用光的時候，運營商會給你發送一個提醒短信。會實時根據流量使用情況告訴你。你就可以快速的知道流量使用情況。如果采用離線批處理，時效性就很不好。這就是一個實時流處理。

電商行業：雙十一大屏

總結

以上是生活随笔為你收集整理的Spark Streaming（一）概述的全部內容，希望文章能夠幫你解決所遇到的問題。

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