Apache Kafka已經(jīng)成為企業(yè)內(nèi)流式數(shù)據(jù)傳輸?shù)氖走x平臺。但如果數(shù)據(jù)可以被清洗、豐富后為下游更多應用提供服務，那么流式處理就更有價值。這就是流處理的作用。

譯自 4 Reasons Why Developers Should Use Apache Flink 。

流處理允許你持續(xù)消費數(shù)據(jù)流，用額外的業(yè)務邏輯處理數(shù)據(jù)，并將其轉(zhuǎn)化為新的流，以便其他人可以在自己的應用中重復使用。其應用范圍廣泛，包括實時控制面板、機器學習模型、物化視圖，以及事件驅(qū)動的應用和微服務。

圖片

流處理用額外的業(yè)務邏輯增強數(shù)據(jù)流，將其轉(zhuǎn)化為新的可重復使用的數(shù)據(jù)流，以供下游應用和流水線使用。

處理邏輯的復雜度因具體應用場景而異，范圍從簡單的過濾和聚合，到更復雜的多路時間關(guān)聯(lián)和任意事件驅(qū)動邏輯。因此，與其他選項(如定期批處理、ELT、經(jīng)典兩層架構(gòu))相比，流處理的優(yōu)勢因情況而異。

盡管如此，推動采用流處理的關(guān)鍵因素通常屬于以下一個或多個類別:

• 延遲: 流處理大大縮短事件發(fā)生和反映在產(chǎn)品或用戶體驗中的時間，無論是控制面板、機器學習模型還是其他應用。
• 創(chuàng)新和重用性: 流處理將數(shù)據(jù)產(chǎn)品轉(zhuǎn)化為可共享的資產(chǎn)，可供下游應用和系統(tǒng)消費和構(gòu)建。數(shù)據(jù)流成為可重用的構(gòu)建塊，具有明確定義和一致的訪問方式，使其他團隊可以輕松在新產(chǎn)品和應用中使用。
• 成本和資源效率: 持續(xù)處理可隨時間分配工作，提高資源利用率。此外，上游處理(如預聚合、會話等)極大地減少下游系統(tǒng)(如數(shù)據(jù)倉庫、實時分析數(shù)據(jù)庫等)的成本，并加速其查詢。
• 表達性: 生活不會分批次發(fā)生。與定期批處理不同，流處理不會在數(shù)據(jù)中引入人為邊界，從而影響處理邏輯。

Flink是最活躍的Apache項目之一，提供了流處理和批處理的統(tǒng)一框架。像Uber、Netflix、LinkedIn這樣的數(shù)字化先鋒公司使用Flink，傳統(tǒng)企業(yè)如高盛和Comcast也在使用。

Flink也擁有大型且活躍的貢獻者社區(qū)，其中包括Apple和阿里巴巴等公司的支持，這有助于保證持續(xù)創(chuàng)新。因此，F(xiàn)link的采用速度與Kafka早期階段相當。

圖片

Flink的增長速度與Kafka生命周期相同階段基本相當。

下面是公司選擇Flink而非其他流處理技術(shù)的四大常見原因：

第一: 它是一個強大的執(zhí)行引擎

Flink擁有強大的運行時，具有卓越的資源優(yōu)化、高吞吐量與低延遲以及可靠的狀態(tài)處理。具體來說，運行時可以:

• 實現(xiàn)每秒數(shù)千萬條記錄的持續(xù)吞吐量
• 大規(guī)模下保持亞秒級延遲
• 跨系統(tǒng)邊界保證端到端的恰好一次處理
• 即使在故障和無序事件下也能計算出正確結(jié)果
• 管理和在錯誤時恢復高達數(shù)十TB的狀態(tài)

Flink可根據(jù)用例配置各種工作負載，包括流處理、批處理或兩者的混合。

第二: 兼容多種API和語言

Flink提供了四種不同的API，可滿足不同用戶和應用需求。Flink還支持多種編程語言，包括Python、Java和SQL。

圖片

Flink提供了多層次的API，抽象級別不同，既可處理常見用例，也可處理不太常見的用例。

適用于Java和Python的DataStream API通過鏈接FlatMap、Filter、Process等轉(zhuǎn)換函數(shù)創(chuàng)建數(shù)據(jù)流圖。在這些用戶定義函數(shù)中，你可以訪問狀態(tài)流處理器的基本組件，如狀態(tài)、時間和事件。這讓你可以細粒度控制記錄在系統(tǒng)中的流動以及讀寫和更新應用狀態(tài)。如果你熟悉Kafka Streams DSL和Kafka Processor API，使用體驗會很熟悉。

