作者：秦江杰
去年 11 月的 Flink Forward Asia 2019（以下簡稱 FFA） 上 Flink 社區(qū)提出了未來發(fā)展的幾個主要方向，其中之一就是擁抱 AI [1]。實(shí)際上，近年來 AI 持續(xù)火熱，各種計算框架、模型和算法層出不窮，從某種角度上來說，這個賽道已經(jīng)有些擁擠了。在這種情況下， Flink 將怎樣擁抱 AI，又會為用戶帶來什么新的價值？Flink AI 的優(yōu)劣勢分別在哪里？本文將通過對這些問題的討論來分析 Flink AI 的發(fā)展方向。
Lambda 架構(gòu)，流批統(tǒng)一和 AI 實(shí)時化
Flink 在 AI 中的價值其實(shí)和大數(shù)據(jù)中 Lambda 架構(gòu)[2]和流批統(tǒng)一這兩個概念有關(guān)系，Flink 為大數(shù)據(jù)實(shí)時化帶來的價值也將同樣使 AI 受益。
不妨讓我們簡單回顧一下大數(shù)據(jù)的發(fā)展過程。從 Google 奠基性的“三架馬車” 3[5] 論文發(fā)表后的很長一段時間內(nèi)，大數(shù)據(jù)的發(fā)展主線上都只有批計算的身影。后來隨著大家認(rèn)識到數(shù)據(jù)時效性的重要作用，Twitter 開源的流計算引擎 Storm [6] 紅極一時，各種流計算引擎也紛紛登場，其中也包括了 Flink。由于成本、計算準(zhǔn)確性和容錯性等方面的考慮，各家企業(yè)紛紛使用起了被稱為 Lambda 架構(gòu)的解決方案，在同一個架構(gòu)下融合批計算和流計算，以便在成本，容錯和數(shù)據(jù)時效性之間達(dá)到一個平衡。
Lambda 架構(gòu)在解決數(shù)據(jù)時效性的同時也存在一些問題，其中最受詬病的就是其系統(tǒng)復(fù)雜度和可維護(hù)性。用戶需要為 Batch Layer 和 Speed Layer 各維護(hù)一套引擎和代碼，還需要保證二者之間的計算邏輯完全一致（圖1）。

圖1
為了解決這個問題，各個計算引擎不約而同的開始了流批統(tǒng)一的嘗試，試圖使用同一套引擎來執(zhí)行流和批的任務(wù)（圖2）。經(jīng)過若干年的大浪淘沙，Spark [7] 和 Flink 成為了目前處于第一梯隊的兩款主流計算引擎。Flink 是從流計算逐漸進(jìn)入到批計算，一個非常典型的成功案例就是使用同一套標(biāo)準(zhǔn)的 SQL 語句對流和批進(jìn)行查詢，并保證最終結(jié)果一致性[8]。而 Spark 則是采用微批 (Micro Batch) 的方式從批計算進(jìn)入到流計算提出了 Spark Streaming，但是在時延的表現(xiàn)上始終遜色一些。

圖2
可以看到，在大數(shù)據(jù)的發(fā)展過程中，Lambda 架構(gòu)和流批一體背后的原始驅(qū)動力是數(shù)據(jù)實(shí)時化。同樣是向數(shù)據(jù)要價值，AI 對數(shù)據(jù)時效性的要求同大數(shù)據(jù)是一致的。因此AI實(shí)時化也將會是一個重要的發(fā)展方向。在觀察目前主流的 AI 場景和技術(shù)架構(gòu)時，我們也會發(fā)現(xiàn)它們與大數(shù)據(jù)平臺有很多聯(lián)系和相似之處。
目前的 AI 大致可以分為數(shù)據(jù)預(yù)處理（也稱數(shù)據(jù)準(zhǔn)備/特征工程等），模型訓(xùn)練和推理預(yù)測三個主要階段。下面我們逐一來看一看在每個階段中 AI 實(shí)時化需求有哪些，又有什么樣的問題待解決。為了便于與大數(shù)據(jù)的架構(gòu)做類比，我們姑且認(rèn)為流計算和批計算作為一種計算類型的劃分維度已經(jīng)將所有基于數(shù)據(jù)的計算一分為二，沒有遺漏了。AI 的各個階段根據(jù)場景不同，也可以歸為二者之一。
數(shù)據(jù)預(yù)處理（數(shù)據(jù)準(zhǔn)備/特征工程）
數(shù)據(jù)預(yù)處理階段是模型訓(xùn)練和推理預(yù)測的前置環(huán)節(jié)，很多時候它更多的是一個大數(shù)據(jù)問題。根據(jù)數(shù)據(jù)預(yù)處理后的下游不同，數(shù)據(jù)預(yù)處理可能是批計算也可能是流計算，計算類型和下游一致。在一個典型的離線訓(xùn)練（批計算）和在線預(yù)測（流計算）場景下，訓(xùn)練和預(yù)測時要求產(chǎn)生輸入數(shù)據(jù)的預(yù)處理邏輯是一致的（比如相同的樣本拼接邏輯），這里的需求和 Lambda 架構(gòu)中的需求一樣，因此一個流批統(tǒng)一的引擎會格外有優(yōu)勢。這樣可以避免批作業(yè)和流作業(yè)使用兩個不同的引擎，省去了維護(hù)邏輯一致的兩套代碼的麻煩。
模型訓(xùn)練

