架構

Apache Flink是一個框架和分布式處理引擎，用于對無界和有界數據流進行有狀態(tài)計算。Flink設計為在所有常見的集群環(huán)境中運行，以內存速度和任何規(guī)模執(zhí)行計算。
在這里，我們解釋了Flink架構的重要方面。

處理無界和有界數據

任何類型的數據都是作為事件流產生的。信用卡交易，傳感器測量，機器日志或網站或移動應用程序上的用戶交互，所有這些數據都作為流生成。 數據可以作為無界或有界流處理。

• 無界流有一個開始但沒有定義的結束。它們不會在生成時終止并提供數據。必須持續(xù)處理無界流，即必須在攝取事件后立即處理事件。無法等待所有輸入數據到達，因為輸入是無界的，并且在任何時間點都不會完成。處理無界數據通常要求以特定順序（例如事件發(fā)生的順序）攝取事件，以便能夠推斷結果完整性。
• 有界流具有定義的開始和結束?？梢栽趫?zhí)行任何計算之前通過攝取所有數據來處理有界流。處理有界流不需要有序攝取，因為可以始終對有界數據集進行排序。有界流的處理也稱為批處理。

Apache Flink擅長處理無界和有界數據集。精確控制時間和狀態(tài)使Flink的運行時能夠在無界流上運行任何類型的應用程序。有界流由算法和數據結構內部處理，這些算法和數據結構專門針對固定大小的數據集而設計，從而產生出色的性能。

部署應用程序在任何地方

Apache Flink是一個分布式系統(tǒng)，需要計算資源來執(zhí)行應用程序。Flink集成了所有常見的集群資源管理器，如Hadoop YARN、Apache Mesos和Kubernetes，但也可以設置為作為獨立集群運行。

Flink被設計成能夠很好地工作于前面列出的每個資源管理器。這是通過特定于資源管理器的部署模式實現的，這種部署模式允許Flink以其慣用的方式與每個資源管理器交互。

在部署Flink應用程序時，Flink根據應用程序的配置并行性自動識別所需的資源，并從資源管理器請求它們。如果發(fā)生故障，Flink將通過請求新的資源來替換失敗的容器。提交或控制應用程序的所有通信都是通過REST調用進行的。這簡化了Flink在許多環(huán)境中的集成。

以任何規(guī)模運行應用程序

Flink設計用于在任何規(guī)模上運行有狀態(tài)流應用程序。應用程序被并行化成數千個任務，這些任務分布在一個集群中并發(fā)執(zhí)行。因此，應用程序實際上可以利用無限數量的cpu、主內存、磁盤和網絡IO。此外，Flink很容易保持非常大的應用狀態(tài)。它的異步和增量檢查點算法確保了對處理延遲的最小影響，同時保證了精確的一次狀態(tài)一致性。

利用內存中的性能

有狀態(tài)Flink應用程序針對本地狀態(tài)訪問進行了優(yōu)化。任務狀態(tài)總是在內存中維護，如果狀態(tài)大小超過可用內存，則在具有訪問效率的磁盤數據結構中維護。因此，任務通過訪問本地(通常是在內存中)狀態(tài)來執(zhí)行所有計算，從而產生非常低的處理延遲。Flink通過定期和異步檢查本地狀態(tài)到持久存儲，保證了在發(fā)生故障時的精確一次狀態(tài)一致性。

應用

Apache Flink是一個用于對無界和有界數據流進行有狀態(tài)計算的框架。Flink在不同的抽象級別提供多個API，并為常見用例提供專用庫。
在這里，我們介紹Flink易于使用和富有表現力的API和庫。

流媒體應用程序構塊

可以由流處理框架構建和執(zhí)行的應用程序類型由框架控制流，狀態(tài)和時間的程度來定義。在下文中，我們描述了流處理應用程序的這些構建塊，并解釋了Flink處理它們的方法。
流
顯然，流是流處理的一個基本方面。但是，流可能具有不同的特性，這些特性會影響流可以且應該如何處理。Flink是一個通用的處理框架，可以處理任何類型的流。

