【Flink】-總結

時間 2019-12-13

標籤 Flink 總結简体版

原文原文鏈接

【Flink】-總結

不善於總結，就是在浪費時間

1、技術背景

Apache Flink（下簡稱Flink）項目是大數據處理領域最近冉冉升起的一顆新星，其不一樣於其餘大數據項目的諸多特性吸引了愈來愈多人的關注。

這幾年大數據的飛速發展，出現了不少熱門的開源社區，其中著名的有 Hadoop、Storm，以及後來的 Spark，他們都有着各自專一的應用場景。Spark 掀開了內存計算的先河，也之內存爲賭注，贏得了內存計算的飛速發展。Spark 的火熱或多或少的掩蓋了其餘分佈式計算的系統身影。就像 Flink，也就在這個時候默默的發展着。

在國外一些社區，有不少人將大數據的計算引擎分紅了 4 代，固然，也有不少人不會認同。咱們先姑且這麼認爲和討論。

首先第一代的計算引擎，無疑就是 Hadoop 承載的 MapReduce。這裏你們應該都不會對 MapReduce 陌生，它將計算分爲兩個階段，分別爲 Map 和 Reduce。對於上層應用來講，就不得不千方百計去拆分算法，甚至於不得不在上層應用實現多個 Job 的串聯，以完成一個完整的算法，例如迭代計算。

因爲這樣的弊端，催生了支持 DAG 框架的產生。所以，支持 DAG 的框架被劃分爲第二代計算引擎。如 Tez 以及更上層的 Oozie。這裏咱們不去細究各類 DAG 實現之間的區別，不過對於當時的 Tez 和 Oozie 來講，大多仍是批處理的任務。接下來就是以 Spark 爲表明的第三代的計算引擎。第三代計算引擎的特色主要是 Job 內部的 DAG 支持（不跨越 Job），以及強調的實時計算。在這裏，不少人也會認爲第三代計算引擎也可以很好的運行批處理的 Job。隨着第三代計算引擎的出現，促進了上層應用快速發展，例如各類迭代計算的性能以及對流計算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應該主要表如今 Flink 對流計算的支持，以及更一步的實時性上面。固然 Flink 也能夠支持 Batch 的任務，以及 DAG 的運算。首先，咱們能夠經過下面的性能測試初步瞭解兩個框架的性能區別，它們均可以基於內存計算框架進行實時計算，因此都擁有很是好的計算性能。通過測試Flink計算性能上略好。

測試環境：

1.CPU：7000個；

2.內存：單機128GB；

3.版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9

4.數據：800MB，8GB，8TB；

5.算法：K-means：以空間中K個點爲中心進行聚類，對最靠近它們的對象歸類。經過迭代的方法，逐次更新各聚類中心的值，直至獲得最好的聚類結果。

6.迭代：K=10，3組數據

迭代次數（縱座標是秒，橫座標是次數）

Spark和Flink所有都運行在Hadoop YARN上，性能爲Flink > Spark > Hadoop(MR)，迭代次數越多越明顯，性能上，Flink優於Spark和Hadoop最主要的緣由是Flink支持增量迭代，具備對迭代自動優化的功能

迭代次數（縱座標是秒，橫座標是次數）

Flink和spark的差別

技術	Spark	Flink
定義	彈性的分佈式數據集，並不是真正的實時計算	真正的流計算，就像storm同樣但flink同時支持有限的數據流計算（批處理）
高容錯	沉重	很是輕量級
內存管理	JVM相關操做暴露給用戶	Flink在JVM中實現的是本身的內存管理
程序調優	只有SQL有自動優化機制	自動地優化一些場景，好比避免一些昂貴的操做（如shuffle和sorts），還有一些中間緩存

2、技術簡介

不少人可能都是在 2015 年才聽到 Flink 這個詞，其實早在 2008 年，Flink 的前身已是柏林理工大學一個研究性項目，在 2014 被 Apache 孵化器所接受，而後迅速地成爲了 ASF（Apache Software Foundation）的頂級項目之一。Flink 的最新版本目前已經更新到了 1.6了，在不少人感慨 Spark 的快速發展的同時，或許咱們也該爲 Flink 的發展速度點個贊。Flink 是一個針對流數據和批數據的分佈式處理引擎。它主要是由 Java 代碼實現。目前主要仍是依靠開源社區的貢獻而發展。對 Flink 而言，其所要處理的主要場景就是流數據，批數據只是流數據的一個極限特例而已。再換句話說，Flink 會把全部任務當成流來處理，這也是其最大的特色。

