引入

我們整個大數據處理里面的計算模式主要可以分為以下四種：

1. 批量計算（batch computing）
   MapReduce
   Hive
   Spark
   Flink
   pig
2. 流式計算（stream computing）
   Storm
   SparkStreaming/StructuredStreaming
   Flink
   Samza
3. 交互計算（interactive computing）
   Presto
   Impala
   Druid
   Drill
4. 圖計算（graph computing）
   Giraph （Facebook)
   Graphx (Spark)
   Gelly（Flink)

在本專欄里面，我們重點關注的是Flink，它涉及批量計算、流式計算以及圖計算，下面我們重點看一下批量計算和流式計算的核心區別：

• 數據時效性不同：流式計算實時、低延遲，批量計算非實時、高延遲。
• 數據特征不同：流式計算的數據一般是動態的、沒有邊界的，而批處理的數據一般則是靜態數據。
• 應用場景不同：流式計算應用在實時場景，時效性要求比較高的場景，如實時推薦、業務監控等；批量計算一般稱為批處理，應用在實時性要求不高、離線計算的場景下，數據分析、離線報表等。
• 運行方式不同：流式計算的任務持續進行的，批量計算的任務則一次性完成。

隨著企業對數據處理實時性要求越來越高，越來越多的業務場景開始更加強調時效性，比如說實時推薦、風控等業務。而伴隨這些這些業務的需求的是開源流式處理技術日趨成熟，這極大的促使數據處理的技術里，流式計算開始逐步成為主流。

業界主流的流式處理框架演進

我們下面來看下，隨著技術發展，有哪些主流的流式框架：

Storm

最早使用的流處理框架，社區比較成熟。
支持原生流處理，即單事件來處理數據流（所有記錄一個接一個處理）。
延遲性低（毫秒級）。
消息保障能力弱，消息傳輸可能重復但不會丟失。
吞吐量比較低。

1. 社區成熟度

Storm 是最早使用的流處理框架之一，社區比較成熟。它最早由Twitter開源，后于2014年成為Apache基金會的頂級項目。Storm社區的活躍度和穩定性較高，全球有眾多代碼貢獻者，這為Storm的持續發展和優化提供了有力支持。

2. 原生流處理能力

Storm 支持原生流處理，即單事件來處理數據流，所有記錄一個接一個處理。Storm中的數據流由一個個連續不斷的Tuple組成，每個Tuple代表一條數據。Spout作為數據源，負責從外部讀取數據并將其發送到數據流中；Bolt作為數據處理節點，負責接收數據流中的數據并進行處理。這種處理方式使得Storm能夠實時地處理數據，適用于需要快速響應的應用場景。

3. 低延遲特性

Storm 的延遲性低，可以達到毫秒級。Storm的這種低延遲特性使得它在實時性要求高的場景中表現出色，例如金融交易、社交媒體監控等。

4. 消息保障能力

Storm 的消息保障能力相對較弱，消息傳輸可能重復但不會丟失。Storm通過ACK機制保證每個消息至少被處理一次，但可能會出現重復處理的情況。這意味著在某些情況下，可能會有重復的消息被發送到下游系統，需要下游系統具備處理重復消息的能力。

5. 吞吐量

Storm 的吞吐量相對較低。盡管Storm能夠高效地處理數據流，但在處理大規模數據時，其吞吐量可能不如其他一些流處理框架（如Apache Flink）。不過，Storm的分布式架構使其具備了良好的擴展性，可以通過增加工作節點來水平擴展系統，以應對不同規模的數據處理需求。

總結

Apache Storm 作為一個開源的分布式實時計算系統，具有社區成熟、原生流處理能力、低延遲等優點，適用于需要實時處理數據的場景。然而，其消息保障能力和吞吐量方面存在一定的局限性，需要根據具體的應用場景進行權衡和選擇。

SparkStreaming

SparkStreaming屬于SparkAPI的擴展。
以固定時間間隔（如幾秒種）處理一段段的批處理作業（即“微批處理”）
延遲性較高（秒級），但能夠保證消息傳輸既不會丟失也不會重復。
具有非常高的吞吐。

1. Spark API 的擴展

Spark Streaming 是 Spark 核心 API 的一個擴展，它允許開發人員使用 Spark 的編程模型和 API 來處理實時數據流。

2. 微批處理機制