目前而言 AI 訓(xùn)練階段基本上是批計算（離線訓(xùn)練）產(chǎn)生靜態(tài)模型（Static Model）的過程。這是因?yàn)槟壳敖^大多數(shù)的模型是基于獨(dú)立同分布（IID）的統(tǒng)計規(guī)律實(shí)現(xiàn)的，也就是從大量的訓(xùn)練樣本中找到特征和標(biāo)簽之間的統(tǒng)計相關(guān)性（Correlation），這些統(tǒng)計相關(guān)性通常不會突然變化，因此在一批樣本上訓(xùn)練出的數(shù)據(jù)在另一批具有相同的特征分布的樣本上依然適用。然而這樣的離線模型訓(xùn)練產(chǎn)生的靜態(tài)模型依然可能存在一些問題。
首先樣本數(shù)據(jù)可能隨著時間推移會發(fā)生分布變化，這種情況下，在線預(yù)測的樣本分布和訓(xùn)練樣本的分布會產(chǎn)生偏移，從而使模型預(yù)測的效果變差。因此靜態(tài)模型通常需要重新訓(xùn)練，這可以是一個定期過程或者通過對樣本和模型的預(yù)測效果進(jìn)行監(jiān)控來實(shí)現(xiàn)（注意這里的監(jiān)控本身其實(shí)是一個典型的流計算需求）。
另外，在有些場景下，預(yù)測階段的樣本分布可能無法在訓(xùn)練階段就知曉。舉例來說，在阿里雙十一，微博熱搜，高頻交易等這類樣本分布可能發(fā)生無法預(yù)測的分布改變的場景下，如何迅速更新模型來得到更好的預(yù)測結(jié)果是十分有價值的。
因此一個理想的 AI 計算架構(gòu)中，應(yīng)該把如何及時更新模型納入考慮。在這方面流計算也有著一些獨(dú)特的優(yōu)勢。事實(shí)上，阿里巴巴在搜索推薦系統(tǒng)中已經(jīng)在使用在線機(jī)器學(xué)習(xí)，并且在雙十一這樣的場景下取得了良好的效果。
推理預(yù)測
推理預(yù)測環(huán)節(jié)的環(huán)境和計算類型比較豐富，既有批處理（離線預(yù)測）又有流處理。流式預(yù)測又大致可以分為在線 (Online) 預(yù)測和近線 (Nearline) 預(yù)測。在線預(yù)測通常處于用戶訪問的關(guān)鍵鏈路(Critical Path 中)，因此對 latency 的要求極高，比如毫秒級。而近線預(yù)測要求略低一些，通常在亞秒級到秒級。目前大多數(shù)純流式分布式計算（Native Stream Processing）引擎可以滿足近線數(shù)據(jù)預(yù)處理和預(yù)測的需求，而在線數(shù)據(jù)預(yù)處理和預(yù)測則通常需要將預(yù)測代碼寫進(jìn)應(yīng)用程序內(nèi)部來滿足極致的低延遲要求。因此在線預(yù)測的場景也比較少看到大數(shù)據(jù)引擎的身影。在這方面 Flink 的 Stateful Function [9] 是一個獨(dú)特的創(chuàng)新，Stateful Function 的設(shè)計初衷是在 Flink 上通過若干有狀態(tài)的函數(shù)來構(gòu)建一個在線應(yīng)用，通過它可以做到超低延遲的在線預(yù)測服務(wù)，這樣用戶可以在離線，近線和在線三種場景下使用同一套代碼同一個引擎來進(jìn)行數(shù)據(jù)預(yù)處理和預(yù)測。
綜上所述，可以看到在機(jī)器學(xué)習(xí)的每個主要階段中對 AI 實(shí)時化都有重要的需求，那什么樣的系統(tǒng)架構(gòu)能夠有效滿足這樣的需求呢？
Flink 和 AI 實(shí)時化的架構(gòu)
目前最典型的 AI 架構(gòu)示例是離線訓(xùn)練配合在線推理預(yù)測（圖3）。

