投入上百人、經歷多次雙 11，Flink 已經足夠強大了嗎？

作為最活躍的大資料專案之一，Flink 進入 Apache 軟體基金會專案已經有八年了。

Apache Flink 是一款實時大資料分析引擎，同時支援流批執行模式，並與 Hadoop 生態可以無縫對接。2014 年，它被接納為 Apache 孵化器專案，僅僅幾個月後，它就成為了 Apache 專案。

對於 Flink 來說，阿里有非常適合的流式場景。作為 Flink 的主導力量，阿里從 2015 年開始調研 Flink，並於 2016 年第一次在搜尋場景中上線 Flink。在落地的同時，阿里對 Flink 進行大量的修改和完善，讓其適應超大規模業務場景。2017 年，阿里已成為 Flink 社群最大規模使用者，Flink 團隊也達上百人。這其中的一些早期改進，阿里在 2018 年的文章《Flink 已經足夠強大了嗎?阿里巴巴說：還不夠》中已有詳盡解讀。

2019 年，阿里宣佈收購了 Flink 背後的企業，並正式開源內部 Flink 版本 Blink，貢獻了超百萬行程式碼，極大地推動了社群的良性發展。在 2021 年雙 11 中，Flink 承載的實時計算峰值達到了每秒 40 億條記錄，資料體量也達到 7 TB 每秒，相當於一秒鐘需要讀完 500 萬本《新華字典》。

這幾年，Flink 社群在國內外技術會議上不斷宣傳推廣，讓 Flink 得到大量採用，各種應用場景也變得更加廣泛，生態快速發展。Flink 已經變得強大，其設計目標也不再僅僅是流計算引擎，而是讓絕大部分資料分析師都可以利用 Flink 流批一體 API 搭建實時資料整合、分析、風控和線上機器學習場景解決方案。

從流計算到流批一體計算

打敗 Storm 和 Spark Streaming 之後，Flink 成為了流計算的唯一標準，技術上已經沒有了競爭對手。

Flink 誕生之初能夠快速打敗上一代流計算引擎 Storm，憑藉的是“有狀態的流計算”這個核心理念和特色。透過合流式計算和狀態管理兩項技術，Flink 不僅提供了高效能的純流式計算，同時也在框架層透過分散式一致性快照技術，為使用者提供了資料精準一致性保證。在莫問看來，這是 Flink 出道後迅速成為流計算領域新主流的關鍵原因。

雖然 Spark Streaming 透過藉助強大的 Spark 生態也能夠成為一些流計算場景的選擇，但其本質依然是基於 Spark Batch 引擎構建的，非純流執行模式還是會限制其執行效能和流語義表達。

而在批計算方面，Flink 已經完成絕大部分工作，並日益成熟。“目前 Flink 已經能夠完整跑通批處理標準測試集 TPC-DS，而且效能也非常不錯，已經達到主流批處理引擎水平，接下來 Flink 在批處理的成熟度上會持續完善和打磨，並結合自身流處理的天然優勢，力求給使用者帶來業界最好的流批一體計算體驗。”

為什麼我們需要流批一體?為什麼基於 Flink 的流批一體更有技術優勢?

我們先從業務視角看待這個問題，早期企業基本都是離線業務，基於批處理一天執行一次報表，但數字世界在不斷進化演進，對實時的需求會越來越多。實時風控、實時 BI 統計、實時推薦、實時監控，這些都不能等到晚上進行(到了晚上可能商品已經賣完了，使用者也走了)，實時化的資料分析才能給使用者帶來價值。逐漸離線和實時就會成為兩條平行割裂的鏈路，並隨著實時資料業務量佔比持續提升，會有越來越多的任務要重複開發兩遍，開發者會開始面臨開發效率問題。

此外，實時和離線鏈路割裂還會存在業務口徑一致性的問題，在之前的技術方案下，實時和離線相當於用了兩套工具幹活，使用不同的語言、不同的引擎，資料口徑也無法一致，這樣的分析結果就會干擾業務決策，甚至會誤導決策失誤。

這時候流批一體自然而然就成為了解決實時離線割裂的“新手段”。用一套計算引擎開發出的實時離線兩個業務流程，天然是一致的，不會存在誤差。尤其在一些高時效的業務場景中，如搜尋、推薦、廣告，資料平臺中的營銷分析，對流批一體的需求自然就會比較高。而且，在搜尋推薦場景中，還能將 Flink 流批任務與線上任務混部到一起，共用一個資源池，進行統一排程，從而最大化利用伺服器資源，這在業界也是比較先進的實踐方式。

