2020 年末，谷歌旗下 DeepMind 研發(fā)的 AI 程序 AlphaFold2 在國際蛋白質(zhì)結(jié)構(gòu)預測競賽上取得驚人的準確度，使得 “AI 預測蛋白質(zhì)結(jié)構(gòu)” 這一領(lǐng)域受到了空前的關(guān)注。今天我們邀請到同領(lǐng)域企業(yè)，深勢科技為大家分享其搭建基礎平臺時的實踐與思考。AI 場景中的使用的數(shù)據(jù)有哪些新特點？混合云架構(gòu)如何與超算平臺結(jié)合？為何會選擇 JuiceFS？
背景
深勢科技成立于 2018 年，是 “AI for Science” 科學研究范式的先行者，致力于運用人工智能和分子模擬算法，結(jié)合先進計算手段求解重要科學問題，為人類文明最基礎的生物醫(yī)藥、能源、材料和信息科學與工程研究打造新一代微尺度工業(yè)設計和仿真平臺。
新一代分子模擬技術(shù)，是深勢科技研究問題的本質(zhì)方法；高性能計算、機器學習、科學計算方法，這些是研究分子模擬技術(shù)的一些工具和手段。
Hermite 和 Bohrium 是針對不同行業(yè)領(lǐng)域的解決方案，Hermite 是針對藥物研發(fā)領(lǐng)域的一個計算設計平臺， Bohrium 是針對材料和科學領(lǐng)域的微尺度計算設計平臺，Lebesgue 是任務調(diào)度和算力編排平臺。
什么是 AI for Science
一直以來對科學研究有兩大范式，第一個是以數(shù)據(jù)驅(qū)動的開普勒范式。第二個是以第一性原理驅(qū)動的牛頓范式。
開普勒范式是通過觀察、總結(jié)的方式，研究事物的規(guī)律，開普勒范式三大定律就是通過不斷的天文觀測，前人積累的天文經(jīng)驗總結(jié)出來的。開普勒范式屬于數(shù)據(jù)驅(qū)動，通過觀察事物的現(xiàn)象，總結(jié)規(guī)律，然后拿它解決實際的問題。這種方式解決問題有一個缺點，可能會出現(xiàn)知其然不知所以然的情況，很難泛化。
牛頓范式是從事物的本質(zhì)出發(fā)，通過第一性原理，發(fā)現(xiàn)事物的規(guī)律。牛頓范式屬于模型驅(qū)動，模型驅(qū)動比較準確，但因為計算的量大，很難用以解決實際的問題。
AI for Science (下文簡稱 AI4S） 就是希望把這兩大范式結(jié)合起來，用 AI 去學習科學原理，然后得到模型，進而去解決實際的問題。
AI for Science 范式如何解決科學原理工程化問題
藥物研發(fā)領(lǐng)域，大家比較熟悉的是明星公司 Deep Mind 開發(fā)的一款人工智能程序 AlphaFold，簡單來說是做蛋白質(zhì)的結(jié)構(gòu)預測；材料研發(fā)主要是做材料的性質(zhì)研究，新材料發(fā)現(xiàn)等。這兩大領(lǐng)域本質(zhì)研究的是微觀粒子的相互作用，微觀粒子的運動軌跡。在高中化學的時候，老師講過結(jié)構(gòu)決定性質(zhì)，性質(zhì)決定用途。微觀粒子的研究會用到薛定諤方程、密度泛函方程、牛頓力學方程等基本方程，這些都是在不同的尺度下的微觀粒子的運動軌跡、運動狀態(tài)的方程。
如果直接用第一性原理去解決問題的話，實際上是比較困難的，會陷入維數(shù)災難問題。 AI4S 新范式就是用 AI 去學習和表示一系列的物理方程，進而去攻克維數(shù)災難，在精度和效率之間取一個平衡。
混合云架構(gòu)的選擇與挑戰(zhàn)
為什么選擇混合云架構(gòu)
深勢科技作為一家初創(chuàng)公司，為什么在開始的時候就選擇了混合云的架構(gòu)，總結(jié)下來，主要是有三點：
第一點業(yè)務算力的需求， AI4S 領(lǐng)域的主戰(zhàn)場是在超算，一些院校和研究所都有自己的超算機器。比較著名的就是天河系列，天河系列在 2014 年的時候拿到過 Top500 的第一名，它對計算的性能和算力的要求是非常高的。
上圖計算任務算力需求： 128 張 A100s 的卡運行 5 天的時間。
下圖是一個訓練任務，分為三步，每一步對資源的需求差別是比較大的。第一步和第三步，對 GPU 的資源要求比較高，第二步它對 CPU 的需求是比較大的，需要 10000+ 核的 CPU 資源。這也是 AI4S 的一個特點，同一任務對資源的需求，在不同階段差異是比較大的。
第二點是客戶的訴求，一些客戶在使用深勢科技的資源或者產(chǎn)品之前，可能已經(jīng)是 AWS 、阿里云或者其他超算的用戶，客戶希望他們的資源能夠最大的程度的復用，從而提升資源的利用效率。
第三點是資源的可用性，算力平臺負責給 AI4S 領(lǐng)域的工業(yè)客戶或者科學研究院校提供算力資源，他們對資源的需求是很大的，在資源使用過程中也會用到一些搶占式資源和潮汐資源，對資源的可用性或者資源的豐富度要求高。所以選擇混合云架構(gòu)，也是比較大的一個優(yōu)勢。
混合云架構(gòu)的挑戰(zhàn)
首先是基礎設施的差異性，公有云是比較開放的，買了一臺機器之后，就有了這臺機器的 root 賬號，資源在底層做了虛擬化隔離，你可以在這個機器上做任何你想做的事情，不會影響到其他人。但是超算相對是比較封閉的，超算的環(huán)境是共用的，用戶之間是邏輯隔離的，超算更多的是把資源拿出來讓你去使用，但是你很難擁有資源的主導權(quán)，你在超算機器上安裝一個軟件，這個軟件可能跟別人的軟件是有沖突的，所以不能隨意安裝。
第二個是運行時環(huán)境的差異性，公有云上跑服務的話會打一個鏡像，把程序依賴的一些操作系統(tǒng)以及依賴的一些軟件都會裝到鏡像里面，直接做分發(fā)，這樣就能屏蔽運行時環(huán)境的差異性。但在超算里面主要是借助 module 工具管理環(huán)境變量，解釋下，module 是 Linux 下的一個管理環(huán)境變量的工具。如果想用一個軟件的話，需要通過 module 的方式把這個軟件增加進來，然后再去使用。
第三點是用戶體驗的一致性，基于上面兩點，公有云和超算還是有比較大的差異性。這會導致用戶在使用的體驗上會有比較大的差異。如何把差異補齊，讓用戶在日志、監(jiān)控的查看上都有一致性的體驗，對架構(gòu)上也是一個挑戰(zhàn)。
云與超算融合的探索
第一點就是容器化，超算上主要是用的是 Podman 和 Singularity 容器鏡像，使用 Docker 是比較難的，因為 Docker 需要在主機上啟動一個 daemon 的進程，其次還需要 root 賬號。這兩點在超算上實際上都是不太方便的，所以超算上一般用的比較多的就是 Singularity 鏡像，Podman 和 Docker 鏡像有比較好的兼容性，也慢慢流行起來。
第二點是Slurm on K8s，Slurm 在超算平臺上是常用的一個資源調(diào)度的框架，早期安裝 Slurm 是需要在物理機上直接安裝，但是隨著對資源彈性的需求，我們希望 Slurm 能直接裝到 K8s 里面去。當用戶需要 Slurm 資源的時候，可以基于 K8s 去分配資源，然后在分配的 pod 上安裝 Slurm。
第三點就是Virtual Kubelet，這是一個虛擬的 kubelet 技術(shù)。在阿里云和 AWS 的彈性資源上也都有一些應用，相當于把一些算力資源通過橋接的方式讓 K8s 能使用起來。在超算上我們也在探索這種方案，讓 K8s 集群通過 Virtual Kubelet 的方式使用超算的資源。
存儲架構(gòu)的思考與實踐
舉一個業(yè)務場景的存儲例子，在藥物研發(fā)場景中，分子對接具有十分重要的應用價值，分子對接就是兩個或多個分子之間相互識別的過程，目的是找到藥物分子與致命靶點的最佳結(jié)合模式。一次分子對接的過程中數(shù)據(jù)的需求如下：會產(chǎn)生約 6 億的小文件，文件壓縮前有 2.3T， 壓縮后有 1.5T，單文件的大小大約 4k。
文件比較小的話，數(shù)據(jù)處理的難度會比較大。比如：在 Linux 上去處理很多的小文件時，它首先會有 inode 個數(shù)的限制，其次小文件比較多的話，讀取的速度也上不去。
存儲訴求
基于上述的業(yè)務場景，我們總結(jié)下對存儲的訴求。 第一是文件的多樣性，除了小文件，在實際業(yè)務場景中還有中文件、大文件，所以多種大小的文件，都需要有一個比較好的支持。
第二點是存儲層的抽象與統(tǒng)一，在 AI 領(lǐng)域，很多都是使用 Python 的服務，Python 的服務對 POSIX 接口是比較友好的，如果用戶在使用存儲的時候，需要頻繁地通過 S3 或 OSS 去下載數(shù)據(jù)的話，會對用戶會有體驗上有影響。
第三點是方案的通用性，在公有云上會有很多的存儲方案，在一家云上使用，完全沒問題，非常的好用。但如果想把這種方案放到超算上去，或者放到一些線下的集群，實際上就不是那么通用了。
第四點是數(shù)據(jù)的分層，我們的數(shù)據(jù)是有典型的冷熱特性，在一個任務在計算過程中，它用到的數(shù)據(jù)是熱數(shù)據(jù)，任務計算之后或者過了幾天之后，這個數(shù)據(jù)就變成了冷數(shù)據(jù)，我們對冷數(shù)據(jù)的讀和操作是比較少的。
最后一點就是安全性的考慮，希望存儲上能有一些業(yè)務的隔離，配額、授權(quán)以及刪除之后的回收站等，來保障數(shù)據(jù)的安全性。
方案選型 & JuiceFS 測試
第一點是功能滿足度，這個方案肯定要滿足上述我們對存儲上的功能需求。
第二點是技術(shù)棧，所采用的技術(shù)棧最好是能和公司使用的技術(shù)棧是匹配的。
第三點是可運維性，希望這個方案的運維相對來說比較容易，如果方案本身的復雜度比較高，那么出了問題之后，解決問題就比較麻煩和復雜。
第四點是社區(qū)活躍度，調(diào)研的時候我們發(fā)現(xiàn) JuiceFS 社區(qū)是非?；钴S的，在使用過程中，有問題的話，會直接發(fā)到 JuiceFS 社區(qū)群里面，不論是晚上還是周末，社區(qū)的響應都是非常及時的，包括創(chuàng)始人蘇銳也經(jīng)常在群里面回答問題，所以社區(qū)的活躍度也是我們在方案選型的時候一個非常重要的考量點。
在做方案選型的時候做了一些測試，供大家參考，主要是以下幾點：
第一點是POSIX 的兼容性，我們對 POSIX 兼容性會考慮得比較多，如果 POSIX 兼容性不好，這個方案基本上是沒法用的。
第二點是性能的基準測試，性能測試的數(shù)據(jù)見下圖。
第三點是K8s 的 CSI 掛載，我們有一些業(yè)務是通過 K8s 調(diào)度的，自然是希望存儲對 K8s 比較友好。
第四點是業(yè)務 PoC 驗證，測試的場景還是比較多的，從小文件中文件大文件，還有包括順序讀，順序讀里面又分為預熱和不預熱。
JuiceFS 有個功能特別好用，就是預熱的功能，當我們需要運算的時候，可以把一些數(shù)據(jù)提前的去做預熱。這功能對我們來說就非常實用，計算過程中任務依賴昂貴的 GPU 資源，成本是比較高的，一般我們會提前把數(shù)據(jù)預熱到本地，然后再開啟任務的運行。
上圖是我們整體的存儲架構(gòu)，底層是基于對象存儲的統(tǒng)一的存儲，然后再往各個地方的計算中心分發(fā)數(shù)據(jù)，不論是超算，還是云機房也好，都是有一個緩存的集群。當任務開始的時候，會把數(shù)據(jù)從統(tǒng)一的存儲中拉到計算集群就近的一個緩存集群里面去，在計算任務運行的過程中，只需要和本地的存儲集群做通信。
JuiceFS 可以把數(shù)據(jù)緩存到本地，當數(shù)據(jù)比較舊的時候，它就會被淘汰掉。如果沒有用 JuiceFS ，我們需要自己去做緩存的淘汰機制，想做好，還是有一定的成本的。但是有了 JuiceFS 之后，我們就不用考慮這個事情了，只需要把 JuiceFS 掛載上去，它就幫我們把這些事情都做了。
深勢科技目前使用的是一個開源版本的 JuiceFS，以 redis 作為元數(shù)據(jù)管理，使用 SSD 做數(shù)據(jù)緩存。
深勢科技生產(chǎn)環(huán)境使用情況
總結(jié)與展望
云與超算融合是趨勢，現(xiàn)在一些公有云上都有超算服務，或者叫高性能計算服務，高性能計算集群等。超算也是不斷的在往云上去靠，超算里面提到了一些超算云或者云超算的概念，就是通過虛擬化的技術(shù)，通過云原生的技術(shù)，把超算的資源更好、更方便的提供出去，讓大家使用。
第二點容器化是關(guān)鍵，我們在做云與超算的融合的過程中，怎么樣把運行時的環(huán)境保持一致，是一個很關(guān)鍵的點。如果在云上用的是容器，但在超算上用的是另一套方案，會出現(xiàn)服務在云上跑得好好的，但放到超算上之后就跑不起來，所以容器化是一個比較關(guān)鍵的點。
第三點統(tǒng)一存儲是基礎，調(diào)度相對來說是比較容易的，把算力從公有云上調(diào)度到超算平臺上，其實是比較簡單的，但是將存儲調(diào)度過去難度就增加了。
這里面會有幾個難點，第一點怎么樣把數(shù)據(jù)從一個地方傳輸?shù)揭粋€地方。數(shù)據(jù)量小倒還好，但是數(shù)據(jù)量比較大就非常困難了。第二點是傳輸?shù)木W(wǎng)絡，也會影響到數(shù)據(jù)傳輸?shù)乃俣?。第三點是數(shù)據(jù)的引用，把數(shù)據(jù)搬遷過去之后，怎么樣和原來路徑或結(jié)構(gòu)保持一致，在不改程序的情況，也能繼續(xù)運行。最后是數(shù)據(jù)的整合，比如整個計算過程中分為 5 步，前 2 步是在云上算的，最后 3 步在超算上算的，會牽涉到數(shù)據(jù)的整合，日志的整合，監(jiān)控的整合。
最后，存算分離是必然，如果機器資源和存儲是綁定的，是沒法去做調(diào)度的。早期，我們的存儲和機器算力是綁定的，機器上掛載了本地盤，當把計算任務調(diào)過去之后，存儲是調(diào)不過去的，所以說存算分離是必然。
