11月28日，F(xiàn)link Forward Asia 2019 在北京國(guó)家會(huì)議中心召開，阿里在會(huì)上發(fā)布Flink 1.10版本功能前瞻，同時(shí)宣布基于Flink的機(jī)器學(xué)習(xí)算法平臺(tái)Alink正式開源，這也是全球首個(gè)批流一體的算法平臺(tái)，旨在降低算法開發(fā)門檻，幫助開發(fā)者掌握機(jī)器學(xué)習(xí)的生命全周期。在去年的Flink Forward China峰會(huì)上，阿里宣布將開源Flink的內(nèi)部分支Blink，把阿里內(nèi)部對(duì)Flink的優(yōu)化工作全部開放給開源社區(qū)，在業(yè)內(nèi)引發(fā)熱烈討論，其中有期待也有懷疑。一年后的今天，阿里是否兌現(xiàn)了去年所作的承諾？Blink的合并工作進(jìn)展如何？剛剛開源的Alink算法平臺(tái)有哪些獨(dú)特之處？AI前線在會(huì)上對(duì)阿里巴巴資深技術(shù)專家、實(shí)時(shí)計(jì)算負(fù)責(zé)人王峰（花名莫問）進(jìn)行了獨(dú)家專訪，讓我們一起來看看Flink的最新變化，以及阿里基于Flink又有哪些新的工作成果。 

自 2019 年 1 月起，阿里巴巴逐步將內(nèi)部維護(hù)的 Blink 回饋給 Flink 開源社區(qū)，目前貢獻(xiàn)代碼數(shù)量已超過 100 萬行。國(guó)內(nèi)包括騰訊、百度、字節(jié)跳動(dòng)等公司，國(guó)外包括 Uber、Lyft、Netflix 等公司都是 Flink 的使用者。

今年 8 月發(fā)布的 Flink 1.9.0 是阿里內(nèi)部版本 Blink 合并入 Flink 后的首次發(fā)版，在今天的 Flink Forward 2019 大會(huì)上，阿里發(fā)布了 Flink 1.10 版本功能前瞻，正式版本預(yù)計(jì)于 2020 年 1 月發(fā)布。

Flink 1.10 版本功能前瞻：Blink 全部功能進(jìn)入 Flink

據(jù)介紹，F(xiàn)link 1.10 版本可以看作一個(gè)比較重要的里程碑式版本，至此，Blink 全部功能都已經(jīng)進(jìn)入 Flink，包括 Blink 中比較關(guān)鍵的設(shè)計(jì)和通用的優(yōu)化。以下是該版本將包含的主要功能和技術(shù)亮點(diǎn)前瞻：

完成Blink/Flink merge

1. 更加強(qiáng)大的Blink Query Processor

• DDL 增強(qiáng)，支持在建表語句中定義計(jì)算列和 watermark
• 生產(chǎn)級(jí)別的Batch支持，完整支持 TPC-H 和TPC-DS 測(cè)試集，其中 TPC-DS 10T的性能是Hive3.0的7倍

2. 完成scheduler的重構(gòu)，支持更靈活batch調(diào)度策略

• 對(duì) TaskExecutor 的內(nèi)存模型進(jìn)行了梳理，解決了 RockDB 內(nèi)存難以配置和管控、TM 啟動(dòng)前后內(nèi)存計(jì)算不一致等長(zhǎng)期存在的問題
• 簡(jiǎn)化了內(nèi)存計(jì)算邏輯，降低了配置難度
•  對(duì)算子級(jí)別的資源用量進(jìn)行更精細(xì)的管理，解決算子資源超用帶來的性能及穩(wěn)定性問題，提高資源利用效率

Hive兼容性生產(chǎn)可用

1. Meta 兼容，支持直接讀取 Hive catalog，版本覆蓋1.x，2.x到3.x
2. 數(shù)據(jù)格式兼容，支持直接讀取 Hive 表，同時(shí)也支持寫成 Hive 表的格式
3. UDF 兼容，支持在 Flink SQL 內(nèi)直接調(diào)用 Hive 的UDF，UDTF，UDAF

