reference
[1]
批處理在大資料世界有著悠久的歷史。批處理主要操作大容量靜態資料集,並在計算過程完成後返回結果。
批處理模式中使用的資料集通常符合下列特徵:
批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時,必須將資料集作為乙個整體加以處理,而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中資料維持自己的狀態。
需要處理大量資料的任務通常最適合用批處理操作進行處理。無論直接從持久儲存裝置處理資料集,或首先將資料集載入記憶體,批處理系統在設計過程中就充分考慮了資料的量,可提供充足的處理資源。由於批處理在應對大量持久資料方面的表現極為出色,因此經常被用於對歷史資料進行分析。
大量資料的處理需要付出大量時間,因此批處理不適合對處理時間要求較高的場合。
apache hadoop是代表性的批處理框架。
流處理系統會對隨時進入系統的資料進行計算。相比批處理模式,這是一種截然不同的處理方式。流處理方式無需針對整個資料集執行操作,而是對通過系統傳輸的每個資料項執行操作。
流處理中的資料集是「無邊界」的,這就產生了幾個重要的影響:
流處理系統可以處理幾乎無限量的資料,但同一時間只能處理一條(真正的流處理)或很少量(微批處理,micro-batch processing)資料,不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法,但流處理主要針對***更少,更加功能性的處理(functional processing)進行優化。
功能性操作主要側重於狀態或***有限的離散步驟。針對同乙個資料執行同乙個操作會或略其他因素產生相同的結果,此類處理非常適合流處理,因為不同項的狀態通常是某些困難、限制,以及某些情況下不需要的結果的結合體。因此雖然某些型別的狀態管理通常是可行的,但這些框架通常在不具備狀態管理機制時更簡單也更高效。
此類處理非常適合某些型別的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程式錯誤日誌,以及其他基於時間的衡量指標是最適合的型別,因為對這些領域的資料變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應,並且關注一段時間內變化趨勢的資料。
流處理是無限界的,適合於處理大量近乎實時的低延遲要求的資料。
apache storm, spark, flink等是代表性的流處理框架。
flink
FW 分布式實時計算storm 原理
fw 分布式實時計算storm 原理簡介及單機版安裝指南 3 下面是以本地模式執行exclamationtopology的 1config conf newconfig 2conf.setdebug true 3conf.setnumworkers 2 4 5localcluster cluster...
《Storm分布式實時計算模式》 導讀
目 錄 前言 第1章 分布式單詞計數 1.1 storm topology的組成部分 stream spout和bolt 1.2 單詞計數topology的資料流 1.3 實現單詞計數topology 1.4 storm的併發機制 1.5 理解資料流分組 1.6 有保障機制的資料處理 總結 第2章 ...
JStorm 是乙個分布式實時計算引擎
jstorm 是乙個類似hadoop mapreduce的系統,使用者按照指定的介面實現乙個任務,然後將這個任務遞交給jstorm系統,jstorm將這個任務跑起來,並且按7 24小時執行起來,一旦中間乙個worker 發生意外故障,排程器立即分配乙個新的worker替換這個失效的worker。因此...