一、多云緩存產(chǎn)生的背景

1、多云架構(gòu)

知乎目前采用的是多云架構(gòu)，主要基于以下三個(gè)方面的考慮：

• 服務(wù)多活。這是為了防止在某個(gè)機(jī)房出現(xiàn)不可抗力、不能提供服務(wù)的時(shí)候，業(yè)務(wù)被全面中斷。
• 容量擴(kuò)展。單一機(jī)房的容量上限是萬臺(tái)，知乎目前的服務(wù)器規(guī)模已經(jīng)超過了萬臺(tái)。
• 降本增效。同一云服務(wù)在不同云廠商的定價(jià)是不同的，我們希望能夠以比較低廉的價(jià)格享受到優(yōu)質(zhì)的服務(wù)。

知乎目前的數(shù)據(jù)中心有5-6個(gè)，核心的機(jī)房有兩個(gè)。一個(gè)是在線機(jī)房，它部署直接面向知乎主站用戶的服務(wù)，比如評論、回答和推薦等。另一個(gè)是離線機(jī)房，主要部署一些離線計(jì)算相關(guān)的服務(wù)，比如我們常見的數(shù)據(jù)平臺(tái)、離線存儲(chǔ)以及OLAP引擎等。這兩個(gè)機(jī)房之間依靠機(jī)房專線進(jìn)行通信，所以機(jī)房專線很重要。

衡量機(jī)房專線是否穩(wěn)定的重要指標(biāo)之一，就是機(jī)房的流量。一般情況下，服務(wù)之間的調(diào)用不會(huì)影響到機(jī)房專線流量，因?yàn)榉?wù)之間的調(diào)用使用的機(jī)房流量非常少。但是在我們的算法場景中，有一類非常特殊的情況，它會(huì)直接占滿整個(gè)機(jī)房專線。這就是接下來要介紹的推薦/搜索模型上線場景。

2、推薦/搜索模型上線場景

我們模型的產(chǎn)出，依賴于離線機(jī)房的機(jī)器學(xué)習(xí)平臺(tái)和Spark集群進(jìn)行大規(guī)模的分布式計(jì)算，模型最后寫入到離線HDFS。模型上線的時(shí)候，推理服務(wù)容器會(huì)有幾百個(gè)容器，多的甚至有上千個(gè)容器，同時(shí)去拉取HDFS上面的模型，這樣會(huì)產(chǎn)生比較大的跨專線流量，會(huì)帶來兩個(gè)問題：

• 流量過大導(dǎo)致專線不可用，這時(shí)專線帶寬直接被占滿。
• 并發(fā)過高出現(xiàn)DN熱節(jié)點(diǎn)。高并發(fā)拉取HDFS，因?yàn)槎际抢⊥环菽Ｐ臀募?，HDFS會(huì)出現(xiàn)DataNode熱節(jié)點(diǎn)的問題。

3、多HDFS集群方案

早期我們解決這種模型上線問題的方案十分簡單，就是多HDFS集群方案。相比于之前直接從離線HDFS拉取，我們在模型產(chǎn)出時(shí)，采用一個(gè)離線拷貝任務(wù)將模型拷貝到在線的HDFS，拉取的時(shí)候直接從在線HDFS讀取模型。這樣做有兩個(gè)好處：

• 解決了專線流量問題。離線拷貝任務(wù)相當(dāng)于模型只通過一次專線，而且因?yàn)殡x線拷貝任務(wù)是定期運(yùn)行的任務(wù)，不會(huì)很多個(gè)任務(wù)一起拷貝，而是排隊(duì)拷貝，所以這個(gè)專線的流量是可控的。
• 增加文件副本解決了熱點(diǎn)問題。在線HDFS增加了文件的副本，解決了DataNode熱節(jié)點(diǎn)的問題。

但是這種做法也存在一些不足：

• 多個(gè)HDFS集群維護(hù)困難。這里既有在線HDFS，又有離線HDFS。
• 引入了新的離線拷貝任務(wù)，文件視圖難以維護(hù)。因?yàn)樵诰€HDFS和離線HDFS的文件視圖是不一樣的業(yè)務(wù)，用起來會(huì)非常麻煩。
• 新建HDFS集群、增加文件副本都會(huì)導(dǎo)致存儲(chǔ)成本激增。

二、自研組件階段

接下來介紹我們迭代的第三個(gè)版本，就是我們的自研組件UnionStore。

1、自研組件——UnionStore

我們的多云緩存自研組件叫UnionStore。顧名思義，它是聯(lián)合存儲(chǔ)的意思，聯(lián)合了HDFS和對象存儲(chǔ)，對外提供對象存儲(chǔ)的訪問接口。其工作流程為：模型通過機(jī)器學(xué)習(xí)平臺(tái)和spark產(chǎn)出，最后寫入HDFS。讀取的時(shí)候通過對象存儲(chǔ)協(xié)議向UnionStore發(fā)出請求。UnionStore接收到讀取文件請求后，會(huì)檢查對象存儲(chǔ)里面是否存在這個(gè)文件，如果存在就直接返回給用戶，如果不存在就從離線HDFS進(jìn)行讀取，然后上傳到對象存儲(chǔ)，最后再從對象存儲(chǔ)返回給用戶。

