Spark架構(gòu)模式與Flink的對比
Spark和Flink都屬于流批一體的分布式計算引擎谬泌。Flink屬于流處理框架务热，通過流來模擬批求晶，Spark屬于批處理框架，通過批來模擬流舵变。其分別屬于Lambda架構(gòu)和Dataflow架構(gòu)。
Spark架構(gòu)模式
Spark包括集群資源管理器（Cluster Manager）瘦穆、多個運行作業(yè)任務(wù)的工作結(jié)點（Worker Node）纪隙、每個應(yīng)用的任務(wù)控制結(jié)點（Driver）和每個工作結(jié)點上負(fù)責(zé)具體任務(wù)的執(zhí)行進程（Executor）。屬于Master/Slave架構(gòu)扛或。Driver節(jié)點向資源管理器（Cluster Manager）申請資源瘫拣，資源管理器分配資源Worker,并在其上啟動Executor進程，Executor向Driver申請Task, Driver根據(jù)劃分的Job,生成DAG圖告喊，并依據(jù)Shuffle切分Stage,封裝為Taskset 分發(fā)為Worker上的Executor, Executor啟動線程執(zhí)行Task麸拄。
Flink架構(gòu)模式
Flink包括，Jobmanager:負(fù)責(zé)協(xié)調(diào)分布式執(zhí)行黔姜，他們調(diào)度任務(wù)拢切、協(xié)調(diào) checkpoints、協(xié)調(diào)故障恢復(fù)等秆吵。高可用情況下可以啟動多個 JobManager淮椰，其中一個選舉為 leader，其余為 standby；Taskmanager:負(fù)責(zé)執(zhí)行具體的 tasks主穗、緩存泻拦、交換數(shù)據(jù)流，至少有一個 TaskManager忽媒；Slot：每個 task slot 代表 TaskManager 的一個固定部分資源争拐，Slot 的個數(shù)代表著 taskmanager 可并行執(zhí)行的 task 數(shù)。
Flink也屬于Master/slave架構(gòu)晦雨，當(dāng)Flink執(zhí)行executor會自動根據(jù)程序代碼生成DAG數(shù)據(jù)流圖架曹，ActorSystem創(chuàng)建Actor將數(shù)據(jù)流圖發(fā)送給JobManager中的Actor，jobManager會不斷接收TaskManager的心跳消息闹瞧，從而可以獲取到有效的TaskManager, JobManager通過調(diào)度器在TaskManager中調(diào)度Task到空閑的Task slot（在Flink中绑雄，最小的調(diào)度單元就是task，對應(yīng)就是一個線程）在程序運行過程中奥邮，task與task之間是可以進行數(shù)據(jù)傳輸?shù)耐蛭askManager啟動之初就啟動了所有的Task slot∏⑾伲總而言之脚粟，F(xiàn)link采用了基于Operator的連續(xù)流模型，F(xiàn)link最核心的數(shù)據(jù)結(jié)構(gòu)是Stream已脓，它代表一個運行在多分區(qū)上的并行流珊楼。與 Spark 的 RDD 不同的是，Stream 代表一個數(shù)據(jù)流而不是靜態(tài)數(shù)據(jù)的集合度液。所以厕宗，它包含的數(shù)據(jù)是隨著時間增長而變化的。而且 Stream 上的轉(zhuǎn)換操作都是逐條進行的堕担，即每當(dāng)有新的數(shù)據(jù)進來已慢，整個流程都會被執(zhí)行并更新結(jié)果。
Flink 通過 Task Slots 來定義執(zhí)行資源霹购。每個 TaskManager 有一到多個 task slot佑惠，每個 task slot 可以運行一條由多個并行 task 組成的流水線。所以說Flink計算任務(wù)分配是固定的齐疙，將StreamGraph拆分為Task后分布執(zhí)行在不同的節(jié)點的slot內(nèi)膜楷。
Spark vs Flink
- Flink是一個流處理系統(tǒng)，采用Dataflow架構(gòu)贞奋。其節(jié)點的數(shù)據(jù)傳輸方式為赌厅，當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中轿塔，然后立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點特愿，由下一個節(jié)點繼續(xù)處理（Flink以固定的緩存塊仲墨，大小設(shè)置為0則為純流）。Spark是批處理系統(tǒng)揍障，其數(shù)據(jù)節(jié)點間的傳輸方式為目养，當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中毒嫡，并不會立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點癌蚁，當(dāng)緩存寫滿，就持久化到本地硬盤上审胚，當(dāng)所有數(shù)據(jù)都被處理完成后匈勋，才開始將處理后的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點礼旅。所以批處理系統(tǒng)更適合處理吞吐量大的任務(wù)膳叨，流處理系統(tǒng)適合處理低延時要求的任務(wù)。
- 任務(wù)的調(diào)度不同痘系，flink 的拓?fù)鋱D生成提交執(zhí)行之后（分布到TaskManager的slot中后）菲嘴，除非故障，否則拓?fù)洳考?zhí)行位置不變汰翠，并行度由每一個算子并行度決定（每一個算子可以設(shè)置自己的并行讀）龄坪，F(xiàn)link的slot的在TaskManager創(chuàng)建時就已經(jīng)確定。Spark是構(gòu)建 DGA 圖复唤，劃分Stage,生成Taskset,Executor申請Task,并根據(jù)任務(wù)創(chuàng)建線程執(zhí)行任務(wù)健田。
- Flink支持三種時間機制：事件時間，注入時間佛纫，處理時間妓局，同時支持 watermark 機制處理滯后數(shù)據(jù)。Spark Streaming 只支持處理時間呈宇，Structured streaming 支持處理時間和事件時間好爬，同時支持 watermark 機制處理滯后數(shù)據(jù)。
- Flink和Spark雖然都支持Exactly once的語義一致性甥啄，但是其原理不同存炮，Spark 使用checkpoint,只能保證數(shù)據(jù)不丟失，不能做到一致性蜈漓。在使用kafka時需穆桂，維護offset,同時結(jié)果輸出和 offset 提交必須在一個事務(wù)，才能保證一致性融虽。Flink使用兩階段提交協(xié)議以及預(yù)提交(pre-commit)階段來解決語義一致性享完。
- Spark與Flink背壓不同，Spark Streaming 在原有的架構(gòu)上加入了一個 RateController衣形，利用的算法是 PID驼侠，需要的反饋數(shù)據(jù)是任務(wù)處理的結(jié)束時間姿鸿、調(diào)度時間、處理時間倒源、消息條數(shù)苛预，這些數(shù)據(jù)是通過 SparkListener 體系獲得，然后通過 PIDRateEsimator 的 compute 計算得到一個速率笋熬，進而可以計算得到一個 offset热某，然后跟限速設(shè)置最大消費條數(shù)比較得到一個最終要消費的消息最大 offset。與 Spark Streaming 的背壓不同的是胳螟，F(xiàn)link 背壓是 jobmanager 針對每一個 task 每 50ms 觸發(fā) 100 次 Thread.getStackTrace() 調(diào)用昔馋，求出阻塞的占比。
參考：https://blog.csdn.net/b6ecl1k7BS8O/article/details/81350587
Spark 和 Flink 的應(yīng)用場景
- Spark 適合于吞吐量比較大的場景糖耸，數(shù)據(jù)量非常大而且邏輯復(fù)雜的批數(shù)據(jù)處理秘遏，并且對計算效率有較高要求（比如用大數(shù)據(jù)分析來構(gòu)建推薦系統(tǒng)進行個性化推薦、廣告定點投放等）嘉竟。
- 其次邦危，Spark是批處理架構(gòu)，適合基于歷史數(shù)據(jù)的批處理舍扰。最好是具有大量迭代計算場景的批處理倦蚪。
- Spark可以支持近實時的流處理，延遲性要求在在數(shù)百毫秒到數(shù)秒之間边苹。
- Spark的生態(tài)更健全陵且，SQL操作也更加健全，已經(jīng)存在Spark生態(tài)的可以直接使用个束。
- Flink 主要用來處理要求低延時的任務(wù)慕购，實時監(jiān)控、實時報表播急、流數(shù)據(jù)分析和實時倉庫脓钾。
- Flink可以用于事件驅(qū)動型應(yīng)用，數(shù)據(jù)管道桩警，數(shù)據(jù)流分析等可训。