• 有界的和無界的流:流可以是無界的或有界的，即，固定大小的數據集。Flink具有處理無界流的復雜特性，但也有專門的操作符來有效地處理有界流。
• 實時流和記錄流:所有數據都作為流生成。有兩種處理數據的方法。當流生成或將其持久化到存儲系統(tǒng)(例如文件系統(tǒng)或對象存儲)時實時處理，并在稍后處理。Flink應用程序可以處理記錄或實時流。

狀態(tài)
每個重要的流應用程序都是有狀態(tài)的，即只有對單個事件應用轉換的應用程序才需要狀態(tài)。運行基本業(yè)務邏輯的任何應用程序都需要記住事件或中間結果，以便在以后的時間點訪問它們，例如在收到下一個事件時或在特定持續(xù)時間之后。

應用程序狀態(tài)是Apache Flink的一等公民?？梢酝ㄟ^查看Flink在狀態(tài)處理環(huán)境中提供的所有功能來查看。

• 多狀態(tài)基元（Multiple State Primitives）：Flink為不同的數據結構提供狀態(tài)基元，例如原子值，列表或映射。開發(fā)人員可以根據函數的訪問模式選擇最有效的狀態(tài)原語。
• 可插拔狀態(tài)后端（Pluggable State Backends）：應用程序狀態(tài)由可插拔狀態(tài)后端管理和檢查點。Flink具有不同的狀態(tài)后端，可以在內存或RocksDB中存儲狀態(tài)，RocksDB是一種高效的嵌入式磁盤數據存儲。也可以插入自定義狀態(tài)后端。
• 完全一次的狀態(tài)一致性（Exactly-once state consistency）：Flink的檢查點和恢復算法可確保在發(fā)生故障時應用程序狀態(tài)的一致性。因此，故障是透明處理的，不會影響應用程序的正確性。
• 非常大的狀態(tài)（Very Large State）：由于其異步和增量檢查點算法，Flink能夠維持幾TB的應用程序狀態(tài)。
• 可擴展的應用程序（Scalable Applications）：Flink通過將狀態(tài)重新分配給更多或更少的工作人員來支持有狀態(tài)應用程序的擴展。

時間
時間是流媒體應用的另一個重要組成部分 大多數事件流都具有固有的時間語義，因為每個事件都是在特定時間點生成的。此外，許多常見的流計算基于時間，例如窗口聚合，會話化，模式檢測和基于時間的連接。流處理的一個重要方面是應用程序如何測量時間，即事件時間和處理時間的差異。

Flink提供了一組豐富的與時間相關的功能。

• Event-time Mode：使用事件時間語義處理流的應用程序根據事件的時間戳計算結果。因此，無論是否處理記錄的或實時的事件，事件時間處理都允許準確和一致的結果。
• 支持Watermark：Flink使用Watermark來推斷事件時間應用中的時間。Watermark也是一種靈活的機制，可以權衡結果的延遲和完整性。
• 延遲數據處理（Late Data Handling）：當使用 watermark 在事件時間模式下處理流時，可能會發(fā)生在所有相關事件到達之前已完成計算。這類事件被稱為遲發(fā)事件。Flink具有多種處理延遲事件的選項，例如通過側輸出重新路由它們以及更新以前完成的結果。
• 處理時間模式（Processing-time Mode）：除了事件時間模式之外，Flink還支持處理時間語義，該處理時間語義執(zhí)行由處理機器的掛鐘時間觸發(fā)的計算。處理時間模式適用于具有嚴格的低延遲要求的某些應用，這些要求可以容忍近似結果。

分層api

Flink 根據抽象程度分層，提供了三種不同的 API。每一種 API 在簡潔性和表達力上有著不同的側重，并且針對不同的應用場景。

分層api

ProcessFunction