2、UnionStore的優(yōu)勢

UnionStore的好處有以下幾點(diǎn)：

• 提供了對象存儲(chǔ)協(xié)議。
• 自動(dòng)緩存機(jī)制替代定時(shí)拷貝任務(wù)。它有一個(gè)自動(dòng)緩存機(jī)制，會(huì)先檢查對象存儲(chǔ)和HDFS的文件的一致性，然后看有沒有緩存到對象存儲(chǔ)上面去。它替代了原來的定時(shí)拷貝任務(wù)。
• 解決了文件視圖的問題。因?yàn)閁nionStore的文件視圖強(qiáng)依賴于離線HDFS，所以它沒有文件視圖不一致的問題。
• 降低了存儲(chǔ)成本。我們下線了一套HDFS集群，換成了對象存儲(chǔ)，所以減少了存儲(chǔ)成本。
• 提供了POSIX讀取HDFS的解決方案。

這是UnionStore的第一個(gè)使用場景。UnionStore提供了對象存儲(chǔ)的訪問方式，它其實(shí)還可以做一件事情，就是用戶可以把UnionStore用s3fs-fuse掛載到POSIX本地目錄上，讀取訓(xùn)練數(shù)據(jù)的時(shí)候直接通過本地目錄來讀，從而為機(jī)器學(xué)習(xí)平臺(tái)提供更好的幫助。

這個(gè)方案一上線就備受用戶好評。當(dāng)時(shí)HDFS掛載采用了兩種方式，第一種是Hadoop社區(qū)提供的HDFS掛載本地目錄的方式，另外一種是以go語言寫的HDFS掛載方式。但是這兩種方案的重試都做得不夠好。s3fs-fuse的重試做得比較好，所以我們選擇了s3fs-fuse這種方式。

3、UnionStore的不足

UnionStore在知乎內(nèi)部運(yùn)行了足足兩年時(shí)間，早期沒有出現(xiàn)任何問題，但是隨著模型規(guī)模的不斷擴(kuò)大，逐漸出現(xiàn)了以下問題：

• 元數(shù)據(jù)強(qiáng)依賴HDFS，在HDFS抖動(dòng)的時(shí)候，有些需要頻繁更新的模型文件會(huì)受影響，無法更新，UnionStore有時(shí)候不可用。
• 緩存文件時(shí)卡住用戶請求，冷讀文件慢。在緩存文件的時(shí)候，UnionStore會(huì)做檢查，這個(gè)時(shí)候會(huì)卡住用戶的請求，導(dǎo)致冷讀文件十分慢。
• 對象存儲(chǔ)存在性能問題，讀取速度慢。這里不僅是單線程讀取的速度很慢，而且對象存儲(chǔ)整體是有帶寬的，一般來說，假如云廠商比較靠譜，能夠提供1TB左右的帶寬，否則只有幾百GB，顯然不能滿足我們的需求。
• S3 fuse組件放大HDFS元數(shù)據(jù)請求，帶來比較大的性能壓力。

以上缺點(diǎn)使我們面臨兩個(gè)選擇，第一個(gè)方案就是繼續(xù)迭代UnionStore，使它能夠滿足我們內(nèi)部的需求；第二個(gè)方案就是尋找一個(gè)合適的開源解決方案，替代UnionStore的使用場景?；谌肆Y源的寶貴，我們選擇了第2個(gè)方案，找一個(gè)合適的開源解決方案。

開源方案需要解決兩個(gè)使用場景，第一個(gè)是模型讀取加速場景，它要提供一個(gè)對象存儲(chǔ)協(xié)議；第二個(gè)是模型訓(xùn)練加速場景，它要提供本地目錄的一種訪問方式。

三、Alluxio階段

我們調(diào)研了很多開源解決方案，內(nèi)部也有很多緩存組件，最后發(fā)現(xiàn)只有Alluxio能夠滿足我們的需求。Alluxio具有以下優(yōu)勢：

• 高性能數(shù)據(jù)緩存能力。它能夠解決對象存儲(chǔ)性能差的問題，其緩存是透明的，業(yè)務(wù)方無需改造就能夠直接上線。透明緩存能力十分重要。我們之前也有一些其他多云緩存組件，緩存不是透明的，必須要向它那里寫才能從它那里讀，而我們的數(shù)據(jù)存在HDFS，因此無法滿足需求。
• 訪問接口非常豐富。它提供了Alluxio fuse，能夠提供本地的文件訪問方式，也提供了對象存儲(chǔ)協(xié)議。
• 豐富的UFS支持。它能夠同時(shí)掛載HDFS和對象存儲(chǔ)。

