大數據Flink學習系列文章(快學)---02 Flink基本概念及架構

Flink筆記02--Flink基本概念及架構

1、基本概念

無界和有界數據。任何類型的數據都可以形成一種事件流。信用卡交易、傳感器測量、機器日誌、網站或移動應用程序上的用戶交互記錄,所有這些數據都形成一種流。數據可以被作爲 無界 或者 有界 流來處理。

  • 無界流 有定義流的開始,但沒有定義流的結束。它們會無休止地產生數據。無界流的數據必須持續處理,即數據被攝取後需要立刻處理。我們不能等到所有數據都到達再處理,因爲輸入是無限的,在任何時候輸入都不會完成。處理無界數據通常要求以特定順序攝取事件,例如事件發生的順序,以便能夠推斷結果的完整性。
  • 有界流 有定義流的開始,也有定義流的結束。有界流可以在攝取所有數據後再進行計算。有界流所有數據可以被排序,所以並不需要有序攝取。有界流處理通常被稱爲批處理。

 

Apache Flink 擅長處理無界和有界數據集。精確的時間控制和狀態化使得 Flink 的運行時能夠運行任何處理無界流的應用。有界流則由一些專爲固定大小數據集特殊設計的算法和數據結構進行內部處理,產生了出色的性能。

State。狀態是計算過程中的數據信息,在容錯恢復和 Checkpoint 中有重要的作用,流計算在本質上是 Incremental Processing,因此需要不斷查詢保持狀態;另外,爲了確保 Exactly- once 語義,需要數據能夠寫入到狀態中;而持久化存儲,能夠保證在整個分佈式系統運行失敗或者掛掉的情況下做到 Exactly- once,這是狀態的另外一個價值。

應用狀態是 Flink 中的一等公民,Flink 提供了許多狀態管理相關的特性支持,其中包括:

  • 多種狀態基礎類型:提供多種狀態基礎類型,例原子值(value),列表(list)以及映射(map);
  • 插件化的State Backend: State Backend 負責管理應用程序狀態,並在需要的時候進行 checkpoint。Flink 支持多種 state backend,可將狀態保存在 內存 或 Rocks DB,以及自定義 state backend 進行狀態存儲。
  • 精確一次語義:Flink 的 checkpoint 和故障恢復算法保證了故障發生後應用狀態的一致性。Flink 能夠在應用程序發生故障時,對應用程序透明,不造成正確性的影響。
  • 超大數據量狀態:Flink 能夠利用其異步以及增量式的 checkpoint 算法,存儲數 TB 級別的應用狀態。
  • 可彈性伸縮的應用:Flink 能夠通過在更多或更少的工作節點上對狀態進行重新分佈,支持有狀態應用的分佈式的橫向伸縮。

時間是流處理應用另一個重要的組成部分。因爲事件總是在特定時間點發生,所以大多數的事件流都擁有事件本身所固有的時間語義。進一步而言,許多常見的流計算都基於時間語義,例如窗口聚合、會話計算、模式檢測和基於時間的 join。流處理的一個重要方面是應用程序如何衡量時間,即區分事件時間(event-time)和處理時間(processing-time)。

Flink 提供了豐富的時間語義支持。分爲 Event time、Ingestion time、Processing time,Flink 的無限數據流是一個持續的過程,時間是判斷業務狀態是否滯後,數據處理是否及時的重要依據。

API。Flink將數據處理接口抽象成四層:

  • SQL API:SQL語言的學習成本低,能夠讓數據分析人員和開發人員快速上手,幫助其更加專注業務本身而不受限於複雜的編程接口,可以通過SQL API完成對批計算和流計算的處理;
  • Table API:將內存中 DataStream 和 DataSet 在原有的基礎上增加Schema信息,將數據類型統一抽象成表結構,然後通過Table API提供的接口處理對應的數據集;
  • DataStream/DataSet API:主要面向具有開發經驗的用戶,用戶可以根據API處理無界流數據和批量數據;
  • Stateful Stream Processing:是Flink中最底層的開發接口,可以使用接口中操作狀態、時間等底層數據,可以實現非常複雜的流式計算邏輯。

API越接近 SQL 層,表達能力會逐步減弱,抽象能力會增強。反之越接近底層,API 的表達能力越強,可以進行多種靈活方便的操作,但抽象能力也相對越小。

 

2、架構

瞭解一個系統,基本都是從架構開始。系統由哪些組件組成,安裝時各節點需要啓動哪些服務,各個服務之間如何交互協調,這些都是首先需要了解的。Flink系統的架構與Spark類似,也是基於Master-Slave風格的架構,如下圖所示:

Flink集羣啓動時,會啓動一個JobManager進程、至少一個TaskManager進程

JobManager

  • Flink系統的協調者,負責接受 Job ,調度組成Job的多個Task的執行
  • 收集Job的狀態信息,並管理Flink集羣中從節點 TaskManager

TaskManager

  • 負責執行計算的Worker,在其上執行Flink Job的一組Task
  • TaskManager負責管理其所在節點上的資源信息,如內存、磁盤、網絡,在啓動的時候將資源的狀態向 JobManager 彙報

Client

  • 用戶提交一個Flink程序時,會首先創建一個Client。Client首先會對提交的Flink程序進行預處理,並提交到Flink集羣
  • Client會將用戶提交的Flink程序組裝JobGraph,最終以JobGraph的形式提交

3、Flink組件棧

Flink 同樣遵循着分層的架構設計理念,在降低系統耦合的同時,也爲上層用戶構建 Flink 應用提供了豐富且友好的接口。

Flink 分層架構,從上到下依次是:API & Libraries 層、Runtime 核心層 和 物理部署層。

API & Libraries 層Flink 同時提供流計算和批計算的接口,並在此基礎上抽象出不同的應用類型的組件庫。如基於流處理的 CEP (複雜事件處理庫),SQL & TABLE 庫 和 基於批處理的機器學習庫(FlinkML)、圖處理庫(Gelly)。

API 層包括構建流計算應用的 DataStream API 和批計算應用的 DataSet API,兩者都是提供給用戶豐富的數據處理高級 API,例如 Map,FlatMap 等。同時也提供比較低級的 Process Function API ,用戶可以直接操作狀態和時間等底層數據。

Runtime 核心層該層負責爲上層接口提供基礎服務,也是 Flink 分佈式計算框架的核心實現層。支持分佈式 Stream 作業的執行、JobGraph 到 ExecutionGraph 的映射轉換、任務調度等。將 DataStream 和 DataSet 轉成統一的可執行的 Task Operator,達到在流式引擎下同時處理批量計算和流式計算的目的。

物理部署層該層主要涉及 Flink 的部署模式,目前 Flink 支持多種部署模式:本地、集羣(Standalone / YARN)、雲(GCE / EC2)、kubenetes。Flink 能夠通過該層支持不同平臺的部署,用戶可以根據需要選擇使用對應的部署模式。

我會不間斷的更新,維護,希望可以對正在找大數據工作的朋友們有所幫助.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章