爲何說 Flink + AI 值得期待？

去年 11 月的 Flink Forward Asia 2019（如下簡稱 FFA） 上 Flink 社區提出了將來發展的幾個主要方向，其中之一就是擁抱 AI [1]。實際上，近年來 AI 持續火熱，各類計算框架、模型和算法層出不窮，從某種角度上來講，這個賽道已經有些擁擠了。在這種狀況下， Flink 將怎樣擁抱 AI，又會爲用戶帶來什麼新的價值？Flink AI 的優劣勢分別在哪裏？本文將經過對這些問題的討論來分析 Flink AI 的發展方向。

Lambda 架構，流批統一和 AI 實時化

Flink 在 AI 中的價值其實和大數據中 Lambda 架構[2]和流批統一這兩個概念有關係，Flink 爲大數據實時化帶來的價值也將一樣使 AI 受益。

不妨讓咱們簡單回顧一下大數據的發展過程。從 Google 奠定性的「三架馬車」 3[5] 論文發表後的很長一段時間內，大數據的發展主線上都只有批計算的身影。後來隨着你們認識到數據時效性的重要做用，Twitter 開源的流計算引擎 Storm [6] 紅極一時，各類流計算引擎也紛紛登場，其中也包括了 Flink。因爲成本、計算準確性和容錯性等方面的考慮，各家企業紛紛使用起了被稱爲 Lambda 架構的解決方案，在同一個架構下融合批計算和流計算，以便在成本，容錯和數據時效性之間達到一個平衡。

Lambda 架構在解決數據時效性的同時也存在一些問題，其中最受詬病的就是其系統複雜度和可維護性。用戶須要爲 Batch Layer 和 Speed Layer 各維護一套引擎和代碼，還須要保證兩者之間的計算邏輯徹底一致（圖1）。

圖1

爲了解決這個問題，各個計算引擎不約而同的開始了流批統一的嘗試，試圖使用同一套引擎來執行流和批的任務（圖2）。通過若干年的大浪淘沙，Spark [7] 和 Flink 成爲了目前處於第一梯隊的兩款主流計算引擎。Flink 是從流計算逐漸進入到批計算，一個很是典型的成功案例就是使用同一套標準的 SQL 語句對流和批進行查詢，並保證最終結果一致性[8]。而 Spark 則是採用微批 (Micro Batch) 的方式從批計算進入到流計算提出了 Spark Streaming，可是在時延的表現上始終遜色一些。

圖2

能夠看到，在大數據的發展過程當中，Lambda 架構和流批一體背後的原始驅動力是數據實時化。一樣是向數據要價值，AI 對數據時效性的要求同大數據是一致的。所以AI實時化也將會是一個重要的發展方向。在觀察目前主流的 AI 場景和技術架構時，咱們也會發現它們與大數據平臺有不少聯繫和類似之處。

目前的 AI 大體能夠分爲數據預處理（也稱數據準備/特徵工程等），模型訓練和推理預測三個主要階段。下面咱們逐一來看一看在每一個階段中 AI 實時化需求有哪些，又有什麼樣的問題待解決。爲了便於與大數據的架構作類比，咱們姑且認爲流計算和批計算做爲一種計算類型的劃分維度已經將全部基於數據的計算一分爲二，沒有遺漏了。AI 的各個階段根據場景不一樣，也能夠歸爲兩者之一。

數據預處理（數據準備/特徵工程）

數據預處理階段是模型訓練和推理預測的前置環節，不少時候它更多的是一個大數據問題。根據數據預處理後的下游不一樣，數據預處理多是批計算也多是流計算，計算類型和下游一致。在一個典型的離線訓練（批計算）和在線預測（流計算）場景下，訓練和預測時要求產生輸入數據的預處理邏輯是一致的（好比相同的樣本拼接邏輯），這裏的需求和 Lambda 架構中的需求同樣，所以一個流批統一的引擎會格外有優點。這樣能夠避免批做業和流做業使用兩個不一樣的引擎，省去了維護邏輯一致的兩套代碼的麻煩。