更加強(qiáng)大的Python支持

1. 增加了對(duì) NativePython UDF 的支持，用戶可以用Python開發(fā)自己的業(yè)務(wù)邏輯
2. 很好的支持了 Python 類庫的依賴管理，Python用戶不僅可以自定義Python UDF 而且可以與其他現(xiàn)有的Python library進(jìn)行集成
3. 在架構(gòu)上引入了BeamPortability Framework，F(xiàn)link與Beam社區(qū)共同打造功能便捷，性能優(yōu)越的Python UDF支持框架
4. 與Flink資源管理框架進(jìn)行集成，實(shí)現(xiàn)了對(duì)Python UDF資源的管控

支持原生K8S集成

1. 原生的資源管理，可以根據(jù)作業(yè)的資源需求動(dòng)態(tài)去申請(qǐng)TaskManager，不需要依賴外部系統(tǒng)或組件
2. 更加方便的任務(wù)提交，不需要安裝kubectl等工具，可以達(dá)到和Yarn相似的體驗(yàn)

新增多個(gè)主流機(jī)器學(xué)習(xí)算法庫

1. 包括邏輯回歸，隨機(jī)森林，KMeans等

AI 前線：在 1.10 版本中，Blink 全部功能都已經(jīng)進(jìn)入 Flink，而這距離上一次 1.9 發(fā)布剛過去三個(gè)月，那也是 Blink 首次并入 Flink 的版本發(fā)布，距離去年阿里宣布要開源 Blink 也不過一年時(shí)間。為什么 Blink 的 Merge 進(jìn)度能做到這么快？過程中遇到了哪些問題？你們是如何解決的？

莫問： 我們投入了很多資源，包括有數(shù)十位技術(shù)人員來做這個(gè)事情，并行度比較大，所以才能在比較短的時(shí)間內(nèi)貢獻(xiàn)多達(dá) 150 萬行代碼。

AI 前線：整個(gè)過程中有沒有遇到什么比較棘手的問題？

莫問： 社區(qū)是一個(gè)相對(duì)開放透明的場(chǎng)景，不像自己的項(xiàng)目可以比較隨意地改動(dòng)，而是要走一個(gè)民主的過程，包括要經(jīng)過社區(qū)的討論、大家的認(rèn)可，要保證代碼的質(zhì)量等。我們既要做到快速推進(jìn)，還要保證質(zhì)量和社區(qū)的公平性，這個(gè)挑戰(zhàn)還是很大的。

AI 前線：所以你們?cè)趺雌胶膺@兩件事情？

莫問： 整個(gè) Flink 社區(qū)的合作模式是比較高效的，社區(qū)不同模塊的負(fù)責(zé)人每周都會(huì)有視頻會(huì)議，可能是不同國(guó)家的社區(qū)討論，這些都做得非常高效，項(xiàng)目管理做得非常好。在這種機(jī)制的保證下，我們可以讓代碼快速進(jìn)入同時(shí)保證迭代的速度。其實(shí)這對(duì)工程效率的開發(fā)也是非常大的挑戰(zhàn)。說白了，我們投入了很多技術(shù)人員做這件事，但也不是只看數(shù)量。我們投入的很多人手本身就是 Apache 項(xiàng)目的 PMC 和 Committer，而不完全是普通的工程師，這些人本身對(duì)于 Apache 項(xiàng)目的工作機(jī)制和流程都比較熟悉，他們的效率和作戰(zhàn)能力不能按一個(gè)人這么算。社區(qū)就是這樣，不是人多的問題，還需要合適的人。

AI 前線：您上午在演講中提到 Flink 正在成為一個(gè)真正的 Unified Engine。有趣的是，我們近期已經(jīng)不止一次聽到不同的計(jì)算引擎提出類似的說法，比如 Spark 的核心理念也是成為“統(tǒng)一數(shù)據(jù)分析平臺(tái)”，能否請(qǐng)您談?wù)?Flink 的設(shè)計(jì)理念？二者的統(tǒng)一有什么相同點(diǎn)和不同點(diǎn)？