這三點(diǎn)就已經(jīng)能夠滿足我們的需求了，但是它還提供了另外三個(gè)功能：

• 元數(shù)據(jù)緩存，它能夠有效降低NameNode的負(fù)載。
• 即席查詢場景加速。它的即席查詢場景加速適配是非常好的。我們內(nèi)部把Spark和Presto作為主要的Ad-hoc場景查詢，Alluxio社區(qū)有非常多的案例可以供我們借鑒。
• 社區(qū)活躍。模型上線的時(shí)候可以借鑒社區(qū)的各種方案，遇到問題也可以向社區(qū)請求一些支援，社區(qū)為我們提供了非常多的幫助。

通過調(diào)研確定功能滿足我們的需求以后，我們使用它進(jìn)行了模型的上線。

1、模型讀取加速場景

第一個(gè)場景，模型讀取加速場景，接下來將從客戶端的選擇、性能測試、部署與調(diào)優(yōu)，以及上線效果這四方面來進(jìn)行介紹。

（1）客戶端選擇—S3 Proxy

我們選擇Alluxio S3 Proxy進(jìn)行模型讀取場景的加速，原因有以下幾點(diǎn)：

• 用戶當(dāng)前使用的UnionStore對象存儲(chǔ)協(xié)議與S3 Proxy天然兼容。
• 用戶單個(gè)容器可用資源比較少，這就排除了Alluxio fuse，因?yàn)樗容^依賴本地緩存，本地元數(shù)據(jù)緩存要消耗比較大的磁盤和內(nèi)存。
• 用戶讀取文件的方式有三種語言：Python、Java和Golang。因?yàn)橹踝铋_始是用Python寫主站程序的，后面才轉(zhuǎn)成Golang和Java，所以這里也排除了Alluxio Java client，因?yàn)樗恢С諮ava語言。

（2）Alluxio S3 Proxy性能測試

我們對Alluxio S3 Proxy進(jìn)行了一系列的性能測試，對比了HDFS、UnionStore以及Alluxio，發(fā)現(xiàn)Alluxio在熱讀文件的時(shí)候，其性能遠(yuǎn)超另外兩個(gè)組件，100GB文件熱讀的時(shí)間只有UnionStore的1/7，這個(gè)加速效果是非常明顯的。

（3）部署方式

部署時(shí)我們選擇了裸金屬機(jī)部署，為什么沒有選擇K8S部署，原因有以下幾點(diǎn)：

• Worker強(qiáng)依賴磁盤，如果和其他的應(yīng)用程序共享磁盤，可能會(huì)影響Worker本身的性能。
• Worker讀取速度太快，容易打滿網(wǎng)卡，影響其他服務(wù)。如果進(jìn)行K8S部署，假如有其他的服務(wù)跟Worker部署到同一個(gè)K8S節(jié)點(diǎn)，那么該節(jié)點(diǎn)的網(wǎng)卡資源將被占滿，調(diào)用不了其他的服務(wù)。
• 裸金屬機(jī)混合部署S3 Proxy與Worker，配置短路讀更加方便。它天然支持短路讀。
• 知乎有基于Ansible構(gòu)建的專屬的大數(shù)據(jù)運(yùn)維平臺(tái)，所以K8S的運(yùn)維優(yōu)勢不大。

這里我們的部署方式是S3 proxy，最后通過DNS代理域名，供用戶的訪問。

（4）部署與調(diào)優(yōu)

模型讀取場景的調(diào)優(yōu)，需要結(jié)合模型讀取場景的特點(diǎn)來進(jìn)行。模型讀取場景有以下三個(gè)特點(diǎn)：

• 并發(fā)高。單一模型文件上線的時(shí)候流量能夠達(dá)到1TB每秒。
• 過期快。模型文件只會(huì)在短時(shí)間內(nèi)使用，讀取完畢后即可視為過期。
• 緩存穿透。數(shù)據(jù)產(chǎn)出與數(shù)據(jù)讀取的時(shí)間間隔短，只有幾秒鐘，所以基本上是無法進(jìn)行提前預(yù)熱的。

我們針對這三個(gè)特點(diǎn)進(jìn)行了針對性的調(diào)優(yōu)：

• 針對并發(fā)高的問題，文件的緩存副本沒有設(shè)置上限，基本上每一個(gè)Worker都會(huì)緩存一個(gè)文件，每一個(gè)文件都會(huì)在每一個(gè)Worker存在一份，供客戶端讀取，并且我們把Worker與Proxy進(jìn)行了混部使用，短路讀節(jié)省流量。
• 針對過期快的問題，過期快對我們來說不是劣勢，反而是一個(gè)優(yōu)勢，意味著集群存儲(chǔ)容量可以非常小，Worker完全可以采取高性能磁盤。我們現(xiàn)在采用NVME磁盤，成本是可控的。
• 緩存穿透的問題，實(shí)際上是非常難以解決的，我們最后改了一些代碼，自研了一些文件預(yù)熱策略，然后進(jìn)行實(shí)時(shí)的預(yù)熱。

