Apache Flink 功能強大,支持開發和運行多種不同種類的應用程序。它的主要特性包括:批流一體化、精密的狀態管理、事件時間支持以及精確一次的狀態一致性保障等。Flink 不僅可以運行在包括 YARN、 Mesos、K8s 在內的多種資源管理框架上,還支持在裸機集群上獨立部署。在啟用高可用選項的情況下,它不存在單點失效問題。事實證明,Flink 已經可以擴展到數千核心,其狀態可以達到 TB 級別,且仍能保持高吞吐、低延遲的特性。世界各地有很多要求嚴苛的流處理應用都運行在 Flink 之上。
事件驅動型應用
什么是事件驅動型應用?
事件驅動型應用是一類具有狀態的應用,它從一個或多個事件流提取數據,并根據到來的事件觸發計算、狀態更新或其他外部動作。事件驅動型應用是在計算存儲分離的傳統應用基礎上進化而來。在傳統架構中,應用需要讀寫遠程事務型數據庫。
相反,事件驅動型應用是基于狀態化流處理來完成。在該設計中,數據和計算不會分離,應用只需訪問本地(內存或磁盤)即可獲取數據。系統容錯性的實現依賴于定期向遠程持久化存儲寫入 checkpoint。下圖描述了傳統應用和事件驅動型應用架構的區別。
事件驅動型應用的優勢?
事件驅動型應用無須查詢遠程數據庫,本地數據訪問使得它具有更高的吞吐和更低的延遲。而由于定期向遠程持久化存儲的 checkpoint 工作可以異步、增量式完成,因此對于正常事件處理的影響甚微。事件驅動型應用的優勢不僅限于本地數據訪問。傳統分層架構下,通常多個應用會共享同一個數據庫,因而任何對數據庫自身的更改(例如:由應用更新或服務擴容導致數據布局發生改變)都需要謹慎協調。反觀事件驅動型應用,由于只需考慮自身數據,因此在更改數據表示或服務擴容時所需的協調工作將大大減少。
Flink 如何支持事件驅動型應用?
事件驅動型應用會受制于底層流處理系統對時間和狀態的把控能力,Flink 諸多優秀特質都是圍繞這些方面來設計的。它提供了一系列豐富的狀態操作原語,允許以精確一次的一致性語義合并海量規模(TB 級別)的狀態數據。此外,Flink 還支持事件時間和自由度極高的定制化窗口邏輯,而且它內置的 ProcessFunction支持細粒度時間控制,方便實現一些高級業務邏輯。同時,Flink 還擁有一個復雜事件處理(CEP)類庫,可以用來檢測數據流中的模式。
Flink 中針對事件驅動應用的明星特性當屬 savepoint。Savepoint 是一個一致性的狀態映像,它可以用來初始化任意狀態兼容的應用。在完成一次 savepoint 后,即可放心對應用升級或擴容,還可以啟動多個版本的應用來完成 A/B 測試。
典型的事件驅動型應用實例
反欺詐
異常檢測
基于規則的報警
業務流程監控
(社交網絡)Web 應用
什么是數據分析應用?
數據分析任務需要從原始數據中提取有價值的信息和指標。傳統的分析方式通常是利用批查詢,或將事件記錄下來并基于此有限數據集構建應用來完成。為了得到最新數據的分析結果,必須先將它們加入分析數據集并重新執行查詢或運行應用,隨后將結果寫入存儲系統或生成報告。
借助一些先進的流處理引擎,還可以實時地進行數據分析。和傳統模式下讀取有限數據集不同,流式查詢或應用會接入實時事件流,并隨著事件消費持續產生和更新結果。這些結果數據可能會寫入外部數據庫系統或以內部狀態的形式維護。儀表展示應用可以相應地從外部數據庫讀取數據或直接查詢應用的內部狀態。如下圖所示,Apache Flink 同時支持流式及批量分析應用。
流式分析應用的優勢?
和批量分析相比,由于流式分析省掉了周期性的數據導入和查詢過程,因此從事件中獲取指標的延遲更低。不僅如此,批量查詢必須處理那些由定期導入和輸入有界性導致的人工數據邊界,而流式查詢則無須考慮該問題。
另一方面,流式分析會簡化應用抽象。批量查詢的流水線通常由多個獨立部件組成,需要周期性地調度提取數據和執行查詢。如此復雜的流水線操作起來并不容易,一旦某個組件出錯將會影響流水線的后續步驟。而流式分析應用整體運行在 Flink 之類的高端流處理系統之上,涵蓋了從數據接入到連續結果計算的所有步驟,因此可以依賴底層引擎提供的故障恢復機制。
Flink 如何支持數據分析類應用?
Flink 為持續流式分析和批量分析都提供了良好的支持。具體而言,它內置了一個符合 ANSI 標準的 SQL 接口,將批、流查詢的語義統一起來。無論是在記錄事件的靜態數據集上還是實時事件流上,相同 SQL 查詢都會得到一致的結果。同時 Flink 還支持豐富的用戶自定義函數,允許在 SQL 中執行定制化代碼。如果還需進一步定制邏輯,可以利用 Flink DataStream API 和 DataSet API 進行更低層次的控制。此外,Flink 的 Gelly 庫為基于批量數據集的大規模高性能圖分析提供了算法和構建模塊支持。
什么是數據管道?
提取-轉換-加載(ETL)是一種在存儲系統之間進行數據轉換和遷移的常用方法。ETL 作業通常會周期性地觸發,將數據從事務型數據庫拷貝到分析型數據庫或數據倉庫。
數據管道和 ETL 作業的用途相似,都可以轉換、豐富數據,并將其從某個存儲系統移動到另一個。但數據管道是以持續流模式運行,而非周期性觸發。因此它支持從一個不斷生成數據的源頭讀取記錄,并將它們以低延遲移動到終點。例如:數據管道可以用來監控文件系統目錄中的新文件,并將其數據寫入事件日志;另一個應用可能會將事件流物化到數據庫或增量構建和優化查詢索引。下圖描述了周期性 ETL 作業和持續數據管道的差異。
典型的數據分析應用實例
電信網絡質量監控
移動應用中的產品更新及實驗評估分析
消費者技術中的實時數據即席分析
大規模圖分析
數據管道的優勢?
和周期性 ETL 作業相比,持續數據管道可以明顯降低將數據移動到目的端的延遲。此外,由于它能夠持續消費和發送數據,因此用途更廣,支持用例更多。
Flink 如何支持數據管道應用?
很多常見的數據轉換和增強操作可以利用 Flink 的 SQL 接口(或 Table API)及用戶自定義函數解決。如果數據管道有更高級的需求,可以選擇更通用的 DataStream API 來實現。Flink 為多種數據存儲系統(如:Kafka、Kinesis、Elasticsearch、JDBC數據庫系統等)內置了連接器。同時它還提供了文件系統的連續型數據源及數據匯,可用來監控目錄變化和以時間分區的方式寫入文件。
典型的數據管道應用實例
[電子商務中的實時查詢索引構建](https://www.ververica.com/blog/blink-flink-alibaba-search)[電子商務中的持續 ETL](https://jobs.zalando.com/tech/blog/apache-showdown-flink-vs.-spark/)