莫問：Flink 的核心理念我們強(qiáng)調(diào)過很多次，它的本質(zhì)計(jì)算思想是流處理核心。流處理核心就是所有的都是基于 Stream 來處理，批可以看作是一個(gè)有限的流。像今天提到的在線的 Stateful Function 也是 Event Driven，所有的 Event 不停地進(jìn)入做函數(shù)計(jì)算，做在線有狀態(tài)的計(jì)算，然后把結(jié)果給用戶，再不停地迭代。其實(shí)在線服務(wù)也是無限的，也是不會(huì)停止的處理，不停地有人訪問，有人處理。Flink 的核心是基于流計(jì)算的 Core，去覆蓋 Offline 和 Online，這樣它跟 Spark 還是不太一樣的。Spark 認(rèn)為所有東西都是基于 Batch 的，而流是無數(shù)個(gè) Batch 湊在一起，這一點(diǎn)不太一樣。

但大家在宏觀上的愿景都是類似的，用一套計(jì)算引擎技術(shù)或大數(shù)據(jù)處理的技術(shù)，來解決盡量多的場(chǎng)景，這樣從用戶的角度來說學(xué)習(xí)成本更低、開發(fā)效率更高、運(yùn)維成本也更低。所以大家的目標(biāo)和理念是一致的，只不過在實(shí)現(xiàn)這個(gè)目標(biāo)的方法上的選擇是不一樣的。

AI 前線：下面這個(gè)問題我們之前問過 Databricks 的工程師，今天也想問問您，如果我要做統(tǒng)一的平臺(tái)，你也要做統(tǒng)一平臺(tái)，那會(huì)不會(huì)存在最后到底誰能真正統(tǒng)一誰的問題？

莫問： 我覺得大家并不是說做什么，什么就一定會(huì)贏，一定會(huì)好。從我個(gè)人態(tài)度來說，技術(shù)還是需要有一定良性的競(jìng)爭(zhēng)，這樣才能相互學(xué)習(xí)，同時(shí)條條大路通羅馬，不一定哪一個(gè)絕對(duì)正確，可能不同場(chǎng)景有不同的偏好或不同的特定區(qū)域的需求，或適應(yīng)的場(chǎng)景不一樣。解決類似問題有兩三家公司共存，這種狀態(tài)是比較健康的，就像數(shù)據(jù)庫領(lǐng)域有 MySQL、PostgreSQL 等，在線服務(wù)也類似，起碼得有兩家大公司在一起競(jìng)爭(zhēng)，是比較合適的。但最終哪個(gè)做得更好，還是取決于是否能把自己的理論做到極致。因?yàn)槔碚撌抢碚摚愕睦碚摵臀业睦碚撀犉饋砀饔星?，但是誰最后能贏看的是細(xì)節(jié)，包括用戶體驗(yàn)。你是否按照正確的方法在做，細(xì)節(jié)做得夠不夠好，而不是大家聽起來思路一樣就沒有區(qū)別了。細(xì)節(jié)和社區(qū)生態(tài)的發(fā)展、推進(jìn)過程都很重要。

開源 Alink：Flink 機(jī)器學(xué)習(xí)進(jìn)度幾何？

Flink 在機(jī)器學(xué)習(xí)領(lǐng)域的進(jìn)展一直是眾多開發(fā)者關(guān)注的焦點(diǎn)，今年 Flink 迎來了一個(gè)小里程碑：機(jī)器學(xué)習(xí)算法平臺(tái) Alink 開源，這也宣告了 Flink 正式切入 AI 領(lǐng)域。

Alink 開源項(xiàng)目鏈接：https://github.com/alibaba/Alink