接下來詳細(xì)說明各個(gè)調(diào)優(yōu)策略。

• 調(diào)優(yōu)一：短路讀

左邊的圖是沒有短路讀的時(shí)候，用戶在請求S3 Proxy讀取文件的時(shí)候，會(huì)經(jīng)過兩層網(wǎng)絡(luò)，第一層網(wǎng)絡(luò)是用戶到S3 Proxy，第二層網(wǎng)絡(luò)是S3 Proxy到Worker，最后由Worker讀取磁盤上的文件，這種情況下網(wǎng)卡的消耗非常大。

右邊的圖是短路讀的情況，用戶在請求了S3 Proxy以后，S3 Proxy會(huì)直接讀取磁盤上的數(shù)據(jù)，無需經(jīng)過Worker，這樣相當(dāng)于省下了S3 Proxy到Worker之間的流量。據(jù)我們線上的測試，大概能夠節(jié)省30%到50%的流量。

• 調(diào)優(yōu)二：文件實(shí)時(shí)預(yù)熱策略

文件實(shí)時(shí)預(yù)熱策略，通俗的講，就是把Distributed Load的功能做到了S3 Proxy里面去。S3 Proxy接受下載請求時(shí)，會(huì)將文件分塊，把每一個(gè)文件塊提交到不同的Worker進(jìn)行并發(fā)緩存。這樣做的好處在于，下載文件時(shí)，前面可能沒緩存，下載得很慢，但是讀到后面文件的時(shí)候，因?yàn)槠渌腤orker可能已經(jīng)把文件緩存完了，所以能夠達(dá)到跟命中緩存幾乎一樣的速度。這種加速策略是文件越大，效果越明顯。在讀取大文件的時(shí)候，比如文件有10GB，這時(shí)讀的速度比冷讀提升到2-5倍；如果是100GB，基本上和熱讀沒有區(qū)別。

第二個(gè)好處是順序靠后的文件塊，因?yàn)橐呀?jīng)提前緩存了，能夠節(jié)省UFS的流量，據(jù)線上數(shù)據(jù)驗(yàn)證，能夠節(jié)省2-3倍的UFS流量。

再來看一下實(shí)時(shí)預(yù)熱策略的效果，下圖是線上的真實(shí)截圖，里面的每一條線段都代表模型讀取的一個(gè)請求，線段越長代表讀模型花費(fèi)的時(shí)間越長，讀取速度越慢。

階段一是用UnionStore讀取的效果，階段二是直接上線S3 Proxy讀取的效果?？梢钥吹秸w的讀取耗時(shí)下降了大概一半，但是出現(xiàn)了一些尖刺，說明有些請求可能會(huì)讀得特別慢，這是因?yàn)锳lluxio在冷讀文件的時(shí)候性能下降得十分明顯。

階段三是上線了實(shí)時(shí)預(yù)熱策略后讀取的效果，可以看到所有的尖刺基本上消失了，而且文件整體的讀取速度也有所提升，預(yù)熱的效果是非常好的。

• 調(diào)優(yōu)三：元數(shù)據(jù)緩存

第三個(gè)優(yōu)化策略是做了一定的元數(shù)據(jù)緩存，分為三個(gè)階段。上圖也是線上的真實(shí)截圖。階段一是用UnionStore讀取，速度非常慢；階段二是直接上線S3 Proxy讀取，可以看到時(shí)間降了一大截，速度幾乎提升了一倍；階段三是上線了一分鐘的元數(shù)據(jù)緩存以后的情況，對比最開始UnionStore，速度提升了幾十倍。

元數(shù)據(jù)緩存開啟以后需要特別注意元數(shù)據(jù)同步，因?yàn)樗赡軙?huì)造成文件的不一致，所以我們也制定了一些文件的使用規(guī)范。比如新增文件，我們讓用戶盡量去寫入新目錄，以版本號的形式管理，盡量不要追加或覆蓋舊文件。如果對于一些業(yè)務(wù)歷史遺留的任務(wù)，實(shí)在需要對舊文件進(jìn)行修改，我們也提供了一些比較特殊的方式。我們在S3 Proxy上改了一些代碼，增加了特殊的命令，供用戶來刷新元數(shù)據(jù)。

• 調(diào)優(yōu)四：S3 Proxy限速

