1.2 架構

從概念上來說，所有的計算都符合“數據輸入—處理轉換—數據輸出”的過程，這個過程有時候叫作數據處理流水線（Pipeline），流水線的概念來自生產制造中的流水線。以WordCount為例，其處理過程抽象如圖1-1所示。

圖1-1中，Source表示數據輸入；轉換表示數據處理的過程，在處理轉換中會包含1個或者多個計算步驟；Sink表示數據輸出。Source、Sink合并起來就是IO。無論是Source、Sink還是中間的轉換，在Flink中都統一抽象為Transformation。

隨著數據量越來越大，遠遠超過了單機的處理能力，作業需要在一個幾十上百臺的集群上執行，這時候就涉及如何將作業橫向和縱向拆分。橫向拆分是將作業中的步驟并行執行，用并行度（Parallism）來表示一個步驟有多少個實例并行執行。縱向拆分是將作業的步驟進行拆分，拆分出來的每一個實體叫作Task，每個Task最終會分配到一臺服務器上執行，最終形成一個由Task組成的有向無環圖（DAG），Task中執行1個或者多個算子的示例如圖1-2所示。

從DAG中可以看到，Source的并行度為1，所以其只有1個Task。FlatMap的并行度為2，所以其有2個Task。KeyedAgg與Sink根據優化策略合并成了1個執行單元，并行度都是2，所以有2個Task。KeyedAgg與Sink的合并使用了算子融合，將符合優化策略的計算步驟合并成為一個OperatorChain，具體內容后邊章節會闡述。

1.2.1 技術架構

Flink是一個批流一體的分布式計算引擎，作為一個分布式計算引擎，必須提供面向開發人員的API，根據業務邏輯開發Flink作業，作業除了包含業務邏輯外，還需要跟外部的數據存儲進行交互。作業開發、測試完畢后，交給Flink集群進行執行，同時還要讓運維人員能夠管理與監控Flink。

Flink技術架構如圖1-3所示。

對于應用開發者而言，直接使用API層和應用框架層，兩者的差別在于API的層次不同，API層是Flink對外提供的核心API，應用框架層是在核心API之上提供的面向特定計算場景、更加易用的API。

1.應用框架層

該層也可以稱為Flink應用框架層，是指根據API層的劃分，在API層之上構建的滿足特定應用場景的計算框架，總體上分為流計算和批處理兩類應用框架。面向流計算的應用框架有流上SQL（Flink Table&SQL）、CEP（復雜事件處理），面向批處理的應用框架有批上SQL（Flink Table&SQL）、Flink ML（機器學習）、Gelly（圖處理）。

（1）Table&SQL

Table&SQL是Flink中提供SQL語義支持的內置應用框架，其中Table API提供Scala和Java語言的SQL語義支持，允許開發者使用編碼的方式實現SQL語義。SQL基于Apache Calcite，支持標準SQL，使用者可以在應用中直接使用SQL語句，同時也支持Table API和SQL的混合編碼。

Table API和SQL在流計算和批處理上提供了一致的接口，批處理和流式傳輸的Table API和SQL程序都遵循相同的模式。

兩者在底層上都依賴于Apache Calcite提供的優化能力，借助Apache Calcite內置的優化規則，加上Flink實現的分布式流、批優化規則，在邏輯和物理兩個層面上進行優化。

（2）CEP

CEP本質上是一種實時事件流上的模式匹配技術，是實時事件流上常見的用例。CEP通過分析事件間的關系，利用過濾、關聯、聚合等技術，根據事件間的時序關系和聚合關系制定匹配規則，持續地從事件流中匹配出符合要求的事件序列，通過模式組合能夠識別更加復雜的事件序列，主要用于反欺詐、風控、營銷決策、網絡安全分析等場景。

常見的開源CEP引擎有Esper、Siddhi、Drools等，商業CEP引擎有Esper企業版、StreamBase、StreamInsight等。其中，Esper是成熟且資歷比較老的CEP引擎，在金融行業的應用比較廣泛，開源Esper支持單機版，Esper企業版支持雙機熱備。

現有的復雜事件處理引擎除Siddhi支持分布式部署之外（依賴Storm），其余的復雜事件處理引擎都存在分布式計算支持不夠的問題。Flink CEP應用開發框架借助Flink的分布式計算引擎，提供了復雜事件處理API，能夠實現完整的模式匹配語義，同時部分實現了SQL 2016標準中的SQL MatchRecognize語義，支持通過SQL定義復雜事件處理匹配規則。

（3）Gelly