ProcessFunction 是 Flink 所提供的最具表達力的接口。ProcessFunction 可以處理一或兩條輸入數據流中的單個事件或者歸入一個特定窗口內的多個事件。它提供了對于時間和狀態(tài)的細粒度控制。開發(fā)者可以在其中任意地修改狀態(tài)，也能夠注冊定時器用以在未來的某一時刻觸發(fā)回調函數。因此，你可以利用 ProcessFunction 實現許多有狀態(tài)的事件驅動應用所需要的基于單個事件的復雜業(yè)務邏輯。

DataStream API

DataStream API為許多通用的流處理操作提供了處理原語。這些操作包括窗口、逐條記錄的轉換操作，在處理事件時進行外部數據庫查詢等。DataStream API 支持 Java 和 Scala 語言，預先定義了例如map()、reduce()、aggregate() 等函數。你可以通過擴展實現預定義接口或使用 Java、Scala 的 lambda 表達式實現自定義的函數。

SQL & Table API

Flink 支持兩種關系型的 API，Table API 和 SQL。這兩個 API 都是批處理和流處理統(tǒng)一的 API，這意味著在無邊界的實時數據流和有邊界的歷史記錄數據流上，關系型 API 會以相同的語義執(zhí)行查詢，并產生相同的結果。Table API 和 SQL 借助了 Apache Calcite來進行查詢的解析，校驗以及優(yōu)化。它們可以與 DataStream 和 DataSet API 無縫集成，并支持用戶自定義的標量函數，聚合函數以及表值函數。

Flink 的關系型 API 旨在簡化數據分析、數據流水線和 ETL 應用的定義。

Libraries

Flink具有幾個用于常見數據處理用例的庫。 這些庫通常嵌入在API中，而不是完全獨立的。 因此，他們可以從API的所有功能中受益，并與其他庫集成。

• 復雜事件處理(Complex Event Processing: CEP):模式檢測是事件流處理的一個非常常見的用例。Flink的CEP庫提供了一個API來指定事件的模式(考慮正則表達式或狀態(tài)機)。CEP庫與Flink的DataStream API集成，以便在DataStreams上評估模式。CEP庫的應用程序包括網絡入侵檢測、業(yè)務流程監(jiān)視和欺詐檢測。
• DataSet API: DataSet API是Flink的核心API，用于批處理應用程序。DataSet API的原語包括map、reduce、(外部)join、co-group和iterate。所有操作都由算法和數據結構支持，這些算法和數據結構對內存中的序列化數據進行操作，如果數據大小超過內存預算，則會溢出到磁盤。Flink的DataSet API的數據處理算法受到傳統(tǒng)數據庫操作符的啟發(fā)，如混合哈希連接或外部合并排序。
• Gelly: Gelly是一個用于可伸縮圖形處理和分析的庫。Gelly是在數據集API的基礎上實現的，并與之集成。因此，它得益于可伸縮和健壯的操作符。Gelly提供了內置的算法，比如標簽傳播(label propagation)、三角形枚舉(triangle enumeration)和頁面排名(page rank)，但也提供了一個Graph API，簡化了自定義圖形算法的實現。

運維

Apache Flink 是一個針對無界和有界數據流進行有狀態(tài)計算的框架。由于許多流應用程序旨在以最短的停機時間連續(xù)運行，因此流處理器必須提供出色的故障恢復能力，以及在應用程序運行期間進行監(jiān)控和維護的工具。

Apache Flink 非常注重流數據處理的可運維性。因此在這一小節(jié)中，我們將詳細介紹 Flink 的故障恢復機制，并介紹其管理和監(jiān)控應用的功能。

7 * 24小時穩(wěn)定運行

在分布式系統(tǒng)中，服務故障是常有的事，為了保證服務能夠7*24小時穩(wěn)定運行，像Flink這樣的流處理器故障恢復機制是必須要有的。顯然這就意味著，它(這類流處理器)不僅要能在服務出現故障時候能夠重啟服務，而且還要當故障發(fā)生時，保證能夠持久化服務內部各個組件的當前狀態(tài)，只有這樣才能保證在故障恢復時候，服務能夠繼續(xù)正常運行，好像故障就沒有發(fā)生過一樣。