圖3
正如之前提到的，這個架構(gòu)存在兩個問題：

模型更新的周期通常比較長。

離線和在線的預(yù)處理可能需要維護(hù)兩套代碼。

為了解決第一個問題，我們需要引入一個實(shí)時訓(xùn)練的鏈路（圖4）。

圖4
在這個鏈路中，線上的數(shù)據(jù)在用于推理預(yù)測之外還會實(shí)時生成樣本并用于在線模型訓(xùn)練。在這個過程中，模型是動態(tài)更新的，因此可以更好的契合樣本發(fā)生的變化。
不論是純在線還是純離線的鏈路，都并非適合所有的 AI 場景。和 Lambda 的思想類似，我們可以把兩者結(jié)合（圖5）。

圖5
同樣的，為了解決系統(tǒng)復(fù)雜度和可運(yùn)維性的問題（也就是上面提到的第二個問題），我們希望在數(shù)據(jù)預(yù)處理的部分用一個流批統(tǒng)一的引擎來避免維護(hù)兩套代碼（圖6）。不僅如此，我們還需要數(shù)據(jù)預(yù)處理和推理預(yù)測能夠支持離線，近線和在線的各種 Latency 要求，所以使用 Flink 是一個非常合適的選擇。尤其是對于數(shù)據(jù)預(yù)處理環(huán)節(jié)而言，Flink 在流和批上全面完整的 SQL 支持可以大大提高的開發(fā)效率。

圖6
除此之外，為了進(jìn)一步降低系統(tǒng)的復(fù)雜度，Flink 也在模型訓(xùn)練環(huán)節(jié)進(jìn)行了一系列努力（圖7）。

• 流批一體算法庫 Alink

在去年的 FFA 2019 上，阿里巴巴宣布開源了基于 Flink 的機(jī)器學(xué)習(xí)算法庫 Alink [10]，并計劃將其逐步貢獻(xiàn)回 Apache Flink，作為 Flink ML Lib 隨 Apache Flink 發(fā)布。除了離線學(xué)習(xí)的算法外，Alink 的一大特色就是為用戶提供了在線學(xué)習(xí)算法，助推 Flink 在 AI 實(shí)時化上發(fā)揮更大的作用。

• Deep Learning on Flink （flink-ai-extended [11]）

幫助用戶把目前流行的深度學(xué)習(xí)框架（TensorFlow、PyTorch）整合到 Flink 中。使除了深度學(xué)習(xí)算法開發(fā)者之外的用戶可以基于 Flink 實(shí)現(xiàn)整套 AI 架構(gòu)。

• 流批統(tǒng)一的迭代語義和高性能實(shí)現(xiàn)

AI 訓(xùn)練中迭代收斂是一個最核心的計算過程。Flink 從一開始就使用了原生迭代的方式來保證迭代計算的效率。為了幫助用戶更好的開發(fā)算法，簡化代碼，進(jìn)一步提高運(yùn)行效率。Flink 社區(qū)也正在統(tǒng)一流和批上迭代的語義，同時對迭代性能進(jìn)行更進(jìn)一步的優(yōu)化，新的優(yōu)化將盡可能避免迭代輪次之間的同步開銷，允許不同批次的數(shù)據(jù)、不同輪次的迭代同時進(jìn)行。

