您好,登錄后才能下訂單哦!
在日常生活中,我們通常會先把數據存儲在一張表中,然后再進行加工、分析,這里就涉及到一個時效性的問題。如果我們處理以年、月為單位的級別的數據,那么多數據的實時性要求并不高;但如果我們處理的是以天、小時,甚至分鐘為單位的數據,那么對數據的時效性要求就比較高。在第二種場景下,如果我們仍舊采用傳統的數據處理方式,統一收集數據,存儲到數據庫中,之后在進行分析,就可能無法滿足時效性的要求。
大數據的計算模式主要分為批量計算(batch computing)、流式計算(stream computing)、交互計算(interactive computing)、圖計算(graph computing)等。其中,流式計算和批量計算是兩種主要的大數據計算模式,分別適用于不同的大數據應用場景。
流數據(或數據流)是指在時間分布和數量上無限的一系列動態數據集合體,數據的價值隨著時間的流逝而降低,因此必須實時計算給出秒級響應。流式計算,顧名思義,就是對數據流進行處理,是實時計算。批量計算則統一收集數據,存儲到數據庫中,然后對數據進行批量處理的數據計算方式。主要體現在以下幾個方面:
1、數據時效性不同:流式計算實時、低延遲, 批量計算非實時、高延遲。
2、數據特征不同:流式計算的數據一般是動態的、沒有邊界的,而批處理的數據一般則是靜態數據。
3、應用場景不同:流式計算應用在實時場景,時效性要求比較高的場景,如實時推薦、業務監控...批量計算一般說批處理,應用在實時性要求不高、離線計算的場景下,數據分析、離線報表等。
4、運行方式不同,流式計算的任務持續進行的,批量計算的任務則一次性完成。
第一類,商業級流式計算平臺(IBM InfoSphere Streams、IBM StreamBase等);
第二類,開源流式計算框架(Twitter Storm、S4等);
第三類,公司為支持自身業務開發的流式計算框架。
Strom:Twitter 開發的第一代流處理系統。
Heron:Twitter 開發的第二代流處理系統。
Spark streaming:是Spark核心API的一個擴展,可以實現高吞吐量的、具備容錯機制的實時流數據的處理。
Flink:是一個針對流數據和批數據的分布式處理引擎。
Apache Kafka:由Scala寫成。該項目的目標是為處理實時數據提供一個統一、高通量、低等待的平臺。
流式處理可以用于兩種不同場景: 事件流和持續計算。
1、事件流
事件流具能夠持續產生大量的數據,這類數據最早出現與傳統的銀行和股票交易領域,也在互聯網監控、無線通信網等領域出現、需要以近實時的方式對更新數據流進行復雜分析如趨勢分析、預測、監控等。簡單來說,事件流采用的是查詢保持靜態,語句是固定的,數據不斷變化的方式。
2、持續計算
比如對于大型網站的流式數據:網站的訪問PV/UV、用戶訪問了什么內容、搜索了什么內容等,實時的數據計算和分析可以動態實時地刷新用戶訪問數據,展示網站實時流量的變化情況,分析每天各小時的流量和用戶分布情況;
比如金融行業,毫秒級延遲的需求至關重要。一些需要實時處理數據的場景也可以應用Storm,比如根據用戶行為產生的日志文件進行實時分析,對用戶進行商品的實時推薦等。
通過大數據處理我們獲取了數據的價值,但是數據的價值是恒定不變的嗎?顯然不是,一些數據在事情發生后不久就有了更高的價值,而且這種價值會隨著時間的推移而迅速減少。流處理的關鍵優勢在于它能夠更快地提供洞察力,通常在毫秒到秒之間。
流式計算的價值在于業務方可在更短的時間內挖掘業務數據中的價值,并將這種低延遲轉化為競爭優勢。比方說,在使用流式計算的推薦引擎中,用戶的行為偏好可以在更短的時間內反映在推薦模型中,推薦模型能夠以更低的延遲捕捉用戶的行為偏好以提供更精準、及時的推薦。
流式計算能做到這一點的原因在于,傳統的批量計算需要進行數據積累,在積累到一定量的數據后再進行批量處理;而流式計算能做到數據隨到隨處理,有效降低了處理延時。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。