使用Apache Flink的四個理由,你知道幾個?
Apache Kafka已經成為企業內流式數據傳輸的首選平臺。但如果數據可以被清洗、豐富后為下游更多應用提供服務,那么流式處理就更有價值。這就是流處理的作用。
譯自 4 Reasons Why Developers Should Use Apache Flink 。
流處理允許你持續消費數據流,用額外的業務邏輯處理數據,并將其轉化為新的流,以便其他人可以在自己的應用中重復使用。其應用范圍廣泛,包括實時控制面板、機器學習模型、物化視圖,以及事件驅動的應用和微服務。
圖片
流處理用額外的業務邏輯增強數據流,將其轉化為新的可重復使用的數據流,以供下游應用和流水線使用。
處理邏輯的復雜度因具體應用場景而異,范圍從簡單的過濾和聚合,到更復雜的多路時間關聯和任意事件驅動邏輯。因此,與其他選項(如定期批處理、ELT、經典兩層架構)相比,流處理的優勢因情況而異。
盡管如此,推動采用流處理的關鍵因素通常屬于以下一個或多個類別:
- 延遲: 流處理大大縮短事件發生和反映在產品或用戶體驗中的時間,無論是控制面板、機器學習模型還是其他應用。
- 創新和重用性: 流處理將數據產品轉化為可共享的資產,可供下游應用和系統消費和構建。數據流成為可重用的構建塊,具有明確定義和一致的訪問方式,使其他團隊可以輕松在新產品和應用中使用。
- 成本和資源效率: 持續處理可隨時間分配工作,提高資源利用率。此外,上游處理(如預聚合、會話等)極大地減少下游系統(如數據倉庫、實時分析數據庫等)的成本,并加速其查詢。
- 表達性: 生活不會分批次發生。與定期批處理不同,流處理不會在數據中引入人為邊界,從而影響處理邏輯。
Flink是最活躍的Apache項目之一,提供了流處理和批處理的統一框架。像Uber、Netflix、LinkedIn這樣的數字化先鋒公司使用Flink,傳統企業如高盛和Comcast也在使用。
Flink也擁有大型且活躍的貢獻者社區,其中包括Apple和阿里巴巴等公司的支持,這有助于保證持續創新。因此,Flink的采用速度與Kafka早期階段相當。
圖片
Flink的增長速度與Kafka生命周期相同階段基本相當。
下面是公司選擇Flink而非其他流處理技術的四大常見原因:
第一: 它是一個強大的執行引擎
Flink擁有強大的運行時,具有卓越的資源優化、高吞吐量與低延遲以及可靠的狀態處理。具體來說,運行時可以:
- 實現每秒數千萬條記錄的持續吞吐量
- 大規模下保持亞秒級延遲
- 跨系統邊界保證端到端的恰好一次處理
- 即使在故障和無序事件下也能計算出正確結果
- 管理和在錯誤時恢復高達數十TB的狀態
Flink可根據用例配置各種工作負載,包括流處理、批處理或兩者的混合。
第二: 兼容多種API和語言
Flink提供了四種不同的API,可滿足不同用戶和應用需求。Flink還支持多種編程語言,包括Python、Java和SQL。
圖片
Flink提供了多層次的API,抽象級別不同,既可處理常見用例,也可處理不太常見的用例。
適用于Java和Python的DataStream API通過鏈接FlatMap、Filter、Process等轉換函數創建數據流圖。在這些用戶定義函數中,你可以訪問狀態流處理器的基本組件,如狀態、時間和事件。這讓你可以細粒度控制記錄在系統中的流動以及讀寫和更新應用狀態。如果你熟悉Kafka Streams DSL和Kafka Processor API,使用體驗會很熟悉。
Table API是Flink更現代的聲明式API。它允許你用連接、過濾、聚合、投影等關系操作以及各種用戶定義函數編寫程序。與DataStream API類似,Table API支持Java和Python。使用此API開發的程序會進行類似Flink SQL查詢的優化,與SQL共享若干特性,如類型系統、內置函數和驗證層。該API與Spark Structured Streaming、Spark DataFrame API和Snowpark DataFrame API有相似處,不過那些API更側重微批和批處理而非流處理。
基于與Table API相同的底層架構,Flink SQL是遵循ANSI標準的SQL引擎,可處理實時和歷史數據。Flink SQL使用Apache Calcite進行查詢規劃和優化。它支持任意嵌套子查詢,廣泛的語言支持包括各種流連接和模式匹配,擁有廣泛的生態系統,包括JDBC驅動程序、目錄和交互式SQL Shell。
最后是“Stateful Functions”,它簡化了狀態化分布式事件驅動應用的創建。這是Flink項目下的一個獨立子項目,與Flink的其他API很不相同。Stateful Functions可以理解為一個基于Flink運行時的狀態化、容錯的分布式Actor系統。
廣泛的API選擇使Flink成為流處理的理想選擇,隨著需求和用例的演變,你可以隨時間混合使用不同的API。
第三: 流處理和批處理融合
Apache Flink統一了流處理和批處理,因為其主要API(SQL、Table API和DataStream API)同時支持有界數據集和無界數據流。具體來說,你可以根據正在處理的數據性質,以批處理或流處理模式運行相同程序。你甚至可以讓系統為你選擇處理模式。
- 只有有界數據源 → 批處理模式
- 至少一個無界數據源 → 流處理模式
圖片
Flink可以在同一平臺上統一流處理和批處理。
流批處理的統一為開發者帶來實實在在的好處:
- 在實時和歷史數據處理場景提供一致語義
- 在實時和歷史數據處理應用間復用代碼、邏輯和基礎設施
- 在單一應用中組合歷史和實時數據處理
第四: 它已做好生產就緒準備
Flink是一個成熟平臺,在最苛刻的生產場景中經受住了檢驗。表現這一點的特性包括:
- 開箱即用地與Datadog、Prometheus等工具集成的指標系統,也可與自定義解決方案集成
- 通過Flink Web UI進行全面的可觀測性、故障排查和調試支持,包括回壓監控、火焰圖和線程轉儲
- 保存點,允許你在保持恰好一次語義的前提下,狀態式擴展、升級、分叉、備份和遷移應用
Flink和Kafka: 強大組合
Flink和Kafka經常一起使用,事實上Kafka是Flink最熱門的連接器。兩者高度兼容,在許多方面Kafka推動了Flink的廣泛采用。
需注意,Flink本身不存儲任何數據,它對其他地方存儲的數據進行操作??梢园袴link視為Kafka的計算層,為實時應用和流水線提供支持,而Kafka是流數據的基礎存儲層。
圖片
在數據流堆棧中,Flink處理計算需求,Kafka提供存儲層。
隨時間推移,Flink在支持Kafka應用方面越來越嫻熟。它可以將Kafka用作數據源和數據匯,利用Kafka豐富的生態系統和工具。Flink還原生支持熱門的數據格式,包括Avro、JSON和Protobuf。
對Flink來說,Kafka也是一個同樣好的匹配。與ActiveMQ、RabbitMQ或PubSub等其他消息系統相比,Kafka為Flink提供持久且無限的數據存儲。此外,Kafka允許多個消費者同時讀取流并按需倒帶。第一個屬性補充了Flink的分布式處理范式,第二個對Flink的容錯機制至關重要。
渴望更多了解Flink?
想深入了解的話,可以在Confluent Developer網站的Flink 101課程或這個Apache Flink培訓中動手實踐。