S3 Proxy限速的目的主要是為了保護(hù)Worker和業(yè)務(wù)容器，防止網(wǎng)卡打滿。因?yàn)镾3 Proxy的速度非常快，最高能夠達(dá)到1.6GB的速度，對網(wǎng)卡的消耗非常大，所以要保護(hù)Worker的網(wǎng)卡和業(yè)務(wù)容器的網(wǎng)卡。這里我們做了兩個(gè)限速，第一個(gè)是進(jìn)行S3 Proxy進(jìn)程的全局限速，這樣可以保護(hù)Worker網(wǎng)卡。第二個(gè)是進(jìn)行了單連接限速，保護(hù)業(yè)務(wù)所在容器的K8S節(jié)點(diǎn)，防止這個(gè)節(jié)點(diǎn)整體的網(wǎng)卡被打滿。這個(gè)功能已經(jīng)貢獻(xiàn)給了社區(qū)，2.9.0以后的版本也都已經(jīng)上線。

下圖是模型讀取加速的整體效果，可以看到速度提高了大概幾十倍。當(dāng)然這里的幾十倍是因?yàn)槲覀兊腁lluxio集群是非?？臻e的，真實(shí)的上線結(jié)果是UnionStore和Alluxio的速度一樣，但是Alluxio用的資源只有UnionStore的一半，相當(dāng)于是節(jié)省了50%的成本。

2、模型訓(xùn)練加速場景

第二個(gè)場景是模型訓(xùn)練加速場景，也從四個(gè)方面來介紹：客戶端的選擇、性能測試、部署與調(diào)優(yōu)、上線效果。

（1）客戶端選擇——Alluxio fuse

客戶端選擇了Alluxio Fuse，原因有以下幾點(diǎn)：

• 用戶當(dāng)前使用s3f3-fuse，它可以被Alluxio fuse替代。
• 模型訓(xùn)練框架對本地目錄支持較好。比如Tensorflow、pytorch這些模型訓(xùn)練框架，對本地目錄支持是最好的，其他的如S3可能也支持，但是沒有本地目錄支持得好，所以我們還是選Alluxio fuse。
• GPU機(jī)器是比較特殊的，它的瓶頸在于GPU，而不是內(nèi)存、磁盤和CPU。它的內(nèi)存、磁盤、CPU相對比較空閑，Alluxio fuse能夠充分地利用這些閑置的資源，進(jìn)行本地的數(shù)據(jù)緩存和元數(shù)據(jù)緩存。

（2）Alluxio fuse性能測試

選擇了客戶端以后，我們對它進(jìn)行性能測試。測試選用官方的默認(rèn)配置，這里有兩個(gè)跟官方默認(rèn)配置不同的點(diǎn)，一個(gè)是開啟了一定的內(nèi)核元數(shù)據(jù)緩存，另一個(gè)是容器的總內(nèi)存非常大，原因是我們想用內(nèi)核元數(shù)據(jù)緩存。

我們以本地磁盤作為測試基準(zhǔn)，測試的結(jié)果如下。本地磁盤的順序讀是1800 MB/S，隨機(jī)讀是1000 MB/S，fuse 1G實(shí)際文件順序讀的時(shí)候，達(dá)到了1700 MB/S的速度，基本達(dá)到本地磁盤90%的性能，這是非常高的性能了。fuse 100G文件順序讀的時(shí)候，性能急速下降，這是因?yàn)槲覀冎叭萜鞯膬?nèi)存是40GB，它沒有充足的page cache來緩存100GB文件，而對于1GB和10GB的文件是有充足的緩存命中的，所以它的性能會(huì)降低一半。

fuse隨機(jī)讀的性能相對較差，只有450 MB/S，但也能滿足我們的模型訓(xùn)練的需求，整體上符合預(yù)期。

（3）部署與調(diào)優(yōu)

模型訓(xùn)練場景的調(diào)優(yōu)需要結(jié)合它的特點(diǎn)進(jìn)行。模型訓(xùn)練場景也有3個(gè)特點(diǎn)：

• 資源充足。GPU機(jī)器除了GPU以外，其他的資源都比較空閑。
• 獨(dú)占。GPU機(jī)器只運(yùn)行模型訓(xùn)練任務(wù)，它不會(huì)和其他服務(wù)進(jìn)行混部，如果不運(yùn)行訓(xùn)練任務(wù)，它就是空閑的。
• 文件快照。訓(xùn)練數(shù)據(jù)是以文件快照的形式進(jìn)行組織的，不會(huì)時(shí)常更新它，所以它對元數(shù)據(jù)的一致性要求比較低。

我們采用DeamonSet的形式來部署fuse進(jìn)程。我們用host path一層一層地掛載緩存數(shù)據(jù)的目錄，然后提供給模型訓(xùn)練容器來使用。

