一、前言
隨着新設備，傳感器和物聯網技術井噴式的發展，數據增長率在不斷加速。據調查分析，如今全球大約有90％的數據是過去短短的兩年內創建的。
從技術上講，這意味着我們的大數據處理世界將變得更加複雜和具有挑戰性。許多用例（例如移動應用廣告，欺詐檢測，出租車預訂，患者監控等）需要在數據到達時實時進行數據處理，以便做出快速可行的決策，這也就是分佈式流處理在大數據世界中變得非常流行的原因。
目前我們所接觸的比較流行的開源流式處理框架：Flink、Spark Streaming、Storm、Kafka Streams。之後的章節中我會對以上幾個框架的應用場景、優勢、劣勢、侷限性一一做說明。
二、什麼是流式處理
目前對信息高時效性、可操作性的需求不斷增長，這要求軟件系統在更少的時間內能處理更多的數據。傳統的大數據處理模型將在線事務處理和離線分析從時序上將兩者完全分割開來，但顯然該架構目前已經越來越落後於人們對於大數據實時處理的需求。
實時計算的產生即來源於對於上述數據加工時效性的嚴苛需求。數據的業務價值隨着時間的流失而迅速降低，因此在數據發生後必須儘快對其進行計算和處理。而傳統的大數據處理模式對於數據加工均遵循傳統日清日畢模式，即以小時甚至以天爲計算週期對當前數據進行累計並處理，顯然這類處理方式無法滿足數據實時計算的需求。
在諸如實時大數據分析、風控預警、實時預測、金融交易等諸多業務場景領域，批量(或者說離線)處理對於上述對於數據處理時延要求苛刻的應用領域而言是完全無法勝任其業務需求的。而實時計算作爲一類針對流數據的實時計算模型，可有效地縮短全鏈路數據流時延、實時化計算邏輯、平攤計算成本，最終有效滿足實時處理大數據的業務需求。
三、流式處理的重點有哪些
爲了理解任何 Streaming 框架的優點和侷限性，我們應該注意與 Streams 處理相關的一些重要特徵和術語：
3.1 交付保障
Atleast-once（即使在出現故障時也至少會被處理一次）
Atmost-once（在發生故障時可能不會被處理）
Exactly-once（即使出現故障，數據也將被處理一次且恰好一次）
從數據一致性的角度上看，完全一次是我們所希望的。但是在分佈式系統中是比較難實現的，處於對性能以及數據安全一致性的考慮，都會從中權衡利弊作出響應的選擇。
3.2 故障容錯
分佈式系統中，包含任務故障、節點故障、網絡故障等，框架應該能夠恢復，並且應該從它離線的位置再次開始處理，一般通過不時地檢查流式傳輸到某個持久存儲的狀態來實現。
例如，在處理來自Kafka的數據時，檢查點kafka在獲得記錄處理後會將offset存儲到zookeeper。如果失敗，請從檢查點offset處重新開始。
3.3 狀態管理
在狀態處理要求的情況下，我們需要維護某些狀態（例如記錄中看到的每個不同單詞的計數），框架應該能夠提供一些機制來保存和更新狀態信息。
3.4 性能
性能上我們考慮的有幾個點：延遲、吞吐量和可伸縮性。理想的情況下，我們希望延遲儘可能小、吞吐量儘可能高，而實際上兩者很難同時實現，只能努力做到兩者之間的平衡。
高級功能（Event Time Processing, Watermarks, Windowing）
主要是應對複雜流處理的場景。
3.5 成熟
從企業技術應用的角度來看，這一點是非常重要的。記得起大公司的大規模驗證和測試，框架的穩定性、可靠性也有一定的保障。成熟的框架，更有可能獲得良好的社區支持和stackoverflow的幫助。
四、流式處理的兩種類型
4.1 Native流
指每個傳入的記錄一到達就會被處理，而不必等待其他記錄。
4.2 小批量處理
也稱爲快速批處理。這意味着每隔幾秒就會將傳入記錄一起批處理，然後在一個小批量中處理，延遲幾秒鐘。
4.3 兩種類型都有一些優點和缺點
Native流：每個記錄在到達時都會被處理，從而允許框架實現最小的延遲。但這也意味着很難在不影響每個記錄的吞吐量的情況下實現容錯，我們需要在處理後跟蹤和檢查點。此外，狀態管理很容易，因爲有長時間運行的過程可以輕鬆地維持所需的狀態。
微批處理：與Native流恰恰相反，容錯是與生俱來的，因爲它本質上是一個批處理，吞吐量也很高，因爲處理和檢查點將一次性完成一組記錄。但它不像Native流一樣，它有一定的延遲成本。此外，有效的狀態管理也將是一項難以維持的挑戰。
五、現有流處理框架介紹
5.1 Storm
Storm是最老的流媒體框架，技術成熟可靠。社區也很活躍。ali還開發了jstorm，對storm進行了拓展完善。後續jstorm也融入到storm中，對於storm也是一個質的提升。比較適合於基於事件的一些簡單用例場景。
優點：
極低的延遲，真正的流媒體，成熟和高吞吐量
非常適合非複雜的流媒體用例
缺點：
不支持狀態管理
沒有事件時間處理，聚合，窗口，會話，水印等高級功能
至少保證一次
5.2 Spark Streaming
Spark已經成爲批處理中hadoop的真正繼承者，也是第一個完全支持Lambda架構的框架。受到各大企業歡迎，並被廣泛採用。2.0版本之後，Spark除了Structured Streaming之外，還配備了許多優秀的功能，如定製內存管理（與flink類似）tungsten、watermarks, event time processing支持等。結構化流也更抽象，並且可以選擇在微批處理之間切換2.3.0版本中的連續流模式。連續流模式有望像Storm和Flink那樣提供低延遲，但它仍處於初始階段，需要在操作中進行測試。
優點：
支持Lambda架構
高吞吐量，適用於不需要低延遲的應用場景
由於微批次性質，默認情況下容錯
簡單易用的高級API
社區活躍，且積極的改進
數據處理有且只有一次
缺點：
不是真正的流媒體，不適合低延遲要求
要調整的參數太多。很難做到最好
在許多高級功能中落後於Flink
5.3 Flink
和Spark一樣，Flink也支持lambda架構。但是這種方法和實現與Spark的方法和實現完全不同。雖然Spark實際上是Spark-Streaming作爲微批處理和Spark Batch特殊情況的批處理，但Flink本質上是一個真正的流引擎，將批處理作爲帶有限數據的流的特殊情況。雖然兩個框架中的API從開發人員的角度來看都很相似，但它們在實現中沒有任何相似之處。在Flink中，map，filter，reduce等各個函數實現爲長時間運行的運算符（類似於Storm中的Bolt）。
Flink看起來像是Storm的真正繼承者，就像Spark成功批量使用hadoop一樣。
優點：
開源流媒體領域的創新領導者
第一個真正的流媒體框架，具有Event Time Processing, Watermarksd等所有高級功能
低延遲，高吞吐量，可根據要求進行配置
自動調整，需要調整的參數較少，調優方便
數據處理有且只有一次
得到像阿里巴巴等大公司的廣泛接受
缺點：
社區沒有Spark那麼大，但是正在快速增長
目前還沒有采用Flink Batch，僅適用於流媒體。
5.4 Kafka Steams
與其他流式框架不同，Kafka Streams是一個輕量級的流式處理類庫。它對於來自Kafka的流數據，進行轉換然後發送回kafka非常有用。我們可以將它看作類似於Java Executor服務線程池的庫，卻內置了對Kafka的支持。它可以與任何應用程序很好地集成，並且可以開箱即用。
由於其重量輕，可用於微服務類型的架構。在與Flink的性能方面沒有匹配，但同時不需要單獨的集羣運行，非常方便，非常快速，易於部署和開始工作。根據相關應用程序的性質，無論是分佈式節點還是單個節點，Kafka Streams都能支持。
優點：
非常輕量級的庫，適用於微服務，物聯網應用
完全一次（kafka 0.11起）
具備kafka所有的優良特性
支持Stream連接，內部使用rocksDb來維護狀態
缺點：
與Kafka緊密相連，不能在沒有Kafka的情況下使用
技術較新，尚未得到廣泛使用
不適用於較爲複雜，繁重的任務
5.5 Kafka Streams vs. Spark Streaming
真 . 實時
我在Hadoop之後接觸的第一個大數據框架就是Spark，所以自然而然曾經對Spark Streaming有着特別的偏愛。但Spark Streaming作爲micro-batch結構，天生不是純正的“真”實時處理。有着秒級別的延時，並且每次處理單個micro-batch中的所有數據記錄。相對而言，Flink和Kafka Streams 則是真正意義上的實時處理，每次處理單個數據記錄。
Kafka系統內的輕度處理
同時，當我在工作中頻繁使用Kafka作爲系統中的數據總線後，一些較爲輕度的數據處理，比如 filter，aggregation， join 等，如果使用Spark Streaming，需要將Kafka topic中的數據導入Spark Streaming，結果處理後再重新導入Kafka中相應的topic，顯得十分繁瑣。
而使用Kafka Streams可以便捷地從源topic取得數據，處理並放入另一個topic，所有工作可以在Kafka內部完成。
不再需要單獨集羣
Kafka Streams 直接集成於Kafka，因此不需要單獨的集羣來支持其運行，這大大減少了額外的維護成本。
六、流式框架比較
我們只能將技術與同類產品進行比較。雖然Storm，Kafka Streams和Samza對於更簡單的用例看起來很棒，但真正的競爭顯然是具有高級功能的重量級框架之間的比較：Spark vs Flink
當我們在對兩個框架做比較時，通常會用數據說話。而基準測試是比較兩個框架的常用方法。Spark在2.0版本之前流式處理做的並不是很好，2.0之後提出了結構化流媒體功能，也在不斷的提升。
既然是用數據說話，那麼就需要得到相同場景下兩者的測試數據，而獲取測試數據，沒有比做一個poc更好的方法了。
截至今天，看起來Flink正在引領Streaming Analytics領域，首先擁有大部分流處理所需的功能，如完全一次，吞吐量，延遲，狀態管理，容錯，高級功能等。Flink仍在不斷創新，如輕量級快照和堆外定製內存管理。
直到某些時候，Flink的一個重要問題是成熟度和採用水平，但現在像優步，阿里巴巴，CapitalOne這樣的大公司正在大規模使用Flink流媒體來證明Flink Streaming的潛力。 最近，優步開放了他們最新的流媒體分析框架，名爲AthenaX，它建立在Flink引擎之上。
七、如何選擇最好的/最適合的流失處理框架？
作爲開發人員，我們不能偏向於任何框架。我們應該記住，沒有一個處理框架可以成爲所有應用場景的靈丹妙藥。每個框架都會有一些優勢和一些限制。下面將分享一些可能有助於做出決定的關鍵點。
7.1 使用場景
如果用例很簡單，而學習和實現起來很複雜，就不需要使用最新的和最好的框架。很大程度上取決於我們願意爲我們想要的回報付出多少投資。
7.2 未來的考慮
在系統調研階段，我們很多時候都會考慮未來可能的用例都有哪些？未來可能會出現Event Time Processing，aggregation，stream joins等高級功能的需求嗎？如果答案是肯定的或可能的話，那麼值得考慮具有Spark Streaming或Flink等高級功能的框架。一旦投資並在一種技術中實施，以後切換框架並不容易，因爲它涉及大量的工作和時間。
7.3 現有的技術堆棧
考慮現有技術堆棧可以說是一個比較重要的一點，畢竟結合已有技術框架在實現難度以及效率上會提升不少。如果現有的管道已經利用了Kafka，那麼Kafka Streams或Samza可能更容易適應。類似地，如果處理管道基於Lambda架構並且Spark或Flink已經用於批處理，則考慮Spark Streaming或Flink Streaming是有意義的。
八、總結
以上對什麼是流處理/流媒體、流處理的分類、流處理框架以及如何選擇一一做了介紹。
總結出來有幾個點：
8.1 延遲要求高
毫秒級：storm、kafka steams、flink
秒級：flink、spark streaming
8.2 功能複雜度
高級功能需求：flink、spark streaming
功能簡單：storm、kafka streams
8.3 現有技術堆棧
以上幾個框架對kafka的支持都已經做的很好了
如果已經使用了flink或者spark做批處理，那麼可以考慮直接用spark streaming或者flink streaming
8.4 未來的考慮
這點還是要具體問題具體分析，很多情況下，一個框架是無法解決所有的應用場景的，有時候拆分處理也不失爲一個好的選擇。
Ref
https://www.linkedin.com/pulse/spark-streaming-vs-flink-storm-kafka-streams-samza-choose-prakash/