什麼是流處理

流處理是一種大資料處理技術。它使使用者能夠查詢連續資料流，並在從接收資料開始很短的時間內快速檢測條件。檢測時間從幾毫秒到幾分鐘不等。例如，通過流處理，你可以通過查詢來自溫度感測器的資料流並檢測溫度何時達到凍結點來接收警報。

它還有許多名稱：實時分析、流分析、複雜事件處理、實時流分析和事件處理。儘管一些術語在歷史上存在差異，但現在工具（框架）在術語流處理下已經趨於一致。（有關框架的列表和本文的最後一節以瞭解歷史，請參閱這個Quora問題）

它通過Apache Storm作為一種像Hadoop一樣能夠快速給出結果的技術得以普及，之後它被當作一種大資料技術採用。現在有很多競爭者。

為什麼需要流處理

從處理資料中得出的見解(insights)是有價值的。這樣的見解(insights)並非都是生來平等的。一些見解(insights)在發生後不久就具有很高的價值，並且隨著時間的流逝，這種價值會迅速減少。流處理針對這樣的場景。流處理的關鍵優勢在於它能夠更快地提供見解(insights)，通常在毫秒到秒之間。

下面是使用流處理的一些次要原因。

原因1: 有些資料自然地以永無止境的事件流出現。要進行批處理，需要儲存它、在某個時間停止資料收集並處理資料。然後你必須執行下一批操作，然後擔心跨多個批進行聚合。相比之下，流處理永無止境的資料流更優雅、更自然。你可以檢測模式、檢查結果、檢視多個焦點級別，還可以輕鬆地同時檢視來自多個流的資料。

流處理天然地適合時間序列資料和隨時間變化的檢測模式。例如，如果你試圖檢測無限流中的web會話的長度（這是嘗試檢測序列的示例）。分批處理非常困難，因為某些會話將分為兩批。流處理可以很容易地處理這個問題。

如果你退一步考慮，最連續的資料序列是時間序列資料：交通感測器、健康感測器、事務日誌、活動日誌等。幾乎所有IoT資料都是時間序列資料。因此，使用天然適用的程式設計模型是有意義的。

原因2: 批處理允許資料建立並嘗試同時處理它們，而流處理立即處理進來的資料，因此處理隨時間擴充套件。因此，流處理可以使用比批處理少得多的硬體。此外，流處理還允許通過系統負載削減進行近似查詢處理。因此，流處理天然適合於近似答案足夠多的用例。

原因3: 有時資料很大，甚至無法儲存。流處理允許你處理大型消防馬型資料，並且只保留有用的位。

原因4: 最後，有許多流資料可用（例如，客戶事務、活動、網站訪問），並且隨著IoT用例（各種感測器）的增長，這些資料將更快。流式是一種更自然的模型，可以考慮和程式設計這些用例。

然而，流處理也不是所有用例都適用的工具。一個好的經驗法則是，如果處理需要多次遍歷完整資料或者具有隨機訪問（想想圖資料集），那麼流處理就很棘手。流處理中一個大的缺失用例是訓練模型的機器學習演算法。另一方面，如果處理可以通過一次遍歷資料完成，或者具有時間位置（處理傾向於訪問最近的資料），那麼它非常適合於流式傳輸。

如何進行流處理

如果你想要構建一個處理流資料並做出實時決策的應用程式，您可以使用工具或者自己構建它。答案取決於你計劃處理多少複雜性、希望擴充套件多少、需要多少可靠性和容錯性等。

如果希望自己構建應用程式，請將事件放在訊息代理主題（例如，ActiveMQ、RabbitMQ或Kafka）中，編寫程式碼以從broker中的主題接收事件（它們成為你的流），然後將結果釋出broker。這樣的程式碼稱為actor。

但是，你可以使用流處理框架來節省時間，而不是從頭開始編碼上述場景。事件流處理器允許你為每個actor編寫邏輯，連線actor，並將邊緣連線到資料來源。你可以直接向流處理器傳送事件，也可以通過broker傳送事件。

事件流處理器將通過收集資料、將資料傳遞給每個actor、確保它們以正確的順序執行、收集結果、如果負載高則進行伸縮以及處理故障來完成艱鉅的工作。例如Storm、Flink和Samza。如果你希望以這種方式構建應用程式，請檢視相應的使用者指南

自2016年以來，出現了名為流式SQL（Streaming SQL 101）的新思想。我們稱一種語言為“流式SQL”，它允許使用者編寫類似查詢的SQL來查詢流式資料。有許多流式SQL語言正在興起。

WSO2流處理器和SQLStreams等專案支援SQL超過五年了。

• Apache Storm在2016年增加了對流式SQL的支援
• [自2016年以來，Apache Flink增加了對流式SQL的支援](Apache Flink added support for Streaming SQL since 2016)
• Apache Kafka在2017年增加了對SQL（他們稱之為KSQL）的支援
• Apache Samza在2017年增加了對SQL的支援

