簡介
流數據是指由數千個數據源持續生成的數據，通常也同時以數據記錄的形式傳送，規模較小（約幾千位元組）。流數據包括多種數據，例如客戶使用您的移動或 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。
流數據所面臨的挑戰
流數據處理需要兩個層：存儲層和處理層。存儲層需要支持記錄定序和高度一致性，以便以快速、便宜且可重複的方式讀取和寫入大型數據流。處理層負責處理存儲層中的數據，基於該數據運行計算，然後通知存儲層刪除不再需要的數據。您還必須為存儲層和處理層制定可擴展性、數據持久性和容錯規劃。因此，出現了可提供構建流數據應用程式所需的基礎設施的多種平台。
