分佈式大數據處理系統概覽（四）
本博文主要對現如今分佈式大數據處理系統進行概括整理，相關課程爲華東師範大學數據科學與工程學院《大數據處理系統》，參考大夏學堂，下面主要整理HDFS/MapReduce/Spark/Yarn/Zookeeper/Storm/SparkStreaming/Lambda/DataFlow/Flink/Giraph有關的內容。
分佈式大數據處理系統大綱
- 分佈式大數據處理系統概覽（一）：HDFS/MapReduce/Spark
- 分佈式大數據處理系統概覽（二）：Yarn/Zookeeper
- 分佈式大數據處理系統概覽（三）：Storm/SparkStreaming
- 分佈式大數據處理系統概覽（四）：Lambda/DataFlow/Flink/Giraph
10 批流融合系統
10.1 批處理與流計算對比：
（1）批處理系統適合處理大批量數據volume，實時性要求不高的應用場景；
（2）流計算系統適合處理快速產生的數據velocity，實時性要求高的應用場景；
10.2 Lambda
（1）設計思想：Lambda架構的目標是設計出一個能滿足實時大數據系統關鍵特性的架構，包括有：高容錯、低延時和可擴展等。Lambda架構整合離線計算和實時計算，融合不可變性（Immunability），讀寫分離和複雜性隔離等一系列架構原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數據組件。
（2）架構：
# Batch Layer：批處理層（全量計算——針對全體數據進行預運算），主要功能用於存儲全體數據集（Master Dataset，不可變），針對這個數據集進行預運算，計算出查詢函數，構建對應的view：batch view = funciton1(master data)
# Speed Layer：加速層（增量運算——只對新增的實時數據進行運算）：用來處理增量的實時數據（最近增量的數據），並不但更新Realtime View：realtime view = function2(realtime view, new data)
# Servimg Layer：服務層用於響應用戶的查詢請求，合併Batch View和Realtime View中的結果數據集到最終的數據集。Query = function3(batch view, relatime view)
（3）優缺點：
# 優點：平衡了重新計算高開銷和需求低延遲的矛盾
# 缺點：開發複雜，實時數據與全體數據合併困難，運維複雜等
10.3 DataFlow
（1）設計思路：由於Lambda架構僅是將批處理與流處理兩個不同的計算框架簡單地拼接起來，並不能本質上解決問題。Dataflow計算模型，則是希望從編程模型的源頭上，統一解決傳統的流式和批量這兩種計算語意所希望處理的問題。
（2）數據類型：
# 有界（bounded）：系統處理的數據是有界的，對應於批處理數據；
# 無解（unbounded）：系統處理的數據是無限的，對應於流數據。
（3）窗口操作：Dataflow認爲batch的處理模式只是streaming處理模式的一個子集。在無邊界數據集的處理過程中，要及時產出數據結果，無限等待顯然是不可能的，所以必然需要對要處理的數據劃定一個窗口區間，從而對數據及時的進行分段處理和產出，而各種處理模式（stream，micro batch，session，batch），本質上，只是窗口的大小不同，窗口的劃分方式不同而已。
（4）Dataflow時間概念：
# 事件事件Event Time：該事件實際發生的時間；事件一旦發生永遠不會變
# 處理時間Processing Time：在數據處理時被系統觀察到的時間；持續變化
（5）輸入數據的特點：由於各種原因，數據採集，傳輸到達處理系統的時間可能會有長短不同的延遲，在分佈式應用場景環境下，出現延遲，數據亂序到達往往是常態。數據處理過程中需要注意的：
# 操作原語：1、ParDo：用於進行通用的並行化處理；GroupByKey：用來按鍵將元素重新分組；
# 窗口表達：Dataflow系統中，將常見的流式計算框架中的[key，value]兩元組tuple形式的信息數據，變換成了[key,value, event time, window]這樣的四元組模型。基於窗口的原子操作（窗口合併、窗口分組、按鍵分組等）
# 觸發器：在某一處理時間決定處理窗口的聚合結果，窗口的語義需要根據事件時間，觸發器則需要利用水位線
10.4 一體化執行引擎
（1）將批流系統分開編程變爲統一編程：Dataflow、Beam等；將兩套執行引擎變爲一體化的批流融合執行引擎：Spark Structured Streaming、Flink：
# 以批處理爲核心（微批處理——基於批處理來處理無界數據）：將無界數據集劃分爲小批量數據，並啓動短作業處理
# 以流計算爲核心（連續處理）：對於有界數據集來說，相當於系統接收一定量的記錄之後就不再接收新的記錄了，需要啓動長作業處理。
11 批流融合系統Flink
11.1 設計思想：
（1）數據模型：Flink將輸入數據看做是一個不間斷的無界的連續數據項序列DataStream；
（2）迭代模型：Flink將迭代的整體視爲一個算子，是一個DAG；
迭代對比：
（3）架構：
# Client：JobClient負責接受用戶的程序代碼，然後創建數據流，並翻譯爲邏輯執行圖並進行chaining優化，將優化後的邏輯執行圖提交給 JobManager 以便進一步執行。執行完成後，JobClient將結果返回給用戶。
# JobManager（作業管理器）：負責協調系統任務執行（任務分配調度、狀態快照），管理checkpoint ，故障恢復等；
# TaskManager（任務管理器）：從 Job Manager 處接收需要部署的 Task。Task Manager 是在 JVM 中的一個或多個線程中執行任務的工作節點。任務執行的並行性由每個Task Manager上可用的任務槽決定。 每個任務代表分配給任務槽的一組資源。 例如，如果 Task Manager 有四個插槽，那麼它將爲每個插槽分配 25％ 的內存。 可以在任務槽中運行一個或多個線程。 同一插槽中的線程共享相同的 JVM。 同一 JVM 中的任務共享 TCP 連接和心跳消息。TaskManager 將內存抽象爲多個TaskSlot，Task Manager 的一個 Slot 代表一個可用線程，該線程具有固定的內存，注意 Slot 只對內存隔離，沒有對 CPU 隔離。默認情況下，Flink 允許子任務共享 Slot，即使它們是不同 task 的 subtask，只要它們來自相同的 job。這種共享可以有更好的資源利用率。
（4）chainning優化：將某些算子合併到一個Task中執行
11.2 工作原理：
（1）非迭代任務之間的數據交換：
# Flink採用流水線方式進行數據交換，上游的Task將數據存儲在buffer緩存中，一旦滿了或超時，則向下遊的Task發送；Flink的pipeline流水線是不同Task之間的數據傳輸（相比之下，Spark的pipeline是stage內部同一個Task的多個不同算子之間的數據傳輸）
# Task之間數據交換方式：阻塞式和非阻塞式：
（2）迭代算子內部的數據交換
# 流式迭代：下左圖
# 批式迭代：當滿足迭代停止條件時，iterationHead發出特殊的控制事件，iterationTail不再反饋數據（上右圖）
（3）Dataflow模型：
# 事件時間：時間發生的時間；
# 水位線：水位線所示的事件時間表示早於該時間的記錄已經完全被系統觀察到；
# 窗口與觸發器
# 算子的watermaker：上游的算子將watermaker傳遞給下游算子
（4）Window操作：
# window assigner：負責將元素分配到不同的window；
# trigger：觸發器，定義什麼情況觸發計算；
# 窗口類型：基於處理時間、基於事件時間
11.3 容錯
（1）狀態管理
# 定義：一種特殊的數據結構，用於記錄需要保存的算子計算結果；
# 有狀態算子：具備記憶能力的算子（可以保留和已經處理完的輸入相關的信息，並對後續輸入的處理造成影響）；無狀態算子：只考慮當前的元素，不會受到處理完畢的元素的影響，也不會影響後續待處理的元素；
# 狀態保存與恢復由系統負責；
# 狀態快照：DAG中若干算子的狀態需要同一時刻被保存；
# 系統主要劃分三類數據，分別是：進入系統且已成功處理的數據（有狀態快照）；進入系統但未成功處理的數據；未進入系統的數據；
# 恢復辦法：
（2）非迭代計算過程中容錯：
# 同步快照：將數據劃分爲一系列的片段，處理一個片段時記錄所有算子的狀態，處理完一個片段後處理下一個片段；類似微批處理，延時高；
# 異步快照：在輸入數據時加入一個barrier（屏障），在處理第一個片段時允許下一個片段進入系統；當某一個算子（結點）接收到一個屏障時，需要暫停接收該屏障所在的數據流，等待接收其他所有屏障（該步驟稱爲片段對齊），避免給算子保存的狀態處理到下一個片段的數據
（3）迭代計算過程中的容錯：
# 首先向每一個數據源發送屏障，
# 如果節點有多條輸入流，在接收到某一條流的屏障之後需要暫時停止對該流的接收，直到接收到該節點所有輸入流中的屏障。
# 對於某一個有倒向輸入流的節點，記錄下每一個倒向流動的數據，直到收到一個倒向的屏障（比如下圖圖c）。收到倒向的屏障之後，生成當前快照。當前快照的內容包括當前節點的運行狀態信息（這個跟有向無環圖一樣），還包含所有所記錄的倒向的數據。在下圖中，倒向的數據是被長方形圈住的三個紅點。
12 圖處理
（1）圖處理的設計思想：
# 對圖處理算法的調用；
# 支持大規模圖處理；
# 自身具備容錯能力；
# 爲圖處理進行優化
（2）MapReduce圖處理
# 將圖轉換爲key-value格式的文件；
# 將圖計算作爲一般的迭代過程；
# 系統爲針對迭代進行優化；
# 圖計算過程中可能僅需要更新部分結點；
13 Giraph/Pregel模型
（1）數據模型：
# 鄰接表&鄰接矩陣；
# 頂點與邊：[vertextID,value,[targetID,weight1],[targetID2,weight2],…]
（2）計算模型：
# 以頂點爲主進行數據表示，頂點執行用戶自定義的計算；
# 邊不會執行計算；
# Combiner：根據定義的combine()函數將發往同一個頂點的U盾謳歌消息進行合併成一個消息，減少傳輸和緩存的開銷；
# Aggregator：全局通信、監控和數據查看的機制：每個頂點都可以向某個aggregator提供數據，系統對這些值聚合後形成一個值，所有頂點可獲取這個值；
（3）迭代模型：
# BSP模型（Bulk Synchronous Parallel）：整體同步準則（超步superstep）
# BSP程序有一系列串行的超步組成，一個超步分爲三個階段：局部計算階段（每個處理器只對存儲本地內存的數據進行本地計算）、全局通信階段（對非本地的數據進行操作）、柵欄同步階段（等待所有通信行爲的結束）
# Giraph/Pregel的BSP過程：
- 局部計算：讀取上一超步得到的消息，並根據自定義的compute函數執行本地計算，更新當前頂點的value以及以該頂點爲源點的所有邊上的權值；
- 全局通信，通過SendMessageTo函數將消息發送給其他頂點；其他頂點獲得消息後繼續執行；
- 柵欄階段：所有頂點等待同步；
14 Pregel架構
（1）Master：負責管理各個Worker執行任務：
# 協調各個Worker執行任務，Worker向Master發送註冊信息，Master爲Worker分配唯一的ID；
# Master維護Worker的地址信息、ID信息、以及被分配到的分區信息；
# Master維護的數據信息的大小隻與分區數量有關，與頂點和邊的數量無關；
（2）Worker系統將圖進行劃分，形成若個分區，每個Worker負責一個或多個分區，並負責針對該分區的計算任務；其所管轄的分區的頂點描述信息時保存在內存中的：
# 頂點與邊的值；
# 消息：包含所有接收到的、發送的消息；
# 標誌位：用來標記頂點是否處於活躍狀態
（3）Coordination Service：協調Master與worker以及worker之間；
15 Giraph
15.1 架構
（1）Giraph參考Pregel體系，而實現過程中借用MapReduce啓動Master和Worker進程，執行Giraph作業只啓動了Map任務；
（2）Giraph採用Zookeeper服務管理體系，通過分佈式選主，選擇一個Map任務作爲Giraph Master；同時Zookeeper支持BSP模式中的柵欄同步；
（3）運行流程：
15.2 工作原理
（1）圖數據的劃分：
# Giraph將一張圖根據頂點分解爲多個分區，再根據ID將頂點分配到各個分區，默認劃分函數Hash(ID) mod N，其中N爲分區的總數；
# 數據劃分實際上是完成輸入數據（HDFS上的劃分可能是對數據的排序，Giraph則是按照取模）到Giraph期望分區的調整；
（2）超步計算：
# MegStore：存儲兩份信息：（t）存儲在超步t-1全局通信階段獲取的消息，此消息用於t超步的compute計算；（t+1）在超步t獲取的消息，用於t+1超步的compute計算。亦即：在當前t階段，既要存儲上一超步得到的消息並在此時進行計算的同時，還要接收當前收到的新信息；
# 當前超步t中，需要存儲兩份標誌位：
某一頂點的處理過程：
（3）Worker同步：
# 多個worker同時進行超步計算，同步控制保證每個worler都完成超步t後再進入t+1；Master與Giraph通過Zookeeper完成同步；
# 超步同步完成後根據StatStore t+1信息把在下一個超步還處於活躍狀態的頂點數目通知Master，若數量爲0，則迭代過程結束，Worker對各自計算結果進行持久化存儲；該部分與MapReduce區別在於MapReduce迭代過程中每次產生中間結果都需要反覆讀寫HDFS，而Giraph的中間結果存儲在內存中；
15.3 容錯
（1）主節點JobTracker故障：重啓；
（2）從節點：
# Master故障：
# Worker故障：設置檢查點：設置檢查點間隔，即每個一定超步，Master通知所有的Worker將管轄的分區狀態（頂點、邊、接收到的消息）寫入持久化存儲中；
# Worker故障恢復：
分佈式大數據處理系統大綱
- 分佈式大數據處理系統概覽（一）：HDFS/MapReduce/Spark
- 分佈式大數據處理系統概覽（二）：Yarn/Zookeeper
- 分佈式大數據處理系統概覽（三）：Storm/SparkStreaming
- 分佈式大數據處理系統概覽（四）：Lambda/DataFlow/Flink/Giraph
博客記錄着學習的腳步，分享着最新的技術，非常感謝您的閱讀，本博客將不斷進行更新，希望能夠給您在技術上帶來幫助。喜歡請關注+點贊o(￣▽￣)ｄ