Flink通過幾下多種機制維護應用可持續(xù)運行及其一致性:

• checkpoint的一致性: Flink的故障恢復機制是通過建立分布式應用服務狀態(tài)一致性檢查點實現的，當有故障產生時，應用服務會重啟后，再重新加載上一次成功備份的狀態(tài)檢查點信息。結合可重放的數據源，該特性可保證精確一次（exactly-once）的狀態(tài)一致性。
• 高效的檢查點: 如果一個應用要維護一個TB級的狀態(tài)信息，對此應用的狀態(tài)建立檢查點服務的資源開銷是很高的，為了減小因檢查點服務對應用的延遲性（SLAs服務等級協(xié)議）的影響，Flink采用異步及增量的方式構建檢查點服務。
• 端到端的精確一次: Flink 為某些特定的存儲支持了事務型輸出的功能，及時在發(fā)生故障的情況下，也能夠保證精確一次的輸出。
• 集成多種集群管理服務: Flink已與多種集群管理服務緊密集成，如 Hadoop YARN, Mesos, 以及 Kubernetes。當集群中某個流程任務失敗后，一個新的流程服務會自動啟動并替代它繼續(xù)執(zhí)行。
• 內置高可用服務: Flink內置了為解決單點故障問題的高可用性服務模塊，此模塊是基于Apache ZooKeeper技術實現的，Apache ZooKeeper是一種可靠的、交互式的、分布式協(xié)調服務組件。

Flink能夠更方便地升級、遷移、暫停、恢復應用服務

Flink的 Savepoint 服務就是為解決升級服務過程中記錄流應用狀態(tài)信息及其相關難題而產生的一種唯一的、強大的組件。一個 Savepoint，就是一個應用服務狀態(tài)的一致性快照，因此其與checkpoint組件的很相似，但是與checkpoint相比，Savepoint 需要手動觸發(fā)啟動，而且當流應用服務停止時，它并不會自動刪除。Savepoint 常被應用于啟動一個已含有狀態(tài)的流服務，并初始化其（備份時）狀態(tài)。

監(jiān)控和控制應用服務

Flink與許多常見的日志記錄和監(jiān)視服務集成得很好，并提供了一個REST API來控制應用服務和查詢應用信息。具體表現如下：

• Web UI方式: Flink提供了一個web UI來觀察、監(jiān)視和調試正在運行的應用服務。并且還可以執(zhí)行或取消組件或任務的執(zhí)行。
• 日志集成服務:Flink實現了流行的slf4j日志接口，并與日志框架log4j或logback集成。
• 指標服務: Flink提供了一個復雜的度量系統(tǒng)來收集和報告系統(tǒng)和用戶定義的度量指標信息。度量信息可以導出到多個報表組件服務，包括 JMX, Ganglia, Graphite, Prometheus, StatsD, Datadog, 和 Slf4j.
• 標準的WEB REST API接口服務: Flink提供多種REST API接口，有提交新應用程序、獲取正在運行的應用程序的Savepoint服務信息、取消應用服務等接口。REST API還提供元數據信息和已采集的運行中或完成后的應用服務的指標信息。

應用場景

概述

Apache Flink因其豐富的功能而成為開發(fā)和運行多種不同類型應用程序的絕佳選擇。Flink的功能包括對流和批處理的支持，復雜的狀態(tài)管理，事件時間處理語義以及狀態(tài)的一致性保證。此外，Flink可以部署在各種資源管理器上（如YARN，Apache Mesos和Kubernetes），也可以作為裸機硬件上的獨立群集。Flink配置為高可用性，沒有單點故障。Flink提供高吞吐量和低延遲，并為世界上一些最苛刻的流處理應用程序提供支持。
下面，我們將探討由Flink提供支持的最常見類型的應用程序，并指出實際示例。

• 事件驅動型的應用程序
• 數據分析型的應用程序
• 數據管道型的應用程序

