作者 | Fabian Hueske and Vasiliki Kalavri

翻譯 | 吳邪 大資料4年從業經驗，目前就職於廣州一家網際網路公司，負責大資料基礎平臺自研、離線計算&實時計算研究

校對 | gongyouliu

編輯 | auroral-L

Apache Flink是一個開源的分散式流處理引擎，為有狀態資料流處理應用程式提供了豐富的api介面，以實現各種簡單或複雜的計算功能。不僅如此，它能夠高效地支援大規模有狀態流應用程式執行，並保證了程式的容錯性，在這一點上會比其他的流式計算引擎凸顯更多優勢。那麼這樣的Flink是從什麼時候開始進入業界的視野的呢？2014年4月，Flink作為一個孵化器專案正式加入了Apache軟體基金會組織，並於2015年1月份成為Apache的頂級專案，發展可謂非常迅速，從Flink加入Apache之後，就擁有一個非常活躍且使用者和程式碼貢獻者持續增長的社群，時至今日，已經有超過500多人為Flink貢獻了程式碼，隨著Flink的快速發展並得到廣泛的應用，Flink得到了業界的認可，慢慢地成為了當下最流行的開源流式計算處理計算引擎，因為Flink可以支援大規模商業核心業務應用場景，因此在全球不同的國家和地區受到很多企業的青睞。

隨著資訊時代的到來，物聯網和5G得到廣泛的使用，帶來的是海量的資料，使用者和企業對資料處理的實時性要求越來越高，流式處理技術變得越來越重要，可以為企業賦能，為大大小小的企業很多成型的業務場景提供了高效可行的解決方案，比如資料分析、ELT資料處理和一些事務性應用程式，同時為企業的應用和軟體架構提供新的解決思路，獲得更多的商機。最後，我們簡易討論一下開源流式計算處理器的演進，並幫助你瞭解如何在本地執行Flink流式應用例項。

傳統的資料基礎架構

在過去的幾十年，資料以及資料處理在企業和商業應用顯得無處不在，隨著時間的推進，多年以來，資料的收集和使用一直保持著持續增長的趨勢，資料如何有效地管理成為每個公司的大事，為了更好的管理源源不斷產生的使用者資料，很多公司著力於設計和構建資料基礎架構，通常情況下主要分為兩種型別的架構：一是事務型資料處理，二是分析型資料處理，基於以上兩種型別，下面我們討論這兩種型別的基礎架構是如何管理和處理資料的。

事務型資料處理架構

很多公司在日常的業務場景中使用了五花八門的應用程式，比如說企業資源管理系統（ERP），客戶關係管理系統（CRM）以及基於Web端的系統。這些系統通常在設計的時候會區分不同的資料處理層（即應用程式本身）和資料儲存（事務型關係資料庫），每個系統自成一套流程，如下圖1-1 所示：

以上這些應用程式通常用於連線系統外部服務或者為使用者處理業務需求，比如獲取訂單資訊、接收或者傳送郵件以及網站點選行為等等，當我們在處理事件時，應用程式會讀取事件的狀態或者透過遠端資料庫系統更新事件的狀態，一般來說，一個數據庫系統會同時為多個應用程式服務，可能出現共用同一個資料庫甚至同一張表的情況。

基於事務型資料處理的架構設計存在不少的弊端，舉個例子，當執行的應用程式需要進行擴充套件時會出現很多的問題，為什麼這麼說呢？從圖中可以看到，由於多個應用程式可能會處理相同的資料或者共享同一個資料儲存系統，耦合性很強，這種情況下會涉及到資料庫表結構或者資料庫的變更，需要花費很多精力去重新設計和規劃，會導致生產成本大大提升且系統不穩定性大大增強，如果資料庫掛了，會導致所有的應用程式無法對外提供服務，造成的損失可想而知。

