流批一體已經(jīng)從理論走向?qū)嵺`，并在 2020 年迎來落地元年。

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

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

這是第一次有互聯(lián)網(wǎng)超級大廠真正在核心數(shù)據(jù)業(yè)務(wù)上規(guī)?；涞亓髋惑w技術(shù)。同時，這也意味著 Flink 在阿里的發(fā)展已經(jīng)進入第二個階段，從全鏈路實時化進階到全鏈路流批一體化。

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

1 從理論到落地

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

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

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

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

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

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

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

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

2 路走對了，就不怕遠

2015 年，針對搜索推薦業(yè)務(wù)做新的大數(shù)據(jù)計算引擎選型時，阿里云實時計算團隊對流批一體的技術(shù)方向就已經(jīng)有初步設(shè)想。

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

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

從技術(shù)本身演化的角度來看，F(xiàn)link 經(jīng)歷了流批一體 API 從無到有、從有到更優(yōu)兩個階段。在早期的 Flink 版本中，F(xiàn)link 的流和批無論在 API 還是在 Runtime 上都沒有達到徹底的統(tǒng)一。但從 1.9 版本開始，F(xiàn)link 加速在流批一體上進行完善和升級，F(xiàn)link SQL 作為用戶使用的最主流 API，率先實現(xiàn)了流批一體語義，用戶只需學習使用一套 SQL 就可以基于 Flink 進行流批一體的開發(fā)，降低了開發(fā)的門檻。

最初 SQL 實現(xiàn)流批一體的做法是將流作業(yè)和批作業(yè)分別翻譯成 Flink 底層的兩個原生 API，包括處理流計算需求的 DataStream 和處理批計算需求的 DataSet，相對來說有些簡單粗暴，當時也引發(fā)了一系列問題，包括開發(fā)鏈路過長導致迭代效率不高等。因此 Flink 社區(qū)又對底層架構(gòu)做了一些重構(gòu)，并引出了 DAG API，F(xiàn)link 分布式運行層針對 DAG 做了一系列優(yōu)化，包括增加流批一體的調(diào)度器、可插拔的 Shuffle 插件等。這樣一來，F(xiàn)link 的分布式運行層也開始逐漸形成了流批一體的 DAG 描述能力和調(diào)度執(zhí)行能力。

目前 Flink 的流批一體方案仍然在持續(xù)改進當中。雖然現(xiàn)在開發(fā)者已經(jīng)可以很方便地基于 SQL API 來執(zhí)行流批一體作業(yè)，但 SQL 并不能解決所有需求。一些邏輯特別復雜或定制化程度較高的作業(yè)還是需要繼續(xù)使用 DataStream API。DataStream API 雖然能更加靈活地應(yīng)對流計算場景的各種需求，但卻缺乏對批處理的高效支持。

因此，F(xiàn)link 社區(qū)在完成 SQL 流批一體升級之后，從 1.11 版本開始投入大量精力完善 DataStream API 的流批一體能力，在 DataSteam API 上增加批處理的語義，同時結(jié)合流批一體 Connector 的設(shè)計，讓 DataStream API 能夠在流批融合場景下對接 Kafka 和 HDFS 等不同類型流批數(shù)據(jù)源。在剛剛發(fā)布的 1.12 版本中，大家就可以體驗到 DataStream 流批一體的原生支持。接下來流批一體的迭代計算 API 也將被引入到 DataStream 中，進一步解鎖一系列機器學習場景。

此外，在當前 Flink 主版本中，不管是 SQL 還是 DataStream API，在流批一體概念上都還是流計算和批計算功能的結(jié)合體。用戶雖然只需要編寫一套代碼，但需要在代碼中選擇使用流的方式跑，還是批的方式跑，執(zhí)行模式比較單一。但有些業(yè)務(wù)場景已經(jīng)提出更高的要求，即流批混合，需要在批和流之間自動切換，F(xiàn)link 也將在后續(xù)支持更加智能的流批融合場景和動態(tài)切換能力。

當然，流批一體不只是一個技術(shù)問題，最終還是業(yè)務(wù)落地的問題，F(xiàn)link 的流批一體能力也是通過大規(guī)模業(yè)務(wù)鍛造出來的。

雖然選型之初，阿里云的技術(shù)團隊看中的就是 Flink 優(yōu)秀的流計算能力，但當時這個能力并未經(jīng)過大規(guī)模線上業(yè)務(wù)驗證。為了快速試錯，團隊決定開辟一個 Flink 的內(nèi)部分支（即后來為大家熟知的 Blink），最大目的是快速增加當時急缺的功能并在線上業(yè)務(wù)驗證，這也是在業(yè)務(wù)早期的選擇。

經(jīng)過團隊一年的努力，基于 Flink 的搜索推薦實時計算平臺成功支持了 2016 年的搜索雙 11，保證了搜索推薦全鏈路實時化。在這之后，F(xiàn)link 開始在阿里集團內(nèi)部服務(wù)于更多實時數(shù)據(jù)業(yè)務(wù)，在更大規(guī)模的業(yè)務(wù)場景驗證并優(yōu)化其流計算能力和穩(wěn)定性。2017 年，F(xiàn)link 成功支持了全集團雙 11 的實時數(shù)據(jù)業(yè)務(wù)，包括 GMV 大屏等最核心的數(shù)據(jù)業(yè)務(wù)場景。

在實時計算能力經(jīng)過充分驗證之后，團隊開始補充和完善 Flink 的批計算能力，并在搜索推薦的索引構(gòu)建、機器學習特征工程和樣本生成等業(yè)務(wù)場景中進行驗證。

經(jīng)過大規(guī)模作業(yè)驗證之后，團隊對 Flink 的流批一體能力更加有底，也是在這個時候，團隊開始醞釀 Blink 的開源。后面的進展很多人都已經(jīng)有所了解：2018 年 12 月阿里宣布開源 Flink 的內(nèi)部分支 Blink；2019 年 1 月起，阿里逐步將內(nèi)部在 Blink 沉淀的能力推回 Flink 開源社區(qū)；到 2019 年 11 月發(fā)布的 Flink 1.10 版本前瞻，Blink 全部功能都已經(jīng)進入 Flink。2020 年雙 11 天貓營銷決策核心系統(tǒng)的這場“大考”，F(xiàn)link 流批一體技術(shù)又得到了更進一步的錘煉。

3 流批一體的雙 11“大考”

在莫問看來，F(xiàn)link 流批一體技術(shù)從最初應(yīng)用于搜索推薦場景，到今年雙 11 在天貓核心數(shù)據(jù)業(yè)務(wù)落地，升級的是業(yè)務(wù)的重要程度，而不是簡單的計算規(guī)模。

在流計算場景上，天貓大數(shù)據(jù)團隊已經(jīng)跟實時計算團隊配合了很多年，但之前一直沒有在批計算場景上線。魯尼透露，天貓的批處理作業(yè)優(yōu)先級在集團內(nèi)屬于級別最高的那一檔，因此在架構(gòu)升級上會更慎重。

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

以前天貓整體的數(shù)據(jù)架構(gòu)使用的是 Lambda 架構(gòu)，數(shù)據(jù)分析需求基于流、批兩套計算引擎產(chǎn)出，這種分離的架構(gòu)不僅會帶來兩套開發(fā)成本，也導致數(shù)據(jù)邏輯和口徑難以對齊。另外，產(chǎn)品搭建數(shù)據(jù)報表的時候，過程繁瑣，容易出現(xiàn)問題。這些痛點促使天貓大數(shù)據(jù)團隊開始調(diào)研流批一體的技術(shù)方案。

流批一體的技術(shù)方案主要分兩種，一種是跨引擎的流批一體，比如更早以前 Storm 和 Spark 結(jié)合使用，批交給 Spark 執(zhí)行，流交給 Storm 執(zhí)行；另一種就是一個引擎本身就具備流批一體的能力，比如 Spark 和 Spark streaming、Flink 等。鑒于 Flink 的流計算能力已經(jīng)在阿里集團內(nèi)部經(jīng)過大規(guī)模業(yè)務(wù)應(yīng)用的驗證，以及 Flink 流批一體技術(shù)的不斷成熟，天貓大數(shù)據(jù)團隊決定嘗試基于 Flink 的流批一體能力升級技術(shù)架構(gòu)。

除了計算層，團隊也調(diào)研了存儲層的流批一體方案，最終確定云原生實時數(shù)倉 Hologres 可以滿足天貓點查和 OLAP 分析這兩個場景的需求。團隊首先設(shè)計了一個 POC 流程對整套方案進行可行性驗證，發(fā)現(xiàn)這套方案是 work 的，的確能對研發(fā)效能和數(shù)據(jù)質(zhì)量帶來了比較大的提升。

黃曉鋒告訴 InfoQ，從決定在雙 11 大促中規(guī)?；褂?Flink 流批一體到最終落地，天貓大數(shù)據(jù)團隊和實時計算團隊并肩作戰(zhàn)了 5 個月，整個改造過程大致可以劃分為四個關(guān)鍵階段。

第一個階段是設(shè)計。首先需要拆解和梳理天貓實際情況，完成流批一體模型的統(tǒng)一。然后需要在平臺這一側(cè)把源數(shù)據(jù)打通，實現(xiàn)用戶只寫一套代碼，平臺自動翻譯成 Flink Batch 任務(wù)和 Flink Stream 任務(wù)，同時寫到一張 Holo 表，完成計算層表達的統(tǒng)一。

第二個階段是落地。流批一體需要依賴離線的調(diào)度，因此需要對 MaxCompute平臺做一定程度的打通。

第三個階段是優(yōu)化。包括語義層表達的優(yōu)化，比如以前寫的趨勢圖邏輯可能針對流場景做了針對性優(yōu)化，但在批上面不起作用甚至可能存在問題，這些特殊場景需要做語義對齊；也包括性能的優(yōu)化，以保證在雙 11 可以達到性能目標。

第四階段是穩(wěn)定性。由于整條鏈路改動比較大，雙 11 場景對穩(wěn)定性的要求又特別高，因此團隊重點展開了數(shù)據(jù)全鏈路的壓測，以保證 Flink 本身流批計算性能、Hologres 的查詢性能和上層 BI 層的查詢性能，都能夠滿足雙 11 的 QPS 訴求。

在整個過程中，團隊也遇到了幾個核心挑戰(zhàn)。

其中一個挑戰(zhàn)來自性能。這是流批一體第一次大規(guī)模使用，不同系統(tǒng)的數(shù)據(jù)打通做的還不是非常完備。比如 MaxCompute 和 Flink 之間的數(shù)據(jù)中轉(zhuǎn)是通過 Tunnel 管道的方式來做的，但在規(guī)?；瘧?yīng)用的過程中才發(fā)現(xiàn) Tunnel 有連接數(shù)的限制，會極大地影響規(guī)?；茝V。后來團隊通過在 Flink 這一層做相應(yīng)的優(yōu)化，先一次性讀取再在 Flink 內(nèi)部做分發(fā)，極大地降低了連接數(shù)并優(yōu)化了讀取性能，問題得以解決。

另一個挑戰(zhàn)來自流批一體的語義統(tǒng)一。在某些場景下，開發(fā)人員對流批語義的理解和 Flink Runtime 翻譯出來的流批一體語義之間存在差異，可能會導致同一套 SQL 跑出來的流批結(jié)果跟業(yè)務(wù)理解的不一樣，比如對于 Index Join 和 Primarykey Join 的處理方式在流批上面的差異。后來兩個團隊聯(lián)合修復了這個問題。

除此之外，天貓大數(shù)據(jù)團隊也聯(lián)合 Hologres 開發(fā)團隊對 Hologres 進行了非常深度的優(yōu)化，包括優(yōu)化器、排隊機制、數(shù)據(jù) Shard 的劃分規(guī)則、計算層的數(shù)據(jù) shuffle 機制都做了針對性的優(yōu)化。

事實上，F(xiàn)link 流批一體成功落地雙 11 天貓核心數(shù)據(jù)場景，不僅更好地提升了開發(fā)團隊成員的技術(shù)能力，在業(yè)務(wù)上的實踐效果也非常喜人。

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

準確性上，流批任務(wù)的業(yè)務(wù)口徑做到了完全一致，數(shù)據(jù)質(zhì)量問題不復存在，成為大促期間重要的業(yè)務(wù)雷達。流批模型也實現(xiàn)了完全統(tǒng)一，產(chǎn)品搭建效率提升 400%。

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

在黃曉鋒的整體規(guī)劃里，F(xiàn)link 流批一體成功落地雙 11 天貓核心數(shù)據(jù)場景，僅僅只是走出了陽光大道的第一步。接下來，天貓大數(shù)據(jù)團隊計劃繼續(xù)探索存儲層的流批一體，而在更長遠的未來，團隊希望推動流批一體往“湖倉一體”方向去演進，并把經(jīng)過內(nèi)部打磨的技術(shù)架構(gòu)和平臺，如 DataPhin、QuickBI、Flink、Hologres 整合的場景，輸出到云上服務(wù)更多外部用戶。

4 下一個規(guī)?；涞貓鼍笆裁磿r候到來？

阿里在核心數(shù)據(jù)業(yè)務(wù)上真正規(guī)?；涞亍傲髋惑w”無疑給業(yè)界開了個好頭。

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

在黃曉鋒看來，流批一體將成為阿里集團內(nèi)部數(shù)據(jù)技術(shù)升級的新賽道。因為天貓的業(yè)務(wù)體量和業(yè)務(wù)場景的復雜度，在整個集團里非常具有代表性，F(xiàn)link 流批一體在天貓業(yè)務(wù)上的成功應(yīng)用，會推動整個集團在流批一體這個賽道上的投入，也會推動更多業(yè)務(wù)去升級到流批一體架構(gòu)，以解決業(yè)務(wù)上的痛點。

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

當然，在 Flink 流批一體推廣和大規(guī)模落地的道路上也充滿挑戰(zhàn)。

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

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

據(jù)了解，目前 Flink 社區(qū)中字節(jié)跳動、快手、小米等幾家頭部公司都已經(jīng)開始探索基于 Flink 的流批一體架構(gòu)，或正在規(guī)劃當中。

展望 2021 年，F(xiàn)link 流批一體或?qū)⒂瓉砜焖侔l(fā)展期。隨著更多大型互聯(lián)網(wǎng)公司成功落地并向業(yè)界輸出經(jīng)驗，相信會推動更多中小企業(yè)選擇跟進和嘗試流批一體架構(gòu)。

責任編輯：xj

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

文章出處：【微信公眾號：算法與數(shù)據(jù)結(jié)構(gòu)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。