短短 5 年，Apache Flink（下稱 Flink）從一個突然出現在大資料舞臺的“萌新”系統，迅速成長為人人皆知的流計算引擎。

在伴隨 Flink 發展掀起的這波實時計算浪潮裡，阿里是國內走得最前、做得也最多的一個，“流批一體”是它的新賽道。今年雙 11， Flink 流批一體開始在阿里最核心的資料業務場景嶄露頭角，並抗住了 40 億條／秒的實時計算峰值。

這是第一次有網際網路超級大廠真正在核心資料業務上規模化落地流批一體技術。同時，這也意味著 Flink 在阿里的發展已經進入第二個階段，從全鏈路實時化進階到全鏈路流批一體化。

恰逢 2020 年 Flink Forward Asia 大會召開之際，InfoQ 對 Apache Flink 中文社群發起人及阿里雲實時計算負責人王峰（花名莫問）、阿里雲實時計算團隊資深技術專家楊克特（花名魯尼）、天貓大資料負責人黃曉鋒進行了獨家專訪，希望從多個角度更完整地還原 Flink 流批一體在阿里落地的過程和背後的技術挑戰，並深入探討這個新賽道對於阿里雲的價值和未來發展方向。

從理論到落地

流批一體的技術理念最早提出於 2015 年，它的初衷是讓開發人員能夠用同一套介面實現大資料的流計算和批計算，進而保證處理過程與結果的一致性。隨後，大資料廠商/框架們如 Spark、Flink、Beam 等，都陸續提出了自己的解決方案，雖然實現方式各不相同，但在一定程度上說明流批一體的思想已經在業界得到廣泛認可。

然而，流批一體要真正從理論走到落地，尤其是在企業的核心資料業務場景規模化落地，往往面臨技術和業務的雙重挑戰。在莫問看來，這也是為什麼流批一體出現的很早，廠商落地案例卻不多見。

從技術層面來看，流計算和批計算從計算方式、支撐模組、資源排程策略到流程規劃等都存在差異，不管是批流一體還是流批一體，都有不少技術問題要解決。這其中關乎研發資源投入，但大前提是需要有一個統一的計算引擎。雖然 Spark 是最早提出流批一體理念的計算引擎之一，但由於其本質還是基於批（mini-batch）來實現流，在流計算語義和延遲上存在硬傷，難以滿足複雜、大規模實時計算場景的極致需求，因此目前很多廠商的資料業務還是選擇將流和批分開來做，流用 Flink、批用 Spark。這就導致前面說的大前提無法滿足，在核心場景落地流批一體更加無從談起。

從業務層面來看，如果企業有非常重的歷史包袱或者在流批一體架構下不能取得足夠多業務價值，那它也不會有足夠的動力去做流批一體的改造和落地。

但對於阿里來說，恰恰是在技術和業務兩個因素共同推動之下，流批一體才得以在雙 11 核心業務場景正式亮相。

技術上，阿里 2019 年收購 Flink 的創始公司 Ververica 後，投入近百名工程師到 Flink 技術研發和社群工作中，在 Flink 基於流實現批計算的能力上做了非常多工作，其中有一些特性優先在雙 11 落地，後續也會全部推進到社群裡。

業務上，今年大促期曾經面臨離線和實時資料統計口徑不一致的問題，這類潛在問題會影響廣告、商務甚至公司運營決策，這是真正的“秒秒鐘幾百萬上下”，強電商屬性和大業務體量倒逼著流批一體技術必須在阿里核心業務落地，方能解決痛點。

莫問提到，當前流批一體已經在許多業務場景成為剛需，而不是一個技術噱頭。這次雙十一就像一場“轉正”考試，意味著在阿里巴巴業務場景中流批一體技術從理論走向落地，同時也標記著 Flink 在阿里開始從全鏈路實時化步入全鏈路流批一體化的新階段。

路走對了，就不怕遠

2015 年，針對搜尋推薦業務做新的大資料計算引擎選型時，阿里雲實時計算團隊對流批一體的技術方向就已經有初步設想。

在經過深度調研、可行性驗證和對未來可能遇到的問題進行推演之後，團隊最終決定引入 Flink。魯尼表示，雖然當時 Flink 整個系統還不是特別成熟，但團隊認為 Flink 以流計算為核心的設計理念更符合未來資料計算實時化發展的大趨勢。在阿里內部有一句土話，叫“路走對了，就不怕遠”，從後續這幾年的發展情況來看，Flink 確實進展順利，甚至超過團隊當時的預期。

