Flink學習筆記-新一代Flink計算引擎

說明：本文爲《Flink大數據項目實戰》學習筆記，想經過視頻系統學習Flink這個最火爆的大數據計算框架的同窗，推薦學習課程：

 Flink大數據項目實戰：http://t.cn/EJtKhaz

 

新一代Flink計算引擎

（1） Flink概述

目前開源大數據計算引擎有不少的選擇，好比流處理有Storm、Samza、Flink、Spark等，批處理有Spark、Hive、Pig、Flink等。既支持流處理又支持批處理的計算引擎只有Apache Flink和Apache Spark。

 

雖然Spark和Flink都支持流計算，但Spark是基於批來模擬流的計算，而Flink則徹底相反，它採用的是基於流計算來模擬批計算。從技術的長遠發展來看，Spark用批來模擬流有必定的技術侷限性，而且這個侷限性可能很難突破。而Flink基於流來模擬批，在技術上有更好的擴展性。因此你們把Flink稱之爲下一代大數據計算引擎。

 

從長遠發展來看，阿里已經使用Flink做爲統一的通用的大數據引擎，並投入了大量的人力、財力、物力。目前阿里巴巴全部的業務，包括阿里巴巴全部子公司都採用了基於Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集羣之上。採用Hadoop的YARN作爲資源管理調度，以 HDFS做爲數據存儲。所以，Flink能夠和開源大數據框架Hadoop無縫對接。

 

基於目前市面上Flink資料比較少，並且不繫統、不全面、不深刻，在這裏跟你們一塊兒分享Flink大數據技術。本書中咱們使用Flink1.6.2，它是目前最新的穩定版本，本書中咱們既會講到Flink批計算和流計算， 同時也會經過2個項目實戰讓你們學習的Flink技術可以快速應用到具體的項目實戰中。

 

 

1. Flink定義

 

1.1簡介

 

Apache Flink是一個分佈式大數據處理引擎，可對有限數據流和無限數據流進行有狀態計算。可部署在各類集羣環境，對各類大小的數據規模進行快速計算。

 

上圖大體能夠分爲三塊內容：左邊爲數據輸入、右邊爲數據輸出、中間爲Flink數據處理。

Flink支持消息隊列的Events（支持實時的事件）的輸入，上游源源不斷產生數據放入消息隊列，Flink不斷消費、處理消息隊列中的數據，處理完成以後數據寫入下游系統，這個過程是不斷持續的進行。

 

數據源：

1.Clicks：即點擊流，好比打開搜狐網站，搜狐網站頁面上埋有不少數據採集點或者探針，當用戶點擊搜狐頁面的時候，它會採集用戶點擊行爲的詳細信息，這些用戶的點擊行爲產生的數據流咱們稱爲點擊流。

 

 

 

 

2.Logs：好比web應用運行過程當中產生的錯誤日誌信息，源源不斷髮送到消息隊列中，後續Flink處理爲運維部門提供監控依據。

 

3.IOT：即物聯網，英文全稱爲Internet of things。物聯網的終端設備，好比華爲手環、小米手環，源源不斷的產生數據寫入消息隊列，後續Flink處理提供健康報告。

 

4.Transactions：即交易數據。好比各類電商平臺用戶下單，這個數據源源不斷寫入消息隊列，

後續Flink處理爲用戶提供購買相關實時服務。

 

數據輸入系統：

Flink既支持實時（Real-time）流處理，又支持批處理。實時流消息系統，好比Kafka。批處理系統有不少，DataBase（好比傳統MySQL、Oracle數據庫），KV-Store（好比HBase、MongoDB數據庫），File System（好比本地文件系統、分佈式文件系統HDFS）。

 

Flink數據處理：

Flink在數據處理過程當中，資源管理調度可使用K8s（Kubernetes 簡稱K8s，是Google開源的一個容器編排引擎）、YARN、Mesos，中間數據存儲可使用HDFS、S3、NFS等，Flink詳細處理過程後續章節詳細講解。

數據輸出：

Flink能夠將處理後的數據輸出下游的應用（Application），也能夠將處理事後的數據寫入消息隊列（好比Kafka），還能夠將處理後的輸入寫入Database、File System和KV-Store。

 

1.2Flink的前世此生

 

 

 