問題的出現必然會推動技術的變更來解決問題，微服務的出現很好的解決了應用程式捆綁的問題，微服務的定義是什麼呢？顧名思義，微服務的設計原則就是拆分功能模組，使其儘可能小且各自獨立，劃分單一職責與功能模組；微服務遵循UNIX的哲學思想，只做一件事，並且做好它。越來越多的複雜應用程式透過連線少量的微服務標準介面進行通訊，比如RESTful HTTP連線，為什麼要這樣做呢？因為微服務彼此之間是嚴格解耦的，透過定義好的介面進行通訊，每個微服務的程式語言也不受限，可以使用不同的技術棧去實現，不侷限於程式語言、庫和資料儲存。通常情況下，微服務和所必需的軟體包以及服務會被打包並部署在獨立的容器中，圖1-2描述的就是微服務的架構：

資料分析型處理架構對於一個公司來說，儲存在各種事務型資料庫系統中的資料，通常能為公司的運營 決策提供有價值的參考依據，比如說，透過對訂單處理系統的資料進行分析，可以掌握商品在一段時間內銷售的增長率，以此來確定商品延期出貨的根源，也可以用來預測未來的銷售趨勢，及時調整商品庫存。然而，事務型資料通常分佈在幾個互不相連的資料庫系統中，在需要進行聯合分析時才顯得更有價值，此外，不同資料庫系統的資料在分析時通常需要轉化為通用的處理格式。與直接在事務型資料庫執行分析查詢有所不同，在資料分析型處理架構中，資料通常會被統一複製到資料倉庫中，即專門用於資料分析查詢的資料儲存倉庫，為了填充資料倉庫，需要將事務型資料庫系統管理的資料庫的資料全部複製到資料倉庫中，這個遷移資料的過程我們通常稱為“提取-轉換-載入”，也就是我們常說的ETL。ETL流程負責從事務型資料庫（OLTP）抽取資料，根據一定的規範對資料進行驗證、編碼、去重以及資料結構等一系列操作進行轉換，最終把處理好的資料載入到分析型資料庫（OLAP）中，當ETL處理過程非常複雜的時候，這時候就需要考慮採用高效能的技術解決方案來滿足需求，ETL通常被設定為一個定期執行的任務，目的是為了及時將事務型資料倉庫的資料同步到資料倉庫中，儘可能保證資料的完整性。資料一旦被匯入到資料倉庫中，就可以用來做查詢和分析，常見的有兩類查詢，第一種型別是定期報表查詢統計，用於計算與業務相關的統計資料，如收入、使用者增長或生產輸出。把這些指標組合彙總到報告中，可以幫助管理層評估業務的總體健康狀況。第二種型別是即席查詢，旨在支撐特定問題的答案用來作為企業關鍵性決策的依據，例如，透過查詢公司營收和投放廣告支出，以評估營銷活動方案的有效性，本質上，這兩類查詢說到底都是透過在資料倉庫中執行批處理任務，從而得到計算結果，如圖FIgure1-3所示：現如今，Apache Hadoop生態系統的元件已經成為很多企業不可或缺的IT基礎架構，而不再是將所有資料都插入到關係資料庫系統中，而是將大量資料(如日誌檔案、社交媒體或web點選日誌)寫入Hadoop的分散式檔案系統(HDFS)、S3或其他大容量資料儲存系統，如Apache HBase，這些資料儲存系統花費很小的成本就可以提供巨大的儲存容量。儲存系統中的資料可以透過SQL-on-Hadoop引擎進行查詢和處理，例如Apache Hive、Apache Drill或Apache Impala。不可否認的是，這些基礎架構設施基本上仍然與傳統的資料倉庫體系結構相同。有狀態流處理實際上，所有資料的產生都可以看做連續的事件流，試想一下，使用者與網站或手機APP應用產生的互動，訂單的資訊，伺服器產生的日誌或者感測器測量等等，統統都可以算是事件流。事實上，很難找到一個一次性生成有限並且完整的資料集的例子。有狀態流處理是用於處理無界事件流的應用程式設計模式，適用於公司IT基礎結構中的許多不同用例，在我們討論這些用例之前，我們先簡單解釋一下有狀態資料流處理的工作原理。任何處理事件流的應用程式都應該是有狀態的、能夠被儲存並且支援中間資料訪問，而不僅僅是簡單做實時資料記錄的轉換，當一個應用程式接收到一個事件時，能夠透過從事件狀態中讀取或寫入的資料進行任意的計算，對於狀態來說，其本身可以儲存並訪問不同的介質，包括程式變數、記憶體、本地檔案、嵌入式資料庫或者外部資料庫系統等。Apache Flink通常將應用程式狀態儲存在本地記憶體中，或者嵌入式資料庫中，比如Redis、RocksDB，由於Flink是一個分散式系統，因此需要保障本地狀態的安全性，避免當應用程式失敗或者機器故障引起資料丟失的情況發生。為了防止這種情況的出現，Flink透過定期對應用程式的狀態做一致性checkpoint（檢查點），類似於快照，並持久化到遠端的資料庫中，在下一章中，我們會對狀態以及狀態一致性和Flink checkpoint機制進行詳細的討論，本章節不做展開，圖1-4展示的是一個有狀態的Flink流式處理程式。有狀態流處理程式可以接收來自很多不同渠道和形式的資料，通常從事件流的日誌提取事件注入流程式中進行計算，將事件日誌儲存並分發到事件流中，在這個過程中，事件會以追加的形式有序地持久化到日誌中，這是一個有序的過程，一旦事件寫入就無法修改順序。寫入事件日誌的流可以被相同或不同的消費者多次讀取，基於日誌只能被追加的屬性，所有的事件始終以完全相同的順序釋出給下游的消費者。在實際的使用中，有幾個基於事件日誌的開源軟體可以作為我們的選擇，比如Kafka、RabbitMQ、ActiveMQ，其中以Apache Kafka最受歡迎，Kafka作為時下最火熱的訊息中介軟體，可以整合到很多不同場景的系統架構中，受到很多雲計算服務廠商的青睞。出於很多不同的原因，將Flink上的有狀態流應用程式和事件日誌系統搭配使用是非常合適的，在這種體系結構中，事件日誌可以用來持久化不斷輸入的事件，並可以按確定性順序進行重放。在出現故障的情況下，Flink可以透過先前儲存的檢查點恢復狀態並且重置事件日誌上的讀取位置來恢復有狀態的流應用程式，然後流應用程式會根據檢查點重放（快速轉發）來自事件日誌的輸入事件，在流中重新進行有效回放，這項技術用於程式故障恢復，同時也可以用於更新應用程式、修復缺陷以及修復先前得出的結果、支援將應用程式遷移到不同的叢集中執行或者用於區分程式版本進行A/B測試。正如上面所說，有狀態的流處理是一種通用且靈活性高的架構設計，可以用來處理不同應用場景下的用例，接下來，我們會介紹三種比較有代表性的應用：事件驅動型應用資料管道型應用資料分析型應用