• Fuse本身提供了CSI的部署方式，但是我們沒有選，主要是基于以下幾點(diǎn)考慮：首先就是GPU機(jī)器的老問題，它大多數(shù)情況下是非常空閑的，所以Alluxio fuse可以提供一個(gè)超級大的胖容器，讓它充分的使用閑置的磁盤、內(nèi)存和CPU。
• 第二個(gè)是訓(xùn)練數(shù)據(jù)的重復(fù)程度高，在分布式訓(xùn)練的時(shí)候，所有的節(jié)點(diǎn)可能會(huì)去讀同一份數(shù)據(jù)，如果用CSI的話，可能同一個(gè)GPU機(jī)器上啟動(dòng)了多個(gè)fuse進(jìn)程，它們將同一個(gè)文件緩存了多份，這樣比較浪費(fèi)磁盤。
• 第三個(gè)是GPU機(jī)器的獨(dú)占性，不需要考慮fuse進(jìn)程資源釋放的問題。即使訓(xùn)練容器退出了，也不需要釋放，它可以長時(shí)間運(yùn)行。
• 最重要的一點(diǎn)就是DeamonSet加上host path的方式，可以很容易實(shí)現(xiàn)掛載點(diǎn)恢復(fù)，這樣即使是在fuse進(jìn)程退出以后，當(dāng)場讀文件失敗了，只要用戶配置了重試，也是可以重新拉起來的。

接下來我們結(jié)合fuse，看一下整個(gè)Alluxio集群的部署方式。我們采取小集群重客戶端的方式，顧名思義，Alluxio集群其實(shí)是非常小的，它只有3個(gè)支持Raft協(xié)議的master節(jié)點(diǎn)以及3個(gè)Worker節(jié)點(diǎn)，但是它支撐了上百臺(tái)GPU機(jī)器，這里大概是100-300臺(tái)GPU機(jī)器，包括幾PB的NVME存儲(chǔ)。有數(shù)百個(gè)fuse進(jìn)程部署在GPU機(jī)器上。每個(gè)fuse進(jìn)程都有10TB的NVME做本地緩存。這樣相當(dāng)于Alluxio集群其實(shí)只做了一件事情，就是數(shù)據(jù)的分發(fā)，其他的如性能保障之類的事情就完全交給fuse進(jìn)程本地完成了。

最后是Alluxio的調(diào)優(yōu)。它的調(diào)優(yōu)項(xiàng)非常簡單，我們僅做了少許改造，其他都是官方配置。

• 首先是適當(dāng)?shù)卦黾颖镜鼐彺骓摰拇笮?，因?yàn)楣俜脚渲玫谋镜鼐彺骓撎?，默認(rèn)是1MB，在讀大文件的時(shí)候性能很差，我們把它改成了16MB。
• 第二個(gè)是開啟內(nèi)核元數(shù)據(jù)緩存。從前面的測試結(jié)果來看，開啟了內(nèi)核元數(shù)據(jù)緩存可以使性能提升一倍。
• 第三個(gè)是推薦使用短內(nèi)核元數(shù)據(jù)緩存時(shí)間配合一個(gè)長時(shí)間的metadata sync時(shí)間，這樣可以讓每個(gè)fuse基本都能夠讀到相同的文件版本。
• 第四個(gè)是實(shí)現(xiàn)掛載點(diǎn)恢復(fù)防止fuse進(jìn)程意外重啟。我們發(fā)現(xiàn)在容器里面部署fuse，在容器里面實(shí)現(xiàn)存儲(chǔ)會(huì)遇到很多奇怪的問題。如果有一種自動(dòng)恢復(fù)的手段，能夠大大提高它的穩(wěn)定性。

（3）模型訓(xùn)練加速效果

從實(shí)際加速效果來看，模型訓(xùn)練整體提速60%，本來需要訓(xùn)練10天的模型，現(xiàn)在只需要6天就可以訓(xùn)練完畢。另外，訓(xùn)練模型時(shí)讀取數(shù)據(jù)的速度也提升了2.5倍。

3、補(bǔ)充場景

我們內(nèi)部還有一個(gè)比較有意思的場景，就是大數(shù)據(jù)運(yùn)維場景，這也是我們的補(bǔ)充場景。

（1）大數(shù)據(jù)組件發(fā)布與上線（優(yōu)化前）

首先介紹一下我們大數(shù)據(jù)組件的發(fā)布與上線流程。比如上線一個(gè)大數(shù)據(jù)組件，用戶開發(fā)者首先提交他的任務(wù)到GitLab，GitLab在收到合并代碼請求以后，會(huì)調(diào)用CI的Web Hook，自動(dòng)幫用戶構(gòu)建打包，然后把二進(jìn)制包上傳到Kosmos。這里的Kosmos是我們內(nèi)部的包管理服務(wù)，Kosmos在收到二進(jìn)制包后，會(huì)轉(zhuǎn)存到對象存儲(chǔ)，這是發(fā)布過程。