模型訓練

目前而言 AI 訓練階段基本上是批計算（離線訓練）產生靜態模型（Static Model）的過程。這是由於目前絕大多數的模型是基於獨立同分布（IID）的統計規律實現的，也就是從大量的訓練樣本中找到特徵和標籤之間的統計相關性（Correlation），這些統計相關性一般不會忽然變化，所以在一批樣本上訓練出的數據在另外一批具備相同的特徵分佈的樣本上依然適用。然而這樣的離線模型訓練產生的靜態模型依然可能存在一些問題。

首先樣本數據可能隨着時間推移會發生分佈變化，這種狀況下，在線預測的樣本分佈和訓練樣本的分佈會產生偏移，從而使模型預測的效果變差。所以靜態模型一般須要從新訓練，這能夠是一個按期過程或者經過對樣本和模型的預測效果進行監控來實現（注意這裏的監控自己實際上是一個典型的流計算需求）。

另外，在有些場景下，預測階段的樣本分佈可能沒法在訓練階段就知曉。舉例來講，在阿里雙十一，微博熱搜，高頻交易等這類樣本分佈可能發生沒法預測的分佈改變的場景下，如何迅速更新模型來獲得更好的預測結果是十分有價值的。

所以一個理想的 AI 計算架構中，應該把如何及時更新模型歸入考慮。在這方面流計算也有着一些獨特的優點。事實上，阿里巴巴在搜索推薦系統中已經在使用在線機器學習，而且在雙十一這樣的場景下取得了良好的效果。

推理預測

推理預測環節的環境和計算類型比較豐富，既有批處理（離線預測）又有流處理。流式預測又大體能夠分爲在線 (Online) 預測和近線 (Nearline) 預測。在線預測一般處於用戶訪問的關鍵鏈路(Critical Path 中)，所以對 latency 的要求極高，好比毫秒級。而近線預測要求略低一些，一般在亞秒級到秒級。目前大多數純流式分佈式計算（Native Stream Processing）引擎能夠知足近線數據預處理和預測的需求，而在線數據預處理和預測則一般須要將預測代碼寫進應用程序內部來知足極致的低延遲要求。所以在線預測的場景也比較少看到大數據引擎的身影。在這方面 Flink 的 Stateful Function [9] 是一個獨特的創新，Stateful Function 的設計初衷是在 Flink 上經過若干有狀態的函數來構建一個在線應用，經過它能夠作到超低延遲的在線預測服務，這樣用戶能夠在離線，近線和在線三種場景下使用同一套代碼同一個引擎來進行數據預處理和預測。

綜上所述，能夠看到在機器學習的每一個主要階段中對 AI 實時化都有重要的需求，那什麼樣的系統架構可以有效知足這樣的需求呢？

Flink 和 AI 實時化的架構

目前最典型的 AI 架構示例是離線訓練配合在線推理預測（圖3）。

圖3

正如以前提到的，這個架構存在兩個問題：

1. 模型更新的週期一般比較長。
2. 離線和在線的預處理可能須要維護兩套代碼。

爲了解決第一個問題，咱們須要引入一個實時訓練的鏈路（圖4）。

圖4

在這個鏈路中，線上的數據在用於推理預測以外還會實時生成樣本並用於在線模型訓練。在這個過程當中，模型是動態更新的，所以能夠更好的契合樣本發生的變化。

不管是純在線仍是純離線的鏈路，都並不是適合全部的 AI 場景。和 Lambda 的思想相似，咱們能夠把二者結合（圖5）。

圖5

一樣的，爲了解決系統複雜度和可運維性的問題（也就是上面提到的第二個問題），咱們但願在數據預處理的部分用一個流批統一的引擎來避免維護兩套代碼（圖6）。不只如此，咱們還須要數據預處理和推理預測可以支持離線，近線和在線的各類 Latency 要求，因此使用 Flink 是一個很是合適的選擇。尤爲是對於數據預處理環節而言，Flink 在流和批上全面完整的 SQL 支持能夠大大提升的開發效率。