雖然我們區分了有狀態流處理的應用型別，目的是為了說明有狀態流處理的通用性，實際上在真實的應用場景中，通常不會使用單獨一種應用型別，一般會結合起來使用。

事件驅動型應用

事件驅動型應用是一類具有狀態的應用，它從一個或多個事件流提取資料，並根據接收到的事件進行資料計算、狀態更新或其他外部動作。根據不同的業務邏輯，事件驅動的應用程式可以觸發不同的操作，例如傳送報警資訊或分析電子郵件資訊或將事件寫入輸出流作為新的事件流給其他的事件驅動程式使用。

事件驅動型應用程式有以下幾種典型的用例：

實時推薦（比如使用者在瀏覽電商網站時推薦產品）模式檢查或複雜事件處理（例如用於信用卡交易中的欺詐檢測）異常檢測（比如試圖侵入計算機網路檢測）

事件驅動型應用是微服務的演進，微服務透過REST呼叫進行通訊，基於事務型資料庫或K-V資料庫寫入或讀取資料；而事件驅動型應用則是利用事件日誌進行通訊，應用資料會以本地狀態形式儲存，圖1-5顯示了由事件驅動的流應用程式組成的服務體系結構。

圖1-5中的應用程式透過事件日誌進行關聯， 一個應用程式將其輸出傳送到下游事件日誌，上游程式的輸出結果可以作為輸入事件給另一個應用程式進行消費，事件日誌可以將傳送器和接收器之間的關聯關係實現解耦，並提供非同步、非阻塞事件傳輸。每個應用程式都可以是有狀態的，並且可以在本地管理自己的狀態，而不需要訪問外部資料儲存，不僅如此，每個 應用程式也可以單獨或者關聯起來執行。

