大資料技術叢書 點選檢視第二章 點選檢視第三章 Flink原理、實戰與性能優化
第1章
Apache Flink介紹
本章對Apache Flink從多個方面進行介紹，讓讀者對Flink這項分布式處理技術能夠有初步的了解。1.1節主要介紹了Flink的由來及其發展曆史，幫助讀者從曆史的角度了解Flink這項技術發展的過程。1.2節重點介紹了Flink能夠支援的各種實際業務場景、Flink所具備的主要特性、Flink組成部分及其基本概念等内容，最後在1.4節中介紹了Flink的基本架構以及主要組成部分。
1.1 Apache Flink是什麼
在目前資料量激增的時代，各種業務場景都有大量的業務資料産生，對于這些不斷産生的資料應該如何進行有效的處理，成為當下大多數公司所面臨的問題。随着雅虎對Hadoop的開源，越來越多的大資料處理技術開始湧入人們的視線，例如目前比較流行的大資料處理引擎Apache Spark，基本上已經取代了MapReduce成為目前大資料處理的标準。但随着資料的不斷增長，新技術的不斷發展，人們逐漸意識到對實時資料處理的重要性。相對于傳統的資料處理模式，流式資料處理有着更高的處理效率和成本控制能力。Apache Flink就是近年來在開源社群不斷發展的技術中的能夠同時支援高吞吐、低延遲、高性能的分布式處理架構。
在2010年至2014年間，由柏林工業大學、柏林洪堡大學和哈索普拉特納研究所聯合發起名為“Stratosphere: Information Management on the Cloud”研究項目，該項目在當時的社群逐漸具有了一定的社群知名度。2014年4月，Stratosphere代碼被貢獻給Apache 軟體基金會，成為Apache基金會孵化器項目。初期參與該項目的核心成員均是Stratosphere曾經的核心成員，之後團隊的大部分創始成員離開學校，共同創辦了一家名叫Data Artisans的公司，其主要業務便是将Stratosphere，也就是之後的Flink實作商業化。在項目孵化期間，項目Stratosphere改名為Flink。Flink在德語中是快速和靈敏的意思，用來展現流式資料處理器速度快和靈活性強等特點，同時使用棕紅色松鼠圖案作為Flink項目的Logo，也是為了突出松鼠靈活快速的特點，由此，Flink正式進入社群開發者的視線。
2014年12月，該項目成為Apache 軟體基金會頂級項目，從2015年9月釋出第一個穩定版本0.9，到目前撰寫本書期間已經釋出到1.7的版本，更多的社群開發成員逐漸加入，現在Flink在全球範圍内擁有350多位開發人員，不斷有新的特性釋出。同時在全球範圍内，越來越多的公司開始使用Flink，在國内比較出名的網際網路公司如阿裡巴巴、美團、滴滴等，都在大規模使用Flink作為企業的分布式大資料處理引擎。
Flink近年來逐漸被人們所熟知，不僅是因為Flink提供同時支援高吞吐、低延遲和exactly-once語義的實時計算能力，同時Flink還提供了基于流式計算引擎處理批量資料的計算能力，真正意義上實作了批流統一，同時随着阿裡對Blink的開源，極大地增強了Flink對批計算領域的支援。衆多優秀的特性，使得Flink成為開源大資料資料處理架構中的一顆新星，随着國内社群不斷推動，越來越多的國内公司開始選擇使用Flink作為實時資料處理技術。在不久的将來，Flink也将會成為企業内部主流的資料處理架構，最終成為下一代大資料處理的标準。
1.2 資料架構的演變
近年來随着開源社群的發展，越來越多新的技術被開源，例如雅虎的Hadoop分布式計算架構、UC伯克利分校的Apache Spark等，而伴随着這些技術的發展，促使着企業資料架構的演進，從傳統的關系型資料存儲架構，逐漸演化為分布式處理和存儲的架構。
1.2.1 傳統資料基礎架構
如圖1-1所示，傳統單體資料架構（Monolithic?Architecture）最大的特點便是集中式資料存儲，企業内部可能有諸多的系統，例如Web業務系統、訂單系統、CRM系統、ERP系統、監控系統等，這些系統的事務性資料主要基于集中式的關系性資料庫（DBMS）實作存儲，大多數将架構分為計算層和存儲層。存儲層負責企業内系統的資料通路，且具有最終資料一緻性保障。這些資料反映了目前的業務狀态，例如系統的訂單交易量、網站的活躍使用者數、每個使用者的交易額變化等，所有的更新操作均需要借助于同一套資料庫實作。
單體架構的初期效率很高，但是随着時間的推移，業務越來越多，系統逐漸變得很大，越來越難以維護和更新，資料庫是唯一的準确資料源，每個應用都需要通路資料庫來擷取對應的資料，如果資料庫發生改變或者出現問題，則将對整個業務系統産生影響。
後來随着微服務架構（Microservices?Architecture）的出現，企業開始逐漸采用微服務作為企業業務系統的架構體系。微服務架構的核心思想是，一個應用是由多個小的、互相獨立的微服務組成，這些服務運作在自己的程序中，開發和釋出都沒有依賴。不同的服務能依據不同的業務需求，建構的不同的技術架構之上，能夠聚焦在有限的業務功能。
如圖1-2所示，微服務架構将系統拆解成不同的獨立服務子產品，每個子產品分别使用各自獨立的資料庫，這種模式解決了業務系統拓展的問題，但是也帶來了新的問題，那就是業務交易資料過于分散在不同的系統中，很難将資料進行集中化管理，對于企業内部進行資料分析或者資料挖掘之類的應用，則需要通過從不同的資料庫中進行資料抽取，将資料從資料庫中周期性地同步到資料倉庫中，然後在資料倉庫中進行資料的抽取、轉換、加載（ETL），進而建構成不同的資料集市和應用，提供給業務系統使用。
1.2.2 大資料資料架構
起初資料倉庫主要還是建構在關系型資料庫之上，例如Oracle、Mysql等資料庫，但是随着企業資料量的增長，關系型資料庫已經無法支撐大規模資料集的存儲和分析，是以越來越多的企業開始選擇基于Hadoop建構企業級大資料平台。同時衆多Sql-On-Hadoop技術方案的提出，也讓企業在Hadoop上建構不同類型的資料應用變得簡單而高效，例如通過使用Apache Hive進行資料ETL處理，通過使用Apache Impala進行實時互動性查詢等。
大資料技術的興起，讓企業能夠更加靈活高效地使用自己的業務資料，從資料中提取出更多重要的價值，并将資料分析和挖掘出來的結果應用在企業的決策、營銷、管理等應用領域。但不可避免的是，随着越來越多新技術的引入與使用，企業内部一套大資料管理平台可能會借助衆多開源技術元件實作。例如在建構企業資料倉庫的過程中，資料往往都是周期性的從業務系統中同步到大資料平台，完成一系列ETL轉換動作之後，最終形成資料集市等應用。但是對于一些時間要求比較高的應用，例如實時報表統計，則必須有非常低的延時展示統計結果，為此業界提出一套Lambda架構方案來處理不同類型的資料。例圖1-3所示，大資料平台中包含批量計算的Batch Layer和實時計算的Speed Layer，通過在一套平台中将批計算和流計算整合在一起，例如使用Hadoop MapReduce進行批量資料的處理，使用Apache Storm進行實時資料的處理。這種架構在一定程度上解決了不同計算類型的問題，但是帶來的問題是架構太多會導緻平台複雜度過高、運維成本高等。在一套資源管理平台中管理不同類型的計算架構使用也是非常困難的事情。總而言之，Lambda架構是建構大資料應用程式的一種很有效的解決方案，但是還不是最完美的方案。
後來随着Apache Spark的分布式記憶體處理架構的出現，提出了将資料切分成微批的處理模式進行流式資料處理，進而能夠在一套計算架構内完成批量計算和流式計算。但因為Spark本身是基于批處理模式的原因，并不能完美且高效地處理原生的資料流，是以對流式計算支援的相對較弱，可以說Spark的出現本質上是在一定程度上對Hadoop架構進行了一定的更新和優化。
1.2.3 有狀态流計算架構
資料産生的本質，其實是一條條真實存在的事件，前面提到的不同的架構其實都是在一定程度違背了這種本質，需要通過在一定時延的情況下對業務資料進行處理，然後得到基于業務資料統計的準确結果。實際上，基于流式計算技術局限性，我們很難在資料産生的過程中進行計算并直接産生統計結果，因為這不僅對系統有非常高的要求，還必須要滿足高性能、高吞吐、低延時等衆多目标。而有狀态流計算架構（如圖1-4所示）的提出，從一定程度上滿足了企業的這種需求，企業基于實時的流式資料，維護所有計算過程的狀态，所謂狀态就是計算過程中産生的中間計算結果，每次計算新的資料進入到流式系統中都是基于中間狀态結果的基礎上進行運算，最終産生正确的統計結果。基于有狀态計算的方式最大的優勢是不需要将原始資料重新從外部存儲中拿出來，進而進行全量計算，因為這種計算方式的代價可能是非常高的。從另一個角度講，使用者無須通過排程和協調各種批量計算工具，從資料倉庫中擷取資料統計結果，然後再落地存儲，這些操作全部都可以基于流式計算完成，可以極大地減輕系統對其他架構的依賴，減少資料計算過程中的時間損耗以及硬體存儲。
如果計算的結果能保持一緻，實時計算在很短的時間内統計出結果，批量計算則需要等待一定時間才能得出，相信大多數使用者會更加傾向于選擇使用有狀态流進行大資料處理。
1.2.4 為什麼會是Flink
可以看出有狀态流計算将會逐漸成為企業作為建構資料平台的架構模式，而目前從社群來看，能夠滿足的隻有Apache Flink。Flink通過實作Google Dataflow流式計算模型實作了高吞吐、低延遲、高性能兼具實時流式計算架構。同時Flink支援高度容錯的狀态管理，防止狀态在計算過程中因為系統異常而出現丢失，Flink周期性地通過分布式快照技術Checkpoints實作狀态的持久化維護，使得即使在系統停機或者異常的情況下都能計算出正确的結果。
Flink具有先進的架構理念、諸多的優秀特性，以及完善的程式設計接口，而Flink也在每一次的Release版本中，不斷推出新的特性，例如Queryable State功能的提出，容許使用者通過遠端的方式直接擷取流式計算任務的狀态資訊，資料不需要落地資料庫就能直接從Flink流式應用中查詢。對于實時互動式的查詢業務可以直接從Flink的狀态中查詢最新的結果。在未來，Flink将不僅作為實時流式處理的架構，更多的可能會成為一套實時的狀态存儲引擎，讓更多的使用者從有狀态計算的技術中獲益。
Flink的具體優勢有以下幾點。
（1）同時支援高吞吐、低延遲、高性能
Flink是目前開源社群中唯一一套集高吞吐、低延遲、高性能三者于一身的分布式流式資料處理架構。像Apache Spark也隻能兼顧高吞吐和高性能特性，主要因為在Spark Streaming流式計算中無法做到低延遲保障；而流式計算架構Apache Storm隻能支援低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個目标對分布式流式計算架構來說是非常重要的。
（2）支援事件時間（Event Time）概念
在流式計算領域中，視窗計算的地位舉足輕重，但目前大多數架構視窗計算采用的都是系統時間（Process Time），也是事件傳輸到計算架構處理時，系統主機的目前時間。Flink能夠支援基于事件時間（Event Time）語義進行視窗計算，也就是使用事件産生的時間，這種基于事件驅動的機制使得事件即使亂序到達，流系統也能夠計算出精确的結果，保持了事件原本産生時的時序性，盡可能避免網絡傳輸或硬體系統的影響。
（3）支援有狀态計算
Flink在1.4版本中實作了狀态管理，所謂狀态就是在流式計算過程中将算子的中間結果資料儲存在記憶體或者檔案系統中，等下一個事件進入算子後可以從之前的狀态中擷取中間結果中計算目前的結果，進而無須每次都基于全部的原始資料來統計結果，這種方式極大地提升了系統的性能，并降低了資料計算過程的資源消耗。對于資料量大且運算邏輯非常複雜的流式計算場景，有狀态計算發揮了非常重要的作用。
（4）支援高度靈活的視窗（Window）操作
在流處理應用中，資料是連續不斷的，需要通過視窗的方式對流資料進行一定範圍的聚合計算，例如統計在過去的1分鐘内有多少使用者點選某一網頁，在這種情況下，我們必須定義一個視窗，用來收集最近一分鐘内的資料，并對這個視窗内的資料進行再計算。Flink将視窗劃分為基于Time、Count、Session，以及Data-driven等類型的視窗操作，視窗可以用靈活的觸發條件定制化來達到對複雜的流傳輸模式的支援，使用者可以定義不同的視窗觸發機制來滿足不同的需求。
（5）基于輕量級分布式快照（Snapshot）實作的容錯
Flink能夠分布式運作在上千個節點上，将一個大型計算任務的流程拆解成小的計算過程，然後将tesk分布到并行節點上進行處理。在任務執行過程中，能夠自動發現事件處理過程中的錯誤而導緻資料不一緻的問題，比如：節點當機、網路傳輸問題，或是由于使用者因為更新或修複問題而導緻計算服務重新開機等。在這些情況下，通過基于分布式快照技術的Checkpoints，将執行過程中的狀态資訊進行持久化存儲，一旦任務出現異常停止，Flink就能夠從Checkpoints中進行任務的自動恢複，以確定資料在處理過程中的一緻性。
（6）基于JVM實作獨立的記憶體管理
記憶體管理是所有計算架構需要重點考慮的部分，尤其對于計算量比較大的計算場景，資料在記憶體中該如何進行管理顯得至關重要。針對記憶體管理，Flink實作了自身管理記憶體的機制，盡可能減少JVM GC對系統的影響。另外，Flink通過序列化/反序列化方法将所有的資料對象轉換成二進制在記憶體中存儲，降低資料存儲的大小的同時，能夠更加有效地對記憶體空間進行利用，降低GC帶來的性能下降或任務異常的風險，是以Flink較其他分布式處理的架構會顯得更加穩定，不會因為JVM GC等問題而影響整個應用的運作。
（7）Save Points（儲存點）
對于7*24小時運作的流式應用，資料源源不斷地接入，在一段時間内應用的終止有可能導緻資料的丢失或者計算結果的不準确，例如進行叢集版本的更新、停機運維操作等操作。值得一提的是，Flink通過Save Points技術将任務執行的快照儲存在存儲媒體上，當任務重新開機的時候可以直接從事先儲存的Save Points恢複原有的計算狀态，使得任務繼續按照停機之前的狀态運作，Save Points技術可以讓使用者更好地管理和運維實時流式應用。
1.3 Flink應用場景
在實際生産的過程中，大量資料在不斷地産生，例如金融交易資料、網際網路訂單資料、GPS定位資料、傳感器信号、移動終端産生的資料、通信信号資料等，以及我們熟悉的網絡流量監控、伺服器産生的日志資料，這些資料最大的共同點就是實時從不同的資料源中産生，然後再傳輸到下遊的分析系統。針對這些資料類型主要包括實時智能推薦、複雜事件處理、實時欺詐檢測、實時數倉與ETL類型、流資料分析類型、實時報表類型等實時業務場景，而Flink對于這些類型的場景都有着非常好的支援。
（1）實時智能推薦
智能推薦會根據使用者曆史的購買行為，通過推薦算法訓練模型，預測使用者未來可能會購買的物品。對個人來說，推薦系統起着資訊過濾的作用，對Web/App服務端來說，推薦系統起着滿足使用者個性化需求，提升使用者滿意度的作用。推薦系統本身也在飛速發展，除了算法越來越完善，對時延的要求也越來越苛刻和實時化。利用Flink流計算幫助使用者建構更加實時的智能推薦系統，對使用者行為名額進行實時計算，對模型進行實時更新，對使用者名額進行實時預測，并将預測的資訊推送給Wep/App端，幫助使用者擷取想要的商品資訊，另一方面也幫助企業提升銷售額，創造更大的商業價值。
（2）複雜事件處理
對于複雜事件處理，比較常見的案例主要集中于工業領域，例如對車載傳感器、機械裝置等實時故障檢測，這些業務類型通常資料量都非常大，且對資料處理的時效性要求非常高。通過利用Flink提供的CEP（複雜事件處理）進行事件模式的抽取，同時應用Flink的Sql進行事件資料的轉換，在流式系統中建構實時規則引擎，一旦事件觸發報警規則，便立即将告警結果傳輸至下遊通知系統，進而實作對裝置故障快速預警監測，車輛狀态監控等目的。
（3）實時欺詐檢測
在金融領域的業務中，常常出現各種類型的欺詐行為，例如信用卡欺詐、信貸申請欺詐等，而如何保證使用者和公司的資金安全，是來近年來許多金融公司及銀行共同面對的挑戰。随着不法分子欺詐手段的不斷更新，傳統的反欺詐手段已經不足以解決目前所面臨的問題。以往可能需要幾個小時才能通過交易資料計算出使用者的行為名額，然後通過規則判别出具有欺詐行為嫌疑的使用者，再進行案件調查處理，在這種情況下資金可能早已被不法分子轉移，進而給企業和使用者造成大量的經濟損失。而運用Flink流式計算技術能夠在毫秒内就完成對欺詐判斷行為名額的計算，然後實時對交易流水進行規則判斷或者模型預測，這樣一旦檢測出交易中存在欺詐嫌疑，則直接對交易進行實時攔截，避免因為處理不及時而導緻的經濟損失。
（4）實時數倉與ETL
結合離線數倉，通過利用流計算諸多優勢和SQL靈活的加工能力，對流式資料進行實時清洗、歸并、結構化處理，為離線數倉進行補充和優化。另一方面結合實時資料ETL處理能力，利用有狀态流式計算技術，可以盡可能降低企業由于在離線資料計算過程中排程邏輯的複雜度，高效快速地處理企業需要的統計結果，幫助企業更好地應用實時資料所分析出來的結果。
（5）流資料分析
實時計算各類資料名額，并利用實時結果及時調整線上系統相關政策，在各類内容投放、無線智能推送領域有大量的應用。流式計算技術将資料分析場景實時化，幫助企業做到實時化分析Web應用或者App應用的各項名額，包括App版本分布情況、Crash檢測和分布等，同時提供多元度使用者行為分析，支援日志自主分析，助力開發者實作基于大資料技術的精細化營運、提升産品品質和體驗、增強使用者黏性。
（6）實時報表分析
實時報表分析是近年來很多公司采用的報表統計方案之一，其中最主要的應用便是實時大屏展示。利用流式計算實時得出的結果直接被推送到前端應用，實時顯示出重要名額的變換情況。最典型的案例便是淘寶的雙十一活動，每年雙十一購物節，除瘋狂購物外，最引人注目的就是天貓雙十一大屏不停跳躍的成交總額。在整個計算鍊路中包括從天貓交易下單購買到資料采集、資料計算、資料校驗，最終落到雙十一大屏上展現的全鍊路時間壓縮在5秒以内，頂峰計算性能高達數三十萬筆訂單/秒，通過多條鍊路流計算備份確定萬無一失。而在其他行業，企業也在建構自己的實時報表系統，讓企業能夠依托于自身的業務資料，快速提取出更多的資料價值，進而更好地服務于企業運作過程中。
1.4 Flink基本架構
1.4.1 基本元件棧
在Flink整個軟體架構體系中，同樣遵循着分層的架構設計理念，在降低系統耦合度的同時，也為上層使用者建構Flink應用提供了豐富且友好的接口。
從圖1-5中可以看出整個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的映射轉換、任務排程等。将DataSteam和DataSet轉成統一的可執行的Task Operator，達到在流式引擎下同時處理批量計算和流式計算的目的。
□實體部署層
該層主要涉及Flink的部署模式，目前Flink支援多種部署模式：本地、叢集（Standalone/YARN）、雲（GCE/EC2）、Kubenetes。Flink能夠通過該層能夠支援不同平台的部署，使用者可以根據需要選擇使用對應的部署模式。
1.4.2 基本架構圖
Flink系統架構設計如圖1-6所示，可以看出Flink整個系統主要由兩個元件組成，分别為JobManager和TaskManager，Flink架構也遵循Master-Slave架構設計原則，JobManager為Master節點，TaskManager為Worker（Slave）節點。所有元件之間的通信都是借助于Akka Framework，包括任務的狀态以及Checkpoint觸發等資訊。
（1）Client用戶端
用戶端負責将任務送出到叢集，與JobManager建構Akka連接配接，然後将任務送出到JobManager，通過和JobManager之間進行互動擷取任務執行狀态。用戶端送出任務可以采用CLI方式或者通過使用Flink WebUI送出，也可以在應用程式中指定JobManager的RPC網絡端口建構ExecutionEnvironment送出Flink應用。
（2）JobManager
JobManager負責整個Flink叢集任務的排程以及資源的管理，從用戶端中擷取送出的應用，然後根據叢集中TaskManager上TaskSlot的使用情況，為送出的應用配置設定相應的TaskSlots資源并指令TaskManger啟動從用戶端中擷取的應用。JobManager相當于整個叢集的Master節點，且整個叢集中有且僅有一個活躍的JobManager，負責整個叢集的任務管理和資源管理。JobManager和TaskManager之間通過Actor System進行通信，擷取任務執行的情況并通過Actor System将應用的任務執行情況發送給用戶端。同時在任務執行過程中，Flink JobManager會觸發Checkpoints操作，每個TaskManager節點收到Checkpoint觸發指令後，完成Checkpoint操作，所有的Checkpoint協調過程都是在Flink JobManager中完成。當任務完成後，Flink會将任務執行的資訊回報給用戶端，并且釋放掉TaskManager中的資源以供下一次送出任務使用。
（3）TaskManager
TaskManager相當于整個叢集的Slave節點，負責具體的任務執行和對應任務在每個節點上的資源申請與管理。用戶端通過将編寫好的Flink應用編譯打包，送出到JobManager，然後JobManager會根據已經注冊在JobManager中TaskManager的資源情況，将任務配置設定給有資源的TaskManager節點，然後啟動并運作任務。TaskManager從JobManager接收需要部署的任務，然後使用Slot資源啟動Task，建立資料接入的網絡連接配接，接收資料并開始資料處理。同時TaskManager之間的資料互動都是通過資料流的方式進行的。
可以看出，Flink的任務運作其實是采用多線程的方式，這和MapReduce多JVM程序的方式有很大的差別Fink能夠極大提高CPU使用效率，在多個任務和Task之間通過TaskSlot方式共享系統資源，每個TaskManager中通過管理多個TaskSlot資源池進行對資源進行有效管理。
1.5 本章小結
在本章1.1節對Flink的基本概念及發展曆史進行了介紹。1.2節對目前資料架構領域的發展進行了深入的介紹，讓讀者能夠了解傳統的資料架構到大資料架構的演變過程，以及在未來支援有狀态流計算的實時計算架構會扮演什麼樣的角色，讓使用者能夠對Flink這項技術的發展中有着更深入的了解。1.3節列舉了Flink不同的應用場景，讓讀者結合自己的業務場景進行技術選型，幫助讀者能夠更加合理地使用Flink這項技術。1.4節介紹了Flink基本元件棧、基本架構以及Flink所具備的特性，例如支援高吞吐、低延時、強一緻性保障等。通過本章的學習可以讓讀者對Flink有一個初步的認識和了解，接下來的章節我們将逐漸深入地了解和掌握Flink分布式計算技術。