簡介：2020 年是 Apache Flink 社區生態加速繁榮的一年。

本文由 Apache Flink 中文社區發起人，阿里云計算平臺事業部實時計算與開放平臺部門負責人王峰分享，主要介紹 Flink 作為一款統一的流批一體引擎其發展現狀及未來規劃。大綱如下：

2020：Apache Flink 社區生態加速繁榮的一年

技術創新：Apache Flink 社區發展的核心驅動力

Flink 在阿里巴巴的現狀和未來

2020：Apache Flink 社區生態加速繁榮的一年

1.Flink 蟬聯 Apache 社區最活躍項目

我們先來介紹一下在 2020 年 Flink 社區生態發展的態勢。整體來說，社區處在一個非常健康和高速的發展過程中，尤其是在 2020 年，我們取得了非常好的成果。從 Apache 軟件基金會 2020 財年的報告中，可以看到一些很關鍵的數據：

• Flink 用戶和開發者郵件列表活躍度 Top1
• Github 上 Flink 代碼提交次數 Top2
• Github 上 Flink 的用戶訪問量 Top2

綜合這幾個數據來看，可以認為 Flink 在 Apache 眾多的開源項目中名列前茅，是 Apache 最活躍的項目之一。我們在 Github 上 Star 的數量，以及 Flink 貢獻者數量的增長趨勢也是非常喜人的。最近幾年來，我們一直處在一個加速上漲的過程，每年都是平均 30% 以上的數據增長，可以看出 Flink 整個生態的繁榮和高速發展。

2.Apache Flink 年度發布總結

我們再回顧一下 2020 年整個社區在技術上取得的成果。Flink 社區在 2020 年發布了三個大的版本， Flink-1.10，Flink-1.11，以及 12 月最新發布的 Flink-1.12 三大版本。這三個版本相對于去年收官的版本 Flink-1.9 有非常大的進步。

在 Flink-1.9 中，我們完成了將 Blink 代碼貢獻合并進入 Flink 社區，使得 Flink 流批一體架構正式啟動。今年我們又通過 1.10、1.11、1.12 這三個版本對 Flink 流批一體架構做了重要的升級和落地。同時在 Flink SQL 的開發場景下，我們不僅支持了流批一體的 SQL，同時也支持讀取數據庫 binlog 的 CDC，并且對接了新一代數據湖的架構。Flink 在 AI 場景下的應用也越來越廣泛，所以我們在 Python 語言上也提供了大量支持，PyFlink 已經可以完整的支持 Flink 的開發。在 K8s 的生態上，我們也做了很多的工作。

Flink 經過今年三個版本的迭代以后，已經可以完整的以云原生的方式運行在 K8s 的生態之上，去除了對 Hadoop 的依賴。以后在 K8s 生態之上也可以使 Flink 的部署與其他的在線業務進行更好的混布。

3.Apache Flink 中文社區持續火熱

在此也跟大家分享一下 Flink 中文社區的發展。

首先，從郵件列表來看，Flink 項目可能是 Apache 頂級項目中唯一一個開通中文用戶郵件列表的項目。Apache 作為一個國際化的軟件基金會，基本上以英文交流的方式為主，由于 Flink 在中國的活躍度空前，所以我們也開通了中文郵件列表。目前中文郵件列表的活躍度甚至已經超過英文郵件列表，成為全球 Flink 最活躍的地區。

其次，社區也開通了 Flink 的中文社區公眾號（上圖左側），每周推送社區資訊、活動信息、最佳實踐等內容為開發者提供了解社區進展的窗口，目前超過 3 萬名活躍的開發者訂閱我們，全年推送超過 200 篇與 Flink 技術，生態以及實踐相關的最新資訊。

前段時間，我們還推出了 Flink 社區官方中文學習網站（https://flink-learning.org.cn/），希望幫助更多的開發者方便的學習 Flink 技術，了解 Flink 的行業實踐，同時我們的 Flink 社區的釘釘大群也為大家提供了技術交流的平臺，歡迎大家加入，進行技術的交流。

