flink架構介紹

時間 2019-11-08

原文原文鏈接

前言

flink做爲基於流的大數據計算引擎，能夠說在大數據領域的紅人，下面對flink-1.7的架構進行邏輯上的分析並和spark作了一些關鍵點的對比。html

架構

如圖1，flink架構分爲3個部分，client，JobManager（簡稱jm）和TaskManager（簡稱tm）。client負責提交用戶的應用拓撲到jm，注意這和spark的driver用法不一樣，flink的client只是單純的將用戶提交的拓撲進行優化，而後提交到jm，不涉及任何的執行操做。jm負責task的調度，協調checkpoints，協調故障恢復等。tm負責管理和執行task。經過flink的架構咱們能夠了解到，flink把任務調度管理和真正執行的任務分離，這裏的分離說的是物理分離。而對比spark的調度和執行任務是在一個jvm裏的，也就是driver。分離的好處很明顯，不一樣任務能夠複用同一個任務管理（jm，tm），避免屢次提交，缺點可能就是多了一個步驟，須要額外提交維護tm。apache

圖1 架構session

flink架構中另外一個重要的概念是slot，在tm中有一個slot的概念，這個概念相似storm裏的slot，用來控制併發度的，但不一樣於storm，flink的slot控制的是線程。首先1個tm對應1個jvm，而後併發度task對應一個線程，而slot就表明1個tm中能夠執行的最大的task數。此外，task被tm管理，可是目前只會對內存進行管理，cpu是不作限制的。建議slot的數量和該節點的cpu數量保持一致。架構

部署策略

flink支持多種部署策略，獨立部署模式或者基於其餘資源容器yarn，mesos。併發

standalone

不依賴第三方資源容器進行部署，部署相對麻煩，須要將jm，tm分別部署到多個節點中，而後啓動，通常不建議單獨部署。app

yarn

基於yarn的部署是比較常見的，flink提供了兩種基於yarn的提交模式，attached和detached。不管是jb和tm的提交仍是任務的提交都支持這兩種模式。和spark基於yarn的兩種模式不一樣，flink的這兩種模式僅僅只是在client端阻塞和非阻塞的區別，attached模式會hold yarn的session直到任務執行結束，detached模式在提交完任務後就退出client，這個區別是很簡單的。結合flink的架構來看，client不參與任何任務的執行，這點和spark是有很大區別的，不要搞混。jvm

調度

flink一樣採用了基於圖的調度策略，client生成圖而後提交給jm，jm解析後執行。可是flink的對task的執行思路和spark不一樣，spark是基於一個操做的併發，而flink是基於操做鏈的併發，這裏先解釋一下操做鏈，好比source(),map(),filter()這些都是操做，操做鏈就是多個連續的操做合併到一塊兒，如圖2，source(),map()造成一個操做鏈，keyBy(),window(),apply()[1]造成一個操做鏈。flink這樣設計的目的在於，操做鏈中的全部操做可使用一個線程來執行，這樣能夠避免多個操做在不一樣線程執行帶來的上下文切換損失，而且能夠直接在一個jvm中共享數據，這個思路能夠說是一種新的優化思路。圖3能夠從一個任務的角度看到flink的併發思路。分佈式

圖2大數據

圖3優化