相對於傳統的事務型應用和微服務來說，事件型驅動應用有幾個比較明顯的優勢，事件驅動型應用無須查詢遠端資料庫，本地資料訪問使得它具有更高的吞吐和更低的延遲。而由於定期向遠端持久化儲存的 checkpoint 工作可以非同步、增量式完成，因此對於正常事件處理的影響甚微。事件驅動型應用的優勢不僅限於本地資料訪問。傳統分層架構下，通常多個應用會共享同一個資料庫，因而任何對資料庫自身的更改（例如：由應用更新或服務擴容導致資料佈局發生改變）都需要謹慎協調。反觀事件驅動型應用，由於只需考慮自身資料，因此在更改資料表示或服務擴容時所需的協調工作將大大減少。

另外，事件驅動型應用程式對執行它們的流處理器有相當高的要求，不是所有的流處理器都適合執行事件驅動型應用程式。事件驅動型應用會受制於底層流處理系統對時間和狀態的把控能力，Flink 諸多優秀特質都是圍繞這些方面來設計的。它提供了一系列豐富的狀態操作原語，允許以精確一次的一致性語義合併海量規模（TB 級別）的狀態資料。此外，Flink 還支援事件時間和豐富的視窗邏輯操作，而且它內建的 ProcessFunction 支援細粒度時間控制，方便實現一些高階業務邏輯。同時，Flink 還擁有一個複雜事件處理（CEP）類庫，可以用來匹配資料流中的模式，Apache Flink符合以上所有的要求，是事件驅動型應用非常好的選擇。Flink 中針對事件驅動應用有一個天然的特性—— savepoint。savepoint 是一個一致性的狀態快照，它可以用來初始化任意狀態相容的應用。在完成一次 savepoint 後，即可放心對應用進行升級或擴容，還可以啟動多個版本的應用來執行 A/B 測試。

資料管道型應用

現如今的IT體系結構包括許多不同的資料儲存媒介，如關係資料庫和非關係型資料庫系統、事件日誌、分散式檔案系統、記憶體快取資料庫和檢索系統等等，以上所有的系統都能以不同的資料格式和資料結構儲存資料，這樣可以為不同資料庫特定訪問模式提供最佳的效能。通常，公司會將相同的資料儲存在多個不同的系統中，目的是為了提高資料訪問的效能，降低單一資料庫的壓力，例如，Webshop中提供的產品資訊可以儲存在事務資料庫、Web快取和全文檢索引擎中；由於資料的複製，意味著不同資料儲存系統之間的資料必須保持同步。

週期性ETL作業是解決不同資料儲存系統直接資料同步問題的常用手段，但是通常延遲非常高，隨著企業對實時性要求越來越高，週期性ETL無法滿足很多要求低延遲的業務場景，這時候可以考慮使用事件日誌進行動態分發，將變更的記錄寫入事件並進行快速分發，及時同步資料更新，這樣一來，日誌的消費者就會將這個更新過的資料記錄同步到不同的資料儲存介質中，根據不同的用例，資料在進入目標資料庫之前需要先進行標準化和聚合處理。和週期性 ETL 作業相比，持續資料管道可以明顯降低將資料移動到目的端的延遲。此外，由於它能夠持續消費和傳送資料，因此用途更廣，支援的應用場景更多。

資料管道和 ETL 作業的用途相似，都可以轉換、提取資料，並將其從某個儲存系統移動到另一個。但資料管道是以持續流的模式執行，而非週期性觸發，因此它支援從一個不斷生成資料的源頭讀取記錄，並將它們以低延遲移動到終點，要求在短時間內處理大量的資料，例如：資料管道可以用來監控檔案系統目錄中的新檔案，並將其資料寫入事件日誌；另一個應用可能會將事件流物化到資料庫或增量構建和最佳化查詢索引。資料管道流處理器還支援各種source connector和sink connector，透過不同的聯結器可以實現不同資料管道資料的關聯和處理，Flink完全滿足資料管道型應用需要的所有特性。

