流批一體已經從理論走向實踐，并在 2020 年迎來落地元年。

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

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

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

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

1 從理論到落地

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

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

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

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

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

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

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

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

2 路走對了，就不怕遠

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 流批一體技術又得到了更進一步的錘煉。

3 流批一體的雙 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 整合的場景，輸出到云上服務更多外部用戶。

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

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

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

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

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

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

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

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

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

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

責任編輯：xj

原文標題：為什么阿里云要做流批一體？

文章出處：【微信公眾號：算法與數據結構】歡迎添加關注！文章轉載請注明出處。