如下圖所示，Spark Streaming 采用微批處理（Micro-batch）的機制來處理數據流。它將輸入的數據流按照固定的時間間隔（如幾秒鐘）分割成一個個小批次（batch），然后對每個批次的數據進行批處理作業。這種機制使得 Spark Streaming 能夠在處理數據時兼顧吞吐量和延遲。具體來說，Spark Streaming 將實時輸入數據流劃分為多個小批次，每個批次對應一個 RDD（彈性分布式數據集），然后通過 Spark Engine 對這些 RDD 進行處理，最終生成結果流。

3. 延遲性較高

由于采用了微批處理機制，Spark Streaming 的延遲性相對較高，通常在秒級。與像 Apache Storm 這樣的純流處理系統相比，Spark Streaming 的延遲要高一些，因為它不是逐條處理數據，而是將數據分批處理。然而，這種微批處理的機制使得 Spark Streaming 能夠在處理大規模數據時保持較高的吞吐量和容錯性。

4. 消息保障能力強

Spark Streaming 能夠保證消息傳輸既不會丟失也不會重復。它通過寫前日志（Write Ahead Log，WAL）機制來實現這一點。當數據到達 Spark Streaming 時，會先寫入 WAL 中，從而確保即使在數據接收過程中發生故障，數據也不會丟失。此外，Spark Streaming 的容錯性還體現在它能夠從節點故障或任務失敗中快速恢復，并重新處理數據，確保數據的完整性和一致性。

5. 高吞吐量

Spark Streaming 具有非常高的吞吐量。它利用 Spark 的分布式計算能力和內存計算特性，能夠高效地處理大規模的數據流。通過將數據分批處理，Spark Streaming 能夠充分利用集群資源，實現數據的并行處理，從而達到高吞吐量的效果。此外，Spark Streaming 還支持多種優化策略，如數據分區、內存管理等，以進一步提高數據處理的效率。

總結

Apache Spark Streaming 作為 Spark 核心 API 的擴展，通過微批處理機制實現了對實時數據流的高吞吐量處理。雖然其延遲性相對較高，但它能夠保證消息傳輸的可靠性和完整性，適用于需要處理大規模數據流且對數據準確性要求較高的應用場景。

Flink

真正的流處理框架（DataFlowModel）。
延遲性較低（毫秒級），且能夠保證消息傳輸不丟失不重復。
具有非常高的吞吐。
支持原生流處理。

1. 真正的流處理框架

Flink 是一個真正的流處理框架，基于 DataFlow Model。它能夠處理任何類型的數據流，無論是有界還是無界的數據流。Flink 的核心是其數據流模型，它將數據視為連續的事件流，并在這些事件到達時進行實時處理。Flink 支持實時數據流和歷史數據流的處理，適用于多種應用場景，如實時數據分析、ETL（Extract, Transform, Load）、機器學習和事件驅動應用等。

2. 低延遲特性

Flink 的延遲性較低，可以達到毫秒級。它通過高效的數據處理引擎和優化的執行計劃，能夠在處理大規模數據流時保持低延遲。Flink 的這種低延遲特性使其適用于需要快速響應的實時應用場景，如網絡安全監測、電商推薦系統和物聯網數據分析等。

3. 消息保障能力強

Flink 能夠保證消息傳輸既不會丟失也不會重復。它通過 Checkpoint 和 WAL 機制來實現這一點。Checkpoint 機制定期將應用狀態持久化到外部存儲系統，如 HDFS、S3 等，從而在發生故障時能夠快速恢復應用狀態，確保數據的完整性和一致性。WAL 機制確保即使在數據接收過程中發生故障，數據也不會丟失。

4. 高吞吐量

Flink 具有非常高的吞吐量。它利用分布式計算和內存計算特性，能夠高效地處理大規模的數據流。Flink 的架構設計使其能夠充分利用集群資源，實現數據的并行處理。此外，Flink 還支持多種優化策略，如數據分區、窗口操作等，以進一步提高數據處理的效率。

5. 支持原生流處理

Flink 支持原生流處理，即單事件來處理數據流。Flink 的 DataStream API 允許開發人員直接操作數據流，進行各種轉換操作，如 map、filter、keyBy、window、reduce 等。這種原生流處理能力使得 Flink 能夠高效地處理無界和有界的數據流，適用于需要實時響應的應用場景。

總結