4.Apache Flink 成為實時計算事實標準

現在 Flink 已經成為了實時計算事實上的標準，我相信目前國內外各種主流的 IT 或科技驅動的公司，都已采用 Flink 做實時計算。Flink Forward Asia 2020 也邀請到了 40 多家國內外一流公司分享他們的 Flink 的技術和實踐，非常感謝這些公司的講師們、專家們來分享。我相信未來各行各業會有更多的公司采用 Flink 去解決實時數據的問題。

技術創新：Apache Flink社區發展的核心驅動力

1. 流計算引擎的內核技術創新

接下來主要跟大家介紹技術方面 Flink 社區在 2020 年的發展。我們相信技術創新是開源項目、開源社區持續發展的核心驅動力。這部分將分為三個方向來分享，首先介紹一下 Flink 在流計算引擎內核的一些技術創新。

Unaligned Checkpoint - 優化加速

第一個例子是非對齊式的 Checkpoint。Checkpoint 技術需要不斷的在實時的數據流中插入 barrier，做定期的 snapshot，這是 Flink 最基本的理念之一。在現有的 Checkpoint 模式下，因為需要對齊 barrier，所以在反壓或者數據計算壓力非常大的情況下，Checkpoint 有可能是做不出來的。所以我們今年在 Flink 社區里做了一個非對齊的 Checkpoint，使得在反壓的情況下，Checkpoint 也能夠比較快速的做出來。

非對齊的 Checkpoint 和現有的對齊的 Checkpoint 可以通過設置 alignment timeout 進行自動切換：正常情況下做對齊式 Checkpoint，而在反壓的時候切換到非對齊的 Checkpoint。

Approximate Failover – 更加靈活的容錯模式

第二個技術創新是在容錯方面。眾所周知，Flink 的數據是支持強一致性（exactly-once）的。但是為了保證強一致性，其實在整個系統的可用性上有一些 trade off。為了保證數據強一致性，任何一個 Flink 節點的失敗都會導致 Flink 全部節點回滾到上一次的 Checkpoint，在這個過程中需要進行整個 DAG 圖的重啟。在重啟的過程中業務會有一個短時間的中斷和回滾。其實很多場景對數據的強一致性不是必須的，對于少量數據的損失是可以接受的。對于一些采樣數據的統計或者機器學習場景下特征計算，并不是說一條數據都不能丟，這些應用場景反而對數據的可用性有更高的要求。

所以我們在社區里創新做一種新的容錯模式，Approximate Failover，一個更加靈活的容錯模式，使得任何一個節點失敗，只對這個節點本身進行重啟和恢復，這樣的話整個圖不用重啟，也就是說整個的數據流程不會中斷。

Nexmark - Streaming Benchmark

同時，我們在流計算方向發現缺乏一個比較標準的 Benchmark 工具。在傳統的批計算中，有各種 TPC Benchmark 可以比較完善的覆蓋傳統批計算的場景。而在實時流計算場景下則缺乏標準的 Benchmark。基于 Nexmark 的一篇論文，我們推出了第一版包含 16 個 SQL Query 的 benchmark 工具 Nexmark。Nexmark 有三個特點：

第一， 覆蓋場景更全面

• 基于在線拍賣系統業務模型設計
• 16 個 Query，全面覆蓋常用流計算場景
• ANSI SQL，標準化，更容易擴展

第二， 更加方便易用

• 純內存數據源生成器，靈活調控負載
• 無外部系統依賴
• 性能指標采集自動化

第三，開源，開放

Nexmark 已經開源 https://github.com/nexmark/nexmark，大家如果希望比對不同 Flink 版本之間流引擎的差異，或者對比不同的流計算引擎之間的差異，都可以采用這個工具。

2.Flink 架構的演進

全新的流批一體架構