Alink 是阿里巴巴機(jī)器學(xué)習(xí)算法團(tuán)隊(duì)從 2017 年開始基于實(shí)時(shí)計(jì)算引擎 Flink 研發(fā)的新一代機(jī)器學(xué)習(xí)算法平臺(tái)，提供豐富的算法組件庫和便捷的操作框架，開發(fā)者可以一鍵搭建覆蓋數(shù)據(jù)處理、特征工程、模型訓(xùn)練、模型預(yù)測(cè)的算法模型開發(fā)全流程。作為業(yè)界首個(gè)同時(shí)支持批式算法、流式算法的機(jī)器學(xué)習(xí)平臺(tái)，Alink 提供了 Python 接口，開發(fā)者無需 Flink 技術(shù)背景也可以輕松構(gòu)建算法模型。Alink 這個(gè)名字取自相關(guān)名稱（Alibaba, Algorithm, AI, Flink,Blink）的公共部分。

據(jù)悉，Alink 已被廣泛運(yùn)用在阿里巴巴搜索、推薦、廣告等多個(gè)核心實(shí)時(shí)在線業(yè)務(wù)中。在剛剛落幕的天貓雙 11 中，單日數(shù)據(jù)處理量達(dá)到 970PB，每秒處理峰值數(shù)據(jù)高達(dá) 25 億條。Alink 成功經(jīng)受住了超大規(guī)模實(shí)時(shí)數(shù)據(jù)訓(xùn)練的檢驗(yàn)，并幫助提升 4% CTR（商品點(diǎn)擊轉(zhuǎn)化率）。

AI 前線：能否先介紹一下 FlinkML 和 Alink 的概況，以及二者的關(guān)系？

莫問：FlinkML 是 Flink 社區(qū)現(xiàn)存的一套機(jī)器學(xué)習(xí)算法庫，這一套算法庫已經(jīng)存在很久而且更新比較緩慢。Alink 是基于新一代的 Flink，完全重新寫了一套，跟 FlinkML 沒有代碼上的關(guān)系。Alink 由阿里巴巴大數(shù)據(jù)團(tuán)隊(duì)開發(fā)，開發(fā)出來以后在阿里巴巴內(nèi)部也用了，然后現(xiàn)在正式開源出來。

未來我們希望 Alink 的算法逐漸替換掉 FlinkML 的算法，可能 Alink 就會(huì)成為新一代版本的 FlinkML，當(dāng)然替換還需要一個(gè)比較漫長(zhǎng)的過程。Alink 包含了非常多的機(jī)器學(xué)習(xí)算法，往 Flink 貢獻(xiàn)或發(fā)布的時(shí)候也需要比較大的帶寬，我們擔(dān)心整個(gè)過程耗時(shí)會(huì)比較長(zhǎng)，所以先把 Alink 單獨(dú)開源出來，大家如果有需要的可以先用起來。后面貢獻(xiàn)進(jìn)展比較順利的情況下，Alink 應(yīng)該能完全合并到 FlinkML，也就是直接進(jìn)入 Flink 生態(tài)的主干，這對(duì)于 Alink 來說是最好的歸宿，到這個(gè)時(shí)候 FlinkML 就可以跟 SparkML 完全對(duì)應(yīng)起來了。

AI 前線：除了 Alink 以外，F(xiàn)link 當(dāng)前在機(jī)器學(xué)習(xí)領(lǐng)域的工作還有哪些進(jìn)展？和其他計(jì)算引擎相比，您如何評(píng)價(jià)當(dāng)前 Flink 在機(jī)器學(xué)習(xí)和 AI 領(lǐng)域的工作，它的競(jìng)爭(zhēng)力足夠強(qiáng)嗎？

莫問： 其實(shí)我們還有很多正在進(jìn)行的工作。機(jī)器學(xué)習(xí)的核心是迭代計(jì)算，機(jī)器學(xué)習(xí)訓(xùn)練就是不停地對(duì)數(shù)據(jù)進(jìn)行迭代訓(xùn)練，訓(xùn)練出來一個(gè)模型然后上線。在核心訓(xùn)練的基礎(chǔ)上，F(xiàn)link 正在設(shè)計(jì)新的迭代計(jì)算，因?yàn)?Flink 是基于流式計(jì)算，所以它的迭代計(jì)算可以轉(zhuǎn)化為 mini-batch 的迭代計(jì)算，可以根據(jù)數(shù)據(jù)條目數(shù)也可以根據(jù)數(shù)據(jù)段的時(shí)長(zhǎng)，在流上打出很多細(xì)粒度的數(shù)據(jù)段。