Apache Flink 是一個功能強大的流處理框架，適用于各種實時數據處理場景。它通過 DataFlow Model 實現了真正的流處理，具有低延遲、高吞吐量和強大的消息保障能力。Flink 的原生流處理支持和靈活的 API 設計使其成為大數據處理的重要工具，能夠滿足不同應用場景的需求。

為什么選擇Flink？

我們通常會從下面四個方面去考察一個流式處理技術是否滿足我們的要求：

• 處理延遲
  我們需要考察這個技術，能否達到我們預期的延時去處理對應的數據。
• 吞吐量
  除了時效性，我們還需要關注這個技術，是不是能夠達到業務需要的，比如每秒千萬級別的吞吐量。
• 準確性
  當然，實時數據處理場景最重要的還是看，這個技術能否達到Exactly-once，也就是數據既不丟失也不重復的這樣一個數據準確性保障。
• 易用性
  最后就是看這個技術，是否提供一些類似于SQL的，能極大提到易用性的開發能力。

對于Storm和Spark Streaming來說，它們都不能在以上四個方面做到完美，而Flink能夠做到低延遲、高吞吐以及達到Exactly-once的準確性，同時還提供了不同抽象級別的能力供用戶使用開發。所以它對于其他的一些流處理框架，具有非常高的一個優勢，這也是它成為目前業界最主流的流處理技術的原因。

Flink發展時間線及重大變更

Flink最早是德國一些大學中的研究項目，并且早期項目名稱也不是Flink，在2010~2014年間，由德國柏林工業大學、德國柏林洪堡大學和德國哈索·普拉特納研究所聯合發起名為"Stratosphere:Information Management on the Cloud"研究項目，該項目就是Flink的前身：Stratosphere項目。該項目創建初衷就是構建一個一數據庫概念為基礎、以大規模并行處理架構為支撐、以MapReduce計算模型為邏輯框架的分布式數據計算引擎，在此構想之上還引入了流處理，為后來的Flink發展打下良好基礎。

2014年4月，Stratosphere代碼被貢獻給Apache軟件基金會，成為Apache基金會孵化器項目，項目孵化期間，項目Stratosphere改名為Flink。Flink在德語中意為"敏捷、快速"，用來體現流式 數據處理器速度快 和 靈活性強 等特點，同時使用棕紅色松鼠圖案作為Flink項目的Logo，也是為了突出松鼠靈活快速的特點，由此，Flink正式進入社區開發者的視線。

Flink自從加入Apache后發展十分迅猛，自2014年8月發布0.6版本后，Flink僅用了3個月左右的時間，在2014年11月發布了0.7版本，該版本包含Flink目前為止最重要的 Flink Streaming 特性，2014年底，Flink順利從孵化器"畢業"成為Apache頂級項目。隨著Flink技術成為Apache頂級項目，Flink受到社區越來越多的關注，Flink逐步增加了很多核心的功能，例如：一致性語義、事件時間和Table API等，其功能和穩定性也不斷得到完善。

早期Stratosphere項目的核心成員曾共同創辦一家名叫"Data Artisans"的公司，其主要的任務就是致力于Flink技術的發展和商業化，2019年阿里巴巴收購了Data Artisans公司，并將其開發的分支Blink開源，越來越多的公司開始將Flink應用到他們真實的生產環境中，并在技術和商業上共同推動Flink的發展。

Flink逐步被廣泛使用不僅僅是因為 Flink支持高吞吐、低延遲和exactly-once語義的實時計算，同時Flink還提供基于流式計算引擎處理批量數據的計算能力，在計算框架角度真正實現了批流統一處理。

Flink發展非常迅速，目前官網Flink最新版本是2.0.0 版本，下面列舉Flink發展過程中重要時間和重要版本發布時間點以及Flink各個版本推出的新特性以幫助大家更好了解Flink：

• 2019-08-22：Flink 1.9.0 版本發布，主要特性如下：

  • 合并阿里內部Blink；

  • 重構Flink WebUI；

  • Hive集成；

  • Python Table API支持；

• 2020-02-11：Flink 1.10.0 版本發布，主要特性如下：

  • 整合Blink全部完成；

  • 集成K8S；

  • PyFlink優化；

  • 內存管理配置優化；

• 2020-07-06：Flink 1.11.0 版本發布，主要特性如下：

  • 從Flink1.11開始,Blink planner是Table API/SQL中的默認設置，仍支持舊的Flink planner；

  • Flink CDC支持；

  • 支持Hadoop3.x版本，不提供任何更新的flink-shaded-hadoop-x jars，用戶需要通過HADOOP_CLASSPATH環境變量（推薦）或 lib/ folder 提供 Hadoop 依賴項。