再看上線過程。開發(fā)者在大數(shù)據(jù)運(yùn)維平臺(tái)點(diǎn)擊新版本上線，然后大數(shù)據(jù)運(yùn)維平臺(tái)會(huì)把部署邏輯分發(fā)到生產(chǎn)環(huán)境服務(wù)器。生產(chǎn)環(huán)境服務(wù)器運(yùn)行部署邏輯，如果中途要下載包，它會(huì)請求Kosmos進(jìn)行下載。Kosmos在接收下載請求以后，會(huì)將請求重定向到對象存儲(chǔ)，這個(gè)時(shí)候生產(chǎn)環(huán)境服務(wù)器直接從對象存儲(chǔ)拉取二進(jìn)制包，整個(gè)流程是非常完美的。唯一的瑕疵出現(xiàn)在對象存儲(chǔ)下載二進(jìn)制包的時(shí)候，它會(huì)有以下兩個(gè)問題：

• 對象存儲(chǔ)下載速度慢，批量部署時(shí)間長。單線程對象存儲(chǔ)的下載速度只有10-30M，在批量部署DataNode的時(shí)候，花費(fèi)的時(shí)間非常長。以1萬臺(tái)DataNode為例，如果我們按兩臺(tái)滾動(dòng)重啟，每一個(gè)就接近半分鐘的下載時(shí)間，整體合計(jì)的部署時(shí)間在48小時(shí)以上。
• 跨機(jī)房使用容易產(chǎn)生外網(wǎng)流量。這是因?yàn)槲覀冎挥昧艘粋€(gè)對象存儲(chǔ)，如果其他地方的技術(shù)組件進(jìn)行部署，而且不在同一個(gè)機(jī)房的話，它會(huì)產(chǎn)生外網(wǎng)流量，這個(gè)成本相當(dāng)高。

（2）大數(shù)據(jù)組件發(fā)布與上線（優(yōu)化后）

我們用Alluxio對這個(gè)流程進(jìn)行了一些優(yōu)化，過程很簡單。我們把Kosmos用的對象存儲(chǔ)直接掛載到Alluxio上，因?yàn)锳lluxio不僅支持HDFS的掛載，還支持對象存儲(chǔ)的掛載。生產(chǎn)環(huán)境服務(wù)器在下載包的時(shí)候，會(huì)直接向S3 Proxy請求二進(jìn)制包。由于是在Alluxio下載的，它的速度非?？?，如下圖所示，這是一個(gè)對比圖，展示了最后上線后的效果。

圖中的紅圈是從對象存儲(chǔ)下載的速度，大概是十幾MB/S，從Alluxio下載大概是600 MB/S。這里的600 MB/S，是壓制下的情況，考慮到前述提及的優(yōu)化方案，即S3 Proxy進(jìn)行限速，我們限速為600 MB/S，它其實(shí)最高能夠達(dá)到1600 MB/S。

四、總結(jié)

最后進(jìn)行一個(gè)技術(shù)總結(jié)?；仡櫸覀兌嘣凭彺娴陌l(fā)展歷程，從最開始的暴力讀取，到后來的多HDFS集群，再到自研組件UnionStore，都不能滿足我們的需求。最后我們上線了Alluxio，才滿足需求。

Alluxio為我們帶來了哪些提升？首先是性能方面，整體上有2-5倍的性能提升。另外是穩(wěn)定性方面，它解除了HDFS的強(qiáng)依賴。最后是成本方面，它為我們節(jié)省了大約一半的成本。

未來我們計(jì)劃在數(shù)據(jù)編排領(lǐng)域以及OLAP加速的場景來使用Alluxio。因?yàn)槲覀冇幸恍┤斯ぶ悄艿膱鼍靶枰玫叫∥募晕覀儽容^期待它的新一代架構(gòu)，Dora架構(gòu)。

五、討論交流

1.Hive使用Alluxio怎么讓用戶歷史創(chuàng)建Hive表盡量少的改動(dòng)？

答：這個(gè)問題我猜可能是不想改Hive表的location，不想讓它從HDFS的開頭改成Alluxio開頭。我們現(xiàn)在還沒做OLAP引擎的加速，但是我們目前有一個(gè)備選的方案。我們可能會(huì)對Hive的MetaStore做一些改造，在計(jì)算引擎讀取HDFS上面的分區(qū)時(shí)，如果已經(jīng)緩存到Alluxio，我們會(huì)直接在Hive MetaStore內(nèi)進(jìn)行修改，然后把HDFS前綴直接修改成Alluxio前綴。這樣就不用改Hive的location。

2.剛剛提到那個(gè)頁的大小，調(diào)優(yōu)從1MB變成了16MB，這是怎么調(diào)出來的？為什么不是32MB？

答：業(yè)務(wù)讀取數(shù)據(jù)的時(shí)候，它不僅有大文件，也有小文件，如果這個(gè)值太大的話，對小文件支持不好，太小的話又對大文件支持不好。所以我們根據(jù)實(shí)驗(yàn)經(jīng)驗(yàn)，選了一個(gè)相對折中的值。

3.Alluxio在冷讀的時(shí)候性能下降得比較明顯，然后通過預(yù)熱的方式來解決這個(gè)問題。請問是怎么做預(yù)熱的？

