Flink關(guān)注點(diǎn)

記錄一下個(gè)人看了一些Flink文章后的理解與個(gè)人關(guān)注點(diǎn)，目錄如下，

0. Overview
1. 基本概念
2. 并行Dataflow
3. 基本模塊
   - JobManager
   - TaskManagers
   - Client
4. 組件棧
   - Deployment層
   - Runtime層
   - API層
   - Libraries層
5. 內(nèi)部原理
   - 容錯(cuò)機(jī)制
   - 調(diào)度機(jī)制
   - 迭代機(jī)制
   - 反壓機(jī)制
6. Reference

Overview

基于Flink 1.4。
先來(lái)看看大數(shù)據(jù)計(jì)算引擎的發(fā)展路線，

  1. 第一代，hadoop的MapReduce
  2. 第二代，DAG框架的Tez，Oozie
  3. 第三代，Job內(nèi)部的DAG支持，以及強(qiáng)調(diào)實(shí)時(shí)計(jì)算，spark
  4. 第四代，迭代，流，批，SQL

基本概念

source -> transformation -> sink

  • stream是算子的中間結(jié)果數(shù)據(jù)
  • transformation是一個(gè)操作，它對(duì)一個(gè)或多個(gè)輸入stream進(jìn)行計(jì)算處理，輸出一個(gè)或多個(gè)結(jié)果stream
  • streaming dataflow是一個(gè)執(zhí)行中的flink程序，啟動(dòng)于一個(gè)或多個(gè)source，結(jié)束于一個(gè)或多個(gè)sink
a complete streaming dataflow (flink apploication)

并行Dataflow

一個(gè)stream可以被分成多個(gè)stream分區(qū)（stream partition）。
一個(gè)operator可以被分成多個(gè)operator subTask。

parallel

基本模塊

flink類(lèi)似spark，是一個(gè)基于master-slave風(fēng)格的架構(gòu)。
運(yùn)行時(shí)runtime主要有2個(gè)進(jìn)程，一個(gè)是JobManagers，另一個(gè)是TaskManagers；client不屬于運(yùn)行時(shí)和程序執(zhí)行的一部分，而是用于準(zhǔn)備dataflow并將其發(fā)送到JobManager。

flink生態(tài)部件

jobManager(master)是flink系統(tǒng)的協(xié)調(diào)者，負(fù)責(zé)接收f(shuō)link job，調(diào)度組成job的多個(gè)task的執(zhí)行；手機(jī)job的狀態(tài)信息，管理flink集群中從節(jié)點(diǎn)taskManager，

  • registerTaskManager，在Flink集群?jiǎn)?dòng)的時(shí)候，TaskManager會(huì)向JobManager注冊(cè)
  • submitJob，F(xiàn)link程序內(nèi)部通過(guò)Client向JobManager提交Flink Job，其中在消息SubmitJob中以JobGraph形式描述了Job的基本信息
  • cancelJob，請(qǐng)求取消一個(gè)Flink Job的執(zhí)行，CancelJob消息中包含了Job的ID
  • updateTaskExecutionState，TaskManager向JobManager請(qǐng)求更新?tīng)顟B(tài)信息
  • requestNextInputSplit，運(yùn)行在TaskManager上面的Task，請(qǐng)求獲取下一個(gè)要處理的輸入Split
  • jobStatusChanged，表示Flink Job的狀態(tài)發(fā)生的變化

taskManager是一個(gè)actor(akka)，負(fù)責(zé)執(zhí)行計(jì)算的worker，在其上執(zhí)行flink job的一組task。每個(gè)taskManager負(fù)責(zé)管理其所在節(jié)點(diǎn)上的資源信息，如mem, disk, network，在啟動(dòng)的時(shí)候?qū)①Y源狀態(tài)向jobManager匯報(bào)，

  • 注冊(cè)階段，TaskManager會(huì)向JobManager注冊(cè)，發(fā)送registerTaskManager消息
  • 可操作階段，接收并處理與Task有關(guān)的消息，如SubmitTask、CancelTask、FailTask

client，當(dāng)用戶(hù)提交一個(gè)flink程序時(shí)，會(huì)首先創(chuàng)建一個(gè)client，該client首先會(huì)對(duì)用戶(hù)提交的flink程序進(jìn)行預(yù)處理，并提交到flink集群中，

  • client需要從用戶(hù)提交的flink程序配置中獲取jobManager的地址，并建立到j(luò)obManager的連接，將flink job提交給jobManager
  • client會(huì)將用戶(hù)提交的flink程序組裝成一個(gè)jobGraph，并且是以jobGraph的形式提交。一個(gè)jobGraph是一個(gè)flink dataflow，它是由多個(gè)jobVertex組成的DAG。JobManager會(huì)將一個(gè)JobGraph轉(zhuǎn)換映射為一個(gè)ExecutionGraph

