云原生與AI漫談

寫完上次的 MLOps 主題文章后，接下來計(jì)劃寫一篇機(jī)器學(xué)習(xí)與云原生結(jié)合的文章。不過個(gè)人在這塊的經(jīng)驗(yàn)并不多，還在各種學(xué)習(xí)和素材積累中。今天先來閑聊一些最近一陣子對(duì)云原生這個(gè)火熱話題的一些發(fā)散性遐想。

云原生的定義

對(duì)于云原生的標(biāo)準(zhǔn)定義，可以參考 CNCF 列舉的四點(diǎn)：

• 微服務(wù)
• 容器化
• DevOps
• 持續(xù)交付

關(guān)于這塊內(nèi)容，已經(jīng)有很多書籍和文章來介紹了，我就不班門弄斧了。主要結(jié)合自己對(duì)云原生的認(rèn)識(shí)，來聊聊一些開腦洞的想法。

云原生時(shí)代的應(yīng)用開發(fā)

在跟算法工程師們一起工作時(shí)，經(jīng)常會(huì)吐槽很多同學(xué)好像計(jì)算機(jī)基礎(chǔ)比較一般，對(duì)于代碼的內(nèi)存開銷，計(jì)算復(fù)雜度等沒有多少概念。更不用說我們?cè)缒曜鲂阅軆?yōu)化時(shí)，還需要考慮程序是不是符合 CPU 的流水線架構(gòu)，是不是 cache friendly，怎么消除 false sharing 等等……

但最近突然有個(gè)想法，那就是到了云原生時(shí)代，程序員可能都不需要再了解 CPU，內(nèi)存，硬盤這些概念了。取而代之的是只需要了解自己的業(yè)務(wù)特性需求，以及提供不同需求的云計(jì)算價(jià)格即可。

例如我們做數(shù)據(jù)處理，按照現(xiàn)在的開發(fā)邏輯，我們可能需要了解數(shù)據(jù)量的大小，計(jì)算時(shí)間的要求，然后來評(píng)估我們可能需要用什么樣的算法和數(shù)據(jù)結(jié)構(gòu)，需要申請(qǐng)多少 CPU 和內(nèi)存的虛擬機(jī)/容器。而在未來，大家只需要知道我需要對(duì) 1 億條數(shù)據(jù)進(jìn)行計(jì)算，如果希望 1 分鐘內(nèi)算完，可能需要多少錢，如果可以放寬到 1 小時(shí)，那么價(jià)格可以降低到多少。

關(guān)注點(diǎn)分離

這個(gè)想法其實(shí)跟關(guān)注點(diǎn)分離的思想很像，這樣可以讓應(yīng)用開發(fā)人員專注在業(yè)務(wù)邏輯，成本和業(yè)務(wù)價(jià)值回報(bào)等方面，不再需要分精力去了解計(jì)算存儲(chǔ)的細(xì)節(jié)，以及各種基礎(chǔ)設(shè)施結(jié)構(gòu)，運(yùn)維方面的考量。

就好比我們只需要知道我們要從 A 地到 B 地，需要在多少時(shí)間內(nèi)到達(dá)即可，其它的交給“云”來打理即可。希望云平臺(tái)能幫我們選擇，如果是高峰期，還需要很短時(shí)間到達(dá)，就給我們派架直升機(jī)，如果是半夜，可能普通出租車就可以了。

對(duì)新編程范式的需求

如果按這個(gè)方向發(fā)展，那么我們需要一種新的編程范式，跟從命令式到聲明式編程類似，我們這里需要一種新的“云原生聲明語言”。可能會(huì)長(zhǎng)這樣：

def my_logic(data):    ret = do_some_job(data)    return ret
function: my_logic    performance: 60s    availability: region    consistency: soft

因?yàn)槭清谙?，所以代碼也是有點(diǎn)亂來。大致分兩部分，一塊是你要做的操作邏輯定義，另一塊是各種計(jì)算屬性的聲明，包括希望響應(yīng)性能如何，可用性希望達(dá)到數(shù)據(jù)中心 level，還是 region level，一致性需要多強(qiáng)等等。對(duì)于這個(gè)代碼的執(zhí)行方式，則通過“云原生編譯器”去進(jìn)行編排，到底是跑在單容器上，還是利用 serverless，還是需要用 Spark/Flink 等引擎，開發(fā)者都不需要 care。怎么做高可用，性能優(yōu)化，彈性擴(kuò)縮容，也都不需要管。想想就很美好吧？

對(duì)新操作系統(tǒng)的需求