答：比如我們現(xiàn)在有一個(gè)用戶向S3 Proxy請求512 MB的文件，然后S3 Proxy從master拉取到這個(gè)文件的元信息，可以看到它有四個(gè)塊，每個(gè)塊是128 MB大小。對這四個(gè)塊，我們會(huì)通過一個(gè)特殊的算法，可以是哈希也可以是別的，分別打到不同的worker進(jìn)行緩存。S3 Proxy在讀取的時(shí)候可能會(huì)先下載，比如說下載塊1，但塊1可能還沒緩存，所以它是直接從UFS讀取再返回給用戶，可能會(huì)很慢。在讀塊2的時(shí)候，它可能已經(jīng)被緩存完了，這種情況下讀取是非常快的。然后在讀塊3、塊4的時(shí)候可能也都緩存完了，也讀取的很快。我們是這樣來做的。這里要求文件的 block數(shù)要大于1，否則就沒有必要去進(jìn)行加速，因?yàn)槲募旧肀容^小，就算性能差，它也能很快地讀完。

4.剛剛提到利用Alluxio做元數(shù)據(jù)緩存，元數(shù)據(jù)到底里面有哪些東西？

答：元數(shù)據(jù)緩存在Alluxio里面分為三塊，第一塊是UFS的元數(shù)據(jù)，比如對象存儲(chǔ)的元數(shù)據(jù)，它會(huì)在master里面進(jìn)行緩存。第二塊是fuse，就是客戶端本地的元數(shù)據(jù)緩存。這個(gè)比較常見，fuse會(huì)用內(nèi)存來緩存一次master的元數(shù)據(jù)。第三塊是內(nèi)核元數(shù)據(jù)，這個(gè)也是fuse里面比較常見的，它是操作系統(tǒng)層面的緩存，緩存操作系統(tǒng)本地的目錄情況。

元數(shù)據(jù)緩存對性能有很大的影響。不開啟元數(shù)據(jù)緩存的時(shí)候，比如我們不緩存UFS的元數(shù)據(jù)，那么客戶端的每一次請求都會(huì)穿透到UFS上面去，性能會(huì)非常差。特別是在對象存儲(chǔ)的時(shí)候，比如要list一個(gè)目錄，對象存儲(chǔ)list目錄的性能是非常差的，有時(shí)候可能要花好幾秒。

我們這里設(shè)置了1分鐘的緩存超時(shí)時(shí)間。1分鐘的元數(shù)據(jù)緩存其實(shí)也是一個(gè)折中的做法，就是要盡可能的讓用戶很快地感受到他的文件有變更，同時(shí)也要做一定程度的緩存。如果對元數(shù)據(jù)一致性要求不是那么的嚴(yán)格的話，其實(shí)也可以調(diào)成1小時(shí)、幾小時(shí)或者幾天都行，或者手動(dòng)刷新都可以。這個(gè)只能根據(jù)場景來調(diào)優(yōu)。

5.模型上線和模型訓(xùn)練場景里邊都有對象存儲(chǔ)，它具體是用的云上的對象存儲(chǔ)，還是本地的對象存儲(chǔ)？它的連接接口都是用標(biāo)準(zhǔn)S3協(xié)議連接的嗎？

答：我們直接買的云廠商的對象存儲(chǔ)服務(wù)。因?yàn)樽约焊阋惶讓ο蟠鎯?chǔ)，這個(gè)成本太高了。

這里涉及到兩種S3協(xié)議。一方面UnionStore本身對外提供S3協(xié)議，這個(gè)組件是我們自研的；另一方面UnionStore利用S3協(xié)議與對象存儲(chǔ)交互，對象存儲(chǔ)是從云廠商買的。

6.模型訓(xùn)練場景中，GPU集群剛開始是幾百個(gè)節(jié)點(diǎn)，但是Alluxio用的是一個(gè)小集群的部署，3個(gè)master加3個(gè)worker的部署，這個(gè)小集群架構(gòu)能滿足整個(gè)熱數(shù)據(jù)的拉取容量以及并發(fā)訪問需求嗎？

答：這個(gè)需要結(jié)合Alluxio自己目前有的一個(gè)問題來解決。目前fuse從集群讀數(shù)據(jù)的時(shí)候是非常慢的，這是Alluxio的一個(gè)缺陷，它最高只能達(dá)到200MB/S左右的速度，所以其實(shí)它怎么讀也讀不滿Worker的網(wǎng)卡。這個(gè)我們已經(jīng)和Alluxio社區(qū)溝通過好多次了，Alluxio下一個(gè)版本會(huì)解決掉這個(gè)問題，我們也非常期待，到時(shí)我們可能也會(huì)做一些版本升級和架構(gòu)升級，比如會(huì)把Worker擴(kuò)一下，或者把Worker直接和業(yè)務(wù)部到一起。