• 2020-12-08：Flink 1.12.0 版本發布，主要特性如下：

  • DataStream API 上添加了高效的批執行模式的支持，批處理和流處理實現真正統一的運行時的一個重要里程碑；

  • 實現了基于Kubernetes的高可用性（HA）方案，作為生產環境中，ZooKeeper方案之外的另外一種選擇；

  • 擴展了 Kafka SQL connector，使其可以在 upsert 模式下工作，并且支持在 SQL DDL 中處理 connector 的 metadata；

  • PyFlink 中添加了對于 DataStream API 的支持；

  • 支持FlinkSink，不建議再使用StreamingFileSink；

• 2021-04-30：Flink 1.13.0 版本發布，主要特性如下：

  • SQL和表接口改進；

  • 改進DataStream API和Table API/SQL之間的互操轉換；

  • Hive查詢語法兼容性；

  • PyFlink的改進；

• 2021-09-29：Flink1.14.0 版本發布，主要特性如下：

  • 改進批和流的狀態管理機制;

  • 優化checkpoint機制;

  • 不再支持Flink on Mesos資源調度；

  • 開始支持資源細粒度管理；

• 2022-05-05：Flink1.15.0 版本發布，主要特性如下：

  • Per-job任務提交被棄用，未來版本會丟棄，改用Application Mode。

  • Flink依賴包不使用Scala的話可以排除Scala依賴項，依賴包不再包含后綴；

  • 持續改進Checkpoint和兩階段提交優化；

  • 對于Table / SQL用戶，新的模塊flink-table-planner-loader取代了flink-Table-planner_xx，并且避免了Scala后綴的需要；

  • 添加對opting-out Scala的支持,DataSet/DataStream api獨立于Scala,不再傳遞地依賴于它。

  • flink-table-runtime不再有Scala后綴了；

  • 支持JDK11,后續對JDK8的支持將會移除；

  • 不再支持Scala2.11，支持Scala2.12；

  • Table API & SQL優化，移除FlinkSQL upsert into支持；

  • 支持最低的Hadoop版本為2.8.5；

  • 不再支持zookeeper3.4 HA ,zookeeper HA 版本需要升級到3.5/3.6；

  • Kafka Connector默認使用Kafka客戶端2.8.1；

• 2022-10-28：Flink1.16.0 版本發布，主要特性如下：

  • 棄用jobmanager.sh腳本中的host/web-ui-port參數，支持動態配置；

  • 刪除字符串表達式DSL;

  • 不再支持Hive1.x、2.1.x、2.2.x版本；

  • 棄用StreamingFileSink，建議使用FileSink。

  • 優化checkpoint機制；

  • PyFlink1.16將python3.6版本標記為棄用，PyFlink1.16版本將成為使用python3.6版本最后一個版本；

  • Hadoop支持3.3.2版本；

  • Kafka支持3.1.1版本；

  • Hive支持2.3.9版本；