當然，從初步設想到實現相對完善的流批一體能力，需要一個循序漸進的過程。

從技術本身演化的角度來看，Flink 經歷了流批一體 API 從無到有、從有到更優兩個階段。在早期的 Flink 版本中，Flink 的流和批無論在 API 還是在 Runtime 上都沒有達到徹底的統一。但從 1.9 版本開始，Flink 加速在流批一體上進行完善和升級，Flink SQL 作為使用者使用的最主流 API，率先實現了流批一體語義，使用者只需學習使用一套 SQL 就可以基於 Flink 進行流批一體的開發，降低了開發的門檻。

最初 SQL 實現流批一體的做法是將流作業和批作業分別翻譯成 Flink 底層的兩個原生 API，包括處理流計算需求的 DataStream 和處理批計算需求的 DataSet，相對來說有些簡單粗暴，當時也引發了一系列問題，包括開發鏈路過長導致迭代效率不高等。因此 Flink 社群又對底層架構做了一些重構，並引出了 DAG API，Flink 分散式執行層針對 DAG 做了一系列最佳化，包括增加流批一體的排程器、可插拔的 Shuffle 外掛等。這樣一來，Flink 的分散式執行層也開始逐漸形成了流批一體的 DAG 描述能力和排程執行能力。

目前 Flink 的流批一體方案仍然在持續改進當中。雖然現在開發者已經可以很方便地基於 SQL API 來執行流批一體作業，但 SQL 並不能解決所有需求。一些邏輯特別複雜或定製化程度較高的作業還是需要繼續使用 DataStream API。DataStream API 雖然能更加靈活地應對流計算場景的各種需求，但卻缺乏對批處理的高效支援。

因此，Flink 社群在完成 SQL 流批一體升級之後，從 1.11 版本開始投入大量精力完善 DataStream API 的流批一體能力，在 DataSteam API 上增加批處理的語義，同時結合流批一體 Connector 的設計，讓 DataStream API 能夠在流批融合場景下對接 Kafka 和 HDFS 等不同型別流批資料來源。在剛剛釋出的1.12版本中，大家就可以體驗到 DataStream 流批一體的原生支援。接下來流批一體的迭代計算 API 也將被引入到 DataStream 中，進一步解鎖一系列機器學習場景。

此外，在當前 Flink 主版本中，不管是 SQL 還是 DataStream API，在流批一體概念上都還是流計算和批計算功能的結合體。使用者雖然只需要編寫一套程式碼，但需要在程式碼中選擇使用流的方式跑，還是批的方式跑，執行模式比較單一。但有些業務場景已經提出更高的要求，即流批混合，需要在批和流之間自動切換，Flink 也將在後續支援更加智慧的流批融合場景和動態切換能力。

當然，流批一體不只是一個技術問題，最終還是業務落地的問題，Flink 的流批一體能力也是透過大規模業務鍛造出來的。

雖然選型之初，阿里雲的技術團隊看中的就是 Flink 優秀的流計算能力，但當時這個能力並未經過大規模線上業務驗證。為了快速試錯，團隊決定開闢一個 Flink 的內部分支（即後來為大家熟知的 Blink），最大目的是快速增加當時急缺的功能並在線上業務驗證，這也是在業務早期的選擇。

經過團隊一年的努力，基於 Flink 的搜尋推薦實時計算平臺成功支援了 2016 年的搜尋雙 11，保證了搜尋推薦全鏈路實時化。在這之後，Flink 開始在阿里集團內部服務於更多實時資料業務，在更大規模的業務場景驗證並最佳化其流計算能力和穩定性。2017 年，Flink 成功支援了全集團雙 11 的實時資料業務，包括 GMV 大屏等最核心的資料業務場景。

在實時計算能力經過充分驗證之後，團隊開始補充和完善 Flink 的批計算能力，並在搜尋推薦的索引構建、機器學習特徵工程和樣本生成等業務場景中進行驗證。

經過大規模作業驗證之後，團隊對 Flink 的流批一體能力更加有底，也是在這個時候，團隊開始醞釀 Blink 的開源。後面的進展很多人都已經有所瞭解：2018 年 12 月阿里宣佈開源Flink 的內部分支 Blink；2019 年 1 月起，阿里逐步將內部在 Blink 沉澱的能力推回 Flink 開源社群；到 2019 年 11 月釋出的 Flink 1.10 版本前瞻，Blink 全部功能都已經進入 Flink。2020 年雙 11 天貓營銷決策核心系統的這場“大考”，Flink 流批一體技術又得到了更進一步的錘鍊。

流批一體的雙 11“大考”