再介紹一下 Flink 架構的演進，Flink 是一個流計算驅動的引擎，它的核心是 Streaming。但是它可以基于 Streaming 的內核，實現流批一體更全能的架構。

2020 年，Flink 在流批一體上走出了堅實的一步，可以抽象的總結為 Flink 1.10 和 1.11 這兩個大的版本，主要是完成 SQL 層的流批一體化和實現生產可用性。我們實現了統一的流批一體的 SQL 和 Table 的表達能力，以及統一的 Query Processor，統一的 Runtime。

在剛發布的 1.12 版本中，我們也對 DataStream API 進行了流批一體化。在 DataStream 原生的流的算子上增加批的算子，也就是說 DataStream 也可以有兩種執行模式，批模式和流模式里面也可以混合批算子和流算子。

正在規劃的 1.13 的版本中，會徹底實現 DataStream 流批一體化的算子，整個的計算框架和 SQL 一樣，完全都是流批一體化的計算能力。這樣一來，原來 Flink 中的 DataSet 這套老的 API 就可以去掉，完全實現真正的流批一體的架構。

在全新的流批一體的架構之下，整個 Flink 的機制也更加清晰。我們有兩種 API，一個是 Table 或者 SQL 的關系型 API，還有 DataStream 這種可以更靈活控制物理執行的 API。無論是高層的 API（Table 或者 SQL），還是低級的 API（DataStream），都可以實現流批一體的統一表達。我們還可以將用戶的需求表達的圖轉換為一套統一的執行 DAG 圖。這套執行 DAG 圖中，可以使用 Bounded Stream，也可以使用 Unbounded Stream，也就是有限流和無限流兩種模式。我們的 Unified Connector 的框架也是流批一體的統一框架：可以讀流式的存儲，也可以讀批式的存儲，整個架構將會把流和批真正融為一體。

在核心的 Runtime 層也實現了流批一體。調度和 Shuffle 是 Runtime 層最核心的兩部分。在調度層支持 Pluggable 的插件機制，可以實現不同的調度策略應對流、批、甚至流批混合的場景。在 Shuffle Service 層面，也支持流式和批式的 Shuffle。

同時我們正在做更新一代的 Shuffle Service 的框架：Remote Shuffle Service。Remote Shuffle Service 可以部署到 K8s 里面，實現存儲計算的分離。就是說，Flink 的計算層和 Shuffle 類似于一個存儲服務層，完全解耦的部署，讓 Flink 的運行更加具有靈活性。

TPC-DS Benchmark

批的性能究竟如何是大家比較關心的一個問題。經過三個版本的努力之后，Flink-1.12 比 Flink-1.9（去年的版本）已經有三倍的提升。可以看到，在 10TB 數據量，20 臺機器的情況下，我們的 TPC-DS 的運行時間已經收斂到 1 萬秒以內了。所以 Flink 的批處理性能已經完全達到生產標準，不亞于任何一個業界目前主流的批處理引擎。

流批一體數據集成

流批一體不只是一個技術上的問題，我想更詳細的解釋一下流批一體架構到底怎么去改變在不同典型場景下的數據處理的方式和數據分析的架構。

我們先看第一個，在大數據場景下經常需要數據同步或者數據集成，也就是將數據庫中的數據同步到大數據的數倉或者其他存儲中。上圖中的左邊是傳統的經典數據集成的模式之一，全量的同步和增量的同步實際上是兩套技術，我們需要定期將全量同步的數據跟增量同步數據做 merge，不斷的迭代來把數據庫的數據同步到數據倉庫中。

但基于 Flink 流批一體的話，整個數據集成的架構將截然不同。因為 Flink SQL 也支持數據庫（像 MySQL 和 PG）的 CDC 語義，所以可以用 Flink SQL 一鍵同步數據庫的數據到 Hive、ClickHouse、TiDB 等開源的數據庫或開源的 KV 存儲中。在 Flink 流批一體架構的基礎上，Flink 的 connector 也是流批混合的，它可以先讀取數據庫全量數據同步到數倉中，然后自動切換到增量模式，通過 CDC 讀 Binlog 進行增量和全量的同步，Flink 內部都可以自動的去協調好，這就是流批一體的價值。