Gelly是一個可擴展的圖形處理和分析庫。Gelly是在DataSet API之上實現的，并與DataSet API集成在一起。因此，它受益于其可擴展且強大的操作符。Gelly具有內置算法，如label propagation（標簽傳播）、triangle enumeration和page rank, 但也提供了一個自定義圖算法實現的簡化Graph API。

Gelly的應用不多，本書中不進行深入闡述，讀者可參考官方文檔進行了解。

（4）ML

Flink ML是Flink的機器學習框架，定位類似于Spark MLLib，但是在目前階段其實現的算法和成熟度距離Spark MLLib有較大差距，不具備生產環境的可用性，在Flink1.9之后的版本中會對其進行重構。本書中不進行詳細闡述，讀者可參考官方文檔進行了解。

2. API層

API層是Flink對外提供能力的接口，實現了面向流計算的DataStream API和面向批處理的DataSet API。理論上來說，Flink的API應該像Apache Beam、Spark那樣實現API層流批統一，但是目前卻依然是兩套系統，使用起來并不方便，所以社區也在以DataStream API為核心，推進批流API的統一。DataSet API未來會被廢棄，所以本書不會對基于DataSet的批處理方面進行過多的闡述。

3.運行時層

運行時層提供了支持Flink集群計算的核心，將開發的Flink應用分布式執行起來，包含如下內容。

1）DAG抽象：將分布式計算作業拆分成并行子任務，每個子任務表示數據處理的一個步驟，并且在上下游之間建立數據流的流通關系。

2）數據處理：包含了開發層面、運行層面的數據處理抽象，例如包含數據處理行為的封裝、通用數據運算的實現（如Join、Filter、Map等）。

3）作業調度：調度批流作業的執行。

4）容錯：提供了集群級、應用級容錯處理機制，保障集群、作業的可靠運行。

5）內存管理、數據序列化：通過序列化，使用二進制方式在內存中存儲數據，避免JVM的垃圾回收帶來的停頓問題。

6）數據交換：數據在計算任務之間的本地、跨網絡傳遞。

Flink運行時層并不是給一般的Flink應用開發者使用的。

4.部署層

該層是Flink集群部署抽象層，Flink提供了靈活的部署模式，可以本地運行、與常見的資源管理集群集成，也支持云上的部署。

Flink支持多種部署模式：

1）Standalone模式：Flink安裝在普通的Linux機器上，或者安裝在K8s中，集群的資源由Flink自行管理。

2）Yarn、Mesos、K8s等資源管理集群模式：Flink向資源集群申請資源，創建Flink集群。

3）云上模式：Flink可以在Google、亞馬遜云計算平臺上輕松部署。

5.連接器（Connector）

Connector是Flink計算引擎與外部存儲交互的IO抽象，是前面提到過的Source和Sink的具體實現。在Connector的實現上，流和批的實現是兩套系統，這屬于歷史遺留問題，未來會逐漸統一。

1.2.2 運行架構

通過技術架構來了解的Flink是靜態的，而實際上Flink集群在運行的時候，存在不同的進程角色來完成集群的管理，作業的提交、執行、管理等一系列的動作，如圖1-4所示。

Flink集群采用Master-Slave架構，Master的角色是JobManager，負責集群和作業管理，Slave的角色是TaskManager，負責執行計算任務。除此之外，Flink還提供了客戶端來管理集群和提交任務，其中JobManager和TaskManager是集群的進程，Flink客戶端是在集群外部執行的進程，不是集群的一部分。

1. Flink客戶端

Flink客戶端是Flink提供的CLI命令行工具，用來提交Flink作業到Flink集群，在客戶端中負責Stream Graph（流圖）和Job Graph（作業圖）的構建，后面有詳細介紹。使用Table API和SQL編寫的Flink應用，還會在客戶端中負責SQL解析和優化。

Flink的Flip改進建議中提出了新的模式，SQL解析、優化，StreamGraph、JobGraph、ExecutionGraph構建轉換等全部都會在JobManager中完成，這將在Flink1.10后續版本中實現。

2. JobManager

JobManager根據并行度將Flink客戶端提交的Flink應用分解為子任務，從資源管理器申請所需的計算資源，資源具備之后，開始分發任務到TaskManager執行Task，并負責應用容錯，跟蹤作業的執行狀態，發現異常則恢復作業等。

3. TaskManager

TaskManager接收JobManager分發的子任務，根據自身的資源情況，管理子任務的啟動、停止、銷毀、異常恢復等生命周期階段。

作業啟動后開始從數據源消費數據、處理數據，并寫入外部存儲中。

無論使用哪種資源集群，以上所介紹的角色是必不可少的，其作用一樣。

從圖1-4中可以看到，JobManager是一個單點的部署模式，在Flink中支持JobManager的HA部署，在后續章節中會介紹Flink HA的部署。