在過去幾年，業界的主流流計算引擎大多採用spark streaming，隨著近兩年flink的快速發展，flink的使用也越來越廣泛。與此同時，spark針對spark streaming的不足，也繼而推出了新的流計算元件。本文旨在深入分析不同的流計算引擎的內在機制和功能特點，為流處理場景的選型提供參考。
spark streaming是spark最早推出的流處理元件，它基於流式批處理引擎，基本原理是把輸入資料以某一時間間隔批量的處理（微批次），當批處理時間間隔縮短到秒級時，便可以用於實時資料流。
在spark streaming內部，將接收到資料流按照一定的時間間隔進行切分，然後交給spark引擎處理，最終得到乙個個微批的處理結果。
2. 資料抽象
離散資料流或者資料流是spark streaming提供的基本抽象。它可以是從資料來源不斷流入的，也可以是從乙個資料流轉換而來的。本質上就是一系列的rdd。每個流中的rdd包含了乙個特定時間間隔內的資料集合，如下圖所示。
spark streaming提供了滑動視窗介面，滑動視窗的兩個重要的引數是視窗大小，滑動步長。它允許在資料的滑動視窗上應用轉換。如下圖所示，每當視窗在源dstream上滑動時，位於視窗內的源rdds就會被合併操作，來生成視窗化的dstream的rdds。
由於spark streaming是基於批處理引擎的，因此它的處理延時較大，基本上為秒級延遲。因此，具有毫秒級的流處理引擎flink誕生了。
flink從2023年12月成為apache的頂級專案，近兩年才逐漸走入大眾視野。flink是乙個框架和分布式處理引擎，用於對無界和有界資料流進行狀態計算。flink的特點是低延遲、高吞吐和一致性（結果的準確和良好的容錯性）。
在flink中，流也被分成兩類：無界流和有界限，分別對應著flink中的流處理場景和批處理場景。
無界流：有開始無結束的資料流；
有界流：有開始也有結束的資料流，批處理被抽象成有界流；
flink中提供了三種視窗計算型別：滾動視窗、滑動視窗和會話視窗。
滾動視窗是將每個元素分配給具有指定視窗大小的視窗。滾動視窗有固定大小，而且不會互相重疊。乙個視窗的結束意味著另乙個視窗的開始。
滑動視窗將元素分配到固定長度的視窗，類似於滾動視窗的分配。視窗大小由視窗大小引數配置。滑動步長控制滑動視窗啟動的頻率，如果滑動步長小於視窗大小，則滑動視窗會有重疊。
會話視窗：會話視窗根據會話間隔進行視窗的劃分，與滑動和滾動視窗相比，會話視窗沒有重疊，也沒有固定的開始和結束時間。
flink提供了三種時間語義，分別是事件時間、注入時間和處理時間。
事件時間即為事件發生的時間；
注入時間是指資料從資料來源進入資料處理引擎的時間；處理時間是真正進行資料處理的任務執行的機器時間。
watermark機制
flink在事件時間應用程式中使用水印來判斷時間。水印也是一種靈活的機制，以權衡結果的延遲和完整性。
隨著flink的興起，以及spark streaming的短板顯現，從spark 2.0開始引入了structured streaming， 將微批次處理從高階 api 中解耦出去，簡化了 api 的使用，api 不再負責進行微批次處理；開發者可以將流看成是乙個沒有邊界的表，並基於這些「表」執行查詢。 structured streaming的預設引擎基於微批處理引擎，並且可以達到最低100ms的延遲和資料處理的exactly-once保證。
從spark 2.3開始，structured streaming繼續向更快、更易用、更智慧型的目標邁進，引入了低延遲的持續流處理模式，這時候已經不再採用批處理引擎，而是一種類似flink機制的持續處理引擎，可以達到端到端最低1ms的延遲和資料處理的at-least-once的保證。採用何種處理模式只需要進行簡單的模式配置即可。
1.程式設計模型
structured streaming將資料流看作是一張無界表，每個流的資料來源從邏輯上來說看做乙個不斷增長的動態表，從資料來源不斷流入的每個資料項可以看作為新的一行資料追加到動態表中。使用者可以通過靜態結構化資料的批處理查詢方式（sql查詢），對資料進行實時查詢。
2.觸發型別
structured streaming通過不同的觸發模式來實現不同的延遲級別和一致性語義。主要提供了以下四種觸發模式：
單次觸發：顧名思義就是只觸發一次執行，類似於flink的批處理；
週期性觸發：查詢以微批處理模式執行，微批執行將以使用者指定的時間間隔來進行；
預設觸發：乙個批次執行結束立即執行下個批次；
連續處理：是structured streaming從2.3開始提出的新的模式，對標的就是flink的流處理模式，該模式支援傳入乙個引數，傳入引數為checkpoint間隔，也就是連續處理引擎每隔多久記錄查詢的進度；
3.寫入模式
為了滿足不同操作的結果需求，還提供了三種寫入模式：
complete：當trigger觸發時，輸出整個更新後的結果表到外部儲存，儲存聯結器決定如何處理整個表的寫入
update：之後結果表中被更新的資料行會被寫出到外部儲存
4.視窗型別
在視窗型別方面，structured streaming繼續支援滑動視窗，跟spark streaming類似，但是spark streaming是基於處理時間語義的，structured streaming還可以基於事件時間語義進行處理。
5.時間語義
時間語義上，structured streaming也是根據當前的需要，支援了事件時間和處理時間，一步步向flink靠近。
6.watermark機制
在進行流處理的時候，不能無限保留中間狀態結果，因此它也通過watermark來丟棄遲到資料。因為flink和structured streaming都是支援事件時間語義，因此都支援watermark機制。
上面的這張表展示了三種流處理在一些特性和機制方面的比較。技術總在互相比較和互相借鑑中發展。spark緊跟流處理的步伐，彌補短板；flink也不僅在流處理方面發力，在生態建設方面也加快了步伐。究竟誰能最終統一江湖，我們可以拭目以待。
謝謝～
kafka實時資料流寫入HDFS
一 摘要 impala作為實時資料分析引擎，其源資料時效性要求不同，主要分為離線資料分析和實時資料分析。離線資料分析應用場景下，可以利用hive離線載入資料。實時資料分析則依靠kafka 高吞吐量的訊息發布訂閱系統 二 kafka介紹 kafka是一種高吞吐量的分布式發布訂閱訊息系統，它可以處理消費...
1 騰訊 實時資料流推薦實踐
tecentrec real time stream recommendation in practice 解決問題 主要解決問題 資料量大 實時 準確性 實時計算平台選取 1 支援實時資料統計計算 2 集群擴充套件性好 3 失敗恢復快 4 活躍度較高的開源工具 5 簡單程式設計模式，支援多種國語言...
從實時資料流中搜尋資料 演算法2
專案需要從實時單向資料流中讀取和篩選資料，即當遇到標誌資料時，執行某些操作。所有資料只能讀一次，不能回溯。我們的場景是監聽串列埠，然後根據監聽結果，讀取後續資料。上午寫了個演算法程式 從實時資料流中搜尋資料，監控實時資料流中的資料，發現資料時立即做出應對。然後，寫完了之後，總覺得效能有缺陷。仔細考慮...