Flink 在AI 中的價值其實和大數據Lambda架構中流批統一這兩個概念有關系，Flink為大數據實時化帶來的價值也將同樣使AI受益
大數據的發展過程
從Google奠基性的“三架馬車” 論文發表后的很長一段時間內，大數據的發展主線上都只有批計算的身影。后來隨着大家認識到數據時效性的重要作用，Twitter 開源的流計算引擎 Storm 紅極一時，各種流計算引擎也紛紛登場，其中也包括了Flink。由於成本、計算准確性和容錯性等方面的考慮，各家企業紛紛使用起了被稱為 Lambda架構 的解決方案，在同一個架構下融合批計算和流計算，以便在成本，容錯和數據時效性之間達到一個平衡。
Lambda架構在解決數據時效性的同時也存在一些問題，其中最受詬病的就是其系統復雜度和可維護性。用戶需要為Batch Layer 和 Speed Layer 各維護一套引擎和代碼，還需要保證二者之間的計算邏輯完全一致（圖1）
為了解決這個問題，各個計算引擎不約而同的開始了流批統一的嘗試，試圖使用同一套引擎來執行流和批的任務。經過若干年的大浪淘沙，Spark 和 Flink 成為了目前處於第一梯隊的兩款主流計算引擎。
- Flink 是從流計算逐漸進入到批計算，一個非常典型的成功案例就是使用同一套標准的SQL語句對流和批進行查詢，並保證最終結果一致性。
- 而Spark 則是采用微批 (Micro Batch) 的方式從批計算進入到流計算 提出了Spark Streaming，但是在時延的表現上始終遜色一些。
可以看到，在大數據的發展過程中，Lambda 架構和流批一體背后的原始驅動力是數據實時化。同樣是向數據要價值，AI對數據時效性的要求同大數據是一致的。因此AI實時化也將會是一個重要的發展方向。在觀察目前主流的AI場景和技術架構時，我們也會發現它們與大數據平台有很多聯系和相似之處。
AI 處理階段
- 數據預處理（數據准備/特征工程）：數據預處理階段是模型訓練和推理預測的前置環節，很多時候它更多的是一個大數據問題。
- 根據數據預處理后的下游不同，數據預處理可能是批計算也可能是流計算，計算類型和下游一致。
- 在一個典型的離線訓練（批計算）和在線預測（流計算）場景下，訓練和預測時要求產生輸入數據的預處理邏輯是一致的（比如相同的樣本拼接邏輯），這里的需求和Lambda架構中的需求一樣，因此一個流批統一的引擎會格外有優勢。這樣可以避免批作業和流作業使用兩個不同的引擎，省去了維護邏輯一致的兩套代碼的麻煩。
- 模型訓練：目前而言AI訓練階段基本上是批計算（離線訓練）產生靜態模型（Static Model）的過程。這是因為目前絕大多數的模型是基於獨立同分布（IID）的統計規律實現的，也就是從大量的訓練樣本中找到特征和標簽之間的統計相關性（Correlation），這些統計相關性通常不會突然變化，因此在一批樣本上訓練出的數據在另一批具有相同的特征分布的樣本上依然適用。然而這樣的離線模型訓練產生的靜態模型依然可能存在一些問題。
- 首先樣本數據可能隨着時間推移會發生分布變化，這種情況下，在線預測的樣本分布和訓練樣本的分布會產生偏移，從而使模型預測的效果變差。因此靜態模型通常需要重新訓練，這可以是一個定期過程或者通過對樣本和模型的預測效果進行監控來實現
- 另外，在有些場景下，預測階段的樣本分布可能無法在訓練階段就知曉。舉例來說，在阿里雙十一，微博熱搜，高頻交易等這類樣本分布可能發生無法預測的分布改變的場景下，如何迅速更新模型來得到更好的預測結果是十分有價值的。
- 因此一個理想的AI計算架構中，應該把如何及時更新模型納入考慮。在這方面流計算也有着一些獨特的優勢。事實上，阿里巴巴在搜索推薦系統中已經在使用在線機器學習，並且在雙十一這樣的場景下取得了良好的效果。
- 推理預測：推理預測環節的環境和計算類型比較豐富，既有批處理（離線預測）又有流處理。流式預測又大致可以分為在線 (Online) 預測和近線 (Nearline) 預測。
- 在線預測：通常處於用戶訪問的關鍵鏈路(Critical Path中)，因此對latency的要求極高，比如毫秒級。
- 近線預測：要求略低一些，通常在亞秒級到秒級。
- 目前大多數純流式分布式計算（Native Stream Processing）引擎可以滿足近線數據預處理和預測的需求，而在線數據預處理和預測則通常需要將預測代碼寫進應用程序內部來滿足極致的低延遲要求。因此在線預測的場景也比較少看到大數據引擎的身影。在這方面Flink的Stateful Function 是一個獨特的創新，Stateful Function 的設計初衷是在Flink上通過若干有狀態的函數來構建一個在線應用，通過它可以做到超低延遲的在線預測服務，這樣用戶可以在離線，近線和在線三種場景下使用同一套代碼同一個引擎來進行數據預處理和預測。
Flink和AI實時化的架構
目前最典型的AI架構示例是離線訓練配合在線推理預測
這個架構存在兩個問題：
- 模型更新的周期通常比較長。
- 離線和在線的預處理可能需要維護兩套代碼。
為了解決第一個問題，我們需要引入一個實時訓練的鏈路
-
在這個鏈路中，線上的數據在用於推理預測之外還會實時生成樣本並用於在線模型訓練。在這個過程中，模型是動態更新的，因此可以更好的契合樣本發生的變化。
不論是純在線還是純離線的鏈路，都並非適合所有的AI場景。和 Lambda 的思想類似，我們可以把兩者結合
同樣的，為了解決系統復雜度和可運維性的問題（也就是上面提到的第二個問題），我們希望在數據預處理的部分用一個流批統一的引擎來避免維護兩套代碼，如下圖。不僅如此，我們還需要數據預處理和推理預測能夠支持離線，近線和在線的各種Latency要求，所以使用Flink是一個非常合適的選擇。尤其是對於數據預處理環節而言，Flink 在流和批上全面完整的 SQL支持可以大大提高的開發效率。
流批一體算法庫Alink
Alink 是阿里巴巴機器學習算法團隊從 2017 年開始基於實時計算引擎 Flink 研發的新一代機器學習算法平台，提供豐富的算法組件庫和便捷的操作框架，開發者可以一鍵搭建覆蓋數據處理、特征工程、模型訓練、模型預測的算法模型開發全流程。作為業界首個同時支持批式算法、流式算法的機器學習平台，Alink 提供了 Python 接口，開發者無需 Flink 技術背景也可以輕松構建算法模型。Alink 這個名字取自相關名稱（Alibaba, Algorithm, AI, Flink,Blink）的公共部分。
AI訓練中迭代收斂是一個最核心的計算過程。Flink從一開始就使用了原生迭代的方式來保證迭代計算的效率。為了幫助用戶更好的開發算法，簡化代碼，進一步提高運行效率。Flink社區也正在統一流和批上迭代的語義，同時對迭代性能進行更進一步的優化，新的優化將盡可能避免迭代輪次之間的同步開銷，允許不同批次的數據、不同輪次的迭代同時進行。
當然，在一個完整的AI架構中，除了以上提到的三個主要階段，還有很多其他工作需要完成，包括對各種數據源的對接，已有AI生態的對接，在線的模型和樣本監控和各類周邊配套支持系統等。阿里巴巴實時計算負責人王峰（花名莫問）在2019年FFA的主題演講中的下圖很好的總結了其中許多工作。
ALink開源算法
參考資料