在莫問看來，Flink 流批一體技術從最初應用於搜尋推薦場景，到今年雙 11 在天貓核心資料業務落地，升級的是業務的重要程度，而不是簡單的計算規模。

在流計算場景上，天貓大資料團隊已經跟實時計算團隊配合了很多年，但之前一直沒有在批計算場景上線。魯尼透露，天貓的批處理作業優先順序在集團內屬於級別最高的那一檔，因此在架構升級上會更慎重。

天貓分析場景下的報表大部分分為實時和離線兩種，商家、小二、管理層透過實時資料和歷史資料進行不同維度、不同時間週期的比對，從而對當前的活動情況作出判斷，這些資料是業務決策的重要判斷依據。

以前天貓整體的資料架構使用的是 Lambda 架構，資料分析需求基於流、批兩套計算引擎產出，這種分離的架構不僅會帶來兩套開發成本，也導致資料邏輯和口徑難以對齊。另外，產品搭建資料報表的時候，過程繁瑣，容易出現問題。這些痛點促使天貓大資料團隊開始調研流批一體的技術方案。

流批一體的技術方案主要分兩種，一種是跨引擎的流批一體，比如更早以前 Storm 和 Spark 結合使用，批交給 Spark 執行，流交給 Storm 執行；另一種就是一個引擎本身就具備流批一體的能力，比如 Spark 和 Spark streaming、Flink 等。鑑於 Flink 的流計算能力已經在阿里集團內部經過大規模業務應用的驗證，以及 Flink 流批一體技術的不斷成熟，天貓大資料團隊決定嘗試基於 Flink 的流批一體能力升級技術架構。

除了計算層，團隊也調研了儲存層的流批一體方案，最終確定雲原生實時數倉 Hologres 可以滿足天貓點查和 OLAP 分析這兩個場景的需求。團隊首先設計了一個 POC 流程對整套方案進行可行性驗證，發現這套方案是 work 的，的確能對研發效能和資料質量帶來了比較大的提升。

黃曉鋒告訴 InfoQ，從決定在雙 11 大促中規模化使用 Flink 流批一體到最終落地，天貓大資料團隊和實時計算團隊並肩作戰了 5 個月，整個改造過程大致可以劃分為四個關鍵階段。

第一個階段是設計。首先需要拆解和梳理天貓實際情況，完成流批一體模型的統一。然後需要在平臺這一側把源資料打通，實現使用者只寫一套程式碼，平臺自動翻譯成Flink Batch任務和Flink Stream任務，同時寫到一張Holo表，完成計算層表達的統一。第二個階段是落地。流批一體需要依賴離線的排程，因此需要對MaxCompute平臺做一定程度的打通。第三個階段是最佳化。包括語義層表達的最佳化，比如以前寫的趨勢圖邏輯可能針對流場景做了針對性最佳化，但在批上面不起作用甚至可能存在問題，這些特殊場景需要做語義對齊；也包括效能的最佳化，以保證在雙11可以達到效能目標。第四階段是穩定性。由於整條鏈路改動比較大，雙11場景對穩定性的要求又特別高，因此團隊重點展開了資料全鏈路的壓測，以保證Flink本身流批計算效能、Hologres的查詢效能和上層BI層的查詢效能，都能夠滿足雙11的QPS訴求。

在整個過程中，團隊也遇到了幾個核心挑戰。

其中一個挑戰來自效能。這是流批一體第一次大規模使用，不同系統的資料打通做的還不是非常完備。比如 MaxCompute 和 Flink 之間的資料中轉是透過 Tunnel 管道的方式來做的，但在規模化應用的過程中才發現 Tunnel 有連線數的限制，會極大地影響規模化推廣。後來團隊透過在 Flink 這一層做相應的最佳化，先一次性讀取再在 Flink 內部做分發，極大地降低了連線數並優化了讀取效能，問題得以解決。

另一個挑戰來自流批一體的語義統一。在某些場景下，開發人員對流批語義的理解和 Flink Runtime 翻譯出來的流批一體語義之間存在差異，可能會導致同一套 SQL 跑出來的流批結果跟業務理解的不一樣，比如對於 Index Join 和 Primarykey Join 的處理方式在流批上面的差異。後來兩個團隊聯合修復了這個問題。

除此之外，天貓大資料團隊也聯合 Hologres 開發團隊對 Hologres 進行了非常深度的最佳化，包括最佳化器、排隊機制、資料 Shard 的劃分規則、計算層的資料 shuffle 機制都做了針對性的最佳化。