Hadoop在2005年左右誕生2009年剛剛嶄露頭角，這以後逐步受到各大公司的歡迎。Flink也早在2009年已經出現，此後一直默默無聞，可是直到在 2015 年忽然出如今大數據舞臺，而後彷佛在一晚上之間從一個無人所知的系統迅速轉變爲人人皆知的流式處理引擎。能夠說Apache Flink起了個大早，趕了個晚集，主要緣由在於不少流式計算框架往Hadoop遷移的過程當中，發現當前流行的不少框架對流式處理對不是太好，即便是Storm，這個時候你們發現Apache Flink對流式處理支持的比較好，並逐步進入你們的視野，愈來愈受歡迎。

 

 

 

Flink在發展過程的關鍵時刻：

 

1. 誕生於2009年，原來叫StratoSphere，是柏林工業大學的一個研究性項目，早期專一於批計算。
2. 2014年孵化出Flink項目並捐給了Apache。
3. 2015年開始引發你們注意，出如今大數據舞臺。
4. 2016年在阿里獲得大規模應用。

 

1.3Flink的誕生

Flink誕生於歐洲的一個大數據研究項目，原名 StratoSphere。該項目是柏林工業大學的一個研究性項目，早期專一於批計算。2014 年，StratoSphere 項目中的核心成員孵化出 Flink，並在同年將 Flink 捐贈 Apache，後來 Flink 順利成爲 Apache 的頂級大數據項目。同時 Flink 計算的主流方向被定位爲流計算，即用流式計算來作全部大數據的計算工做，這就是 Flink 技術誕生的背景。

 

1.4Flink嶄露頭角

 

 

 

2014 年 Flink 做爲主攻流計算的大數據引擎開始在開源大數據行業內嶄露頭角。區別於 Storm、Spark Streaming 以及其餘流式計算引擎的是：它不只是一個高吞吐、低延遲的計算引擎，同時還提供不少高級功能。好比它提供有狀態的計算，支持狀態管理，支持強一致性的數據語義以及支持 Event Time,WaterMark 對消息亂序的處理等。

 

 

 

2015 年是流計算百花齊放的時代，各個流計算框架層出不窮。Storm, JStorm, Heron, Flink, Spark Streaming, Google Dataflow (後來的 Beam) 等等。其中 Flink 的一致性語義和最接近 Dataflow 模型的開源實現，使其成爲流計算框架中最耀眼的一顆。也許這也是阿里看中 Flink的緣由，並決心投入重金去研究基於 Flink的 Blink框架。

 

 

 

 

 

1.5Flink爲什麼受青睞

 

 

 

Flink之因此受到愈來愈多公司的青睞，確定有它不少過人之處。

 

1.支持批處理和數據流程序處理。

 

2.優雅流暢的支持java和scala api。

 

3.同時支持高吞吐量和低延遲。

 

4.支持事件處理和無序處理經過SataStream API，基於DataFlow數據流模型。

 

5.在不一樣的時間語義(事件時間，攝取時間、處理時間)下支持靈活的窗口(時間，滑動、翻滾，會話，自定義觸發器)。

 

6.擁有僅處理一次的容錯擔保，Flink支持恰好處理一次。

 

7.擁有自動反壓機制，當Flink處理數據達到上限的時候，源頭會自動減小數據的輸入，避免形成Flink應用的崩潰。

 

8.支持圖處理(批)、 機器學習(批)、 復瑣事件處理(流)。

 

9.在dataSet(批處理)API中內置支持迭代程序(BSP)。

 

10.高效的自定義內存管理和健壯的在in-memory和out-of-core中的切換能力。

 

11.同時兼容hadoop的mapreduce和storm。

 

12.可以集成YARN,HDFS,Hbase 和其它hadoop生態系統的組件。

 

2. Flink生態與將來

 

2.1核心組件棧

Flink發展愈來愈成熟，已經擁有了本身的豐富的核心組件棧，以下圖所示。

 

 

 

從上圖能夠看出Flink的底層是Deploy，Flink能夠Local模式運行，啓動單個 JVM。Flink也能夠Standalone 集羣模式運行，同時也支持Flink ON YARN，Flink應用直接提交到YARN上面運行。另外Flink還能夠運行在GCE（谷歌雲服務）和EC2（亞馬遜雲服務）。

 

 

 

Deploy的上層是Flink的核心（Core）部分Runtime。在Runtime之上提供了兩套核心的API，DataStream API（流處理）和DataSet API（批處理）。在覈心API之上又擴展了一些高階的庫和API，好比CEP流處理，Table API和SQL，Flink ML機器學習庫，Gelly圖計算。SQL既能夠跑在DataStream API，又能夠跑在DataSet API。

 

2.2生態

從上圖能夠看出Flink擁有更大更豐富的生態圈：

 

