您好,登錄后才能下訂單哦!
本篇內容主要講解“Storm為什么比Hadoop快”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Storm為什么比Hadoop快”吧!
“快”這個詞是不明確的,專業屬于點有兩個層面:
時延 , 指數據從產生到運算產生結果的時間,題主的“快”應該主要指這個。
吞吐, 指系統單位時間處理的數據量。
首先明確一點,在消耗資源相同的情況下,一般來說storm的延時低于mapreduce。但是吞吐也低于mapreduce。
storm的網絡直傳、內存計算,其時延必然比hadoop的通過hdfs傳輸低得多;當計算模型比較適合流式時,storm的流式處理,省去了批處理的收集數據的時間;因為storm是服務型的作業,也省去了作業調度的時延。所以從時延上來看,storm要快于hadoop。
說一個典型的場景,幾千個日志生產方產生日志文件,需要進行一些ETL操作存入一個數據庫。
假設利用hadoop,則需要先存入hdfs,按每一分鐘切一個文件的粒度來算(這個粒度已經極端的細了,再小的話hdfs上會一堆小文件),hadoop開始計算時,1分鐘已經過去了,然后再開始調度任務又花了一分鐘,然后作業運行起來,假設機器特別多,幾鈔鐘就算完了,然后寫數據庫假設也花了很少的時間,這樣,從數據產生到***可以使用已經過去了至少兩分多鐘。
而流式計算則是數據產生時,則有一個程序去一直監控日志的產生,產生一行就通過一個傳輸系統發給流式計算系統,然后流式計算系統直接處理,處理完之后直接寫入數據庫,每條數據從產生到寫入數據庫,在資源充足時可以在毫秒級別完成。
當然,跑一個大文件的wordcount,本來就是一個批處理計算的模型,你非要把它放到storm上進行流式的處理,然后又非要讓等所有已有數據處理完才讓storm輸出結果,這時候,你再把它和hadoop比較快慢,這時,其實比較的不是時延,而是比較的吞吐了。
storm是典型的流計算系統,mapreduce是典型的批處理系統。下面對流計算和批處理系統流程。
整個數據處理流程來說大致可以分三個階段:
1. 數據采集與準備
2. 數據計算(涉及計算中的中間存儲), 題主中的“那些方面決定”應該主要是指這個階段處理方式。
3. 數據結果展現(反饋)
1)數據采集階段,目前典型的處理處理策略:數據的產生系統一般出自頁面打點和解析DB的log,流計算將數據采集中消息隊列(比如kafaka,metaQ,timetunle)等。批處理系統一般將數據采集進分布式文件系統(比如HDFS),當然也有使用消息隊列的。我們暫且把消息隊列和文件系統稱為預處理存儲。二者在延時和吞吐上沒太大區別,接下來從這個預處理存儲進入到數據計算階段有很大的區別,流計算一般在實時的讀取消息隊列進入流計算系統(storm)的數據進行運算,批處理一系統一般會攢一大批后批量導入到計算系統(hadoop),這里就有了時延的區別。
2)數據計算階段,流計算系統(storm)的時延低主要有一下幾個方面
A: storm 進程是常駐的,有數據就可以進行實時的處理
mapreduce 數據攢一批后由作業管理系統啟動任務,Jobtracker計算任務分配,tasktacker啟動相關的運算進程
B: stom每個計算單元之間數據之間通過網絡(zeromq)直接傳輸。
mapreduce map任務運算的結果要寫入到HDFS,在于reduce任務通過網絡拖過去運算。相對來說多了磁盤讀寫,比較慢
C: 對于復雜運算
storm的運算模型直接支持DAG(有向無環圖)
mapreduce 需要肯多個MR過程組成,有些map操作沒有意義的
3)數據結果展現
流計算一般運算結果直接反饋到最終結果集中(展示頁面,數據庫,搜索引擎的索引)。而mapreduce一般需要整個運算結束后將結果批量導入到結果集中。
實際流計算和批處理系統沒有本質的區別,像storm的trident也有批概念,而mapreduce可以將每次運算的數據集縮小(比如幾分鐘啟動一次),facebook的puma就是基于hadoop做的流計算系統。
到此,相信大家對“Storm為什么比Hadoop快”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。