基于 Flink 的流批一體數倉架構

第二個變化，數倉架構。目前主流數倉架構都是一套典型的離線數倉和一套新的實時數倉，但這兩套技術棧是分開的。在離線數倉里，大家還是習慣用 Hive 或者 Spark，在實時數倉中用 Flink 加 Kafka。但是這個方案總結下來有三個問題需要解決：

• 兩套開發流程，成本高。
• 數據鏈路冗余。數倉的經典架構大家都知道，ODS 層，DWD 層，DWS 層。在 DWD 的明細層可以看到實時數倉和離線數倉經常做的是一模一樣的事情，如數據清洗、數據補齊、數據過濾等，兩套鏈路將上面的事情做了兩遍。
• 數據口徑的一致性難以保證。實時報表需要實時觀看，同時每天晚上會再做一次離線報表用于第二天分析。但是這兩份報表的數據在時間的維度上可能是不一致的，因為它是由兩套引擎算出來的，可能有兩套用戶代碼，兩套 UDF，兩套 SQL，兩套數倉的構建模型，在業務上造成了巨大的困惑，很難通過資源或人力來彌補。

如果用新的流批一體架構來解決，以上難題將極大降低。

• 首先，Flink 是一套 Flink SQL 開發，不存在兩套開發成本。一個開發團隊，一套技術棧，就可以做所有的離線和實時業務統計的問題。
• 第二，數據鏈路也不存在冗余，明細層的計算一次即可，不需要離線再算一遍。
• 第三，數據口徑天然一致。無論是離線的流程，還是實時的流程，都是一套引擎，一套 SQL，一套 UDF，一套開發人員，所以它天然是一致的，不存在實時和離線數據口徑不一致的問題。

基于 Flink 的流批一體數據湖架構

再往前走一步，我們通常會把數據落到 Hive 存儲層，但是當數據規模逐漸的增大，也存在一些瓶頸。比如說數據文件規模增大以后，元數據的管理可能是瓶頸。還有一個很重要的問題，Hive 不支持數據的實時更新。Hive 沒有辦法實時，或者準實時化地提供數倉能力。現在比較新的數據湖架構，在一定程度上可以解決 Hive 作為數倉的問題。數據湖可以解決這種更具擴展性的元數據的問題，而且數據湖的存儲支持數據的更新，是一個流批一體的存儲。數據湖存儲與 Flink 結合，就可以將實時離線一體化的數倉架構演變成實時離線一體化的數據湖架構。比如：

Flink + Iceberg：

• 通用化設計，解耦計算引擎，開放數據格式
• 提供基礎 ACID 保證以及 Snapshot 功能
• 存儲流批統一，支持批量和細粒度更新
• 低成本的元數據管理
• 0.10 已發布 Flink 實時寫入和批量讀取分析功能
• 0.11 規劃自動小文件合并和 Upsert 支持。

另外，Flink 跟 Hudi 的整合，我們也在跟 Hudi 社區做比較密切的合作，未來的幾個月我們將會推出 Flink 加 Hudi 的完整的解決方案。

Flink + Hudi：

• Upsert 功能支持較為成熟
• Table 組織方式靈活（根據場景選擇 copy on write 還是 merge on read）
• Flink 與 Hudi 的集成正在積極對接中

3.大數據與AI一體化

最后一個主流技術方向就是 AI，現在 AI 是非常火的一個場景，同時 AI 對大數據存在著很強的算力需求。接下來跟大家分享 Flink 在 AI 場景下，社區做的一些事情，以及未來的規劃。

PyFlink 逐步走向成熟

