前言
今天給大家分享阿里P8架構師整理的大數據之Flink計算引擎，希望大家能夠喜歡！
新一代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在發展過程的關鍵時刻：
-
誕生於2009年，原來叫StratoSphere，是柏林工業大學的一個研究性項目，早期專注於批計算。
-
2014年孵化出Flink項目並捐給了Apache。
-
2015年開始引起大家注意，出現在大數據舞臺。
-
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的應用主要包含四個模塊：實時監控、實時報表、流數據分析和實時倉庫。
實時監控：
-
用戶行爲預警、app crash 預警、服務器攻擊預警
-
對用戶行爲或者相關事件進行實時監測和分析，基於風控規則進行預警
實時報表：
-
雙11、雙12等活動直播大屏
-
對外數據產品：生意參謀等
-
數據化運營
流數據分析：
-
實時計算相關指標反饋及時調整決策
-
內容投放、無線智能推送、實時個性化推薦等
實時倉庫：
-
數據實時清洗、歸併、結構化
-
數倉的補充和優化
背景：假設你是一個電商公司，經常搞運營活動，但收效甚微，經過細緻排查，發現原來是羊毛黨在薅平臺的羊毛，把補給用戶的補貼都薅走了，錢花了不少，效果卻沒達到。
怎麼辦呢？
你可以做一個實時的異常檢測系統，監控用戶的高危行爲，及時發現高危行爲並採取措施，降低損失。
系統流程：
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 更友好一些。
4.6總結
Spark 和 Flink 都是通用的開源大規模處理引擎，目標是在一個系統中支持所有的數據處理以帶來效能的提升。兩者都有相對比較成熟的生態系統。是下一代大數據引擎最有力的競爭者。
Spark 的生態總體更完善一些，在機器學習的集成和易用性上暫時領先。
Flink 在流計算上有明顯優勢，核心架構和模型也更透徹和靈活一些。
在易用性方面兩者也都還有一些地方有較大的改進空間。接下來誰能儘快補上短板發揮強項就有更多的機會。
總而言之，Flink與Spark沒有誰強誰弱，只有哪個更適合當前的場景。
感謝大家支持！↓↓↓↓
