實時流處理架構示意圖
___
|Web|
| |----------------> WebServer---------->Flume---->Kafka
|app| /var/log/access.log |
|___| |
\|/
Spark/Storm
|
\|/
可視化展示 <----------RDBMS/NoSql
Spark和MapReduce對比
|
|-MapReduce特點|--1.僅支持Map和Reduce兩種操作
| |--2.處理效率低效。
| | a）Map中間結果寫磁盤，Reduce寫HDFS，多個MR之間通過HDFS交換數據; 任務調度和啓動開銷大;
| | b）無法充分利用內存
| | c）Map端和Reduce端均需要排序
| |--3.不適合迭代計算(如機器學習、圖計算等)，交互式處理(數據挖掘) 和流式處理(點擊日誌分析)
|
|-Spark特點|--1.運行速度快(基於內存計算和引入DAG執行引擎);
| | 如果數據由磁盤讀取，速度是hadoop mapreduce的10倍以上，
| | 如果數據從內存讀取，速度是hadoop mapreduce的100倍以上。
| |--2.易用性好，spark不僅支持scala編程呢個，還支持java和python編寫。
| |--3.通用性好
| |--4.隨處運行
|
|-spark和mapreduce的比較|1.spark把中間數據放在內存中，迭代運算效率高。
| | mapreduce中的計算結果保存在磁盤上，
| | 而spark支持DAG圖的分佈式並行計算的編程框架，減少了迭代過程中數據的落地，提高了處理效率。
| |
| |2.spark容錯性高。
| | 引進了RDD,如果數據集一部分丟失，則可以重建。另外，在RDD計算時可以通過checkpoint來實現容錯。
| |
| |3.spark更加通用。不像hadoop只提供map和reduce兩種操作。
| | spark提供的數據集操作類型有很多種，大致分爲轉換操作和行動操作。
| | 轉換操作包括map,filter,flatmap,sample,groupbykey,reducebykey,union,join,cogroup,mapvalues,sort和partionby等多種操作類型，
| | 行動操作包括collect,reduce,lookup和save等操作類型。
| | 另外，各個處理節點之間的通信模型不再像Hadoop只有shuffle一種模式，用戶可以命名，物化，控制中間結果的存儲，分區等。
Spark(Streaming)和Storm對比
|
|_特性對比________________________________________________________
| | Stom | Spark |
|__________|________________________|_____________________________|
|計算模型 | 純實時,來一條處理一條 | 準實時,對一個時間段內的數據|
| | | 收集起來,作爲一個RDD再處理 |
| | | |
|計算延時 | 毫秒級 | 秒級 |
| | | |
|吞吐量 | 低 | 高 |
| | | |
|事務機制 | 支持完善 | 支持,但不夠完善 |
| | | |
|健壯性 | Zookeeper,Acker,非常強 | Checkpoint，WAL，一般 |
| | | |
|動態並行度| 支持 | 不支持 |
|__________|________________________|_____________________________|
|
|-Storm適用場景|--1.需要純實時，不能忍受1秒以上延遲的場景下使用，
| | 比如實時金融系統，要求純實時進行金融交易和分析
| |--2.對於實時計算的功能中，要求可靠的事務機制和可靠性機制，即數據的處理完全精準，
| | 一條也不能多，一條也不能少，也可以考慮使用Storm
| |--3.若還需要針對高峯低峯時間段，動態調整實時計算程序的並行度，
| | 以最大限度利用集羣資源（通常是在小型公司，集羣資源緊張的情況），也可以考慮用Storm
| |--4.如果一個大數據應用系統，它就是純粹的實時計算，
| | 不需要在中間執行SQL交互式查詢、複雜的transformation算子等，那麼用Storm是比較好的選擇
|
|-Spark適用場景|--1.不要求純實時，不要求強大可靠的事務機制，不要求動態調整並行度，
| | 那麼可以考慮使用Spark Streaming
| |--2.如果一個項目除了實時計算之外，還包括了離線批處理、交互式查詢等業務功能，
| | 而且實時計算中，可能還會牽扯到高延遲批處理、交互式查詢等功能，
| | 那麼就應該首選Spark生態,三者可以無縫整合
| | |
| | |---用Spark Core 開發離線批處理
| | |---用Spark SQL 開發交互式查詢
| | |---用Spark Streaming開發實時計算
| |--3.吞吐量要求很高的場景(但並不是所有實時計算場景下,都那麼注重吞吐量)