Flink 的好處是在流上打細(xì)粒度的數(shù)據(jù)段可行性上沒有問題，因?yàn)樗緛砭褪羌兞魇降?，截成一段一段沒有問題。而 Spark 的迭代是把一個(gè)數(shù)據(jù)集做一次迭代，再做一次迭代，這個(gè)數(shù)據(jù)集很難切得特別細(xì)，切出來一段就是一次任務(wù)的運(yùn)行，細(xì)粒度的挑戰(zhàn)比較大。Flink 的好處是本身可以把粒度截得很細(xì)，所以重構(gòu)原有的迭代計(jì)算是可行的。

Flink 最早的迭代計(jì)算也跟 Spark 一樣，要么是一批迭代要么是一條一條迭代，完全是兩個(gè)極端，我們想把它做一個(gè)抽象，可以按照時(shí)間、大小來設(shè)定迭代的 batch 大小，就類似于 Flink 窗口的概念，這樣可以支持嵌套迭代、增量迭代等。我們?cè)谝鎸用孀龊昧嘶诹鞯牡夹g(shù)之后，整個(gè)機(jī)器學(xué)習(xí)的訓(xùn)練就會(huì)大幅度加速。雖然算法本身的效果可能是一樣的，但是運(yùn)行的性能和速度不一樣。

同時(shí)它還可以解決在線訓(xùn)練的問題，比如說互聯(lián)網(wǎng)的日志流、用戶行為是不停產(chǎn)生的，F(xiàn)link 流式迭代可以不間斷地處理用戶產(chǎn)生的實(shí)時(shí)數(shù)據(jù)，可以在線迭代更新，模型可以每隔 5 分鐘更新一次，也可以每隔 1 分鐘更新一次。這樣它的模型上線是一個(gè) 7×24 小時(shí)環(huán)狀的更新，這樣一套在線學(xué)習(xí)的體系會(huì)給用戶帶來很大的變化，這個(gè)變化不是簡(jiǎn)單的 30% 的提升或者是工程上的優(yōu)化，而是在使用機(jī)器學(xué)習(xí)的理念上會(huì)有優(yōu)化。

這是我們當(dāng)前正在做的工作，社區(qū)里也已經(jīng)開始討論了，可能會(huì)作為 Flink 明年 1-2 個(gè)版本的重點(diǎn)。你可以這么認(rèn)為，F(xiàn)link 去年還是 Unified Engine，今年開始擁抱 AI 了，2019 年我們做的很多工作是偏 SQL 的優(yōu)化，明年我們會(huì)更多地切入到 AI，就是 FlinkML 和 AI 場(chǎng)景的方向上。

AI 前線：阿里是什么時(shí)候決定開源 Alink 的？

莫問： 去年 Blink 開源的時(shí)候，我們就在考慮是否把 Alink 一起開源了。但是后來覺得，第一個(gè)開源還沒做，不敢一下子步子邁得這么大，要一步步來，而且 Blink 開源也要準(zhǔn)備很多東西。當(dāng)時(shí)我們沒有辦法做到兩個(gè)大的項(xiàng)目同時(shí)開源，所以就先把 Blink 開源做好。

Blink 開源以后，我們想是不是把 Alink 的算法推到 Flink 就好了。但是發(fā)現(xiàn)往社區(qū)貢獻(xiàn)確實(shí)是比較復(fù)雜的過程，Blink 在推的時(shí)候已經(jīng)占用了很大的帶寬，而社區(qū)的帶寬就那么多，沒有辦法同時(shí)做多件事情。社區(qū)也需要一段時(shí)間消耗，所以決定先把 Blink 消耗掉，貢獻(xiàn)完了，社區(qū)吃得下，然后再把 Alink 逐步貢獻(xiàn)回社區(qū)。這是沒有辦法跨越的一個(gè)過程。

