本文由 Apache Flink 中文社群發起人，阿裡雲計算平台事業部實時計算與開放平台部門負責人王峰分享，主要介紹 Flink 作為一款統一的流批一體引擎其發展現狀及未來規劃。大綱如下：
- 2020：Apache Flink 社群生态加速繁榮的一年
- 技術創新：Apache Flink 社群發展的核心驅動力
- 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 這個版本。
技術的創新和技術的價值一定要靠業務去檢驗，業務價值是最終的判定标準。阿裡巴巴不僅是 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 融合的方式，在各行各業釋放其價值。