流批一體新架構能夠帶來的收益是明顯的，但也並不是說它就是“放之四海而皆準”的一種技術架構。莫問認為，“如果當前資料業務基本都在離線數倉，尚未有一定規模的實時化業務，那也沒有必要過早去做流批一體改造，因為這樣收益並不大。當實時業務量日益成為主流，相對離線佔比日益增大，或者對資料一致性有越來越強一致的要求的話，那麼流批一體架構就是面向未來的必然選擇。”

流式數倉：基於流批一體的新數倉架構

流批一體是一個技術理念。

Flink 在 SQL 層提供了流批一體語義表達能力，即使用者可以寫一套 SQL，從而同時用在實時和離線兩個場景，從而得到全增量一體化的資料開發體驗。

這是流批一體理念的終點嗎?顯然還不夠。因為在資料儲存鏈路上，還是存在很大的複雜性，例如：在實時鏈路上，Flink 需要將資料寫入 Kafka 等流式儲存中，在離線鏈路上，Flink 往往要將資料寫入到 Hive/Iceberg/Hudi 等批式儲存中。兩條儲存鏈路是割裂的，使用者依然要同時維護兩條資料鏈路，造成較大的管理難度。

然而目前我們要同時維護兩套儲存的原因主要是業界目前沒有一個較為生產可用的流批一體儲存，同時支援高效的流讀、流寫、批讀、批寫能力，使用者為了滿足不同業務需求(時效性，可分析性等)只能透過多條鏈路的組合來拼接，甚至還要在不同儲存間同步資料，這必然會讓整個鏈路變得日益複雜。

那目前業界是否已經存在可用的流批一體儲存來解決這個問題呢?大家可能會想到 Apache Hudi 的這個主流湖儲存專案，Hudi 也確是目前業界流批一體儲存能力上相對最完善的技術，但 Hudi 在儲存結構的設計上，並不適合大規模更新。因此，Flink 社群下一個階段的重點方向就是要去解決這個使用者痛點，將流批一體理念進一步完善，提供真正可用的流批一體儲存技術，從而基於流批一體計算和儲存推出完整的流式數倉新架構，這也是 2021 年底 Flink 社群推出 Flink Table Store 獨立子專案的背景。

2022 年，Flink Table Store 已經完成了從 0 到 1 的孵化，併發布了 2 個 release 版本，除了阿里巴巴，包括位元組跳動在內的多家公司都已經參與了這個專案的貢獻，並有不少公司開始試用。Flink 社群接下來的重點演進方向就是流式數倉新架構， 為使用者提供更加簡潔、實時化的數倉架構，並提供更加一體化的體驗，這也是 Flink 多年來倡導的流批一體理念的完整落地場景，流批一體計算和儲存的完美結合。

在今天的 Flink Forward Asia 2022 上，莫問給大家展示了一個完整的產品化 Demo，基於阿里的實時計算平臺，在 TPC-H 業務背景下跑通了完整的流批一體資料處理和分析流程，包括從資料庫源頭開始的 Flink CDC 資料入湖(寫入 Table Store)、Flink SQL 實時流式分析(訂閱 Table Store)以及批次資料訂正和實時互動查詢，給大家呈現了一個完整的流式數倉新架構成果。此外，Flink 流式數倉架構也是開放的體系，支援對接其他一切具備流批一體能力的儲存系統，例如阿里雲的 Hologres，阿里也在內部完成了 Flink SQL + Hologres 的企業級自研流式數倉產品，不久也將正式對外發布。

基於 Flink 的全增量一體化資料整合

資料整合是實時流處理平臺中非常重要的一個應用場景，這在 Garnter 2022 年 1 月釋出的流處理平臺市場引導報告中也可以得到印證，從全球市場看大概 1/3 的流處理場景是和實時資料整合相關的，即透過流處理能力將各種不斷變化資料來源中的資料同步到分析資料庫，資料倉儲和資料湖中，從而確保使用者可以實時分析到最新的數字世界。

隨著實時化資料分析技術的普及，使用者的資料同步需求也在進一步升級，期望能夠使用一套一體化的全量資料同步工具，一鍵實現資料同步。但在傳統資料整合技術體系下，全量和實時資料同步往往需要兩套工具(基於批和流的)，並且使用者需要在兩套工具之間進行協同，因此要真正實現全增量同步流程的無縫對接並保證資料一致性，這個難度和挑戰是非常大的。但如果能夠利用上 Flink 流批一體融合特性，那實現全增量一體化的實時資料整合就變得可行了。

此外，Flink 本身也具備了豐富的 Connector 生態，能夠連線業界各種主流儲存，以及優秀的分散式整合框架，包括容錯和分散式一致性快照等能力。因此在 Flink 的基礎上做全增量一體化資料整合，相當於“站在巨人肩膀上”，會更快更容易。