開源是一個(gè)很慎重的過程，不能隨意想開就開一個(gè)。孩子不能管生不管養(yǎng)，要發(fā)東西就要有一個(gè)長(zhǎng)期的計(jì)劃，要負(fù)責(zé)任的，得給大家一個(gè)很明確的信號(hào)，這是有長(zhǎng)期計(jì)劃的，不是放了開源就結(jié)束了，以后肯定會(huì)有用戶問你們放上去以后管不管？如果我們不想好這些問題，對(duì)用戶來說就適得其反，大家覺得你并沒有給大家一個(gè)清晰的信號(hào)，大家也不敢用。

AI 前線：相比 SparkML，Alink 的亮點(diǎn)是什么？對(duì)于開發(fā)者來說在哪些方面會(huì)比較有吸引力？

莫問：Alink 一是依賴于 Flink 計(jì)算引擎層；第二 Flink 框架中有 UDF 的算子，Alink 本身對(duì)算法做了很多優(yōu)化，包括在算法實(shí)現(xiàn)上做了細(xì)節(jié)的優(yōu)化，比如通信、數(shù)據(jù)訪問、迭代數(shù)據(jù)處理的流程等多方面的優(yōu)化?；谶@些優(yōu)化可以讓算法運(yùn)行的效率更高，同時(shí)我們還做了很多配套工具，讓易用性更好。同時(shí) Alink 還有一個(gè)核心技術(shù)，就是做了很多 FTRL 的算法，是天然針對(duì)在線學(xué)習(xí)的。在線學(xué)習(xí)需要高頻快速更新的迭代算法，這種情況下 Alink 有天然的優(yōu)勢(shì)，像今日頭條、微博的信息流都會(huì)經(jīng)常遇到這樣的在線場(chǎng)景。

[[284093]]

在離線學(xué)習(xí)上 Alink 跟 SparkML 對(duì)比基本上差不多，只要大家工程化都做得足夠好，離線學(xué)習(xí)無法打出代差，真正的代差一定是設(shè)計(jì)上的理念不一樣。設(shè)計(jì)上、產(chǎn)品形態(tài)、技術(shù)形態(tài)不一樣才會(huì)有代差明顯的優(yōu)勢(shì)。

相比 SparkML，我們的基調(diào)是批式算法基本一致，包括功能和性能，Alink 可以支持算法工程師常用的所有算法，包括聚類、分類、回歸、數(shù)據(jù)分析、特征工程等，這些類型的算法是算法工程師常用的。我們開源之前也對(duì)標(biāo)了 SparkML 所有的算法，做到了 100% 對(duì)標(biāo)。除此之外，Alink 最大的亮點(diǎn)是有流式算法和在線學(xué)習(xí)，在自己的特色上能做到獨(dú)樹一幟，這樣對(duì)用戶來說沒有短板，同時(shí)優(yōu)勢(shì)又很明顯。

Alink 支持的機(jī)器學(xué)習(xí)算法

后續(xù)規(guī)劃和未來展望

AI 前線：接下來 Flink 會(huì)按照什么樣的頻率更新版本？能否透露 Flink 接下來還會(huì)有哪些值得期待的新特性或功能？

莫問：3-4 個(gè)月，基本上會(huì)是一個(gè)季度更新一個(gè)版本，比如 2020 年 1 月份會(huì)發(fā) 1.10，4 月份會(huì)發(fā) 1.11?，F(xiàn)在還說不好什么時(shí)候切 2.0，2.0 應(yīng)該會(huì)是一個(gè)非常有里程碑意義的版本?，F(xiàn)在 Flink 社區(qū)可以看到非常多的點(diǎn)，不僅有 AI、機(jī)器學(xué)習(xí)，還有今天主題演講 Stephan Ewen 提到的 Stateful Function，也是非常有前景的。其實(shí)在線場(chǎng)景還有很多有前景的東西可以挖掘，Serverless（Faas）也是 Flink 后面的方向。Flink 社區(qū)有一點(diǎn)非常好，它剛剛演進(jìn)到 1.x 版本，還有很大的上升空間，社區(qū)的生命力和狀態(tài)都很好，大家有很多想法想放進(jìn)去。