首先我們看一下語言層，因為 AI 的開發者很喜歡用 Python，所以 Flink 提供了 Python 語言的支持，在 2020 年社區做了很多的工作，我們的 PyFlink 項目也取得了很多的成果。

Python 版本的 Table 和 DataStream API：

• Python UDX 支持 logging、metrics 等功能，方便作業調試及監控
• 用戶可以用純 Python 語言開發 Flink 程序

SQL 中支持 Python UDX：

• 包括 Python UDF、Python UDTF 以及 Python UDAF
• SQL 開發人員也可以直接使用 Python 庫

增加 Pandas 類庫支持：

• 支持 Pandas UDF、Pandas UDAF 等功能
• 支持 Python Table 與 Pandas DataFrame 的互轉
• 用戶可以在 Flink 程序中使用 Pandas 類庫。

Alink 新增數十個開源算法

在算法層面，阿里巴巴去年（2019）開源了 Alink，一套在 Flink 上的流批一體的傳統機器學習算法。今年阿里巴巴的機器學習團隊也在 Alink 上繼續開源數 10 種新的算法，去解決更多場景下的算法組件的問題，進一步提升機器學習的開發體驗。我們希望未來隨著 Flink 新的 DataStream 的 API 也支持流批一體的迭代能力，我們會將 Alink 基于新的 DataStream 上面的迭代能力貢獻到 Flink 的機器學習中，讓標準的 Flink 機器學習能有一個比較大的突破。

大數據與 AI 一體化流程管理

大數據與 AI 一體化是最近很值得探討的問題之一。大數據和 AI 技術是水乳交融的。通過大數據加 AI 的很多核心技術一體化，去解決整個在線的，比如實時推薦，或者其他的在線機器學習的一套完整流程。在這個過程中，大數據側重的是數據處理、數據驗證、數據分析，而 AI 的技術更側重于模型的訓練、模型的預測等等。

但這一整套的過程，其實要大家合力才能去真正解決業務的問題。阿里巴巴有很強的基因來做這件事情，Flink 最早誕生于搜索推薦場景，所以我們的在線搜索、在線推薦就是用 Flink 加 TensorFlow 的技術來實現的后臺機器學習流程。我們也將阿里積累的這套流程做了一個抽象，把業務屬性的東西全部去掉，只把開源的純技術體系留下，它抽象成一套標準的模板，標準的解決方案，并開源出來，叫 Flink AI Extended。這個項目主要由兩個部分來組成。

第一，Deep Learning on Flink: Flink 計算引擎和深度學習引擎集成

• Tensorflow / PyTorch on Flink
• 大數據計算任務和機器學習任務無縫對接。

第二， Flink AI Flow: 基于 Flink 的實時機器學習工作流

• 基于事件的流批混合工作流
• 大數據與機器學習全鏈路一體化。

我們希望通過開源主流的大數據加 AI 的技術體系，大家都可以快速的應用到業務場景中，做出來一套在線機器學習業務，比如實時推薦等。這個項目目前也是非常靈活，它可以運行 Standalone 單機版，也可以運行在 Hadoop YARN，或者 Kubernetes 上。

Flink Native on K8S

K8s 是現在標準化的一個行為，云原生。我們相信 K8s 的未來會更加的廣闊，起碼 Flink 一定要支持在 K8s 之下原生的運行，實現云原生的部署模式。經過今年三個版本的努力，我們已經支持原生的將 Flink 部署到 K8s 里面。Flink 的 job manager 可以跟 K8s 的 master 進行直接通信，動態的申請資源，根據運行的負載動態擴縮容。同時我們完全對接了 K8s 的 HA 方案，也支持 GPU 的調度和 CPU 的調度。所以現在 Flink Native on K8S 這個方案已經非常成熟，如果企業對 Flink 在 K8s 部署上有訴求，可以使用 Flink-1.12 這個版本。

Flink 在阿里巴巴的現狀和未來