Table API是Flink更現(xiàn)代的聲明式API。它允許你用連接、過濾、聚合、投影等關(guān)系操作以及各種用戶定義函數(shù)編寫程序。與DataStream API類似，Table API支持Java和Python。使用此API開發(fā)的程序會進行類似Flink SQL查詢的優(yōu)化，與SQL共享若干特性，如類型系統(tǒng)、內(nèi)置函數(shù)和驗證層。該API與Spark Structured Streaming、Spark DataFrame API和Snowpark DataFrame API有相似處，不過那些API更側(cè)重微批和批處理而非流處理。

基于與Table API相同的底層架構(gòu)，F(xiàn)link SQL是遵循ANSI標準的SQL引擎，可處理實時和歷史數(shù)據(jù)。Flink SQL使用Apache Calcite進行查詢規(guī)劃和優(yōu)化。它支持任意嵌套子查詢，廣泛的語言支持包括各種流連接和模式匹配，擁有廣泛的生態(tài)系統(tǒng)，包括JDBC驅(qū)動程序、目錄和交互式SQL Shell。

最后是“Stateful Functions”，它簡化了狀態(tài)化分布式事件驅(qū)動應用的創(chuàng)建。這是Flink項目下的一個獨立子項目，與Flink的其他API很不相同。Stateful Functions可以理解為一個基于Flink運行時的狀態(tài)化、容錯的分布式Actor系統(tǒng)。

廣泛的API選擇使Flink成為流處理的理想選擇，隨著需求和用例的演變，你可以隨時間混合使用不同的API。

第三: 流處理和批處理融合

Apache Flink統(tǒng)一了流處理和批處理，因為其主要API(SQL、Table API和DataStream API)同時支持有界數(shù)據(jù)集和無界數(shù)據(jù)流。具體來說，你可以根據(jù)正在處理的數(shù)據(jù)性質(zhì)，以批處理或流處理模式運行相同程序。你甚至可以讓系統(tǒng)為你選擇處理模式。

• 只有有界數(shù)據(jù)源 → 批處理模式
• 至少一個無界數(shù)據(jù)源 → 流處理模式

圖片

Flink可以在同一平臺上統(tǒng)一流處理和批處理。

流批處理的統(tǒng)一為開發(fā)者帶來實實在在的好處：

• 在實時和歷史數(shù)據(jù)處理場景提供一致語義
• 在實時和歷史數(shù)據(jù)處理應用間復用代碼、邏輯和基礎設施
• 在單一應用中組合歷史和實時數(shù)據(jù)處理

第四: 它已做好生產(chǎn)就緒準備

Flink是一個成熟平臺，在最苛刻的生產(chǎn)場景中經(jīng)受住了檢驗。表現(xiàn)這一點的特性包括：

• 開箱即用地與Datadog、Prometheus等工具集成的指標系統(tǒng)，也可與自定義解決方案集成
• 通過Flink Web UI進行全面的可觀測性、故障排查和調(diào)試支持，包括回壓監(jiān)控、火焰圖和線程轉(zhuǎn)儲
• 保存點，允許你在保持恰好一次語義的前提下，狀態(tài)式擴展、升級、分叉、備份和遷移應用

Flink和Kafka: 強大組合

Flink和Kafka經(jīng)常一起使用，事實上Kafka是Flink最熱門的連接器。兩者高度兼容，在許多方面Kafka推動了Flink的廣泛采用。

需注意，F(xiàn)link本身不存儲任何數(shù)據(jù)，它對其他地方存儲的數(shù)據(jù)進行操作?？梢园袴link視為Kafka的計算層，為實時應用和流水線提供支持，而Kafka是流數(shù)據(jù)的基礎存儲層。

圖片

在數(shù)據(jù)流堆棧中，F(xiàn)link處理計算需求，Kafka提供存儲層。

隨時間推移，F(xiàn)link在支持Kafka應用方面越來越嫻熟。它可以將Kafka用作數(shù)據(jù)源和數(shù)據(jù)匯，利用Kafka豐富的生態(tài)系統(tǒng)和工具。Flink還原生支持熱門的數(shù)據(jù)格式，包括Avro、JSON和Protobuf。

對Flink來說，Kafka也是一個同樣好的匹配。與ActiveMQ、RabbitMQ或PubSub等其他消息系統(tǒng)相比，Kafka為Flink提供持久且無限的數(shù)據(jù)存儲。此外，Kafka允許多個消費者同時讀取流并按需倒帶。第一個屬性補充了Flink的分布式處理范式，第二個對Flink的容錯機制至關(guān)重要。

渴望更多了解Flink？

想深入了解的話，可以在Confluent Developer網(wǎng)站的Flink 101課程或這個Apache Flink培訓中動手實踐。