Flink 能夠支持本地的快速迭代，以及一些環形的迭代任務。而且 Flink 能夠定製化內存管理。在這點，若是要對比 Flink 和 Spark 的話，Flink 並無將內存徹底交給應用層。這也是爲何 Spark 相對於 Flink，更容易出現 OOM 的緣由（out of memory）。就框架自己與應用場景來講，Flink 更類似與 Storm。若是以前瞭解過 Storm 或者 Flume 的讀者，可能會更容易理解 Flink 的架構和不少概念。

Flink核心是一個流式的數據流執行引擎，其針對數據流的分佈式計算提供了數據分佈、數據通訊以及容錯機制等功能。基於流執行引擎，Flink提供了諸多更高抽象層的API以便用戶編寫分佈式任務：

DataSet API，對靜態數據進行批處理操做，將靜態數據抽象成分佈式的數據集，用戶能夠方便地使用Flink提供的各類操做符對分佈式數據集進行處理，支持Java、Scala和Python。
DataStream API，對數據流進行流處理操做，將流式的數據抽象成分佈式的數據流，用戶能夠方便地對分佈式數據流進行各類操做，支持Java和Scala。
Table API，對結構化數據進行查詢操做，將結構化數據抽象成關係表，並經過類SQL的DSL對關係表進行各類查詢操做，支持Java和Scala。
此外，Flink還針對特定的應用領域提供了領域庫，例如：

Flink ML，Flink的機器學習庫，提供了機器學習Pipelines API並實現了多種機器學習算法。
Gelly，Flink的圖計算庫，提供了圖計算的相關API及多種圖計算算法實現。

3、應用領域

優化電子商務的實時搜索結果：阿里巴巴的全部基礎設施團隊使用flink實時更新產品細節和庫存信息，爲用戶提供更高的關聯性。針對數據分析團隊提供實時流處理服務：king經過flink-powered數據分析平臺提供實時數據分析，從遊戲數據中大幅縮短了觀察時間。
網絡/傳感器檢測和錯誤檢測：Bouygues電信公司，是法國最大的電信供應商之一，使用flin監控其有線和無線網絡，實現快速故障響應。
商業智能分析ETL：Zalando使用flink轉換數據以便於加載到數據倉庫，將複雜的轉換操做轉化爲相對簡單的並確保分析終端用戶能夠更快的訪問數據。
多種數據源(有時不可靠)：當數據是由數以百萬計的不一樣用戶或設備產生的，它是安全的假設數據會按照事件產生的順序到達，和在上游數據失敗的狀況下，一些事件可能會比他們晚幾個小時，遲到的數據也須要計算，這樣的結果是準確的。
應用程序狀態管理：當程序變得更加的複雜，比簡單的過濾或者加強的數據結構，這個時候管理這些應用的狀態將會變得比較難(例如：計數器，過去數據的窗口，狀態機，內置數據庫)。flink提供了工具，這些狀態是有效的，容錯的，和可控的，因此你不須要本身構建這些功能。
數據的快速處理：有一個焦點在實時或近實時用例場景中，從數據生成的那個時刻，數據就應該是可達的。在必要的時候，flink徹底有能力知足這些延遲。
海量數據處理：這些程序須要分佈在不少節點運行來支持所需的規模。flink能夠在大型的集羣中無縫運行，就像是在一個小集羣同樣。

4、實現架構

Flink基本架構：

從上圖可知，Flink從另外一個角度看待流處理和批處理，將2者統一塊兒來。Flink是徹底支持流處理，也就是說流處理看待數據是無界限的，批處理做爲流處理的一種特殊狀況，數據只是被定義爲有界的。

Flink能夠與Hadoop集成，能夠方便讀取Hadoop項目中的組件數據，如hive,hdfs及Hbase等。以kafka做爲流式的數據源，直接能夠重用storm代碼

DataStream API 能夠流暢地分析無限數據流，而且能夠用Java 或者Scala 來實現。開發人員須要基於一個叫DataStream 的數據結構來開發，這個數據結構用於表示永不中止的分佈式數據流。Flink 的分佈式特色體如今它可以在成百上千臺機器上運行，它將大型的計算任務分紅許多小的部分，每一個機器執行一個部分。Flink 可以自動地確保在發生機器故障或者其餘錯誤時計算能持續進行，或者在修復bug 或進行版本升級後有計劃地再執行一次。這種能力使得開發人員不須要擔憂失敗。Flink 本質上使用容錯性數據流，這使得開發人員能夠分析持續生成且永遠不結束的數據（即流處理）。