事實上，Flink 流批一體成功落地雙 11 天貓核心資料場景，不僅更好地提升了開發團隊成員的技術能力，在業務上的實踐效果也非常喜人。

時效性上，面對 58.3 萬筆/秒的交易峰值和上億/秒的無線流量洪峰，天貓的所有任務都達到了秒級延時，整個實時計算叢集峰值 TPS 達到 40 億條/秒。同時，叢集資源利用率也得到了大幅提升，批任務可以錯峰執行。

準確性上，流批任務的業務口徑做到了完全一致，資料質量問題不復存在，成為大促期間重要的業務雷達。流批模型也實現了完全統一，產品搭建效率提升 400%。

靈活性上，流批一體實現了多個計算處理模式也只需要撰寫一套程式碼，需求迭代效率提升 2 倍，大促當天緊急需求承接效率提升 5 倍。同時，實時數倉+OLAP 場景結合，也使得變更成本大幅下降，能更好地滿足分析師按需取數場景的需要。

在黃曉鋒的整體規劃裡，Flink 流批一體成功落地雙 11 天貓核心資料場景，僅僅只是走出了陽光大道的第一步。接下來，天貓大資料團隊計劃繼續探索儲存層的流批一體，而在更長遠的未來，團隊希望推動流批一體往“湖倉一體”方向去演進，並把經過內部打磨的技術架構和平臺，如 DataPhin、QuickBI、Flink、Hologres 整合的場景，輸出到雲上服務更多外部使用者。

下一個規模化落地場景什麼時候到來？

阿里在核心資料業務上真正規模化落地“流批一體”無疑給業界開了個好頭。

近幾年，大資料領域逐漸開始擁抱“融合”（或所謂“一體化”）演進的新方向，不管是今年剛成為熱議話題的“湖倉一體”，還是更早提出的“流批一體”，其實都是這一思路的階段性成果。對於新的技術思路，大眾在一開始肯定會有質疑和觀望情緒。莫問表示，團隊希望透過這次成功打樣的案例向業界證明，Flink 流批一體是真正能夠落地核心業務併為業務創造價值的。這或許能讓更多企業和團隊打消觀望情緒，並使 2020 年成為流批一體落地的元年。

在黃曉鋒看來，流批一體將成為阿里集團內部資料技術升級的新賽道。因為天貓的業務體量和業務場景的複雜度，在整個集團裡非常具有代表性，Flink 流批一體在天貓業務上的成功應用，會推動整個集團在流批一體這個賽道上的投入，也會推動更多業務去升級到流批一體架構，以解決業務上的痛點。

除了在阿里內部推動更多業務落地 Flink 流批一體，莫問提到，未來還會將更多精力和焦點放在開源社群。下一步，阿里雲實時計算團隊會把在阿里業務場景下打磨出來的核心技術積累，在 Flink 未來的 1 到 2 個版本中逐步推回開源社群，讓更多企業都能夠用上 Flink 流批一體的能力。

當然，在 Flink 流批一體推廣和大規模落地的道路上也充滿挑戰。

流批一體技術本身的挑戰在於，原來是一個單一引擎解決單一問題（批或者流），現在需要一個引擎同時解決流+批的問題，如果未來流和批的概念逐漸淡化，那麼引擎本身就需要具備針對不同場景和需求智慧化選擇流批模式的能力，這在技術上是非常大的挑戰。不過魯尼認為，機遇和挑戰是一併存在的，如果使用者能夠把更多精力從選擇引擎、維護引擎中解放出來，就可以更專注於業務本身，既能加快迭代效率也能利用流批一體引擎的靈活性解鎖更多有價值的業務場景。

另一個挑戰在於改變使用者的心智，莫問表示，流批一體需要使用者轉變原來固有的流批分離的思維模式，這並不是一件簡單的事情，企業在做相關的決策時肯定會更加謹慎，需要逐步試點和推進。另外，當前很多網際網路公司離線計算團隊和實時計算團隊是兩個獨立的團隊、兩套獨立的體系，如果要做流批一體，就需要兩個團隊密切合作和共建，組織架構上的挑戰不亞於技術上的挑戰。但莫問相信，只要方向對了，一切只是時間問題。

據瞭解，目前 Flink 社群中位元組跳動、快手、小米等幾家頭部公司都已經開始探索基於 Flink 的流批一體架構，或正在規劃當中。

展望 2021 年，Flink 流批一體或將迎來快速發展期。隨著更多大型網際網路公司成功落地並向業界輸出經驗，相信會推動更多中小企業選擇跟進和嘗試流批一體架構。