事件驅動型的應用程序

事件驅動型的應用程序是一個有狀態(tài)的應用程序，它從一個或多個事件流中提取事件，并通過觸發(fā)計算、狀態(tài)更新或外部操作對傳入事件做出反應。
傳統(tǒng)應用程序設計具有分離的計算和數據存儲層，在此體系結構中，應用程序從遠程事務數據庫中讀取數據并將數據持久化。
相反，事件驅動的應用程序基于有狀態(tài)流處理應用程序。在這種設計中，數據和計算是共同定位的，這產生了本地（內存或磁盤）數據訪問。通過定期將檢查點寫入遠程持久存儲來實現容錯。
事件驅動的應用程序不是查詢遠程數據庫，而是在本地訪問其數據，從而在吞吐量和延遲方面產生更好的性能。遠程持久存儲的檢查點可以異步和遞增完成。因此，檢查點對常規(guī)事件處理的影響非常小。

幾種典型的事件驅動型應用程序：

• 欺詐識別

• 異常檢測

• 基于規(guī)則的警報

• 業(yè)務流程監(jiān)控

• Web應用程序（社交網絡）

數據分析型應用程序

數據分析工作從原始數據中提取信息。傳統(tǒng)上，數據分析是在記錄事件的有界數據集上作為批量查詢或應用程序執(zhí)行。為了將最新數據合并到分析結果中，必須將其添加到分析的數據集中，并重新運行查詢或應用程序。結果將寫入存儲系統(tǒng)或作為報告發(fā)出。
借助先進的流處理引擎，還可以實時地執(zhí)行分析。流式查詢或應用程序不是讀取有限數據集，而是攝取實時事件流，并在消耗事件時不斷生成和更新結果。結果要么寫入外部數據庫，要么保持為內部狀態(tài)。儀表板應用程序可以從外部數據庫讀取最新結果或直接查詢應用程序的內部狀態(tài)。Apache Flink支持流式和批量分析應用程序。
與批量分析相比，連續(xù)流分析的優(yōu)勢不僅限于低延遲。與批量查詢相比，流式查詢不必處理輸入數據中的人為邊界，這些邊界是由定期導入和輸入的有界性質引起的。
另一方面是更簡單的應用程序架構。批量分析管道由若干獨立組件組成，以定期調度數據提取和查詢執(zhí)行?？煽康夭僮鬟@樣的管道并非易事，因為一個組件的故障會影響管道的后續(xù)步驟。相比之下，在像Flink這樣的復雜流處理器上運行的流分析應用程序包含從數據攝取到連續(xù)結果計算的所有步驟。

幾種典型的數據分析型應用程序：

• 電信網絡的質量監(jiān)控

• 分析移動應用程序中的產品更新和實驗評估

• 對消費者技術中的實時數據進行特別分析

• 大規(guī)模圖分析

數據管道型應用程序

提取 - 轉換 - 加載（ETL）是在存儲系統(tǒng)之間轉換和移動數據的常用方法。通常會定期觸發(fā)ETL作業(yè)，以將數據從事務數據庫系統(tǒng)復制到分析數據庫或數據倉庫。
數據管道與ETL作業(yè)具有相似的用途。它們可以轉換和豐富數據，并可以將數據從一個存儲系統(tǒng)移動到另一個存儲系統(tǒng)。但是，它們以連續(xù)流模式運行，而不是定期觸發(fā)。因此，他們能夠從連續(xù)生成數據的源中讀取記錄，并以低延遲將其移動到目的地。例如，數據管道可能會監(jiān)視文件系統(tǒng)目錄中的新文件并將其數據寫入事件日志。
連續(xù)數據流水線優(yōu)于周期性ETL作業(yè)的原因是減少了將數據移動到目的地的延遲。此外，數據管道更通用，可用于更多用例，因為它們能夠連續(xù)消耗和發(fā)送數據。

幾種典型的數據管道型應用：

• 電子商務中的實時搜索索引構建

• 電子商務中持續(xù)的ETL