中間最底層Deploy模式包含 Local本地模式、Cluster（包含Standalone和YARN）集羣模式以及Cloud雲服務模式，而後它的上層是Flink runtime運行時，而後它的上層是Flink DataSet批處理和DataStream流處理，而後它的上層又擴展了Hadoop MR、Table、Gelly（圖計算）、ML（機器學習）、Zoppelin（可視化工具）等等。

 

左邊爲輸入Connectors。流處理方式包含Kafka（消息隊列），AWS kinesis（實時數據流服務），RabbitMQ（消息隊列），NIFI（數據管道），Twitter（API）。批處理方式包含HDFS（分佈式文件系統），HBase（分佈式列式數據庫），Amazon S3（文件系統），MapR FS（文件系統），ALLuxio（基於內存分佈式文件系統）。

 

右邊爲輸出Connectors。流處理方式包含Kafka（消息隊列），AWS kinesis（實時數據流服務），RabbitMQ（消息隊列），NIFI（數據管道），Cassandra（NOSQL數據庫），ElasticSearch（全文檢索），HDFS rolling file（滾動文件）。批處理包含HBase（分佈式列式數據庫），HDFS（分佈式文件系統）。

 

 

 

2.3將來

 

Flink會進行批計算的突破、流處理和批處理無縫切換、界限愈來愈模糊、甚至混合。

 

 

 

Flink會開發更多語言支持

 

 

 

Flink會逐步完善Machine Learning 算法庫，同時 Flink 也會向更成熟的機器學習、深度學習去集成(好比Tensorflow On Flink)。

 

3. Flink應用場景

 

主要應用場景有三類：

 

1.Event-driven Applications【事件驅動】

 

 

 

2.Data Analytics Applications【分析】

 

 

 

3.Data Pipeline Applications【管道式ETL】

 

3.1 Event-driven Applications

 

 

 

 

上圖包含兩塊：Traditional transaction Application（傳統事務應用）和Event-driven Applications（事件驅動應用）。

 

Traditional transaction Application執行流程：好比點擊流Events能夠經過Application寫入Transaction DB（數據庫），同時也能夠經過Application從Transaction DB將數據讀出，並進行處理，當處理結果達到一個預警值就會觸發一個Action動做，這種方式通常爲過後諸葛亮。

 

Event-driven Applications執行流程：好比採集的數據Events能夠不斷的放入消息隊列，Flink應用會不斷ingest（消費）消息隊列中的數據，Flink 應用內部維護着一段時間的數據（state），隔一段時間會將數據持久化存儲（Persistent sstorage），防止Flink應用死掉。Flink應用每接受一條數據，就會處理一條數據，處理以後就會觸發（trigger）一個動做（Action），同時也能夠將處理結果寫入外部消息隊列中，其餘Flink應用再消費。

 

典型的事件驅動類應用：

1.欺詐檢測(Fraud detection)

2.異常檢測(Anomaly detection)

3.基於規則的告警(Rule-based alerting)

4.業務流程監控(Business process monitoring)

5.Web應用程序(社交網絡)

 

3.2 Data Analytics Applications

 

 

 

Data Analytics Applications包含Batch analytics（批處理分析）和Streaming analytics（流處理分析）。

 

 

 

 

 

Batch analytics能夠理解爲週期性查詢：好比Flink應用凌晨從Recorded Events中讀取昨天的數據，而後作週期查詢運算，最後將數據寫入Database或者HDFS，或者直接將數據生成報表供公司上層領導決策使用。

 

 

 

Streaming analytics能夠理解爲連續性查詢：好比實時展現雙十一天貓銷售GMV，用戶下單數據須要實時寫入消息隊列，Flink 應用源源不斷讀取數據作實時計算，而後不斷的將數據更新至Database或者K-VStore，最後作大屏實時展現。

 

3.3 Data Pipeline Applications

 

 

 

Data Pipeline Applications包含Periodic （週期性）ETL和Data Pipeline（管道）

 

 

 

Periodic ETL：好比天天凌晨週期性的啓動一個Flink ETL Job，讀取傳統數據庫中的數據，而後作ETL，最後寫入數據庫和文件系統。

 

 

 

 

 

Data Pipeline：好比啓動一個Flink 實時應用，數據源（好比數據庫、Kafka）中的數據不斷的經過Flink Data Pipeline流入或者追加到數據倉庫（數據庫或者文件系統），或者Kafka消息隊列。

 

3.4阿里Flink應用場景

 

 

 