• 2023-03-23：Flink 1.17.0版本發布，主要特性如下：

  • Streaming Warehouse API: FLIP-282 在 Flink SQL 中引入了新的 Delete 和 Update API，它們可以在 Batch 模式下工作。在此基礎上，外部存儲系統比如 Flink Table Store 可以通過這些新的 API 實現行級刪除和更新。同時對 ALTER TABLE 語法進行了增強，包括 ADD/MODIFY/DROP 列、主鍵和 watermark 的能力，這些增強使得用戶更容易維護元數據。

  • Batch 性能優化: 在 Flink 1.17 中，批處理作業的執行在性能、穩定性和可用性方面都得到了顯著改進。就性能而言，通過策略優化和算子優化，如新的 join-reorder 算法和自適應的本地哈希聚合優化、Hive 聚合函數改進以及混合 shuffle 模式優化，這些改進帶來了 26% 的 TPC-DS 性能提升。就穩定性而言，Flink 1.17 預測執行可以支持所有算子，自適應的批處理調度可以更好的應對數據傾斜場景。就可用性而言，批處理作業所需的調優工作已經大大減少。自適應的批處理調度已經默認開啟，混合 shuffle 模式現在可以兼容預測執行和自適應批處理調度，同時所需的各種配置都進行了簡化。

  • SQL Client/Gateway: Apache Flink 1.17 支持了 SQL Client 的 gateway 模式，允許用戶將 SQL 提交給遠端的 SQL Gateway。同時，用戶可以在 SQL Client 中使用 SQL 語句來管理作業，包括查詢作業信息和停止正在運行的作業等。這表示 SQL Client/Gateway 已經演進為一個作業管理、提交工具。

  • Streaming SQL 語義增強: 非確定性操作可能會導致不正確的結果或異常，這在 Streaming SQL 中是一個極具挑戰性的話題。Flink 1.17 修復了不正確的優化計劃和功能問題，并且引入了實驗性功能 PLAN_ADVICE，PLAN_ADVICE 可以為 SQL 用戶提供潛在的正確性風險提示和 SQL 優化建議。

  • Checkpoint 改進: 通用增量 Checkpoint（GIC）增強了 Checkpoint 的速度和穩定性，Unaligned Checkpoint (UC) 在作業反壓時的穩定性也在 Flink 1.17 中提高至生產可用級別。此外，該版本新引入一個 REST API 使得用戶可以觸發自定義 Checkpoint 類型的 Checkpoint。

  • Watermark 對齊完善: 高效的 watermark 處理直接影響 event time 作業的執行效率，在 Flink 1.17 中， FLIP-217 通過對 Source 算子內部的 split 進行數據對齊發射，完善了 watermark 對齊功能。這一改進使得 Source 中 watermark 進度更加協調，從而減輕了下游算子的緩存過多數據，增強了流作業執行的整體效率。

  • StateBackend 升級: 此次發布將 FRocksDB 的版本升級到了 6.20.3-ververica-2.0，對 RocksDBStateBackend 帶來了許多改進。同時，例如在插槽之間共享內存，并且現在支持 Apple Silicon 芯片組，如 Mac M1。Flink 1.17 版本還提供了參數擴大 TaskManager 的 slot 之間共享內存的范圍，提升了 TaskManager 中 slot 內存使用不均是的效率。

• 2023-10-25：Flink 1.18.0版本發布，主要特性如下：

  • Flink SQL 提升

  • 流處理提升

  • 批處理提升

  • Java 17 支持

  • SourceFunction現在已經棄用。如果您仍在使用基于 SourceFunction 構建的連接器，請將其遷移到 Source。SinkFunction 目前尚未正式棄用，但它也即將接近生命周期結束，將被 SinkV2 所取代。

  • Queryable State現已棄用，將在 Flink 2.0 中移除。

  • DataSet API現已棄用。建議用戶遷移到執行模式設置為 BATCH 的 DataStream API。

• 2024-03-18：Flink 1.19.0版本發布，主要特性如下：

  • Flink SQL 提升

  • Runtime & Coordination 提升

  • Checkpoints 提升

  • Connector API提升

• 2024-08-02：???????Flink 1.20.0版本發布，主要特性如下：

  • 引入物化表

  • 完善 Catalog 相關語法

  • DDL 支持 DISTRIBUTED BY 語句

  • 統一的檢查點文件合并機制

  • 壓縮小的 SST 文件

  • JobMaster 發生故障時更好的錯誤恢復機制

  • HiveSource 支持動態并發推斷

  • 支持 DataStream API 上的全量分區數據處理

• 2024-10-23：???????Flink 2.0-preview1發布；2025-03-24：Flink 2.0.0 發布，這是自 Flink 1.0 發布以來的首次重大更新。主要特性如下：

  • 存算分離狀態管理：引入了基于遠程存儲的存算分離狀態管理，解決了容器化環境下計算節點受本地磁盤大小限制的問題，以及 RocksDB 中 LSM 結構的周期性 Compaction 導致計算資源尖峰的問題。

  • 物化表：增強了物化表功能，支持與主流的湖格式集成以及生產就緒的調度器實現。

  • 批作業的自適應執行：具備基于作業已完成階段的信息，對邏輯計劃和物理計劃進行動態優化的能力，初步支持的策略包括動態應用 Broadcast Join 以及對數據傾斜的 Join 進行優化。

  • 流式湖倉：Flink 和 Apache Paimon 的集成邁出了重要一步，帶來了諸多重要改進，如使用 Paimon 豐富的合并引擎進行 SQL 執行計劃優化、大幅提升 Lookup-Join 的性能、支持 Flink 物化表、以及對自適應批處理和推測執行的支持。