AI 前線：未來大數(shù)據(jù)領(lǐng)域還有哪些新的技術(shù)方向或趨勢(shì)是比較重要的？

莫問： 大數(shù)據(jù)和 AI 的融合可能是一個(gè)很好的機(jī)會(huì)，大家現(xiàn)在純玩大數(shù)據(jù)基本上五花八門什么都玩過了，各種項(xiàng)目層出不窮。AI 也是百花爭(zhēng)鳴，但其實(shí)用戶想要的不只是 AI，數(shù)據(jù)在哪？AI 沒有數(shù)據(jù)怎么玩？得把特征算好、樣本算好才能訓(xùn)練出好的模型。這個(gè)模型只有經(jīng)過不斷地迭代反饋才能越來越好。這個(gè)過程中數(shù)據(jù)處理和數(shù)據(jù)分析非常重要，如果沒有一套完整的反饋體系，大數(shù)據(jù) +AI 的鏈路玩不通。有再好的引擎，如果沒有閉環(huán)的計(jì)算路徑也無法真正發(fā)揮生產(chǎn)或業(yè)務(wù)上的效果。

所以要把大數(shù)據(jù) +AI 整套處理做成非常易用、好用的解決方案，這是大家最需要的。現(xiàn)在可能一個(gè)個(gè)零散的點(diǎn)大家已經(jīng)做到了，很多東西都能找到對(duì)應(yīng)的開源項(xiàng)目，但是需要有一個(gè)整體的平臺(tái)把所有技術(shù)串起來。

AI 前線：Flink 在一定程度上也想做這樣的？

莫問： 明年我們會(huì)開源一個(gè)新的項(xiàng)目 AI Flow，目前還沒有 Ready，我們希望 AI Flow 可以通過一個(gè)工作流程把數(shù)據(jù)處理、預(yù)處理，包括模型的訓(xùn)練、模型管理、模型上線、動(dòng)態(tài)更新，更新完拿到反饋，反饋之后怎么反向優(yōu)化流程，整個(gè)系統(tǒng)串起來。其中每個(gè)環(huán)節(jié)都可以使用不同的引擎來實(shí)現(xiàn)，用 Flink OK，用 Spark 也 OK，就看最后哪個(gè)好用。比如可以用 Flink 做大數(shù)據(jù)處理，TensorFlow 做深度學(xué)習(xí)訓(xùn)練，F(xiàn)linkML 做流式訓(xùn)練，把這些都串聯(lián)起來給用戶提供一個(gè)端到端的解決方案，這是很有前景的一個(gè)項(xiàng)目。

AI 前線：這是不是跟 Databricks 的 MLflow 有點(diǎn)類似？

莫問：AI Flow 大于 MLflow，因?yàn)?MLflow 只定義了數(shù)據(jù)格式，AI Flow 可能跟 Kubeflow 更像，AI Flow 偏工作流程，MLflow 偏重于數(shù)據(jù)格式，沒有覆蓋特別完整的工作流程，但我們也不排除 MLflow 將來越做越大。

為什么我們要做這個(gè)東西？因?yàn)槲覀冊(cè)诎⒗锇桶蛢?nèi)部非常熟悉整個(gè)搜索推薦廣告最核心的系統(tǒng)怎么玩，如何一步步流程化才能形成一套大腦去調(diào)控整個(gè)流量，甚至是搜索流量、推薦流量、廣告流量，在業(yè)務(wù)流量和現(xiàn)金流量去 battle 等，這是整個(gè)商業(yè)化最核心的系統(tǒng)，這個(gè)系統(tǒng)就是基于大數(shù)據(jù) +AI 的方案，而這套方案離不開 workflow，離不開數(shù)據(jù)格式的定義，離不開不同計(jì)算引擎的協(xié)同，這是更大的一個(gè)概念。我們明年會(huì)在這方面投入更多資源，也會(huì)聯(lián)合其他的公司一起來做。