為什么阿里云要做流批一體？

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

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

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

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

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

從理論到落地

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

然而，流批一體要真正從理論走到落地，尤其是在企業(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)流，在流計算語義和延遲上存在硬傷，難以滿足復(fù)雜、大規(guī)模實時計算場景的極致需求，因此目前很多廠商的數(shù)據(jù)業(yè)務(wù)還是選擇將流和批分開來做，流用Flink、批用Spark。這就導(dǎo)致前面說的大前提無法滿足，在核心場景落地流批一體更加無從談起。

從業(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ù)也會全部推進(jìn)到社區(qū)里。

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

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

路走對了，就不怕遠(yuǎn)

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

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

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

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

最初SQL實現(xiàn)流批一體的做法是將流作業(yè)和批作業(yè)分別翻譯成Flink底層的兩個原生API，包括處理流計算需求的DataStream和處理批計算需求的DataSet，相對來說有些簡單粗暴，當(dāng)時也引發(fā)了一系列問題，包括開發(fā)鏈路過長導(dǎo)致迭代效率不高等。因此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ù)改進(jìn)當(dāng)中。雖然現(xiàn)在開發(fā)者已經(jīng)可以很方便地基于SQL API來執(zhí)行流批一體作業(yè)，但SQL并不能解決所有需求。一些邏輯特別復(fù)雜或定制化程度較高的作業(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中，進(jìn)一步解鎖一系列機器學(xué)習(xí)場景。

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

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

雖然選型之初，阿里云的技術(shù)團隊看中的就是Flink優(yōu)秀的流計算能力，但當(dāng)時這個能力并未經(jīng)過大規(guī)模線上業(yè)務(wù)驗證。為了快速試錯，團隊決定開辟一個Flink的內(nèi)部分支（即后來為大家熟知的Blink），最大目的是快速增加當(dāng)時急缺的功能并在線上業(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)建、機器學(xué)習(xí)特征工程和樣本生成等業(yè)務(wù)場景中進(jìn)行驗證。

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

流批一體的雙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ù)進(jìn)行不同維度、不同時間周期的比對，從而對當(dāng)前的活動情況作出判斷，這些數(shù)據(jù)是業(yè)務(wù)決策的重要判斷依據(jù)。

以前天貓整體的數(shù)據(jù)架構(gòu)使用的是Lambda架構(gòu)，數(shù)據(jù)分析需求基于流、批兩套計算引擎產(chǎn)出，這種分離的架構(gòu)不僅會帶來兩套開發(fā)成本，也導(dǎo)致數(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流程對整套方案進(jìn)行可行性驗證，發(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表，完成計算層表達(dá)的統(tǒng)一。

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

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

第四階段是穩(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翻譯出來的流批一體語義之間存在差異，可能會導(dǎo)致同一套SQL跑出來的流批結(jié)果跟業(yè)務(wù)理解的不一樣，比如對于Index Join和Primarykey Join的處理方式在流批上面的差異。后來兩個團隊聯(lián)合修復(fù)了這個問題。

除此之外，天貓大數(shù)據(jù)團隊也聯(lián)合Hologres開發(fā)團隊對Hologres進(jìn)行了非常深度的優(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ù)都達(dá)到了秒級延時，整個實時計算集群峰值TPS達(dá)到40億條/秒。同時，集群資源利用率也得到了大幅提升，批任務(wù)可以錯峰執(zhí)行。

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

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

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

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

阿里在核心數(shù)據(jù)業(yè)務(wù)上真正規(guī)模化落地“流批一體”無疑給業(yè)界開了個好頭。

近幾年，大數(shù)據(jù)領(lǐng)域逐漸開始擁抱“融合”（或所謂“一體化”）演進(jìn)的新方向，不管是今年剛成為熱議話題的“湖倉一體”，還是更早提出的“流批一體”，其實都是這一思路的階段性成果。對于新的技術(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ù)雜度，在整個集團里非常具有代表性，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流批一體的能力。

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

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

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

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

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