組件棧

Flink是一個(gè)分層架構(gòu)的系統(tǒng)，每一層所包含的組件都提供了特定的抽象，用來(lái)服務(wù)于上層組件，

flink組件棧
flink on yarn

啟動(dòng)flink yarn session的時(shí)候，

  1. 最左邊的模塊Flink YARN Client check requested resources (containers and memory) are available，檢查資源可得性
  2. Client uploads a jar that contains Flink and the configuration to HDFS，上傳代碼和配置
  3. Client request a YARN container to start the ApplicationMaster(AM，單個(gè)作業(yè)的資源管理和任務(wù)監(jiān)控模塊，以前是一個(gè)全局的JobTracker負(fù)責(zé)的，現(xiàn)在每個(gè)作業(yè)都一個(gè))，啟動(dòng)yarn AM
  4. AM starts allocating the containers for Flink’s TaskManagers, which will download the jar file and the modified configuration from the HDFS

客戶(hù)端client負(fù)責(zé)向ResourceManager(RM)提交ApplicationMaster，并查詢(xún)應(yīng)用程序運(yùn)行狀態(tài)，ApplicationMaster(AM)負(fù)責(zé)向ResourceManager申請(qǐng)資源（以Container形式表示），并與NodeManager(NM)通信以啟動(dòng)各個(gè)Container，此外，ApplicationMaster還負(fù)責(zé)監(jiān)控各個(gè)任務(wù)運(yùn)行狀態(tài)，并在失敗是為其重新申請(qǐng)資源。

flink RM Dispatcher，用于統(tǒng)一發(fā)布Job并監(jiān)控實(shí)例的運(yùn)行。但是可以選擇是否使用Dispatcher。

without dispatch yarn
with dispatch yarn
with dispatch mesos
  • Runtime層，提供了支持Flink計(jì)算的全部核心實(shí)現(xiàn)
  • API層，實(shí)現(xiàn)了面向無(wú)界streaming的流處理和面向有界Batch的批處理接口
  • Libraries層，F(xiàn)link應(yīng)用框架層，CEP復(fù)雜事件處理、Table基于SQL-like的關(guān)系操作、FlinkML機(jī)器學(xué)習(xí)、Gelly圖處理

內(nèi)部原理

容錯(cuò)機(jī)制

Flink基于Checkpoint機(jī)制實(shí)現(xiàn)容錯(cuò)，它的原理是不斷地生成分布式Streaming數(shù)據(jù)流Snapshot。在流處理失敗時(shí)，通過(guò)這些Snapshot可以恢復(fù)數(shù)據(jù)流處理。

Barriers

checkpoint, snapshot, stream aligning, exactly once, at least once

調(diào)度機(jī)制

在jobManager，會(huì)接收到client提交的jobGraph形式的flink job，并將其轉(zhuǎn)換映射為executionGraph

JobManager transforms the JobGraph into an ExecutionGraph
  • jobGraph是一個(gè)job的用戶(hù)邏輯視圖表示，將一個(gè)用戶(hù)要對(duì)數(shù)據(jù)流進(jìn)行的處理表示為單個(gè)DAG圖
  • executionGraph是jobGraph的并行表示，也就是實(shí)際jobManager調(diào)度一個(gè)job在taskManager上運(yùn)行的邏輯視圖，也是一個(gè)DAG
Op

上圖用戶(hù)提交的Flink Job對(duì)各個(gè)Operator進(jìn)行的配置（從下往上），即data source的并行度設(shè)置為4（最底層1個(gè)data source，但是其parallel=4），MapFunction的并行度也為4（中間層），ReduceFunction的并行度為3（頂層）。

迭代機(jī)制

機(jī)器學(xué)習(xí)和圖計(jì)算應(yīng)用，都會(huì)使用到迭代計(jì)算。flink通過(guò)迭代operator中定義step函數(shù)來(lái)實(shí)現(xiàn)迭代算法，包括Iterate和Delta Iterate兩類(lèi)，

iterate operator
delta iterate operator

反壓機(jī)制

flink使用了高效有界的分布式阻塞隊(duì)列，就像java通用的blockingQueue。一個(gè)較慢的接收者會(huì)降低發(fā)送者的發(fā)送速率，因?yàn)橐坏┯薪珀?duì)列滿了發(fā)送者會(huì)被阻塞。