資料分析型應用

資料分析型應用根據實時性大致可以分為批處理和流處理兩種型別。

批處理分析

其中最典型的處理方式就是ETL，ETL作業定期將資料匯入到資料儲存中，用於臨時查詢或生成報表，批處理的一個好處是，不需要關心資料儲存的架構是基於資料倉庫還是Hadoop生態系統的元件， 雖然ETL技術在不斷地改進，但是仍然存在一個很明顯的缺點，對於資料分析還是存在著相當大的延遲。根據作業排程時間間隔和資料量的不同，有些任務需要執行幾個小時甚至幾天才能生成報表，意味著要得到分析結果需要等待相當長的時間，有時候會很大程度上影響企業的運營決策，錯失商業機會，付出不小的代價。透過資料管道型應用匯入資料到資料儲存介質可以在一定程度上降低時間延遲，儘管如此，就算是連續的ETL作業，在執行查詢事件之前還是會存在延遲，這種情況放在以前是能夠被企業所接受的，但是呢，放在今天的話，人們更多的是希望可以做到實時採集資料並即刻響應資料的變化和快速得到查詢分析結果，比如說，根據系統訂單的狀態，實時修改處理商品庫存的變化。

流式處理分析與批處理分析型應用不同的是，流式處理不需要週期性去觸發作業，而是實時地處理不斷輸入的事件流，透過及時計算併合並最新的結果，達到低延遲的效果，類似資料庫用於更新物化檢視技術。通常來說，流應用程式將其計算結果儲存在支援高效更新的外部資料儲存中，例如資料庫或K-V型別的儲存系統中，另外，流分析應用的實時更新結果可應用到儀表盤，如圖1-6所示。流分析應用程式除了能用更短的時間合併事件的分析結果之外，還有一個相對不太明顯的優勢，傳統的資料分析管道由幾個獨立的元件組成，比如ETL作業、儲存系統，以及基於hadoop生態的資料處理引擎和排程器觸發作業或查詢，通常需要將這些元件進行編排，當程式出現故障時需要花費比較多的時間去排查錯誤。與之相反的是，有狀態流應用程式的流處理器會負責處理所有這些資料處理步驟，包括事件攝入、連續計算（中間狀態維護）和結果更新。不但如此，Flink提供exactly-once（狀態一致性）機制，可以保證程式出現異常時進行正確的恢復並調整叢集計算資源，諸如Flink這樣的流計算引擎擁有事件時間機制、高吞吐量的特性，可以很短的時間內處理海量資料，輸出正確的結果。流分析型應用有下面幾種較典型的場景：

1.實時監控移動裝置的網路和流量

2.基於移動裝置的使用者行為分析

3.實時分析消費者資料

值得一提的是，雖然以上內容沒有提到Flink的另一個功能特性，其實Flink也支援在流上執行SQL查詢，透過執行SQL語句就可以得到與開發流處理應用程式一樣的效果，在使用上更加簡單，市場上已經有很多企業應用到實際的場景中了。

開源流處理的演進

其實流處理技術並非完全是新生技術，早在20世紀90年代末就已經出現有人研究這方面的模型，並且出現了商業化的產品，近些年來隨著流處理技術被廣泛使用，很大程度上驅動著開源流處理技術變得愈加成熟。在今天，開源的分散式流處理引擎在很多方面為不同的企業賦能，如零售行業、社交領域、行動通訊、遊戲行業和金融領域等方面，為什麼開源技術能得到大量的使用呢？主要有兩方面的原因：

開源意味著免費和開放，門檻低，容易被大眾接受和使用。由於開源社群的努力，很多開放者貢獻了自己的程式碼，使得開源技術往更好、易用、高效能等好的方向快速發展，促進開源技術變得越來越成熟。

Apache 軟體基金會擁有超過12個與流處理相關的專案，不斷催生新的孵化專案成為新的開源分散式流處理引擎，以新的功能特性和自身優勢向其他流處理引擎發起挑戰，試圖引起人們的關注，與其他流處理引擎形成良性競爭。同時，開源社群持續不斷增加開源專案的功能特性和核心能力，不侷限於解決單一的業務場景，逐步擴大流處理的邊界，大有流批一體化的趨勢，在這裡我們簡要回顧一下流處理技術發展的歷史以及當前的形勢。