這類程序如何跑起來，除了前面假想的編譯器，我們還需要運(yùn)行時(shí)，操作系統(tǒng)等。其實(shí)從上面的偽代碼可以看出，這個(gè)操作系統(tǒng)很可能就是現(xiàn)在火熱的 k8s，而運(yùn)行時(shí)嘛可能是 CRD 基礎(chǔ)上封裝的一個(gè)中間層，可以將一些原語轉(zhuǎn)化為分布式的計(jì)算和存儲(chǔ)過程，比如批流處理走 Flink，數(shù)據(jù)的 mutation 和持久化走 cloud DB……

云原生時(shí)代的系統(tǒng)開發(fā)

對(duì)于系統(tǒng)開發(fā)人員來說（比如云數(shù)據(jù)庫(kù)，云 AI 平臺(tái)），云原生的趨勢(shì)也會(huì)產(chǎn)生相應(yīng)的影響。

Trade-off 的變化

對(duì)系統(tǒng)開發(fā)者來說，架構(gòu)上的思考會(huì)從原先的固定計(jì)算池的 trade-off（比如空間換時(shí)間），轉(zhuǎn)變成云服務(wù) cost 的 trade-off（用錢換性能）。

例如經(jīng)典的 MySQL 索引優(yōu)化，大家為了加快讀的性能，會(huì)構(gòu)建索引，而過多的索引，一方面會(huì)增加存儲(chǔ)開銷，另一方面會(huì)增加寫入時(shí)的計(jì)算開銷，因此經(jīng)常需要有經(jīng)驗(yàn)的 DBA 來進(jìn)行各種權(quán)衡優(yōu)化。這是非常典型的資源池思想，假定我們的 CPU，內(nèi)存，磁盤是相對(duì)固定的一個(gè)值。

但是到了云原生時(shí)代，我們可以完全打破這個(gè)固有框架，我們擁有的計(jì)算，存儲(chǔ)都可以理解為是“無限”的，只要有錢就可以！例如為了讀取速度夠快，我干脆對(duì)所有的數(shù)據(jù)做索引，這樣可能需要更多的存儲(chǔ)成本（x 元）；為了在寫入時(shí)的性能不受影響，我在寫入時(shí)利用一些彈性擴(kuò)展的計(jì)算資源做超大規(guī)模的并行計(jì)算（又多花了 y 元）。但只要低延遲的讀取，例如全量索引的 DB 能讓業(yè)務(wù)的大量讀取請(qǐng)求變得飛快，從原先的頻繁全表掃描到現(xiàn)在的命中索引，計(jì)算資源可以減少 n 元，最終達(dá)到 n > x + y 的情況，那么這個(gè)設(shè)計(jì)就是合理有效的。

上面這個(gè)例子不全是我異想天開，而是有真實(shí)的案例^[1]支持哦。

軟硬一體化

另外一個(gè)想象空間是在云原生時(shí)代，越來越多的云計(jì)算都是以服務(wù)化的產(chǎn)品形式提供出來，而不再像以前那樣是用戶單獨(dú)購(gòu)買虛擬機(jī)，再部署自己的應(yīng)用。這就給軟硬件的聯(lián)合優(yōu)化打開了一扇大門。

當(dāng)用戶采購(gòu)?fù)ㄓ糜?jì)算設(shè)備時(shí)，往往需要考慮各種硬件架構(gòu)，指令集，上層的操作系統(tǒng)，運(yùn)行環(huán)境等各個(gè)層面的通用化，所以導(dǎo)致很多針對(duì)性的優(yōu)化無法開展。但如果用戶采購(gòu)的是一種專門解決某個(gè)問題的云服務(wù)，那么只要提供的接口是相對(duì)標(biāo)準(zhǔn)化的，內(nèi)部的軟硬件棧都可以由系統(tǒng)開發(fā)者來自行選擇和優(yōu)化。

舉幾個(gè)簡(jiǎn)單的例子，比如大家現(xiàn)在常用的 s3 存儲(chǔ)，其實(shí)我們都不知道 AWS 在底層具體用了什么樣的軟件或者硬件，我們只關(guān)心它能提供穩(wěn)定可靠的存儲(chǔ)服務(wù)即可。因此 AWS 如果在底層做了很復(fù)雜的軟硬件優(yōu)化，使得 s3 的存儲(chǔ)成本低于 Azure, GCP，那么就會(huì)有很大的競(jìng)爭(zhēng)優(yōu)勢(shì)。最近還看了個(gè) TinyML 的軟硬件一體優(yōu)化，能夠在非常有限的 FPGA 硬件資源上跑復(fù)雜的 CV 模型，感覺這里面的機(jī)會(huì)和想象空間著實(shí)巨大！

多租戶

沿著上面云服務(wù)產(chǎn)品化的思路，多租戶也將變成一種趨勢(shì)。在多租戶的情況下，也會(huì)誕生出很多新的挑戰(zhàn)和機(jī)會(huì)。例如如何去安排多租戶的具體計(jì)算調(diào)度，存儲(chǔ)形式，來降低系統(tǒng)整體的資源開銷；通過多租戶不同 workload 數(shù)據(jù)的積累，構(gòu)建一些智能模型來做系統(tǒng)層面的優(yōu)化；甚至在用戶許可的情況下，我們可以做一些類似聯(lián)邦學(xué)習(xí)的手段來構(gòu)建一些領(lǐng)域模型，優(yōu)化所有用戶的使用體驗(yàn)等等。

