Spark Streaming(一)概述
需求
統(tǒng)計(jì)主站每個(指定)課程訪問的客戶端、地域信息分布
地域:IP轉(zhuǎn)換
客戶端: useragent獲取
===> 如上兩個操作:采用(Spark/MapReduce)的方式進(jìn)行統(tǒng)計(jì)
實(shí)現(xiàn)步驟:
課程編號、ip信息、useragent
進(jìn)行相應(yīng)的統(tǒng)計(jì)分析操作:MapReduce/Spark
項(xiàng)目架構(gòu)
日志收集:Flume
離線分析:MapReduce/Spark
統(tǒng)計(jì)結(jié)果圖形化展示
問題
按小時級別統(tǒng)計(jì)沒問題 如果按秒級進(jìn)行統(tǒng)計(jì),MapReduce則不現(xiàn)實(shí),MapReduce時效性不好,處理時間較長。因?yàn)镸apReduce是適合做離線批處理的,對于數(shù)據(jù)量并不關(guān)心(只要硬盤容量夠用就可以), 但是MapReduce并不能快速的處理一個作業(yè),并顯示結(jié)果。因?yàn)镸apReduce分為Map Task和Reducer Task, 他們都是進(jìn)程級別的,每一次都需要啟動進(jìn)程,運(yùn)行完之后銷毀進(jìn)程,這一過程是占用一定的時間的。雖然可以通過JVM復(fù)用,讓多個Task跑在一個jvm上,但是他的計(jì)算模型導(dǎo)致了他并不適合做我們的實(shí)時計(jì)算(中間過程還需要寫磁盤)如何解決? 實(shí)時流處理框架
實(shí)時流處理的產(chǎn)生背景
實(shí)時流處理概述
離線計(jì)算與實(shí)時計(jì)算對比
離線:HDFS歷史數(shù)據(jù) 數(shù)據(jù)量比較大
實(shí)時:消息隊(duì)列(Kafka), 實(shí)施新增/修改記錄過來的某一筆數(shù)據(jù)。
離線:MapReduce:map + reduce
實(shí)時:Spark(DStream/SS)
離線:速度慢
實(shí)時:快速
離線:啟動+銷毀
實(shí)時:7*24 運(yùn)行
實(shí)時流處理框架對比
通常情況下, 一種業(yè)務(wù)場景有多個框架能夠滿足需求。
實(shí)時流處理架構(gòu)與技術(shù)選型
為什么不能直接將Flume手機(jī)的日志直接丟給Spark/Storm中呢?因?yàn)橐话愕脑L問行為會有高峰期和低谷期,如果在高峰期直接發(fā)送給Spark中后,spark有可能會扛不住這么大的數(shù)據(jù)量導(dǎo)致崩潰,所以一般將數(shù)據(jù)先存放至Kafka中去,然后spark/storm直接從Kafka中獲取數(shù)據(jù),這里的Kafka就可以起到一個緩沖的作用,然后將處理后的結(jié)果存放在關(guān)系型數(shù)據(jù)庫中去,然后可視化展示。
實(shí)時流處理在企業(yè)中的應(yīng)用
總結(jié)
以上是生活随笔為你收集整理的Spark Streaming(一)概述的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 「已解决」台式电脑音量怎么调大
- 下一篇: Spark Streaming(二)Fl