歷史回顧

第一代開源分散式流處理引擎出現在2011年，主要用於解決低延遲事件處理，達到毫秒級，並提供了容災機制，避免在程式發生故障時出現數據丟失的情況。初期，這些系統只提供了低階API，沒有內建保證結果一致性和正確性的語義，最終的結果往往取決於事件到達的時間和順序，而且，就算事件沒有被丟失，也會出現重複計算的情況。與批處理引擎相比，第一代開源的流處理引擎犧牲了結果的精確度，換來了低延遲響應計算結果，彌補了批處理的不足，有個折中的辦法就是同時進行批處理和流處理作業，既保證了結果正確性又降低了時間延遲，這也是lambda架構設計出現的根本原因，如圖1-7所示：

從圖中可以看到，lambda架構的底層使用了Speed Layer層來解決傳統週期性批處理延遲高的問題，事件日誌進去lambda架構之後，會被同時寫入批處理程式和流處理程式，此時，流處理程式可以快速計算結果並寫入速度表（Speed Table）中，用於快速查詢分析，而批處理程式則負責週期性處理資料得到準確的結果並存入表中，與流處理程式得到的結果進行校對，移除速度表中不準確的計算結果，最終程式對兩張表的結果進行合併，這樣既保證了資料的準確性又實現了低延遲。

lambda架構雖然不是最好的架構，因為其本身的架構設計，存在著很明顯的缺陷，首先需要維護兩套計算邏輯，開發的時候需要用不同的API，其次，流處理程式計算的結果會出現不準確性，相對來說，lambda體系本身比較複雜，所以很多人不選擇使用它，儘管如此，還是存在不少的應用場景使用到了lambda架構。

基於第一代開源分散式流處理引擎存在的問題，2013年，第二代開源分散式流處理引擎出現了，並在第一代的基礎上提供了更優秀的容錯機制，更好地保證結果一致性，另外，相對於第一代提供的低階API，第二代封裝了很多高階的API，大大豐富了API的類別，雖然第二代流處理引擎很多方面得到了提升，但是在時間延遲方面不升反降，時間延遲由毫秒級變為秒級，而且最終的結果還是取決於事件到達的順序和時間。

直至2015年，第三代開源分散式流處理引擎才解決了計算結果取決於事件到達的順序和時間這個問題，併成為第一個同時解決一致性計算且保證計算結果正確性的流處理引擎，不僅可以用於實時處理資料，還可以用於離線資料的計算，快速得到計算結果。不僅如此，這一代的流處理器同時滿足了低延遲、高吞吐量的特性，解決了lambda架構的嚴重缺陷，lambda架構被在逐漸被新的流處理引擎所取代。除此之外，在計算資源管理方面，第三代流處理引擎支援整合YARN、Mesos或者Kubernetes等資源管理器，可以更好的控制資源合理分配，降低資源粒度，而且還支援升級應用程式程式碼或將作業遷移到不同的叢集以及流處理器的版本向下相容等特性，並保證不會丟失應用程式的當前狀態。

Flink 速覽

Apache Flink就是第三代流式處理引擎中的典型代表，具備很多卓越的特性，如低延遲、高吞吐量等，在這裡列舉Flink的部分優勢：

豐富的時間語義，支援三種時間語義，processing-time、ingest-time、event-time，其中event-time語義提供了一致性結算結果支援，可以處理亂序資料，而process-time語義適用於實時性要求非常嚴格的應用程式。狀態一致性保證。Flink實現了毫秒級別延遲，並且能夠每秒處理數百萬個事件，Flink應用程式可以擴充套件到在數千個cpu core上執行。Flink具有層次分明的API，提供了三種不同的 API，每一種 API 在簡潔性和表達力上有著不同的側重，並且針對不同的應用場景。本書涵蓋了DataStream API和底層ProcessFunction，常用於流處理操作(如視窗處理和非同步通訊)，還提供了精確控制狀態和時間的介面。包括了SQL&Table API，本書不做展開說明。Flink提供了豐富的connector聯結器與外部儲存系統連線，如Apache Kafka、Apache Cassandra、Elasticsearch、JDBC、Kinesis、HDFS和S3等儲存媒介。保證7x24小時全天候服務，提供高可用方案並將程式託管在YARN、Mesos和Kubernetes等高效的資源管理器上，動態調控資源，提升資源利用率。能夠更新應用程式程式碼並將作業遷移到不同的Flink叢集中，而不會丟失應用程式的狀態。細粒度監控叢集各項指標，以提前做好預警處理工作。支援流批一體化。