flink在網(wǎng)絡(luò)傳輸場(chǎng)景下的內(nèi)存管理
  • 當(dāng)netty接收端發(fā)送數(shù)據(jù)時(shí)，為了將netty中的數(shù)據(jù)拷貝到task中（往task寫(xiě)入數(shù)據(jù)），InputChannel會(huì)向其對(duì)應(yīng)的緩沖池localBufferPool申請(qǐng)內(nèi)存塊，
    • 如果localBufferPool也沒(méi)有可用內(nèi)存塊且申請(qǐng)的數(shù)量還沒(méi)到池子（隊(duì)列）上限，則就向networkBufferPool申請(qǐng)內(nèi)存塊
    • 如果localBufferPool已申請(qǐng)的數(shù)量達(dá)到上限了，或者networkBufferPool也沒(méi)有可用內(nèi)存塊，此時(shí)task的netty channel會(huì)暫停讀取，上游的發(fā)送端會(huì)立即響應(yīng)停止發(fā)送，拓?fù)溥M(jìn)入反壓狀態(tài)
  • 當(dāng)task線程寫(xiě)數(shù)據(jù)到resultPartition時(shí)（task數(shù)據(jù)往外寫(xiě)），也會(huì)向池子請(qǐng)求內(nèi)存塊，如果沒(méi)有可用內(nèi)存塊時(shí)，也阻塞在請(qǐng)求內(nèi)存塊的地方，達(dá)到暫停寫(xiě)入的目的
  • 在一個(gè)內(nèi)存塊被消費(fèi)完成之后（在輸出端是指內(nèi)存塊中的字節(jié)寫(xiě)入到netty channel；在輸入端是指內(nèi)存塊中的字節(jié)被反序列化成對(duì)象），會(huì)調(diào)用buffer.recycle()方法，將內(nèi)存塊還給localBufferPool，如果localBufferPool中當(dāng)前申請(qǐng)的數(shù)量超過(guò)了池子容量，則localBufferPool會(huì)將該內(nèi)存塊回收給networkBufferPool。如果沒(méi)超池子容量，則繼續(xù)留在localBufferPool中，減少反復(fù)申請(qǐng)的開(kāi)銷(xiāo)

backPressure在流式計(jì)算系統(tǒng)中用于協(xié)調(diào)上、下游operator的處理速度。因?yàn)樵谝粋€(gè)stream上進(jìn)行處理的多個(gè)operator之間，它們的處理速度和方式可能非常不同，所以就存在上游operator如果處理速度過(guò)快，下游operator可能會(huì)堆積stream記錄。因此，對(duì)下游operator處理速度跟不上的情況，如果下游operator能夠?qū)⒆约禾幚頎顟B(tài)傳播給上游operator，使得上游operator處理速度慢下來(lái)，從而緩解上述問(wèn)題。

堆棧跟蹤Sampling線程

JobManager會(huì)反復(fù)調(diào)用Task運(yùn)行所在線程的Thread.getStackTrace()，默認(rèn)情況下，JobManager會(huì)每隔50ms觸發(fā)對(duì)每個(gè)Task依次進(jìn)行100次堆棧跟蹤調(diào)用，根據(jù)調(diào)用調(diào)用結(jié)果來(lái)確定Backpressure，通過(guò)計(jì)算得到一個(gè)比值radio來(lái)確定當(dāng)前運(yùn)行Job的Backpressure狀態(tài)。在Web界面上可以看到這個(gè)Radio值，它表示在一個(gè)內(nèi)部方法調(diào)用中阻塞（Stuck）的堆棧跟蹤次數(shù)，例如，radio=0.01，表示100次中僅有1次方法調(diào)用阻塞。Flink目前定義了如下Backpressure狀態(tài)：

  • OK: 0 <= Ratio <= 0.10
  • LOW: 0.10 < Ratio <= 0.5
  • HIGH: 0.5 < Ratio <= 1

Reference

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 簡(jiǎn)單之美 | Apache Flink：特性、概念、組件棧、架構(gòu)及原理分析http://shiyanjun.cn/...
    葡萄喃喃囈語(yǔ)閱讀 7,552評(píng)論 0贊 27
  • 介紹 概述 Apache Flink是一個(gè)面向數(shù)據(jù)流處理和批量數(shù)據(jù)處理的可分布式的開(kāi)源計(jì)算框架，它基于同一個(gè)Fli...
    stephen_k閱讀 51,632評(píng)論 0贊 22
  • Spring Cloud為開(kāi)發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見(jiàn)模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智...
    卡卡羅2017閱讀 136,569評(píng)論 19贊 139
  • Flink初體驗(yàn) 安裝 官網(wǎng)：http://flink.apache.org/downloads.html 可以看...
    it_zzy閱讀 29,945評(píng)論 0贊 10
  • 最近幾本書(shū)同步讀，跟著心情任性地切換。今天大部分時(shí)間在看"The Notebook"。 掐指算借回來(lái)這本書(shū)足足有一...
    史妍閱讀 307評(píng)論 2贊 2

友情鏈接更多精彩內(nèi)容