圖6

除此以外，爲了進一步下降系統的複雜度，Flink 也在模型訓練環節進行了一系列努力（圖7）。

• 流批一體算法庫 Alink

在去年的 FFA 2019 上，阿里巴巴宣佈開源了基於 Flink 的機器學習算法庫 Alink [10]，並計劃將其逐步貢獻回 Apache Flink，做爲 Flink ML Lib 隨 Apache Flink 發佈。除了離線學習的算法外，Alink 的一大特點就是爲用戶提供了在線學習算法，助推 Flink 在 AI 實時化上發揮更大的做用。

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

幫助用戶把目前流行的深度學習框架（TensorFlow、PyTorch）整合到 Flink 中。使除了深度學習算法開發者以外的用戶能夠基於 Flink 實現整套 AI 架構。

• 流批統一的迭代語義和高性能實現

AI 訓練中迭代收斂是一個最核心的計算過程。Flink 從一開始就使用了原生迭代的方式來保證迭代計算的效率。爲了幫助用戶更好的開發算法，簡化代碼，進一步提升運行效率。Flink 社區也正在統一流和批上迭代的語義，同時對迭代性能進行更進一步的優化，新的優化將盡量避免迭代輪次之間的同步開銷，容許不一樣批次的數據、不一樣輪次的迭代同時進行。

圖7

固然，在一個完整的 AI 架構中，除了以上提到的三個主要階段，還有不少其餘工做須要完成，包括對各類數據源的對接，已有 AI 生態的對接，在線的模型和樣本監控和各種周邊配套支持系統等。阿里巴巴實時計算負責人王峯（花名莫問）在 2019 年 FFA 的主題演講中的一張圖（圖8）很好的總結了其中許多工做。

圖8

Flink 社區也正在爲此作出努力。大體上來講，這些 AI 相關的工做能夠分紅補足，提升和創新三類。下面羅列了其中一部分進行中的工做，有些工做也許與 AI 不直接相關，可是卻會對 Flink 更好的服務於 AI 實時化產生影響。

補足：人有我無

• Flink ML Pipeline [12]：幫助用戶方便的存儲和複用一個機器學習的完整計算邏輯。
• Flink Python API（PyFlink [13]）：Python 是 AI 的母語，PyFlink 爲用戶提供 AI 中最重要的編程接口。
• Notebook Integration [14]（Zeppelin）：爲用戶的 AI 實驗提供友好的 API。
• 原生 Kubernetes 支持 [15]：和 Kubernetes 集成來支持基於雲原生的的開發、部署和運維。

提升：人有我強

• Connector 的從新設計和優化 [16]：簡化 Connector 實現，擴大 Connector 生態。

創新：人無我有

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

其中有些是 Flink 做爲流行的大數據引擎的自有功能，好比豐富 Connector 生態來對接各類外部數據源。另外一些則要依靠 Flink 以外的生態項目來完成，其中比較重要的是 AI Flow。它雖然起源於支持 AI 實時化架構，可是在引擎層並不綁定 Flink，而聚焦於頂層的流批統一工做流抽象，旨在爲不一樣平臺，不一樣引擎和不一樣系統共同服務於 AI 實時化的架構提供環境支持。因爲篇幅關係在此很少贅述，將另文向你們介紹。

寫在最後

Apache Flink 從一個簡單的流計算想法開始，直到今天成長爲一個業界流行的實時計算開源項目，使全部人受益，這個過程當中離不開 Flink 社區中數以百計的代碼貢獻者和數以萬計的用戶。咱們相信 Flink 在 AI 上也可以有所做爲，也歡迎更多的人可以加入到 Flink 社區，同咱們一塊兒共創並共享 AI 實時化的價值。

查看更多：https://yqh.aliyun.com/detail..._content=g_1000105250

上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/