阿里在Flink的應用主要包含四個模塊：實時監控、實時報表、流數據分析和實時倉庫。

 

實時監控：

 

1. 用戶行爲預警、app crash 預警、服務器攻擊預警
2. 對用戶行爲或者相關事件進行實時監測和分析，基於風控規則進行預警

 

 

 

實時報表：

 

1. 雙11、雙12等活動直播大屏
2. 對外數據產品：生意參謀等
3. 數據化運營

 

 

 

流數據分析：

 

1. 實時計算相關指標反饋及時調整決策
2. 內容投放、無線智能推送、實時個性化推薦等

 

 

 

實時倉庫：

 

1. 數據實時清洗、歸併、結構化
2. 數倉的補充和優化

欺詐檢測

 

 

 

背景：

 

假設你是一個電商公司，常常搞運營活動，但收效甚微，通過細緻排查，發現原來是羊毛黨在薅平臺的羊毛，把補給用戶的補貼都薅走了，錢花了很多，效果卻沒達到。

 

 

 

怎麼辦呢？

 

 

 

你能夠作一個實時的異常檢測系統，監控用戶的高危行爲，及時發現高危行爲並採起措施，下降損失。

 

 

 

系統流程：

 

1.用戶的行爲經由app 上報或web日誌記錄下來，發送到一個消息隊列裏去；

 

2.而後流計算訂閱消息隊列，過濾出感興趣的行爲，好比：購買、領券、瀏覽等；

 

3.流計算把這個行爲特徵化；

 

4.流計算經過UDF調用外部一個風險模型，判斷此次行爲是否有問題（單次行爲）；

 

5.流計算裏經過CEP功能，跨多條記錄分析用戶行爲（好比用戶先作了a，又作了b，又作了3次c），總體識別是否有風險；

 

6.綜合風險模型和CEP的結果，產出預警信息。

 

4. FlinkVSSpark

 

4.1流處理的幾個流派

 

在流式計算領域，同一套系統須要同時兼具容錯和高性能其實很是難，同時它也是衡量和選擇一個系統的標準。

 

4.2Flink VS Spark 之 API

Spark與Flink API pk以下所示：

Spark與Flink 對開發語言的支持以下所示：

 

 

4.3 Flink VS Spark 之 Connectors

 

Spark 支持的Connectors以下所示：

 

 

Flink支持的Connectors以下所示：

 

 

 

從Flink和Spark Connectors對比能夠看出，Spark與Flink支持的Connectors的數量差很少，目前來講可能Spark支持更多一些，Flink後續的支持也會逐步的完善。

 

4.4 Flink VS Spark 之 運行環境

Spark 與Flink所支持的運行環境基本差很少，都比較普遍。

 

 

 

 

4.5 Flink VS Spark 之 社區

 

Spark 社區在規模和活躍程度上都是領先的，畢竟多了幾年發展時間，同時背後的商業公司Databricks因爲本土優點使得Spark在美國的影響力明顯優於Flink

 

 

 

並且做爲一個德國公司，Data Artisans 想在美國擴大影響力要更難一些。不過 Flink 社區也有一批穩定的支持者，達到了可持續發展的規模。

 

 

 

在中國狀況可能會不同一些。比起美國公司，中國公司作事情速度更快，更願意嘗試新技術。中國的一些創新場景也對實時性有更高的需求。這些都對 Flink 更友好一些。

 

 

 

近期 Flink 的中國社區有一系列動做，是瞭解 Flink 的好機會。

 

 

 

Flink 的中文社區在 ：http://flink-china.org/

 

 

 

另外，2018 年 12 月 20 日 -21 日在國家會議中心舉辦的首屆 Flink Forward China 峯會（千人規模），參與者將有機會了解阿里巴巴、騰訊、華爲、滴滴、美團、字節跳動等公司爲什麼將 Flink 做爲首選的流處理引擎。

 

4.6總結

 

Spark 和 Flink 都是通用的開源大規模處理引擎，目標是在一個系統中支持全部的數據處理以帶來效能的提高。二者都有相對比較成熟的生態系統。是下一代大數據引擎最有力的競爭者。

 

 

 

Spark 的生態整體更完善一些，在機器學習的集成和易用性上暫時領先。

 

 

 

Flink 在流計算上有明顯優點，核心架構和模型也更透徹和靈活一些。

 

 

 

在易用性方面二者也都還有一些地方有較大的改進空間。接下來誰能儘快補上短板發揮強項就有更多的機會。

 

 

 

總而言之，Flink與Spark沒有誰強誰弱，只有哪一個更適合當前的場景。