這就是 Flink CDC 專案誕生的背景，其大量藉助了 Flink 自身的優勢，利用流批一體執行模式實現了全增量同步自動切換，基於 Flink Checkpointing 能力實現了資料同步斷點續傳特性，並基於增量快照一致性讀取演算法保證了資料同步全程對線上資料庫無鎖操作，這樣對生產業務不會產生任何影響。

作為流批一體的另一個創新應用場景，CDC 專案發展速度也非常快，網易、騰訊、Oceanbase、嗶哩嗶哩、Xtransfer 等公司都參與了社群貢獻，GitHub Star 目前已經突破 3000，生態上支援了很多主流資料庫，包括 MySQL、Oracle、PostgreSQL、MongoDB、TiDB、PolarDB 和 OceanBase 等。莫問表示，Flink CDC 會進一步利用 Flink 社群的創新成果，接入更多的資料來源，成為新一代全增量一體化的資料整合引擎。

雲原生時代的 Flink

隨著雲原生的普及，越來越多的企業應用進行了容器化遷移，並透過 K8s 進行編排管理。最近幾年，大資料領域的 Spark、Kafka 等都開始支援 K8s，使得大資料應用從傳統的 Yarn 時代轉變為雲原生時代。

Flink 社群很早以前就開始基於雲原生來設計了，包括 Flink 的資源排程、流式 Shuffle，都是天然適合雲原生的。Flink 作為一個流式計算引擎，資料的 Shuffle 不需要落盤，都是流式的進行資料傳輸，分散式計算之間資料的流動都是透過網路加記憶體，不依賴本地盤，因此天然就是存算分離的架構。另外，Flink 自帶了一個狀態儲存，計算的運算元和狀態訪問是一體的，在運算元內部就支援狀態訪問，這個其實也在朝著存算分離方向去演進，也就是說 Flink 隨時可以關掉 RocksDB 服務，把狀態資料 SnapShot 到持久化的 HDFS 或者是雲端儲存上。

Flink 作為雲原生架構下的產物，本身也一直朝著雲原生架構去設計，社群在五六年前就開始做 Flink on K8s。支援 K8s 之後，對 Flink 有很大的幫助，比如部署不依賴 Hadoop 了：只要有 K8s，就可以部署 Flink，也沒有任何依賴。運維方案也非常標準化，K8s 的運維體系也會運維 Flink。同時，Flink 也可以基於容器來進行部署，容器給 Flink 帶來了更好的隔離性，包括任務之間的隔離、多租戶的管理，甚至下一步做 Serverless，也會更加自然和容易。

在雲原生的發展趨勢下，自適應性非常重要。更好的資源彈性讓業務的波動也變得更加靈活，而云上的資源也是海量的，使用者可以根據業務的需求不斷彈性調資源規模。特別是 Serverless 的環境下，使用者甚至不需要去考慮機器資源了。Flink 自身也會去增加更多的自適應的能力，實現自動化的任務併發管理和狀態資料管理，從而讓 Flink 能更好地使用雲上的彈性機制。

Apache Flink 正在蓬勃發展，並在廣大的大資料分析生態中變得不可或缺，逐漸成為了企業資料戰略的關鍵支柱。但對於一些傳統企業來說，如果沒有很強大的大資料技術團隊，用開源軟體自建一個資料分析平臺還是比較困難的。所以提供產品化服務，降低技術門檻，也是阿里雲 Flink 技術團隊正在做的事情。

阿里雲已經推出了一款雲原生的實時計算 Flink 產品，提供了以 Flink SQL 為核心的開發運維平臺，將阿里內部積累的 Flink 生產運維經驗和企業級能力都透過產品化的形式開放給廣大中小企業，提供實時數倉、實時資料整合、實時風控和實時特徵工程等解決方案，幫助數字化企業加速大資料技術實時化升級。

另外，阿里雲提供的 Flink 產品也採用了先進的 Serverless 架構，使用者只要按需購買計算資源就可以執行方便使用 Flink，讓實時計算更加普惠。莫問表示，未來幾個月之內，基於 Flink 的多雲 PaaS Serverless 服務也將在全球範圍公測，作為推動 Flink 社群不斷技術創新的核心研發團隊，阿里雲希望把 Flink 技術生態進一步推向全球。

採訪嘉賓簡介

王峰，花名“莫問”，阿里巴巴研究員，2006 年北航畢業加入阿里巴巴，目前負責阿里雲開源大資料平臺，並擔任阿里巴巴開源委員會大資料與 AI 方向副主席。2015 年開始將萌芽狀態的 Apache Flink 引入中國，基於 Flink 推動阿里大資料進入全鏈路實時化時代，並以此為標杆效應帶動了 Flink 在全球各個行業的快速普及和發展，讓 Flink 成為了大資料實時計算領域的事實標準。阿里積極擁抱開源，也主動貢獻開源。迄今，阿里已累計對外開源了上百個優秀專案，在 GitHub 上 Star 總數超百萬。