技術的創新和技術的價值一定要靠業務去檢驗，業務價值是最終的判定標準。阿里巴巴不僅是 Apache Flink 最大的推動者和支持者，同時也是最大的用戶。下面介紹 Flink 在阿里應用的現狀以及后續規劃。

1.Flink 在阿里巴巴的發展歷程

首先看一下 Flink 在阿里巴巴的成長路線，還是非常有節奏的。

• 2016 年，我們將 Flink 大規模運行在雙 11 場景，最早的是在搜索推薦的落地，支持了搜索推薦的全鏈路實時化，以及在線學習的實時化。
• 2017 年，我們認定 Flink 作為一個全集團級別的實時數據處理引擎，支持整個阿里巴巴集團的業務。
• 2018 年，我們開始上云，第一次通過將 Flink 推到云上，去積累技術，服務更多中小企業。
• 2019 年，我們向國際化邁進了一步，收購了 Flink 的創始公司，阿里巴巴投入了更多的資源和人力去推動 Flink 社區的發展。

到今年，我們已經看到 Flink 成為了一個實時計算事實上的國際的標準。在全球，許多云廠商和大數據的軟件廠商都已經將 Flink 內置到他們的產品里，成為標準云產品的形態之一。

2.雙十一全鏈路數據實時化

今年雙 11，基于 Flink 的實時計算平臺在阿里內部已經完整的支持了所有場景的實時數據的業務。在數據規模上，已經有超過數百萬的 CPU Core 在運行。今年在資源基本上沒有增加的情況下，計算能力相對去年有一倍的增長。同時，通過技術優化，實現了整個阿里經濟體的全鏈路數據實時化。

3.“全鏈路數據實時化” to ”實時離線一體化”

全鏈路數據實時化不是我們的終點，下一步是實現實時離線一體化的訴求。在電商大促的場景下，需要對實時數據與離線數據做對比，如果實時和離線的數據不一致，或者不知道是不是一致的，那就會對業務造成很大的干擾，業務沒有辦法判斷到底是技術上的誤差導致的結果不符合預期，還是業務效果真的不符合預期。所以今年雙 11，阿里巴巴第一次大規模落地流批一體的場景以及實時離線一體化業務場景。

今年雙 11 流批一體的落地場景是天貓的雙11營銷大屏分析。通過大屏數據分析，可以看到不同的維度的數據，對比雙11當天用戶的交易量和一個月前、甚至去年雙 11，它的增長是否符合預期。我們能確保流批結果是一致的。

此外，我們結合了阿里巴巴自研的 Hologres 流批一體的存儲能力，加上 Flink 流批一體的計算能力，實現了全鏈路的流批一體的數據架構，以及整個業務架構。在此架構下，我們不僅保持數據天然的一致性，業務上沒有了干擾，同時我們使淘寶的小二開發數據報表的開發效率提升了 4~10 倍。

另一方面，Flink 的流任務和批任務運行在一個集群里，雙11當天巨大的流量到了晚上可能會變成一個波谷，這時我們會運行大量離線的批的分析任務，為第二天的報表做準備。所以削峰填谷的應用使我們的資源節省了一倍，這是一個非常可觀的數據。

目前，除了阿里巴巴外，社區上也有諸多合作密切的伙伴如字節跳動、小米、網易、知乎等在探索使用 Flink 做流批一體統一架構的方案。我相信 2020 年是 Flink 新一代數據架構落地的元年，從全鏈路數據實時化走向實時離線一體化的元年，并且阿里巴巴已經在最核心的雙 11 業務場景下進行了落地。

明年，會有更多的企業嘗試，并貢獻社區完善新架構，推動社區朝著新方向：流批一體化、離線實時一體化、大數據與 AI 一體化演進。真正讓技術創新服務好業務，改變大數據處理架構、大數據與 AI 融合的方式，在各行各業釋放其價值。

原文鏈接：https://developer.aliyun.com/article/781348?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的蝉联 Apache 最活跃项目，Flink 社区是如何保持高速发展的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。