作者 | 蔡芳芳
采訪嘉賓 | 王峰（花名莫問）
11月28日，Flink Forward Asia 2019 在北京國家會議中心召開，阿裡在會上釋出Flink 1.10版本功能前瞻，同時宣布基于Flink的機器學習算法平台Alink正式開源，這也是全球首個批流一體的算法平台，旨在降低算法開發門檻，幫助開發者掌握機器學習的生命全周期。在去年的Flink Forward China峰會上，阿裡宣布将開源Flink的内部分支Blink，把阿裡内部對Flink的優化工作全部開放給開源社群，在業内引發熱烈讨論，其中有期待也有懷疑。一年後的今天，阿裡是否兌現了去年所作的承諾？Blink的合并工作進展如何？剛剛開源的Alink算法平台有哪些獨特之處？AI前線在會上對阿裡巴巴資深技術專家、實時計算負責人王峰（花名莫問）進行了獨家專訪，讓我們一起來看看Flink的最新變化，以及阿裡基于Flink又有哪些新的工作成果。
自 2019 年 1 月起，阿裡巴巴逐漸将内部維護的 Blink 回饋給 Flink 開源社群，目前貢獻代碼數量已超過 100 萬行。國内包括騰訊、百度、位元組跳動等公司，國外包括 Uber、Lyft、Netflix 等公司都是 Flink 的使用者。
今年 8 月釋出的 Flink 1.9.0 是阿裡内部版本 Blink 合并入 Flink 後的首次發版，在今天的 Flink Forward 2019 大會上，阿裡釋出了 Flink 1.10 版本功能前瞻，正式版本預計于 2020 年 1 月釋出。
Flink 1.10 版本功能前瞻：Blink 全部功能進入 Flink
據介紹，Flink 1.10 版本可以看作一個比較重要的裡程碑式版本，至此，Blink 全部功能都已經進入 Flink，包括 Blink 中比較關鍵的設計和通用的優化。以下是該版本将包含的主要功能和技術亮點前瞻：
1.完成Blink/Flink merge
（1）更加強大的Blink Query Processor
- DDL 增強，支援在建表語句中定義計算列和 watermark
-
生産級别的Batch支援，完整支援 TPC-H 和TPC-DS 測試集，其中 TPC-DS 10T的性能是Hive3.0的7倍
（2）完成scheduler的重構，支援更靈活batch排程政策
（3）更完善，更細粒度，更靈活的資源管理
- 對 TaskExecutor 的記憶體模型進行了梳理，解決了 RockDB 記憶體難以配置和管控、TM 啟動前後記憶體計算不一緻等長期存在的問題
- 簡化了記憶體計算邏輯，降低了配置難度
- 對算子級别的資源用量進行更精細的管理，解決算子資源超用帶來的性能及穩定性問題，提高資源利用效率
2.Hive相容性生産可用
（1）Meta 相容，支援直接讀取 Hive catalog，版本覆寫1.x，2.x到3.x
（2）資料格式相容，支援直接讀取 Hive 表，同時也支援寫成 Hive 表的格式
（3）UDF 相容，支援在 Flink SQL 内直接調用 Hive 的UDF，UDTF，UDAF
3.更加強大的Python支援
- 增加了對 NativePython UDF 的支援，使用者可以用Python開發自己的業務邏輯
- 很好的支援了 Python 類庫的依賴管理，Python使用者不僅可以自定義Python UDF 而且可以與其他現有的Python library進行內建
- 在架構上引入了BeamPortability Framework，Flink與Beam社群共同打造功能便捷，性能優越的Python UDF支援架構
- 與Flink資源管理架構進行內建，實作了對Python UDF資源的管控
4.支援原生K8S內建
（1）原生的資源管理，可以根據作業的資源需求動态去申請TaskManager，不需要依賴外部系統或元件
（2）更加友善的任務送出，不需要安裝kubectl等工具，可以達到和Yarn相似的體驗
5.新增多個主流機器學習算法庫
（1）包括邏輯回歸，随機森林，KMeans等
提問：在 1.10 版本中，Blink 全部功能都已經進入 Flink，而這距離上一次 1.9 釋出剛過去三個月，那也是 Blink 首次并入 Flink 的版本釋出，距離去年阿裡宣布要開源 Blink 也不過一年時間。為什麼 Blink 的 Merge 進度能做到這麼快？過程中遇到了哪些問題？你們是如何解決的？
莫問： 我們投入了很多資源，包括有數十位技術人員來做這個事情，并行度比較大，是以才能在比較短的時間内貢獻多達 150 萬行代碼。
提問：整個過程中有沒有遇到什麼比較棘手的問題？
莫問： 社群是一個相對開放透明的場景，不像自己的項目可以比較随意地改動，而是要走一個民主的過程，包括要經過社群的讨論、大家的認可，要保證代碼的品質等。我們既要做到快速推進，還要保證品質和社群的公平性，這個挑戰還是很大的。
提問：是以你們怎麼平衡這兩件事情？
莫問： 整個 Flink 社群的合作模式是比較高效的，社群不同子產品的負責人每周都會有視訊會議，可能是不同國家的社群讨論，這些都做得非常高效，項目管理做得非常好。在這種機制的保證下，我們可以讓代碼快速進入同時保證疊代的速度。其實這對工程效率的開發也是非常大的挑戰。說白了，我們投入了很多技術人員做這件事，但也不是隻看數量。我們投入的很多人手本身就是 Apache 項目的 PMC 和 Committer，而不完全是普通的工程師，這些人本身對于 Apache 項目的工作機制和流程都比較熟悉，他們的效率和作戰能力不能按一個人這麼算。社群就是這樣，不是人多的問題，還需要合适的人。
提問：您上午在演講中提到 Flink 正在成為一個真正的 Unified Engine。有趣的是，我們近期已經不止一次聽到不同的計算引擎提出類似的說法，比如 Spark 的核心理念也是成為“統一資料分析平台”，能否請您談談 Flink 的設計理念？二者的統一有什麼相同點和不同點？
莫問：Flink 的核心理念我們強調過很多次，它的本質計算思想是流處理核心。流處理核心就是所有的都是基于 Stream 來處理，批可以看作是一個有限的流。像今天提到的線上的 Stateful Function 也是 Event Driven，所有的 Event 不停地進入做函數計算，做線上有狀态的計算，然後把結果給使用者，再不停地疊代。其實線上服務也是無限的，也是不會停止的處理，不停地有人通路，有人處理。Flink 的核心是基于流計算的 Core，去覆寫 Offline 和 Online，這樣它跟 Spark 還是不太一樣的。Spark 認為所有東西都是基于 Batch 的，而流是無數個 Batch 湊在一起，這一點不太一樣。
但大家在宏觀上的願景都是類似的，用一套計算引擎技術或大資料處理的技術，來解決盡量多的場景，這樣從使用者的角度來說學習成本更低、開發效率更高、運維成本也更低。是以大家的目标和理念是一緻的，隻不過在實作這個目标的方法上的選擇是不一樣的。
**提問：下面這個問題我們之前問過 Databricks 的工程師，今天也想問問您，如果我要做統一的平台，你也要做統一平台，那會不會存在最後到底誰能真正統一誰的問題？
**莫問： 我覺得大家并不是說做什麼，什麼就一定會赢，一定會好。從我個人态度來說，技術還是需要有一定良性的競争，這樣才能互相學習，同時條條大路通羅馬，不一定哪一個絕對正确，可能不同場景有不同的偏好或不同的特定區域的需求，或适應的場景不一樣。解決類似問題有兩三家公司共存，這種狀态是比較健康的，就像資料庫領域有 MySQL、PostgreSQL 等，線上服務也類似，起碼得有兩家大公司在一起競争，是比較合适的。但最終哪個做得更好，還是取決于是否能把自己的理論做到極緻。因為理論是理論，你的理論和我的理論聽起來各有千秋，但是誰最後能赢看的是細節，包括使用者體驗。你是否按照正确的方法在做，細節做得夠不夠好，而不是大家聽起來思路一樣就沒有差別了。細節和社群生态的發展、推進過程都很重要。
開源 Alink：Flink 機器學習進度幾何？
Flink 在機器學習領域的進展一直是衆多開發者關注的焦點，今年 Flink 迎來了一個小裡程碑：機器學習算法平台 Alink 開源，這也宣告了 Flink 正式切入 AI 領域。
Alink 開源項目連結：
https://github.com/alibaba/AlinkAlink 是阿裡巴巴機器學習算法團隊從 2017 年開始基于實時計算引擎 Flink 研發的新一代機器學習算法平台，提供豐富的算法元件庫和便捷的操作架構，開發者可以一鍵搭建覆寫資料處理、特征工程、模型訓練、模型預測的算法模型開發全流程。作為業界首個同時支援批式算法、流式算法的機器學習平台，Alink 提供了 Python 接口，開發者無需 Flink 技術背景也可以輕松建構算法模型。Alink 這個名字取自相關名稱（Alibaba, Algorithm, AI, Flink,Blink）的公共部分。
據悉，Alink 已被廣泛運用在阿裡巴巴搜尋、推薦、廣告等多個核心實時線上業務中。在剛剛落幕的天貓雙 11 中，單日資料處理量達到 970PB，每秒處理峰值資料高達 25 億條。Alink 成功經受住了超大規模實時資料訓練的檢驗，并幫助提升 4% CTR（商品點選轉化率）。
提問：能否先介紹一下 FlinkML 和 Alink 的概況，以及二者的關系？
莫問：FlinkML 是 Flink 社群現存的一套機器學習算法庫，這一套算法庫已經存在很久而且更新比較緩慢。Alink 是基于新一代的 Flink，完全重新寫了一套，跟 FlinkML 沒有代碼上的關系。Alink 由阿裡巴巴大資料團隊開發，開發出來以後在阿裡巴巴内部也用了，然後現在正式開源出來。
未來我們希望 Alink 的算法逐漸替換掉 FlinkML 的算法，可能 Alink 就會成為新一代版本的 FlinkML，當然替換還需要一個比較漫長的過程。Alink 包含了非常多的機器學習算法，往 Flink 貢獻或釋出的時候也需要比較大的帶寬，我們擔心整個過程耗時會比較長，是以先把 Alink 單獨開源出來，大家如果有需要的可以先用起來。後面貢獻進展比較順利的情況下，Alink 應該能完全合并到 FlinkML，也就是直接進入 Flink 生态的主幹，這對于 Alink 來說是最好的歸宿，到這個時候 FlinkML 就可以跟 SparkML 完全對應起來了。
提問：除了 Alink 以外，Flink 目前在機器學習領域的工作還有哪些進展？和其他計算引擎相比，您如何評價目前 Flink 在機器學習和 AI 領域的工作，它的競争力足夠強嗎？
莫問： 其實我們還有很多正在進行的工作。機器學習的核心是疊代計算，機器學習訓練就是不停地對資料進行疊代訓練，訓練出來一個模型然後上線。在核心訓練的基礎上，Flink 正在設計新的疊代計算，因為 Flink 是基于流式計算，是以它的疊代計算可以轉化為 mini-batch 的疊代計算，可以根據資料條目數也可以根據資料段的時長，在流上打出很多細粒度的資料段。
Flink 的好處是在流上打細粒度的資料段可行性上沒有問題，因為它本來就是純流式的，截成一段一段沒有問題。而 Spark 的疊代是把一個資料集做一次疊代，再做一次疊代，這個資料集很難切得特别細，切出來一段就是一次任務的運作，細粒度的挑戰比較大。Flink 的好處是本身可以把粒度截得很細，是以重構原有的疊代計算是可行的。
Flink 最早的疊代計算也跟 Spark 一樣，要麼是一批疊代要麼是一條一條疊代，完全是兩個極端，我們想把它做一個抽象，可以按照時間、大小來設定疊代的 batch 大小，就類似于 Flink 視窗的概念，這樣可以支援嵌套疊代、增量疊代等。我們在引擎層面做好了基于流的疊代技術之後，整個機器學習的訓練就會大幅度加速。雖然算法本身的效果可能是一樣的，但是運作的性能和速度不一樣。
同時它還可以解決線上訓練的問題，比如說網際網路的日志流、使用者行為是不停産生的，Flink 流式疊代可以不間斷地處理使用者産生的實時資料，可以線上疊代更新，模型可以每隔 5 分鐘更新一次，也可以每隔 1 分鐘更新一次。這樣它的模型上線是一個 7×24 小時環狀的更新，這樣一套線上學習的體系會給使用者帶來很大的變化，這個變化不是簡單的 30% 的提升或者是工程上的優化，而是在使用機器學習的理念上會有優化。
這是我們目前正在做的工作，社群裡也已經開始讨論了，可能會作為 Flink 明年 1-2 個版本的重點。你可以這麼認為，Flink 去年還是 Unified Engine，今年開始擁抱 AI 了，2019 年我們做的很多工作是偏 SQL 的優化，明年我們會更多地切入到 AI，就是 FlinkML 和 AI 場景的方向上。
**提問：阿裡是什麼時候決定開源 Alink 的？
**
莫問： 去年 Blink 開源的時候，我們就在考慮是否把 Alink 一起開源了。但是後來覺得，第一個開源還沒做，不敢一下子步子邁得這麼大，要一步步來，而且 Blink 開源也要準備很多東西。當時我們沒有辦法做到兩個大的項目同時開源，是以就先把 Blink 開源做好。
Blink 開源以後，我們想是不是把 Alink 的算法推到 Flink 就好了。但是發現往社群貢獻确實是比較複雜的過程，Blink 在推的時候已經占用了很大的帶寬，而社群的帶寬就那麼多，沒有辦法同時做多件事情。社群也需要一段時間消耗，是以決定先把 Blink 消耗掉，貢獻完了，社群吃得下，然後再把 Alink 逐漸貢獻回社群。這是沒有辦法跨越的一個過程。
開源是一個很慎重的過程，不能随意想開就開一個。孩子不能管生不管養，要發東西就要有一個長期的計劃，要負責任的，得給大家一個很明确的信号，這是有長期計劃的，不是放了開源就結束了，以後肯定會有使用者問你們放上去以後管不管？如果我們不想好這些問題，對使用者來說就适得其反，大家覺得你并沒有給大家一個清晰的信号，大家也不敢用。
提問：相比 SparkML，Alink 的亮點是什麼？對于開發者來說在哪些方面會比較有吸引力？
莫問：Alink 一是依賴于 Flink 計算引擎層；第二 Flink 架構中有 UDF 的算子，Alink 本身對算法做了很多優化，包括在算法實作上做了細節的優化，比如通信、資料通路、疊代資料處理的流程等多方面的優化。基于這些優化可以讓算法運作的效率更高，同時我們還做了很多配套工具，讓易用性更好。同時 Alink 還有一個核心技術，就是做了很多 FTRL 的算法，是天然針對線上學習的。線上學習需要高頻快速更新的疊代算法，這種情況下 Alink 有天然的優勢，像今日頭條、微網誌的資訊流都會經常遇到這樣的線上場景。
在離線學習上 Alink 跟 SparkML 對比基本上差不多，隻要大家工程化都做得足夠好，離線學習無法打出代差，真正的代差一定是設計上的理念不一樣。設計上、産品形态、技術形态不一樣才會有代差明顯的優勢。
相比 SparkML，我們的基調是批式算法基本一緻，包括功能和性能，Alink 可以支援算法工程師常用的所有算法，包括聚類、分類、回歸、資料分析、特征工程等，這些類型的算法是算法工程師常用的。我們開源之前也對标了 SparkML 所有的算法，做到了 100% 對标。除此之外，Alink 最大的亮點是有流式算法和線上學習，在自己的特色上能做到獨樹一幟，這樣對使用者來說沒有短闆，同時優勢又很明顯。
Alink 支援的機器學習算法
後續規劃和未來展望
提問：接下來 Flink 會按照什麼樣的頻率更新版本？能否透露 Flink 接下來還會有哪些值得期待的新特性或功能？
莫問：3-4 個月，基本上會是一個季度更新一個版本，比如 2020 年 1 月份會發 1.10，4 月份會發 1.11。現在還說不好什麼時候切 2.0，2.0 應該會是一個非常有裡程碑意義的版本。現在 Flink 社群可以看到非常多的點，不僅有 AI、機器學習，還有今天主題演講 Stephan Ewen 提到的 Stateful Function，也是非常有前景的。其實線上場景還有很多有前景的東西可以挖掘，Serverless（Faas）也是 Flink 後面的方向。Flink 社群有一點非常好，它剛剛演進到 1.x 版本，還有很大的上升空間，社群的生命力和狀态都很好，大家有很多想法想放進去。
提問：未來大資料領域還有哪些新的技術方向或趨勢是比較重要的？
莫問： 大資料和 AI 的融合可能是一個很好的機會，大家現在純玩大資料基本上五花八門什麼都玩過了，各種項目層出不窮。AI 也是百花争鳴，但其實使用者想要的不隻是 AI，資料在哪？AI 沒有資料怎麼玩？得把特征算好、樣本算好才能訓練出好的模型。這個模型隻有經過不斷地疊代回報才能越來越好。這個過程中資料處理和資料分析非常重要，如果沒有一套完整的回報體系，大資料 +AI 的鍊路玩不通。有再好的引擎，如果沒有閉環的計算路徑也無法真正發揮生産或業務上的效果。
是以要把大資料 +AI 整套處理做成非常易用、好用的解決方案，這是大家最需要的。現在可能一個個零散的點大家已經做到了，很多東西都能找到對應的開源項目，但是需要有一個整體的平台把所有技術串起來。
提問：Flink 在一定程度上也想做這樣的？
莫問： 明年我們會開源一個新的項目 AI Flow，目前還沒有 Ready，我們希望 AI Flow 可以通過一個工作流程把資料處理、預處理，包括模型的訓練、模型管理、模型上線、動态更新，更新完拿到回報，回報之後怎麼反向優化流程，整個系統串起來。其中每個環節都可以使用不同的引擎來實作，用 Flink OK，用 Spark 也 OK，就看最後哪個好用。比如可以用 Flink 做大資料處理，TensorFlow 做深度學習訓練，FlinkML 做流式訓練，把這些都串聯起來給使用者提供一個端到端的解決方案，這是很有前景的一個項目。
提問：這是不是跟 Databricks 的 MLflow 有點類似？
莫問：AI Flow 大于 MLflow，因為 MLflow 隻定義了資料格式，AI Flow 可能跟 Kubeflow 更像，AI Flow 偏工作流程，MLflow 偏重于資料格式，沒有覆寫特别完整的工作流程，但我們也不排除 MLflow 将來越做越大。
為什麼我們要做這個東西？因為我們在阿裡巴巴内部非常熟悉整個搜尋推薦廣告最核心的系統怎麼玩，如何一步步流程化才能形成一套大腦去調控整個流量，甚至是搜尋流量、推薦流量、廣告流量，在業務流量和現金流量去 battle 等，這是整個商業化最核心的系統，這個系統就是基于大資料 +AI 的方案，而這套方案離不開 workflow，離不開資料格式的定義，離不開不同計算引擎的協同，這是更大的一個概念。我們明年會在這方面投入更多資源，也會聯合其他的公司一起來做。