除了以上的特性，Flink封裝了很多易用的API介面，這對開發人員來說是一個非常友好的框架，在開發和測試的過程中，還可以在單核JVM處理器中透過IDE工具進行除錯。

執行首個Flink 應用

接下來，我們指導你在本地叢集執行你的第一個Flink應用程式，對隨機生成的溫度感測器資料進行轉換和聚合操作，讓你對Flink應用有個大概的瞭解。首先準備Flink叢集執行的環境，JDK 1.8，Unix或Centos 系統，實在不行也可以在window是系統上安裝虛擬機器環境。

1.下載安裝包，具體可以到Apache Flink官網下載不同的版本，這裡以flink-1.7.1-bin-scala_2.12.tgz為例。

2.解壓安裝包

tar xvfz flink-1.7.1-bin-scala_2.12.tgz 

3.啟動叢集$ cd flink-1.7.1$ ./bin/start-cluster.shStarting cluster.Starting standalonesession daemon on host xxx.Starting taskexecutor daemon on host xxx.4.在瀏覽器輸入 http:// localhost:8081，進入flink webUI頁面，預設只有一個slot，如圖1-8所示。

5.下載本書示例的JAR檔案

$ wget https://streaming-with-flink.github.io/\examples/download/examples-scala.jar

6.在本地叢集執行樣例程式

$ ./bin/flink run \-cio.github.streamingwithflink.chapter1.AverageSensorReadings \examples-scala.jar提供任務之後會出現以下提示資訊：Starting execution of programJob has been submitted with JobIDcfde9dbe315ce162444c475a08cf93d9

8.計算結果會被標準輸出到預設的檔案中，可以在 安裝目錄的log資料夾下看到，執行下面的指令即可。

$ tail -f ./log/flink-<user>-taskexecutor-<n>-<hostname>.out 執行命令之後，就會看到下面的輸出資訊，包括了SensorReading物件的id，時間戳，和平均溫度SensorReading(sensor_1,1547718199000,35.80018327300259)SensorReading(sensor_6,1547718199000,15.402984393403084)SensorReading(sensor_7,1547718199000,6.720945201171228)SensorReading(sensor_10,1547718199000,38.101067604893444)

10.關閉叢集

$ ./bin/stop-cluster.sh

以上我們完成了Apache Flink本地叢集的安裝部署，並且試著運行了第一個流應用程式，當然啦，目前為止，我們只是簡單認識了Flink，對於Flink來說，可能勉強算得上剛入門，關於Apache Flink這個框架還有非常多的內容需要我們不斷去學習，這也是本書的價值所在。

總結

本章節我們介紹了Apache Flink的有狀態流處理的架構思想和常見的應用型別，討論了很多不同的用例；對比了傳統的資料基礎架構，瞭解現階段很多企業在資料採集、分析場景下的技術架構選型，企業對實時性有了更高的要求，從ETL到微服務再到流處理引擎這樣一個演變的過程；回顧流處理引擎發展的歷史，明白了流處理引擎是如何一步步提升最佳化，最後發展為如今炙手可熱的技術，為企業提供了可靠可行的解決方案，得到市場的青睞，文章最後介紹了Apache Flink一些突出的特性並演示了單機部署Flink叢集和執行第一個流應用程式。

批註：Flink支援批處理API和流處理API，即DataSet API和DataStream API，分別對應不同的應用場景，目前Flink社群正致力於實現真正的流批一體化，原理是將批處理看成流處理的一種特殊狀態，把離線的資料看作有界的資料流，這樣一來的話，流處理API同樣適用於批處理。