Spark缺點
無論是 Spark Streaming還是 Structured Streaming,
Spark流處理的實時性還不夠,所以無法用在一些對實時性要求很高的流處理場景中。
這是因為 Spark的流處理是基於所謂微批處理( Micro- batch processing)的思想,即它把流
處理看作是批處理的一種特殊形式,每次接收到一個時間間隔的數據才會去處理,所以天生很難在實時性上有所提升。
雖然在 Spark2.3中提出了連續處理模型( Continuous Processing Model),但是現在只支持
很有限的功能,並不能在大的項目中使用。 Spark還需要做出很大的努力才能改進現有的流處理模型想要在流處理的實時性上提升,就不能継續用微批處理的模式,而要想辦法實現真正的流處理即每當有一條數據輸入就立刻處理,不做等待。
Flink
采用了基於操作符（Operator）的連續流模型，可以做到微秒級別的延遲。
Flink 核心模型簡介
Flink最核心的數據結構是Stream，它代表一個運行在多分區上的並行流。
在 Stream 上同樣可以進行各種轉換操作（Transformation）。與 Spark 的 RDD 不同的是，Stream 代表一個數據流而不是靜態數據的集合。所以，它包含的數據是隨着時間增長而變化的。而且 Stream 上的轉換操作都是逐條進行的，即每當有新的數據進來，整個流程都會被執行並更新結果。這樣的基本處理模式決定了 Flink 會比 Spark Streaming 有更低的流處理延遲性。
當一個 Flink 程序被執行的時候，它會被映射為 Streaming Dataflow，下圖就是一個Streaming Dataflow 的示意圖。
在圖中，你可以看出Streaming Dataflow 包括Stream和Operator（操作符）。轉換操作符把一個或多個Stream 轉換成多個Stream。每個Dataflow都有一個輸入數據源（Source）和輸出數據源（Sink）。與Spark的RDD轉換圖類似，Streaming Dataflow也會被組合成一個有向無環圖去執行。
在Flink中，程序天生是並行和分布式的。一個Stream可以包含多個分區（Stream Partitions），一個操作符可以被分成多個操作符子任務，每一個子任務是在不同的線程或者不同的機器節點中獨立執行的。如下圖所示：
從上圖你可以看出，Stream在操作符之間傳輸數據的形式有兩種：一對一和重新分布。
一對一（One-to-one）：Stream維護着分區以及元素的順序，比如上圖從輸入數據源到map間。這意味着map操作符的子任務處理的數據和輸入數據源的子任務生產的元素的數據相同。你有沒有發現，它與RDD的窄依賴類似。
重新分布（Redistributing）：Stream中數據的分區會發生改變，比如上圖中map與keyBy之間。操作符的每一個子任務把數據發送到不同的目標子任務。
Flink的架構
當前版本Flink的架構如下圖所示
這個架構和Spark 架構比較類似，都分為四層：存儲層、部署層、核心處理引擎、high-level的API和庫。
從存儲層來看，Flink 同樣兼容多種主流文件系統如HDFS、Amazon S3，多種數據庫如HBase和多種數據流如Kafka和Flume。
從部署層來看，Flink不僅支持本地運行，還能在獨立集群或者在被YARN或Mesos管理的集群上運行，也能部署在雲端。
核心處理引擎就是我們剛才提到的分布式Streaming Dataflow，所有的高級API及應用庫都會被翻譯成包含Stream和Operator的Dataflow來執行。
Flink 提供的兩個核心API就是DataSet APl和DataStream APl。你沒看錯，名字和Spark的DataSet、DataFrame 非常相似。顧名思義，DataSet代表有界的數據集，而DataStream代表流數據。所以，DataSet API是用來做批處理的，而DataStream API是做流處理的。
也許你會問，Flink 這樣基於流的模型是怎樣支持批處理的？在內部，DataSet 其實也用Stream表示，靜態的有界數據也可以被看作是特殊的流數據，而且DataSet與DataStream 可以無縫切換。所以，Flink的核心是DataStream。
Flink 和 Spark 對比
通過前面的學習，我們了解到，Spark和Flink都支持批處理和流處理，接下來讓我們對這兩種流行的數據處理框架在各方面進行對比。首先，這兩個數據處理框架有很多相同點。
都基於內存計算；
都有統一的批處理和流處理APl，都支持類似SQL的編程接口；
都支持很多相同的轉換操作，編程都是用類似於Scala Collection APl的函數式編程模式；
都有完善的錯誤恢復機制；
都支持Exactly once的語義一致性。
當然，它們的不同點也是相當明顯，我們可以從4個不同的角度來看。
從流處理的角度來講，Spark基於微批量處理，把流數據看成是一個個小的批處理數據塊分別處理，所以延遲性只能做到秒級。而Flink基於每個事件處理，每當有新的數據輸入都會立刻處理，是真正的流式計算，支持毫秒級計算。由於相同的原因，Spark只支持基於時間的窗口操作（處理時間或者事件時間），而Flink支持的窗口操作則非常靈活，不僅支持時間窗口，還支持基於數據本身的窗口，開發者可以自由定義想要的窗口操作。
從SQL 功能的角度來講，Spark和Flink分別提供SparkSQL和Table APl提供SQL
交互支持。兩者相比較，Spark對SQL支持更好，相應的優化、擴展和性能更好，而Flink在SQL支持方面還有很大提升空間。
從迭代計算的角度來講，Spark對機器學習的支持很好，因為可以在內存中緩存中間計算結果來加速機器學習算法的運行。但是大部分機器學習算法其實是一個有環的數據流，在Spark中，卻是用無環圖來表示。而Flink支持在運行時間中的有環數據流，從而可以更有效的對機器學習算法進行運算。
從相應的生態系統角度來講，Spark 的社區無疑更加活躍。Spark可以說有着Apache
旗下最多的開源貢獻者，而且有很多不同的庫來用在不同場景。而Flink由於較新，現階段的開源社區不如Spark活躍，各種庫的功能也不如Spark全面。但是Flink還在不斷發展，各種功能也在逐漸完善。
如何選擇Spark和Flink
對於以下場景，你可以選擇 Spark。
數據量非常大而且邏輯復雜的批數據處理，並且對計算效率有較高要求（比如用大數據分析來構建推薦系統進行個性化推薦、廣告定點投放等）；
基於歷史數據的交互式查詢，要求響應較快；
基於實時數據流的數據處理，延遲性要求在在數百毫秒到數秒之間。
Spark完美滿足這些場景的需求，而且它可以一站式解決這些問題，無需用別的數據處理平台。由於Flink是為了提升流處理而創建的平台，所以它適用於各種需要非常低延遲（微秒到毫秒級）的實時數據處理場景，比如實時日志報表分析。
而且Flink 用流處理去模擬批處理的思想，比Spark 用批處理去模擬流處理的思想擴展性更好。
————————————————
版權聲明：本文為CSDN博主「苝花向暖丨楠枝向寒」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_40247263/article/details/97000109