具體的例子比如我們可以通過用戶的數(shù)據(jù)查詢看到經(jīng)常使用的過濾維度，來重新安排數(shù)據(jù)的排序和分區(qū)，這樣在同樣的數(shù)據(jù)量情況下，系統(tǒng)可以花更少的計(jì)算資源來完成查詢，增加系統(tǒng)的利潤(rùn) :)

云原生+AI

最后再來看下跟 AI 相關(guān)的部分。Andrej 之前提出了 Software 2.0 的概念，對(duì)應(yīng)到我們上面的圖景主要是針對(duì)應(yīng)用開發(fā)層面，從原先的過程式編程，轉(zhuǎn)變向以數(shù)據(jù)和優(yōu)化目標(biāo)驅(qū)動(dòng)的聲明式編程。在數(shù)據(jù)智能越來越重要的今天，這個(gè)趨勢(shì)在不斷改變我們開發(fā)應(yīng)用的方式，包括出現(xiàn)了很多交互式開發(fā)，可視化，data-centric，low-code/no-code 等形式。而前面講的“云原生語言”，則更關(guān)注在程序具體執(zhí)行層面的關(guān)注點(diǎn)分離。

把兩者結(jié)合起來看，云原生時(shí)代的 AI 平臺(tái)開發(fā)會(huì)是一片巨大的未開墾之地，對(duì)于云和算法各自都有很寬很長(zhǎng)的路可以走。舉幾個(gè)隨便想到的例子:

• 在計(jì)算資源“無限”的前提下，設(shè)計(jì)靈活的 ML 執(zhí)行框架。我可以用 1 臺(tái)機(jī)器訓(xùn)練 100 小時(shí)或 100 臺(tái)機(jī)器訓(xùn)練 1 小時(shí)達(dá)到相同的結(jié)果。
• AutoML cost 成本優(yōu)化，在不改變算法效率的前提下，或許我們可以通過大規(guī)模利用 spot instance 的低計(jì)算成本來承載 autoML 的搜索計(jì)算，在某些場(chǎng)景上或許能實(shí)現(xiàn)一些正收益。而且 autoML 的優(yōu)化目標(biāo)，也可以不僅僅是 accuracy，而可以同時(shí)考慮各種 cost。
• Cloud 與邊緣計(jì)算結(jié)合的應(yīng)用，比如在云端跑 teacher model，客戶端跑 student model，實(shí)現(xiàn)持續(xù)的模型更新與端上運(yùn)算的低資源開銷。
• 在應(yīng)用開發(fā)方面，我們可以利用云原生的計(jì)算彈性，實(shí)現(xiàn)更好的無縫開發(fā)體驗(yàn)。例如在做原型開發(fā)時(shí)，可以利用本地硬件做小數(shù)據(jù)量的調(diào)試。而當(dāng) pipeline 跑通之后，又可以靈活切換到使用云端算力，進(jìn)行全量數(shù)據(jù)的實(shí)驗(yàn)與后續(xù)的發(fā)布上線。
• 云原生編譯這塊，也可以充分考慮機(jī)器學(xué)習(xí)類任務(wù)的特性，比如異構(gòu)硬件，MPI 計(jì)算框架，pipeline 模式等，實(shí)現(xiàn)軟硬一體優(yōu)化，讓算法任務(wù)能更好的在云操作系統(tǒng)上來執(zhí)行。
• 算法的各類優(yōu)化，反過來也可以應(yīng)用于系統(tǒng)本身的優(yōu)化。比如經(jīng)典的通過機(jī)器學(xué)習(xí)來優(yōu)化 DB 索引的構(gòu)建。通過算法來做自動(dòng)的代碼優(yōu)化^[2]等。
• 多租戶情況下的聯(lián)邦學(xué)習(xí)，多任務(wù)/元學(xué)習(xí)的可能性。

目前云原生跟 AI 結(jié)合的一個(gè)比較好的學(xué)習(xí)樣例是 Kubeflow，之前春節(jié)期間讀了一本《Kubeflow for Machine Learning^[3]》，感覺收獲還是挺多的，如Istio，CRD的應(yīng)用等。

總體來說，這塊我的思考還非常有限，接下來會(huì)持續(xù)關(guān)注和學(xué)習(xí)，再與大家做更系統(tǒng)性的分享。也歡迎對(duì)這方面有興趣有經(jīng)驗(yàn)的同學(xué)來一起交流探討，需要給位大佬的多多指導(dǎo)。

參考資料