在平常生活中,咱們一般會先把數據存儲在一張表中,而後再進行加工、分析,這裏就涉及到一個時效性的問題。若是咱們處理以年、月爲單位的級別的數據,那麼多數據的實時性要求並不高;但若是咱們處理的是以天、小時,甚至分鐘爲單位的數據,那麼對數據的時效性要求就比較高。在第二種場景下,若是咱們仍舊採用傳統的數據處理方式,統一收集數據,存儲到數據庫中,以後在進行分析,就可能沒法知足時效性的要求。數據庫
大數據的計算模式主要分爲批量計算(batch computing)、流式計算(stream computing)、交互計算(interactive computing)、圖計算(graph computing)等。其中,流式計算和批量計算是兩種主要的大數據計算模式,分別適用於不一樣的大數據應用場景。微信
流數據(或數據流)是指在時間分佈和數量上無限的一系列動態數據集合體,數據的價值隨着時間的流逝而下降,所以必須實時計算給出秒級響應。流式計算,顧名思義,就是對數據流進行處理,是實時計算。批量計算則統一收集數據,存儲到數據庫中,而後對數據進行批量處理的數據計算方式。主要體如今如下幾個方面:網絡
一、數據時效性不一樣:流式計算實時、低延遲, 批量計算非實時、高延遲。框架
二、數據特徵不一樣:流式計算的數據通常是動態的、沒有邊界的,而批處理的數據通常則是靜態數據。運維
三、應用場景不一樣:流式計算應用在實時場景,時效性要求比較高的場景,如實時推薦、業務監控...批量計算通常說批處理,應用在實時性要求不高、離線計算的場景下,數據分析、離線報表等。分佈式
四、運行方式不一樣,流式計算的任務持續進行的,批量計算的任務則一次性完成。post
第一類,商業級流式計算平臺(IBM InfoSphere Streams、IBM StreamBase等);學習
第二類,開源流式計算框架(Twitter Storm、S4等);大數據
第三類,公司爲支持自身業務開發的流式計算框架。網站
Strom:Twitter 開發的第一代流處理系統。
Heron:Twitter 開發的第二代流處理系統。
Spark streaming:是Spark核心API的一個擴展,能夠實現高吞吐量的、具有容錯機制的實時流數據的處理。
Flink:是一個針對流數據和批數據的分佈式處理引擎。
Apache Kafka:由Scala寫成。該項目的目標是爲處理實時數據提供一個統1、高通量、低等待的平臺。
流式處理能夠用於兩種不一樣場景: 事件流和持續計算。
一、事件流
事件流具可以持續產生大量的數據,這類數據最先出現與傳統的銀行和股票交易領域,也在互聯網監控、無線通訊網等領域出現、須要以近實時的方式對更新數據流進行復雜分析如趨勢分析、預測、監控等。簡單來講,事件流採用的是查詢保持靜態,語句是固定的,數據不斷變化的方式。
二、持續計算
好比對於大型網站的流式數據:網站的訪問PV/UV、用戶訪問了什麼內容、搜索了什麼內容等,實時的數據計算和分析能夠動態實時地刷新用戶訪問數據,展現網站實時流量的變化狀況,分析天天各小時的流量和用戶分佈狀況;
好比金融行業,毫秒級延遲的需求相當重要。一些須要實時處理數據的場景也能夠應用Storm,好比根據用戶行爲產生的日誌文件進行實時分析,對用戶進行商品的實時推薦等。
經過大數據處理咱們獲取了數據的價值,可是數據的價值是恆定不變的嗎?顯然不是,一些數據在事情發生後不久就有了更高的價值,並且這種價值會隨着時間的推移而迅速減小。流處理的關鍵優點在於它可以更快地提供洞察力,一般在毫秒到秒之間。
流式計算的價值在於業務方可在更短的時間內挖掘業務數據中的價值,並將這種低延遲轉化爲競爭優點。比方說,在使用流式計算的推薦引擎中,用戶的行爲偏好能夠在更短的時間內反映在推薦模型中,推薦模型可以以更低的延遲捕捉用戶的行爲偏好以提供更精準、及時的推薦。
流式計算能作到這一點的緣由在於,傳統的批量計算須要進行數據積累,在積累到必定量的數據後再進行批量處理;而流式計算能作到數據隨到隨處理,有效下降了處理延時。
相關閱讀:
如欲瞭解更多,歡迎搜索並關注先薦微信公衆號(ID:dsfsxj)。
本帳號爲第四範式智能推薦產品先薦的官方帳號。帳號立足於計算機領域,特別是人工智能相關的前沿研究,旨在把更多與人工智能相關的知識分享給公衆,從專業的角度促進公衆對人工智能的理解;同時也但願爲人工智能相關人員提供一個討論、交流、學習的開放平臺,從而早日讓每一個人都享受到人工智能創造的價值。