簡介
流數據是指由數千個數據源持續生成的數據,通常也同時以數據記錄的形式傳送,規模較小(約幾千位元組)。流數據包括多種數據,例如客戶使用您的移動或 Web 應用程式生成的日誌檔案、網購數據、遊戲內玩家活動、社交網站信息、金融交易大廳或地理空間服務,以及來自數據中心內所連線設備或儀器的遙測數據。
此類數據需要按記錄或根據滑動時間視窗按順序進行遞增式處理,可用於多種分析,包括關聯、聚合、篩選和取樣。藉助此類分析得出的信息,公司得以深入了解其業務和客戶活動的方方面面,例如服務使用情況(用於計量/計費)、伺服器活動、網站點擊量以及設備、人員和實物的地理位置,從而迅速對新情況做出回響。例如,公司可以持續分析社交媒體流,從而跟蹤公眾對其品牌和產品的看法的變化,並在必要時及時做出反應。
流數據優勢及特點
對於持續生成動態新數據的大多數場景,採用流數據處理是有利的。這種處理方法適用於大多數行業和大數據使用案例。通常情況下,各公司一開始都是從簡單的應用程式開始,例如收集系統日誌以及進行滾動計算最小值-最大值等初級處理。然後,這些應用程式逐漸發展為需要完成更加複雜的近實時處理。最初,應用程式可能通過處理數據流生成簡單的報告,然後再執行一些簡單的回響操作,例如在關鍵指標超出一定閥值時發出警報。最終,這些應用程式會執行形式更加複雜的數據分析,如套用機器學習算法,還會從數據中提取更深入的信息。經過一段時間後,開始套用複雜的流事件處理算法,如利用時間視窗衰減算法查找最近的熱門電影,進一步豐富了信息內容。
流數據具有四個特點:
1)數據實時到達;
2)數據到達次序獨立,不受套用系統所控制;
3)數據規模宏大且不能預知其最大值;
4)數據一經處理,除非特意保存,否則不能被再次取出處理,或者再次提取數據代價昂貴。
套用及示例
流數據在
網路監控、
感測器網路、航空航天、氣象測控和金融服務等套用領域廣泛出現,通過對流數據研究可以進行衛星雲圖監測、股市走向分析、
網路攻擊判斷等。
流數據示例
1. 交通工具、工業設備和農業機械上的感測器將數據傳送到流處理應用程式。該應用程式再監控性能,提前檢測任何潛在缺陷,自動訂購備用部件,從而防止設備停機。
2. 一家金融機構實時跟蹤股市波動,計算風險價值,然後根據股票價格變動自動重新平衡投資組合。
3. 一家房地產網站跟蹤客戶移動設備中的一部分數據,然後根據其地理位置實時建議應走訪的房產。
4. 一家太陽能發電公司必須維持可滿足客戶需求的發電量,否則就要支付罰金。該公司實施了一個流數據應用程式,用以監控電力系統中的所有電池板,並實時調度服務,從而最大限度縮短了每個電池板的低產能期,也因此減少了相關的罰款支出。
5. 一家媒體出版商對數十億的線上內容點擊流記錄進行流處理,利用有關用戶的人口統計信息匯總和豐富數據,並最佳化網站上的內容投放,從而實現關聯性並為客群提供更佳的體驗。
6. 一家網路遊戲公司收集關於玩家與遊戲間互動的流數據,並將這些數據提供給遊戲平台,然後再對這些數據進行實時分析,並提供各種激勵措施和動態體驗來吸引玩家。
比較批處理與流處理
在討論流數據之前,有必要比較一下流處理和批處理。批處理可用於計算對不同數據集的任意查詢。它一般用於計算從所含的所有數據得到的結果,並實現對大數據集的深入分析。例如,Amazon EMR 等基於MapReduce 的系統就是支持批處理任務的平台。相反,流處理則需要攝取一個數據序列,增量式更新指標、報告和匯總統計結果,以回響每個到達的數據記錄。這種處理方法更適合實時監控和回響函式。
| 批處理 | 流處理 |
數據範圍 | 對數據集中的所有或大部分數據進行查詢或處理。 | 對滾動時間視窗內的數據或僅對最近的數據記錄進行查詢或處理。 |
數據大小 | 大批量數據。 | 單條記錄或包含幾條記錄的微批量數據。 |
性能 | 幾分鐘至幾小時的延遲。 | 只需大約幾秒或幾毫秒的延遲。 |
分析 | 複雜分析。 | 簡單的回響函式、聚合和滾動指標。 |
很多組織紛紛結合使用兩種方法,從而構建一種混合模式,並同時維持實時處理層和批處理層。數據首先經由流數據平台(如 Amazon Kinesis)處理,以提取實時信息,然後保存到 S3 等存儲中,數據可在此進行轉換和載入,以用於各種批處理使用案例。
流式大數據處理框架
許多分散式計算系統都可以實時或接近實時地處理大數據流。這裡將對三種Apache框架分別進行簡單介紹,然後嘗試快速、高度概述其異同。
Apache Storm
在Storm中,先要設計一個用於實時計算的圖狀結構,我們稱之為拓撲(topology)。這個拓撲將會被提交給集群,由集群中的主控節點(master node)分發代碼,將任務分配給工作節點(worker node)執行。一個拓撲中包括spout和bolt兩種角色,其中spout傳送訊息,負責將數據流以tuple元組的形式傳送出去;而bolt則負責轉換這些數據流,在bolt中可以完成計算、過濾等操作,bolt自身也可以隨機將數據傳送給其他bolt。由spout發射出的tuple是不可變數組,對應著固定的鍵值對。
Apache Spark
Spark Streaming是核心Spark API的一個擴展,它並不會像Storm那樣一次一個地處理數據流,而是在處理前按時間間隔預先將其切分為一段一段的批處理作業。Spark針對持續性數據流的抽象稱為DStream(DiscretizedStream),一個DStream是一個微批處理(micro-batching)的RDD(彈性分散式數據集);而RDD則是一種分散式數據集,能夠以兩種方式並行運作,分別是任意函式和滑動視窗數據的轉換。
Apache Samza
Samza處理數據流時,會分別按次處理每條收到的訊息。Samza的流單位既不是元組,也不是Dstream,而是一條條訊息。在Samza中,數據流被切分開來,每個部分都由一組唯讀訊息的有序數列構成,而這些訊息每條都有一個特定的ID(offset)。該系統還支持批處理,即逐次處理同一個數據流分區的多條訊息。Samza的執行與數據流模組都是可插拔式的,儘管Samza的特色是依賴Hadoop的Yarn(另一種資源調度器)和Apache Kafka。
共同之處
以上三種實時計算系統都是開源的分散式系統,具有低延遲、可擴展和容錯性諸多優點,它們的共同特色在於:允許你在運行數據流代碼時,將任務分配到一系列具有容錯能力的計算機上並行運行。此外,它們都提供了簡單的API來簡化底層實現的複雜程度。
三種框架的術語名詞不同,但是其代表的概念十分相似:
對比圖
下面表格總結了一些不同之處:
數據傳遞形式分為三大類:
最多一次(At-most-once):訊息可能會丟失,這通常是最不理想的結果。
最少一次(At-least-once):訊息可能會再次傳送(沒有丟失的情況,但是會產生冗餘)。在許多用例中已經足夠。
恰好一次(Exactly-once):每條訊息都被傳送過一次且僅僅一次(沒有丟失,沒有冗餘)。這是最佳情況,儘管很難保證在所有用例中都實現。
另一個方面是狀態管理:對狀態的存儲有不同的策略,Spark Streaming將數據寫入分散式檔案系統中(例如HDFS);Samza使用嵌入式鍵值存儲;而在Storm中,或者將狀態管理滾動至套用層面,或者使用更高層面的抽象Trident。
流數據所面臨的挑戰
流數據處理需要兩個層:存儲層和處理層。存儲層需要支持記錄定序和高度一致性,以便以快速、便宜且可重複的方式讀取和寫入大型數據流。處理層負責處理存儲層中的數據,基於該數據運行計算,然後通知存儲層刪除不再需要的數據。您還必須為存儲層和處理層制定可擴展性、數據持久性和容錯規劃。因此,出現了可提供構建流數據應用程式所需的基礎設施的多種平台。