圖7
當(dāng)然，在一個完整的 AI 架構(gòu)中，除了以上提到的三個主要階段，還有很多其他工作需要完成，包括對各種數(shù)據(jù)源的對接，已有 AI 生態(tài)的對接，在線的模型和樣本監(jiān)控和各類周邊配套支持系統(tǒng)等。阿里巴巴實(shí)時計算負(fù)責(zé)人王峰（花名莫問）在 2019 年 FFA 的主題演講中的一張圖（圖8）很好的總結(jié)了其中許多工作。

圖8
Flink 社區(qū)也正在為此做出努力。大致上來說，這些 AI 相關(guān)的工作可以分成補(bǔ)足，提高和創(chuàng)新三類。下面羅列了其中一部分進(jìn)行中的工作，有些工作也許與 AI 不直接相關(guān)，但是卻會對 Flink 更好的服務(wù)于 AI 實(shí)時化產(chǎn)生影響。補(bǔ)足：人有我無

• Flink ML Pipeline [12]：幫助用戶方便的存儲和復(fù)用一個機(jī)器學(xué)習(xí)的完整計算邏輯。
• Flink Python API（PyFlink [13]）：Python 是 AI 的母語，PyFlink 為用戶提供 AI 中最重要的編程接口。
• Notebook Integration [14]（Zeppelin）：為用戶的 AI 實(shí)驗(yàn)提供友好的 API。
• 原生 Kubernetes 支持 [15]：和 Kubernetes 集成來支持基于云原生的的開發(fā)、部署和運(yùn)維。

提高：人有我強(qiáng)

• Connector 的重新設(shè)計和優(yōu)化 [16]：簡化 Connector 實(shí)現(xiàn)，擴(kuò)大 Connector 生態(tài)。

創(chuàng)新：人無我有

• AI Flow：兼顧流計算的大數(shù)據(jù) + AI 頂層工作流抽象和配套服務(wù)（即將開源）。
• Stateful Function[9]：提供堪比在線應(yīng)用的超低延遲數(shù)據(jù)預(yù)處理和推理預(yù)測。

其中有些是 Flink 作為流行的大數(shù)據(jù)引擎的自有功能，比如豐富 Connector 生態(tài)來對接各種外部數(shù)據(jù)源。另一些則要依靠 Flink 之外的生態(tài)項目來完成，其中比較重要的是 AI Flow。它雖然起源于支持 AI 實(shí)時化架構(gòu)，但是在引擎層并不綁定 Flink，而聚焦于頂層的流批統(tǒng)一工作流抽象，旨在為不同平臺，不同引擎和不同系統(tǒng)共同服務(wù)于 AI 實(shí)時化的架構(gòu)提供環(huán)境支持。由于篇幅關(guān)系在此不多贅述，將另文向大家介紹。
寫在最后
Apache Flink 從一個簡單的流計算想法開始，直到今天成長為一個業(yè)界流行的實(shí)時計算開源項目，使所有人受益，這個過程中離不開 Flink 社區(qū)中數(shù)以百計的代碼貢獻(xiàn)者和數(shù)以萬計的用戶。我們相信 Flink 在 AI 上也能夠有所作為，也歡迎更多的人能夠加入到 Flink 社區(qū)，同我們一起共創(chuàng)并共享 AI 實(shí)時化的價值。Flink AI，未來可期。參考資料：
[1]https://ververica.cn/developers/the-number-of-github-stars-doubled-in-only-one-year/[MOU1]
[2] https://en.wikipedia.org/wiki/Lambda_architecture
[3]https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
[4]https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf
[5]https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf
[6] https://storm.apache.org/
[7] https://spark.apache.org/
[8]https://ci.apache.org/projects/flink/flink-docs-release-1.10//dev/table/sql/index.html
[9] https://statefun.io/
[10] https://github.com/alibaba/alink
[11] https://github.com/alibaba/flink-ai-extended
[12]https://cwiki.apache.org/confluence/display/FLINK/FLIP-39+Flink+ML+pipeline+and+ML+libs
[13]https://ci.apache.org/projects/flink/flink-docs-release-1.10/tutorials/python_table_api.html
[14] https://mp.weixin.qq.com/s/a6Zau9c1ZWTSotl_dMg0Xg
[15]https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/kubernetes.html
[16]https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載，如需轉(zhuǎn)載請發(fā)送郵件至yqeditor@list.alibaba-inc.com；如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：yqgroup@service.aliyun.com 進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的flink开发案例_为什么说 Flink + AI 值得期待？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。