使用流式SQL語言，開發人員可以快速地將流式查詢合併到他們的應用程式中。到2018年，大多數流處理器支援通過流SQL語言處理資料。

讓我們瞭解如何將SQL對映到流。流是移動中的表資料。設想一個永無止境的表，其中隨著時間的流逝，新資料出現。流就是這樣的一張表。流中的一個記錄或一行稱為事件。但是，它有一個模式，並且表現得像資料庫行。為了理解這些觀點，Tyler Akidau在Strata的演講是一個很好的資源。

編寫SQL查詢時，查詢儲存在資料庫中的資料。然而，當你編寫流式SQL查詢時，你將它們寫在現在的資料以及將來將要出現的資料上。因此，流式SQL查詢永遠不會結束。有問題嗎？沒有，因為查詢的輸出是流。一旦事件匹配，並且輸出事件立即可用，事件將被放置在輸出流中。

流表示可以通過邏輯通道的所有事件，並且永遠不會結束。例如，如果我們在鍋爐中有一個溫度感測器，我們可以將感測器的輸出表示為一個流。但是，經典的SQL攝取儲存在資料庫表中的資料，對其進行處理，並將其寫入資料庫表。相反，上面的查詢將在資料流進入時接收資料流，並生成資料流作為輸出。例如，假設鍋爐流中每10分鐘發生一次事件。當事件與篩選器匹配時，篩選器查詢將立即在結果流中生成事件。

因此，你可以按照以下方式構建應用程式。通過直接傳送或通過broker向流處理器傳送事件。然後你可以使用“流式SQL”編寫應用程式的流式部分。最後，將Stream處理器配置為對結果進行操作。這通過在流處理器觸發時呼叫服務或通過將事件釋出到broker主題並監聽主題來完成。

有許多流處理框架可用。（參見Quora問題：什麼是最好的流處理解決方案？）.

我推薦一個我幫助構建的，WSO2流處理器（WSO2SP）。它可以從Kafka、HTTP請求、訊息broker中獲取資料，並且可以使用“流式SQL”語言查詢資料流。WSO2SP是Apache許可下的開源。只需要兩臺普通伺服器，就可以提供高可用性，並且可以處理100K+TPS吞吐量。它可以在Kafka之上擴充套件到數百萬個TPS，並支援多個數據中心的部署。

誰正在使用流式處理

一般來說，流處理對於我們能夠檢測問題並且我們有合理的響應來改善結果的用例是有用的。此外，在資料驅動的組織中，它還起著關鍵作用。

以下是一些使用案例

• 演算法交易，股市監控
• 智慧病人護理
• 監控生產線
• 供應鏈優化
• 入侵、監視和欺詐檢測(例如Uber)
• 大多數智慧裝置應用：智慧汽車，智慧家居
• 智慧電網-（例如，負載預測和離群值插頭檢測參見智慧電網，40億個事件，吞吐在100Ks）
• 交通監控，地理圍欄，車輛和野生動物跟蹤，例如TFL倫敦運輸管理系統
• 運動分析-用實時分析來增強運動（例如，這是我們在真正的足球比賽中所做的工作（例如，在足球廣播上覆蓋實時分析）
• 上下文感知促銷和廣告
• 計算機系統與網路監控
• 預測性維護(例如，用於預測性維護的機器學習技術)
• 地理空間資料處理

有關如何使用流處理的更多討論，請參閱用於構建流處理和實時應用程式的13種流處理模式

流處理的歷史及其框架

流處理從提供對資料庫中儲存的資料的有條件查詢的活動資料庫開始已經有很長的歷史了。第一個流處理框架之一是TelegraphCQ，它構建在PostgreSQL之上。

然後它們長成兩個分支。

第一個分支稱為流處理。這些框架允許使用者建立查詢圖連線使用者程式碼並使用許多機器執行查詢圖。例如Aurora、PIPES、STREAM、Borealis和雅虎S4。這些流處理架構關注可伸縮性。

第二個分支稱為複雜事件處理。這些框架支援查詢語言（比如現在我們使用流式SQL），並且關注針對給定查詢進行有效的事件處理，但是通常執行在1-2個節點上。例如ODE、SASE、Esper、Cayuga和Sidhi。這些架構關注於高效的流演算法。

這兩個分支的流處理框架僅限於學術研究或股票市場等利基應用。流處理重新成為雅虎S4和Apache Storm關注的焦點。它被介紹為“類似於Hadoop，但是是實時的”。它成為大資料運動的一部分。

在過去的五年裡，這兩個分支合併了。我在前面的文章中詳細討論了這個問題。

如果您想了解更多關於流處理框架的歷史，請閱讀Recent Advancements in Event Processing 和 Processing flows of information: From data stream to complex event Processing

希望這是有用的。如果你喜歡這篇文章，你也許會發現Stream Processing 101和Patterns for Streaming Realtime Analytics.