🍋🍋大數據學習🍋🍋
🔥系列專欄： 👑哲學語錄: 用力所能及，改變世界。
💖如果覺得博主的文章還不錯的話，請點贊👍+收藏??+留言📝支持一下博主哦🤞
🍋一、Flink and Spark基本原理
????????Flink 和 Spark Streaming 都是用于實時流式數據處理的分布式計算框架,但兩者的基本設計思想和內部執行機制有些不同。
????????Flink 基于流的理念,采用了基于數據流模型的核心運行時引擎。它可以對無界和有界數據流進行有狀態的計算。Flink 使用了鏈式操作來表達運算邏輯,并基于流水線的方式進行任務調度。
????????Spark Streaming 則是通過微批處理的方式來實現對實時數據流的處理。它將數據流切分成很小的批數據,然后提交給 Spark 執行批處理任務。Spark Streaming 基于 RDD 來表達運算邏輯,并通過 Spark 的任務調度機制進行調度。
????????Flink 的內部把流處理算法表示為數據流圖,并以流水線的方式持續運算。而 Spark Streaming 是將流任務拆解為一個個小批的 Spark 任務,這些批任務按時間順序執行。
????????兩者在 fault tolerance 機制上也有區別。Flink 基于檢查點機制實現了 exactly-once 語義。而 Spark Streaming 通過 Write ahead logs 實現了至少一次保證。
實現機制
- 數據處理模式上,Flink 是基于流的真正runtime,可以持續地對無界數據流進行計算。Spark Streaming 則采用的是微批處理模型,將數據流離散為批進行處理。
- Flink 通過aperator chains實現了流式數據流水線計算。Spark Streaming基于RDD拼接批結果來模擬流計算。
- Flink 使用輕量級的流水線調度機制進行任務調度。Spark Streaming則依賴Spark Engine進行任務調度。
- Flink檢查點機制實現了Exactly-once語義。Spark Streaming通過Write Ahead Logs實現了至少一次保證。
- Flink基于數據流圖進行計算,允許循環數據流(迭代計算)。Spark Streaming的DAG不允許存在循環。
- Flink有更低的延遲,可以達到毫秒級。Spark Streaming批間隔一般在500毫秒以上。
- Flink有更好的重啟能力,可以從檢查點恢復狀態。Spark Streaming重啟后需要重新計算。
- Flink有更多針對流的優化,如窗口機制等。Spark Streaming繼承自Spark的批設計。
- Flink需要額外的Cluster部署和操作。Spark Streaming可以直接基于Spark Cluster運行。
🍋二、運行角色
Spark Streaming 運行時的角色(standalone 模式)主要有：
-
Master:主要負責整體集群資源的管理和應用程序調度；
-
Worker:負責單個節點的資源管理，driver 和 executor 的啟動等；
-
Driver:用戶入口程序執行的地方，即 SparkContext 執行的地方，主要是 DGA 生成、stage 劃分、task 生成及調度；
-
Executor:負責執行 task，反饋執行狀態和執行結果。
-
Flink 運行時的角色(standalone 模式)主要有:
-
Jobmanager: 協調分布式執行，他們調度任務、協調 checkpoints、協調故障恢復等。至少有一個 JobManager。高可用情況下可以啟動多個 JobManager，其中一個選舉為 leader，其余為 standby；
-
Taskmanager: 負責執行具體的 tasks、緩存、交換數據流，至少有一個 TaskManager；
-
Slot: 每個 task slot 代表 TaskManager 的一個固定部分資源，Slot 的個數代表著 taskmanager 可并行執行的 task 數。
🍋三、spark?streaming和Flink運行模型
1.Spark Streaming 是微批處理，運行的時候需要指定批處理的時間，每次運行 job 時處理一個批次的數據，流程如圖 3 所示：
2.Flink 是基于事件驅動的，事件可以理解為消息。事件驅動的應用程序是一種狀態應用程序，它會從一個或者多個流中注入事件，通過觸發計算更新狀態，或外部動作對注入的事件作出反應。
🍋四、任務調度
1.Spark 任務調度
????????Spark Streaming 任務如上文提到的是基于微批處理的，實際上每個批次都是一個 Spark Core 的任務。對于編碼完成的 Spark Core 任務在生成到最終執行結束主要包括以下幾個部分：
-
構建 DGA 圖；
-
劃分 stage；
-
生成 taskset；
-
調度 task。
????????對于 job 的調度執行有 fifo 和 fair 兩種模式，Task 是根據數據本地性調度執行的。 假設每個 Spark Streaming 任務消費的 kafka topic 有四個分區，中間有一個 transform操作（如 map）和一個 reduce 操作。
????????假設有兩個 executor，其中每個 executor 三個核，那么每個批次相應的 task 運行位置是固定的嗎？是否能預測？ 由于數據本地性和調度不確定性，每個批次對應 kafka 分區生成的 task 運行位置并不是固定的。
2.Flink 任務調度
????????對于 flink 的流任務客戶端首先會生成 StreamGraph，接著生成 JobGraph，然后將 jobGraph 提交給 Jobmanager 由它完成 jobGraph 到 ExecutionGraph 的轉變，最后由 jobManager 調度執行。
? ? ? ? 上圖所示有一個由 data source、MapFunction和 ReduceFunction 組成的程序，data source 和 MapFunction 的并發度都為 4，而 ReduceFunction 的并發度為 3。一個數據流由 Source-Map-Reduce 的順序組成，在具有 2 個TaskManager、每個 TaskManager 都有 3 個 Task Slot 的集群上運行。
????????可以看出 flink 的拓撲生成提交執行之后，除非故障，否則拓撲部件執行位置不變，并行度由每一個算子并行度決定，類似于 storm。而 spark Streaming 是每個批次都會根據數據本地性和資源情況進行調度，無固定的執行拓撲結構。 flink 是數據在拓撲結構里流動執行，而 Spark Streaming 則是對數據緩存批次并行處理。
】)
