Alluxio助力AI模型訓(xùn)練加速寶典2.0實戰(zhàn)篇

目錄引言 03背景&Alluxio賦能AI場景 05小紅書|加速云端機(jī)器學(xué)習(xí)-Alluxio在小紅書的實踐 15一、面臨的挑戰(zhàn) 15二、多云數(shù)據(jù)加速層 16三、小紅書實踐案例 18四、未來規(guī)劃 29知乎|AlluxioAI助力知乎千卡模型訓(xùn)練 31一、混合云架構(gòu)，帶來便捷與挑戰(zhàn) 31二、知乎的探索歷程 32三、持續(xù)合作，保持探索 40B站|Alluxio在B站AI訓(xùn)練場景的應(yīng)用 41一、B站AI的訓(xùn)練場景 41二、Alluxio在AI訓(xùn)練場景的應(yīng)用 45三、未來規(guī)劃 51輝羲智能|Alluxio在自動駕駛模型訓(xùn)練中的應(yīng)用與部署 52一、自動駕駛數(shù)據(jù)閉環(huán) 52二、算法訓(xùn)練：NAS 53三、算法訓(xùn)練引入Alluxio 55四、Alluxio部署：單機(jī)房 56目錄五、Alluxio部署：跨機(jī)房 57六、Alluxio測試：功能 58七、Alluxio測試：性能 59八、Alluxio落地：調(diào)參適配環(huán)境 60九、Alluxio落地：運維 61十、Alluxio落地：共同進(jìn)步 62十一、小結(jié) 63中汽創(chuàng)智|Alluxio在自動駕駛數(shù)據(jù)閉環(huán)中的應(yīng)用 65一、自動駕駛業(yè)務(wù)介紹 65二、數(shù)據(jù)平臺架構(gòu)以及存儲選型 67三、自動駕駛數(shù)據(jù)平臺使用場景 70四、未來規(guī)劃 78關(guān)于Alluxio引言在當(dāng)今這個人工智能飛速發(fā)展的時代，諸多企業(yè)正站在一個充滿挑戰(zhàn)與機(jī)遇的路口。隨著AI模型訓(xùn)練的熱潮不斷升溫，企業(yè)在追求更高性能計算的同時，也不得不面對GPU資源緊張、模型部署緩慢以及存儲成本失控等問題。這些問題不僅加劇了技術(shù)團(tuán)隊的工作壓力，也對企業(yè)的業(yè)務(wù)發(fā)展和市場競爭力構(gòu)成了嚴(yán)峻考驗。本電子書將深入剖析Alluxio如何在AI/ML場景中發(fā)揮其分布式緩存的作用，助力企業(yè)突破IO瓶頸。Alluxio作為一個高效的數(shù)據(jù)訪問層，優(yōu)化了數(shù)據(jù)在存儲與計算引擎間的流動，顯著提升了數(shù)據(jù)訪問速度和操作便捷性。文章詳盡地列舉了企業(yè)在探索AI過程中遇到的挑戰(zhàn)，細(xì)致闡釋了Alluxio在技術(shù)架構(gòu)中的關(guān)鍵角色，以及其如何通過優(yōu)化AI框架的IO性能，提升整體數(shù)據(jù)處理能力。同時，文中通過小紅書、知乎、B站、輝羲智能以及中汽創(chuàng)智等知名企業(yè)的實戰(zhàn)案例，生動展示了Alluxio如何助力企業(yè)在解決技術(shù)難題的同時，實現(xiàn)更快的模型開發(fā)周期、更及時的數(shù)據(jù)更新、更高的模型準(zhǔn)確性和可追溯性，以及更好地適應(yīng)數(shù)據(jù)集的迅猛增長。本電子書將幫助用戶迅速把握Alluxio如何助力企業(yè)應(yīng)對AI模型訓(xùn)練的多重挑戰(zhàn)，捕捉行業(yè)發(fā)展的脈搏，實現(xiàn)技術(shù)上的飛躍和業(yè)務(wù)上的持續(xù)增長。用戶收益實戰(zhàn)經(jīng)驗借鑒：通過小紅書、B站、知乎、輝羲智能等企業(yè)案例，了解如何將Alluxio應(yīng)用于實際場景，解決具體的業(yè)務(wù)挑戰(zhàn)。多云架構(gòu)優(yōu)化：了解如何在多云環(huán)境中利用Alluxio實現(xiàn)數(shù)據(jù)的高效管理和訪問，從而優(yōu)化多云架構(gòu)下的數(shù)據(jù)使用和存儲成本。性能與成本的雙重優(yōu)化：掌握如何通過Alluxio提升數(shù)據(jù)處理性能，同時實現(xiàn)成本優(yōu)化。前沿技術(shù)洞察：獲得對未來技術(shù)發(fā)展趨勢的洞察，為技術(shù)選型和業(yè)務(wù)布局提供參考。靈活性與擴(kuò)展性實踐：了解Alluxio如何支持不同技術(shù)棧和框架，增強(qiáng)現(xiàn)有系統(tǒng)的靈活性和擴(kuò)展性，以適應(yīng)不斷變化的技術(shù)需求。適用人群數(shù)據(jù)科學(xué)家與機(jī)器學(xué)習(xí)工程師、AI研發(fā)團(tuán)隊、技術(shù)架構(gòu)師、基礎(chǔ)設(shè)施團(tuán)隊、技術(shù)平臺團(tuán)隊、云計算與存儲團(tuán)隊、IT運維與系統(tǒng)管理員、業(yè)務(wù)分析師與決策者、學(xué)術(shù)研究人員、技術(shù)愛好者、產(chǎn)品經(jīng)理、行業(yè)解決方案顧問背景&Alluxio賦能AI場景一、企業(yè)在嘗試AI時面臨的挑戰(zhàn)GPU短缺其實從幾年前就已經(jīng)呈現(xiàn)了一些趨勢，不管是在云上使用GPU還是自己購買GPU搭建IDC（數(shù)據(jù)倉庫），AI基礎(chǔ)設(shè)施都比較困難，原因大概可以分為3種情況：很多公司無法買到GPU；部分公司即使買到了GPU，量也不是很大，很難滿足業(yè)務(wù)需求；部分公司或許可以在阿里云或者騰訊云上買到GPU，但如何把這些GPU形成一個系統(tǒng)的計算池，供上層業(yè)務(wù)使用，是比較困難的。模型上線慢公司現(xiàn)有數(shù)倉/存儲方案較陳舊，很難迭代，進(jìn)行GPU訓(xùn)練后，如何把模型上線到推理的集群中，是必不可少的一個環(huán)節(jié)，也是困難重重的一個環(huán)節(jié)：很多數(shù)倉、底層的存儲都還是公司里比較傳統(tǒng)的存儲方案，比如HDFS，可能十幾年前就開始用了，現(xiàn)在很難調(diào)整存儲的設(shè)置；數(shù)據(jù)在云上，限流情況嚴(yán)重，使用限制較多。后面也會深入聊一下，如何解決這個問題。GPU使用率低現(xiàn)在很多公司模型訓(xùn)練過程GPU利用率普遍比較低，當(dāng)然這個不是Alluxio一家就能解決的問題，普遍現(xiàn)象是：企業(yè)的數(shù)據(jù)大多在數(shù)倉中，這些數(shù)據(jù)如何引入GPU集群，存在非常多的挑戰(zhàn)。后文也會分享在不同云廠商、國內(nèi)外的大型企業(yè)中，Alluxio是如何解決這一問題的：前面所提到的更多都是業(yè)務(wù)的壓力或者是商業(yè)上業(yè)務(wù)決策的壓力，這些壓力反映到基礎(chǔ)上對工程人員來說就會變成技術(shù)壓力，為了能夠更快進(jìn)行模型開發(fā)，Alluxio其實是有一些期望的：更快的模型開發(fā)時間；更頻繁的模型數(shù)據(jù)更新；更高的準(zhǔn)確性和可追溯性；適應(yīng)快速增長的數(shù)據(jù)集。這些壓力反映到技術(shù)側(cè)大概可以概括為3點：廣泛的數(shù)據(jù)拷貝任務(wù)管理比如以現(xiàn)在的應(yīng)用，如何做這套系統(tǒng)，很多時候需要進(jìn)行一些復(fù)雜的數(shù)據(jù)拷貝任務(wù)，從數(shù)據(jù)倉庫往GPU的訓(xùn)練集群中進(jìn)行數(shù)據(jù)拷貝，無論是拷貝到本地的NAS、NFS系統(tǒng)，或者是拷貝到本地的磁盤中進(jìn)行數(shù)據(jù)管理，都是比較復(fù)雜的專用存儲為了滿足AI場景的需求，對性能的要求會比較高，可以這么理解：20-30年前，GPU是和HPC（高性能計算）一起發(fā)展起來的，所以那時候大家普遍傾向于要有一套IB的網(wǎng)絡(luò)，并且是有一套高性能存儲（全閃）支撐業(yè)務(wù)的發(fā)展，其實現(xiàn)在在云上或者是IDC里，這個問題是非常難解決的，因為大部分公司/云上設(shè)施沒有辦法提供這么高的專用存儲支持模型訓(xùn)練或者是模型分發(fā)的任務(wù)。云和基礎(chǔ)設(shè)施成本失控模型上線以后，隨著業(yè)務(wù)規(guī)模的增長，云和基礎(chǔ)設(shè)施的成本是非常容易失控的，可以看到非常多的場景，比如3年增加5倍的云上成本都是很正常的。二、Alluxio在技術(shù)棧中的位置在進(jìn)入詳細(xì)技術(shù)討論之前，再系統(tǒng)介紹一下Alluxio在AI/ML技術(shù)棧中的位置。首先，Alluxio不是一個持久化的存儲層，持久化存儲比較依賴云上S3Storage、Ceph或者是HDFS這種分布式存儲，這些都是Alluxio下面的一個接口，和Alluxio不是同一個概念。再往上，Alluxio在AI領(lǐng)域是一個高性能的接入層，因為對于持久化存儲層來講，大部分公司追求的是價格和性能效率，而這個效率就意味著要有一個非常便宜的存儲池，可以存儲很多資源，并不期望有一套非常昂貴的高性能存儲來做持久化存儲，之所以會這樣是因為很多互聯(lián)網(wǎng)廠商或者是傳統(tǒng)企業(yè)的數(shù)據(jù)量有幾百個PB至是EB級別的，但同時需要訓(xùn)練的數(shù)據(jù)并沒有那么多，可能就是幾十個TB，甚至高一點的也就1PB左右，如果可以把這些數(shù)據(jù)放到一個高性能存儲向上進(jìn)行對接，對用戶來說這個性價比是非常低的，所以Alluxio比較依賴這種持久化存儲層進(jìn)行非常簡單的對接，或者現(xiàn)在已經(jīng)有了持久化存儲層，不改變它的架構(gòu)，可以直接進(jìn)行數(shù)據(jù)對接。再往上，Alluxio對Pytorch、TensorFlow的IO性能做了非常多優(yōu)化，包括緩存策略、調(diào)度的優(yōu)化/如何與它對接、Kubernetes的部署等。再往上就是Ray或者是MLFlow這種AI/ML的編排層。Alluxio是一個從大數(shù)據(jù)場景發(fā)展起來的公司，在這波AICG浪潮中逐漸被用戶轉(zhuǎn)移使用場景到支持AI/ML的workload，從使用Alluxio的客戶/用戶環(huán)境中總結(jié)的價值是有非常多的，大概可以概括成4點：更高性能、可擴(kuò)展的AI/ML管道Alluxio不改變現(xiàn)有的集群部署，比如已有的對象存儲、HDFS等，同時又想擴(kuò)展業(yè)務(wù)，這里其實有兩個關(guān)鍵點：一般大數(shù)據(jù)和AI兩個Team雖然在一個大的架構(gòu)下，但其實技術(shù)棧是非常不同的，比如大數(shù)據(jù)技術(shù)棧會有Spark、Trino、Hive、HBase等，向下對接的是HDFS、云上的一些對象存儲等，這些數(shù)據(jù)是一直在的，數(shù)據(jù)量可能有幾百個PB甚至EB級別的，同時需要搭建一個AIInfra的平臺，AI技術(shù)棧其實是Pytorch、TensorFlow，下面對接比較多的是對象存儲，比如Ceph、MinIO等，其它的會有一些專用存儲，比如提供NFS、NAS的這些系統(tǒng)向上對接；其實這兩個系統(tǒng)的存在就產(chǎn)生了對接的問題，就是數(shù)據(jù)在數(shù)倉中，但是處理是到AIInfra里，這就變成一套非常復(fù)雜的系統(tǒng)了，而Alluxio可以幫助打通這套系統(tǒng)，不需要每次都進(jìn)行非常復(fù)雜的數(shù)據(jù)遷移。隨時獲取及時、準(zhǔn)確的模型數(shù)據(jù)模型的數(shù)據(jù)從訓(xùn)練集群出來，需要先落到存儲中，然后再向上拉取到推理集群，這個過程很多時候是非常復(fù)雜的，比如DataPipeline，之前遇到很多互聯(lián)網(wǎng)公司都有一個臨時的checkpointstore，然后還有一個持久化的checkpointstore，他們進(jìn)行低性能和高性能的互相拉取是一個非常復(fù)雜的過程。避免復(fù)雜的數(shù)據(jù)遷移模型上線時間相比對象存儲與傳統(tǒng)數(shù)倉快2-4倍底層存儲一般都是對象存儲或者是傳統(tǒng)HDFS，比如傳統(tǒng)的HDFS大家都是給大量數(shù)據(jù)存儲設(shè)計的，這個不是為了性能而設(shè)計的，大部分情況是為了保障容錯，同時針對云上的存儲，在跟諸多云廠商交流后了解到，他們很多情況下沒辦法直接在云上用對象存儲支持AI的業(yè)務(wù)，原因在于限流的問題，拉取數(shù)據(jù)的速度很快，所以沒辦法處理。下面詳細(xì)介紹Alluxio是如何做這套系統(tǒng)的，里面有很多場景的沉淀，此處分享一下Alluxio架構(gòu)設(shè)計的初衷：首先在很多互聯(lián)網(wǎng)廠商群體中，大部分的客戶/用戶，他們的數(shù)據(jù)大概率是在數(shù)據(jù)湖中（有90-95%），他們的數(shù)據(jù)并不是以一個單獨的數(shù)據(jù)集群來做這個事，而是有非常多的數(shù)據(jù)，包括傳統(tǒng)的HiveMetastore、現(xiàn)在比較流行的數(shù)據(jù)湖里的數(shù)據(jù)，同時還有很多StreamingData的數(shù)據(jù)直接進(jìn)來，也有很多非結(jié)構(gòu)化的數(shù)據(jù)是放在數(shù)據(jù)湖里的。那么Alluxio是如何在其中發(fā)揮作用的呢？現(xiàn)在比較流行的就是用Spark或者Ray的架構(gòu)，把這個數(shù)據(jù)預(yù)處理完，放回數(shù)據(jù)湖中，后面的TensorFlow、Pytorch會拉取這里的數(shù)據(jù)進(jìn)行訓(xùn)練，比如看左邊這個圖，如果不用Alluxio拉取數(shù)據(jù)會產(chǎn)生什么問題呢？比如原來的數(shù)倉用的是HDFS集群，AI訓(xùn)練會用一個Ceph的集群：09首先要把處理好/未處理好的數(shù)據(jù)拉到Ceph的集群中，再向上serving這些拉取的data，在這里就會出現(xiàn)一些問題：首先這套拉取的流程會非常復(fù)雜，很多公司會自己開發(fā)一套數(shù)據(jù)管理系統(tǒng)完成，會有幾套不同的流程在里邊，比如用metastore對應(yīng)這些表/數(shù)據(jù)在哪里；其次需要增量的拉取數(shù)據(jù)；最后需要對數(shù)據(jù)進(jìn)行檢驗，查看是否有問題。這套流程下來從拉取到可用有很長的延遲，而Alluxio緩存的功能幫助大家解決這個問題。首先可以預(yù)先將部分?jǐn)?shù)據(jù)加載到Alluxio中，放到更靠近計算的存儲中，從而降低帶寬消耗。同時，即使沒有預(yù)加載數(shù)據(jù)，Alluxio的緩存機(jī)制也能幫助快速拉取數(shù)據(jù)到訓(xùn)練集群中。這種方式類似于股票交易中的T+1（T+0）交易，即從一開始訪問數(shù)據(jù)的瞬間，數(shù)據(jù)就可以被迅速提供，不需要等待數(shù)小時再傳遞數(shù)據(jù)上去，從而節(jié)省了大量時間。其次，Alluxio還能減少用戶自行開發(fā)而產(chǎn)生的數(shù)據(jù)治理問題。如果用戶已經(jīng)有一套數(shù)據(jù)治理系統(tǒng)，Alluxio也提供了多種API，包括原始數(shù)據(jù)更新的API，方便用戶進(jìn)行定制化開發(fā)。此外，Alluxio還著重關(guān)注：在訓(xùn)練集群上如何降低成本并提高效率。過去很多公司使用高性能的存儲集群進(jìn)行訓(xùn)練，但這種成本可能非常昂貴，限制了業(yè)務(wù)的擴(kuò)GPUGPU集群整體成本相比，這個成本通35%。此外，許多公司擁有大量存儲資源，但如何充分利用這些資源仍然是一個挑戰(zhàn)。Alluxio在這方面提供了很多結(jié)合點?？梢詫lluxio集群直接部署到訓(xùn)練節(jié)點上，這樣的消耗非常?。s30-40GB內(nèi)存），卻能提供高性能的訓(xùn)練支持。用戶35GPU服IO瓶頸達(dá)到GPU100%使用率。除了訓(xùn)練集群，Alluxio也特別關(guān)注推理集群的成本和效率問題。隨著推理集群的擴(kuò)展，成本可能遠(yuǎn)高于訓(xùn)練集群。因此Alluxio致力于解決如何快速將訓(xùn)練產(chǎn)生的模型部署到線上集群的問題。在傳統(tǒng)方式中，訓(xùn)練結(jié)果會寫回到一個Ceph存儲，然后線上集群可能位于同一個或不同的IDC中，涉及到復(fù)雜的管理。很多公司會開發(fā)一套自己的存儲網(wǎng)關(guān)(storageGateway）來解決跨域或跨IDC的問題，但是網(wǎng)關(guān)解決的是一個跨域或者是跨IDC問題，實際上沒有解決的是高性能和跨域的問題，簡單理解就是可以把訓(xùn)練集群和線上的ML打通，但如果在AWS里這個Gateway是完全沒有辦法支撐推理集群的，比如擴(kuò)展到100個甚至1000個節(jié)點的推理集群后，上線的時候會抖動的非常厲害，再比如：Alluxio可以在2-3分鐘內(nèi)把整個模型全都部署到推理集群上面，一般這種系統(tǒng)需要耗費的時間是它的10倍，而且它的P95和P99會非常長。三、Alluxio在模型訓(xùn)練&模型上線場景的應(yīng)用接下來會詳細(xì)講解不同場景中，Alluxio是如何做的：第一個就是之前說到的問題，在GPU非常短缺的情況下，很多公司其實之前都不是多云戰(zhàn)略，不是IDC融合或者是云上、本地都有的架構(gòu)，但為了滿足GPU資源的部署，很多時候被迫變成這樣，舉個例子：很多客戶/用戶，數(shù)據(jù)都是在AWS上，根本就不想用Azure、GoogleCloud等其他云，但今年，Azure把所有GPU都買了，在這種情況下其實很難說在AWS上可以找到所有集群，然后這些集群就必須在Azure里，就必須得有個方法直接去訪問AWS里的數(shù)據(jù)，這個問題就導(dǎo)致如果直接去獲取，數(shù)據(jù)性能就會非常低，如果是在網(wǎng)絡(luò)帶寬非常低的情況下，GPU的利用率通常不會超過10%，好一點的網(wǎng)絡(luò)（比如有專線）情況下，可以達(dá)到20-30%。第二個問題是如果要建一個多集群數(shù)據(jù)管理是非常復(fù)雜的，包括要保證數(shù)據(jù)的一致性，如何更新、拉取這些數(shù)據(jù)，但Alluxio做了很多的集成，就可以直接使用Alluxio解決這些問題。其次就是不希望大家專門買一套硬件解決方案，之前接觸過的實驗室有在做HPC的，HPC有一個很大的問題就是成本非常高，買1套HPC通?？梢再I10套Hadoop硬件，或者是云上的存儲硬件，所以如果需要購買一套專有的硬件搭建AIInfra架構(gòu)，是事倍功半的，成本非常昂貴，看到這個場景后，Alluxio提出還是希望可以直接在數(shù)據(jù)湖上構(gòu)建AI和ML的數(shù)據(jù)通路，可以不更改存儲系統(tǒng)，同時可以利用已有的，不需要額外購買IDMA這種硬件，就可以支撐訓(xùn)練的需求。同時不用考慮和原數(shù)倉中任務(wù)進(jìn)行數(shù)據(jù)隔離的問題（所謂隔離就是需要進(jìn)行數(shù)據(jù)遷移，然后運行成兩套非常獨立的系統(tǒng)，這對數(shù)據(jù)的拉取、獲取是非常有問題的）。上圖就是前面提到的，Alluxio提供的一些功能，比如自動數(shù)據(jù)湖加載/卸載、更新數(shù)據(jù)功能，從而提高數(shù)據(jù)工程團(tuán)隊的生產(chǎn)力，一個比較常見的場景就是：如果基于原有的系統(tǒng)搭建，加一個Ceph，基本時間線會拉長到3-6個月，在國外公司拉長到6個月以上是非常常見的，但是用了Alluxio整套系統(tǒng)拉取后，基本就可以在1-2月內(nèi)把整個DataPipeline建起來，如果大家感興趣可以去詳細(xì)了解一下用案例，里邊有非常詳細(xì)的解讀，告訴大家如何去搭建這套系統(tǒng)。

乎的應(yīng)上圖是前面提到的另一個問題：模型部署受限于底層的存儲，包括帶寬的問題，還受限于IDC不同位置的問題，Alluxio可以做一個多云多架構(gòu)，不管是從公有云到私有云，還是不同公有云之間進(jìn)行模型部署，都會非?？焖俚慕鉀Q這個問題，同時會提供一個高并發(fā)的緩存系統(tǒng)，支持業(yè)務(wù)高并發(fā)拉取。稍微總結(jié)一下，Alluxio在AI架構(gòu)中處于怎樣的位置？Alluxio幫助大家解決什么問題？第一個就是降低改造和適配的成本，幫助大家更聚焦在模型上線的邏輯上；第二個就是消除了專用存儲架構(gòu)，比如原來必須要用NAS、NFS這些系統(tǒng)來做的，用了Alluxio之后就不再需用，Alluxio和下面原來已有的HDFS，對象存儲配合就可以搭建AI平臺；第三個就是需要添加緩存，就可以把GPU利用率提高到較高的水平；第四個就是滿足公司自由部署GPU的需求，不管是云上還是云下買的GPU，不論數(shù)據(jù)在哪，都可以實現(xiàn)很高效的數(shù)據(jù)適配，后面會提供一個具體案例。關(guān)于Alluxio在AI場景是如何助力企業(yè)解決問題的，詳細(xì)分享幾個備受關(guān)注的案例：小紅書|加速云端機(jī)器學(xué)習(xí)-Alluxio在小紅書的實踐一、面臨的挑戰(zhàn)首看看小紅書的業(yè)務(wù)都碰到了哪些挑戰(zhàn)。小紅書作為云上的原住民，從成立之初就構(gòu)建在公有云上，下圖是小紅書多云架構(gòu)的示意圖：圖中的三個圈代表兩個云廠商的不同Zone（區(qū)域），云廠商1ZoneAZoneB，云廠商2是在ZoneC。核心業(yè)務(wù)分別分布在多個云廠商的不同可用區(qū)，核心業(yè)務(wù)如搜廣推、社區(qū)通常在主要機(jī)房都會存在，是多活架構(gòu)；主要業(yè)務(wù)如電商直播及部分大數(shù)據(jù)服務(wù)，是雙活架構(gòu)；其他如訓(xùn)練等服務(wù)，是單活架構(gòu)，這個只是個簡化后的示意圖，真實情況遠(yuǎn)比這復(fù)雜。多云架構(gòu)對小紅書帶來了非常明顯的成本優(yōu)勢和可用性優(yōu)勢，但業(yè)務(wù)的通信鏈路也隨之復(fù)雜，各種跨專線調(diào)用；還有個特點是不同region之間rt差異比較大，且專線容量非常稀缺，因此帶來了一些業(yè)務(wù)使用上的痛點。多云架構(gòu)下有哪些典型的問題機(jī)器學(xué)習(xí)訓(xùn)練在小紅書是資源大戶，屬于公司Top級別，但海量的CPU和GPU資源的利用率不及預(yù)期，訓(xùn)練速度上不去，業(yè)務(wù)體感比較差。推薦服務(wù)是小紅書最核心的服務(wù)之一。它的核心邏輯是推薦召回需要有索引分發(fā)的過程，比如刷小紅書刷到的個性化的筆記列表，就主要用到了索引。索引服務(wù)因為索引分發(fā)慢，從而導(dǎo)致穩(wěn)定性比較差，且因為索引數(shù)據(jù)存儲在云盤里，成本也很高。在AI場景下，有業(yè)務(wù)面臨60億+的元信息小文件場景，需要有一個低成本的解決方案。而且隨著AI的飛速發(fā)展，AI模型從之前的百GB級發(fā)展到如今的級別。原來的架構(gòu)通常先把模型拉到本地盤，再從本地盤加載到內(nèi)存，才可以進(jìn)行在線推理。這個過程在模型增大到TB級之后，會有兩個嚴(yán)重的問題：一個是加載過程非常緩慢，另一個是模型存儲在本地盤的成本非常高昂。多云架構(gòu)本身帶來的網(wǎng)絡(luò)鏈路復(fù)雜，跨專線傳輸數(shù)據(jù)量非常大，專線單價也是非常高昂，有成本和穩(wěn)定性的雙重挑戰(zhàn)。二、多云數(shù)據(jù)加速層接下來介紹下小紅書是如何通過構(gòu)建多云統(tǒng)一數(shù)據(jù)加速層來解決這些痛點的。上圖是小紅書業(yè)務(wù)架構(gòu)的示意圖。最上層是業(yè)務(wù)層，主要包括社區(qū)、搜廣推、直播、電商這些核心服務(wù)。接下來是平臺層，這里只列了一些和數(shù)據(jù)強(qiáng)相關(guān)的，如機(jī)器學(xué)習(xí)平臺、AI訓(xùn)練平臺，模型發(fā)布平臺、推薦索引平臺、數(shù)據(jù)平臺等。最底層是公有云的存儲產(chǎn)品，這里只列了主要依賴的對象存儲，其實包括異構(gòu)的HDFS等產(chǎn)品都可以適用于這個通用的解決方案。在平臺層和存儲層之間，基于Alluxio構(gòu)建了一層多云統(tǒng)一數(shù)據(jù)加速層并研發(fā)了對應(yīng)的智能緩存服務(wù)。為什么選擇Alluxio作為多云統(tǒng)一的加速層首先基于面臨的問題，抽象出了選型的重點目標(biāo)：需要能夠復(fù)用業(yè)務(wù)歷史上已經(jīng)存儲的數(shù)據(jù)，不需要再次搬遷或者導(dǎo)入到其他高速存儲或文件系統(tǒng)就能享受到數(shù)據(jù)的加速。以典型的搜廣推和訓(xùn)練業(yè)務(wù)為例，這些業(yè)務(wù)的存儲量大概是數(shù)百PB級別，搬遷一遍才能使用不太可行。需要支持S3和POSIX協(xié)議，以便于與其他平臺無縫對接。如機(jī)器學(xué)習(xí)訓(xùn)練通常是S3協(xié)議，AI訓(xùn)練通常是POSIX協(xié)議，如果加速層能夠兼容這類協(xié)議，業(yè)務(wù)方就不需要改代碼，遷移成本也會低很多。需要實現(xiàn)跨云專線傳輸?shù)膸捒刂坪凸?jié)省。因為跨云本身業(yè)務(wù)是多活、多云的。但多云之間本身就有實時的數(shù)據(jù)同步，如果把帶寬打爆，那穩(wěn)定性問題就會立馬出來，所以一定要能夠控制住帶寬。能夠支撐百億級別的AI訓(xùn)練，小紅書有單個訓(xùn)練任務(wù)就有60億+元信息的場景需要支持。能夠支持常見的云存儲產(chǎn)品，以主流云廠商的對象存儲為主。經(jīng)過調(diào)研發(fā)現(xiàn)，業(yè)界目前唯一能同時滿足上述訴求的產(chǎn)品，就是Alluxio。Alluxio主要特性特性一：格式透明，不侵入業(yè)務(wù)數(shù)據(jù)存儲格式。數(shù)據(jù)湖里的數(shù)據(jù)量非常大，是不可能再導(dǎo)入進(jìn)來重復(fù)存儲的，有了Alluxio，只需要在原來存儲上加一層Alluxio，就可以直接去訪問那些數(shù)據(jù)了，讓業(yè)務(wù)直接享受到加速收益，這是非常關(guān)鍵的特性。特性二：協(xié)議兼容。Alluxio支持非常豐富的S3\POSIX\HDFS\JavaFileAPI\RESTAPI等協(xié)議，幫助Alluxio上層AI/ML訓(xùn)練引擎（如Pytorch、Ray、TensorFlow）和查詢引擎（如Presto、Spark、Trino）與底層存儲進(jìn)行無縫對接。特性三：多云統(tǒng)一視圖。不管底層存儲是HDFS、Ceph還是各云廠商的對象存儲，對于用戶，只要通過Alluxio，任何API都可以去訪問不同存儲位置的數(shù)據(jù)，從而可以實現(xiàn)多云統(tǒng)一視圖的效果。特性四：數(shù)據(jù)僅需通過專線傳輸一次，后續(xù)可通過緩存就近讀取，不需要再次跨專線，這個關(guān)鍵特性對小紅書專線的保護(hù)意義重大。通過合理地利用這些特性，就能夠解決上述提到的小紅書多云架構(gòu)的業(yè)務(wù)痛點。三、小紅書實踐案例機(jī)器學(xué)習(xí)訓(xùn)練場景機(jī)器學(xué)習(xí)訓(xùn)練原架構(gòu)機(jī)器學(xué)習(xí)訓(xùn)練最初的架構(gòu)是直接從對象存儲拉取數(shù)據(jù)（主要是訓(xùn)練樣本），拉取完這些訓(xùn)練樣本就開始在TensorFlow框架做訓(xùn)練。主要問題：訓(xùn)練速度不太符合預(yù)期，導(dǎo)致一些任務(wù)訓(xùn)練很慢，以及其他人排隊調(diào)度不上，體驗很差。海量的集群資源利用率太低對成本也帶來了很大挑戰(zhàn)。主要原因是一些熱點的數(shù)據(jù)集（如小紅書的筆記樣本），是公共的樣本，總量非常大（大概每天幾百TB）。這些公共數(shù)據(jù)集會被很多任務(wù)使用，在小紅書的場景下大概是20倍的扇出，如果是幾百TB的數(shù)據(jù)會有20倍的扇出，這個總傳輸數(shù)據(jù)量是非常大的，整體流量達(dá)到了Tbps級，觸達(dá)到了對象存儲桶的帶寬瓶頸。如果數(shù)據(jù)集大、扇出也大的話，一定會有額外的帶寬需要，云廠商的解決方案通常是要么增加存儲量，要么對增加帶寬進(jìn)行額外收費，兩種方式都不太友好。因為業(yè)務(wù)會直連對象存儲，而對象存儲本身是高吞吐的產(chǎn)品，并不會過分強(qiáng)調(diào)單線程有多快，這就需要業(yè)務(wù)不斷的去調(diào)優(yōu)，才能達(dá)到適合的吞吐?；谝陨先齻€問題，機(jī)器學(xué)習(xí)訓(xùn)練架構(gòu)經(jīng)過了升級改造，最新架構(gòu)如下圖所示。新架構(gòu)對于普通數(shù)據(jù)還是直接會去對象存儲讀取，對于筆記這種熱點的訓(xùn)練數(shù)據(jù)集，會把它緩存到Alluxio，當(dāng)業(yè)務(wù)來Alluxio訪問的時候，如果第一次數(shù)據(jù)不存在，就會去對象存儲透傳，然后把數(shù)據(jù)返回給訓(xùn)練框架，如果數(shù)據(jù)已經(jīng)在Alluxio上，那就可以命中緩存，直接由Alluxio返回數(shù)據(jù)。雖然第一遍讀完數(shù)據(jù)，Alluxio一定會去緩存數(shù)據(jù)，但這還很難解決業(yè)務(wù)的問題。第一種情況是Alluxio緩存是用到本地磁盤把數(shù)據(jù)緩存下來，但磁盤容量是有限的，如果總訓(xùn)練的樣本空間遠(yuǎn)大于磁盤緩存容量，就會不斷的淘汰緩存數(shù)據(jù)，可能第一個任務(wù)緩存了，第二個任務(wù)就沒有空間緩存了，或是會把別的緩存數(shù)據(jù)給擠掉。第二種情況是有些訓(xùn)練任務(wù)可能因為計算資源或者故障的原因帶來嚴(yán)重的延遲，之后這個業(yè)務(wù)一旦跑上來，可能需要訓(xùn)練30天之前的數(shù)據(jù)，或者直接回溯很老的數(shù)據(jù)去訓(xùn)練，那這30天的數(shù)據(jù)很容易就把所有的緩存空間全部用掉。以上兩種場景通過研發(fā)了智能緩存管理服務(wù)來解決。智能存儲管理服務(wù)智能緩存管理服務(wù)主要是基于任務(wù)的歷史運行規(guī)律，可以基于任務(wù)的歷史運行規(guī)律，更加智能的把數(shù)據(jù)提前做預(yù)加載，這樣通常第一次訓(xùn)練就能夠命中緩存，而且可以更及時地淘汰掉不使用的緩存。不僅如此，還對緩存淘汰場景進(jìn)行了評估，比如發(fā)現(xiàn)最近1-2天的筆記訓(xùn)練樣本是非常重要的，就會把這些數(shù)據(jù)用Pin機(jī)制固定在磁盤里，就不會被自動淘汰，從而實現(xiàn)重要數(shù)據(jù)的淘汰完全由智能緩存管理服務(wù)去控制。通過這兩個措施的共同保障，緩存命中率能跑到90%以上，很好節(jié)省了對象存儲的帶寬。同時，Alluxio也提供了load任務(wù)的管理和執(zhí)行能力，但目前還不完全符合小紅書的需求。具體的業(yè)務(wù)中需要監(jiān)控到任務(wù)粒度的load進(jìn)展，比如有10個任務(wù)（有幾個是重要的），在按小時提前預(yù)加載數(shù)據(jù)，結(jié)果集群故障了，但故障時間也較長，第二天馬上又要用新的樣本去訓(xùn)練數(shù)據(jù)，那該如何止損呢？措施是通過實現(xiàn)load進(jìn)度的可觀測機(jī)制，能夠觀察到每個任務(wù)當(dāng)前正在加載第幾小時的數(shù)據(jù)。當(dāng)在不及預(yù)期的時候，會馬上發(fā)出告警并做止損。當(dāng)止損的時候，會基于任務(wù)的優(yōu)先級去判斷優(yōu)先補(bǔ)償哪些任務(wù)，并提供一鍵補(bǔ)償?shù)哪芰Γ纯催@些任務(wù)已經(jīng)錯過了哪些小時的緩存數(shù)據(jù)，然后全部加載進(jìn)來，從而規(guī)避帶寬全部透傳到對象存儲所造成的的穩(wěn)定性風(fēng)險。第三是為穩(wěn)定性實現(xiàn)了一個探針服務(wù)，它可以完全模擬業(yè)務(wù)的讀寫行為，是一個端到端的探活服務(wù)。探活實踐下來非常好用，無論是代碼本身有問題，還是機(jī)器磁盤、網(wǎng)絡(luò)等出現(xiàn)問題，都能反映在探針里，方便快速介入。目前能達(dá)到3分鐘發(fā)現(xiàn)和1分鐘止損的效率。經(jīng)過將近一年時間的運行，故障告警的準(zhǔn)確率幾乎達(dá)到了100%。訓(xùn)練速度提升效果上圖展示的是一個非常典型的筆記訓(xùn)練大任務(wù)，其他業(yè)務(wù)訓(xùn)練效果都差不多。在遷移之前，訓(xùn)練時長達(dá)到9小時36分，單一任務(wù)就需要消耗2000核，非常消耗資源，而平均CPU利用率只有30%，只是到了最后面會有一些上升，這是因為這時候大部分任務(wù)已經(jīng)訓(xùn)練完成，對象存儲的帶寬有些緩解了。在遷移到Alluxio之后，訓(xùn)練時長直接縮減到了542CPU維持在75%，并且再也沒有被限流影響到。整體訓(xùn)練速度在時長上優(yōu)化了41%，雖然很多業(yè)務(wù)比這個效果更好，但這個例子是一個非常典型的大任務(wù)，更具有代表性。推薦召回索引下載場景索引對于推薦非常核心，穩(wěn)定性是非常重要的問題。上圖是未引入Alluxio之前的架構(gòu)圖。最上面是搜推平臺，會對搜推的索引做一些生成或者更新，更新完了之后會存儲到索引存儲（一般是就近機(jī)房的對象存儲）。存儲索引之后，搜推平臺會通知其他服務(wù)下發(fā)索引，下發(fā)索引的服務(wù)會把數(shù)據(jù)通過專線從原來索引存儲的對象存儲桶傳輸?shù)搅硗庖粋€多云機(jī)房的本地磁盤，也就是索引服務(wù)的本地磁盤上。以圖中的架構(gòu)為例，共有兩個跨區(qū)域的機(jī)房，當(dāng)把索引數(shù)據(jù)下載到本地盤后索引服務(wù)就能夠把數(shù)據(jù)加載到內(nèi)存中，對外提供一些索引的服務(wù)。這樣的架構(gòu)帶來的問題很大：以推薦場景下的索引讀取速度來說，通常發(fā)布一個機(jī)房的服務(wù)需要3-4個小時，因為是多活設(shè)計，發(fā)布完四個機(jī)房整整需要一整天，這是非常令人頭疼的問題。同樣，當(dāng)單機(jī)房發(fā)生故障，止損時長同樣也需要3-4小時，如果你要把很老的一個索引回滾，就需要重新走這個流程，四個機(jī)房就需要一天時間。磁盤存儲成本非常高。因為索引服務(wù)本身是一個主從架構(gòu)，典型的場景是一主兩從。同一個索引會有三副本的云盤存儲，而云盤本身就是三副本冗余存儲，那整體下來就是九副本，而云盤的單價通常比對象存儲貴得多，這樣計算下來整體成本是非常高的。下圖是引入Alluxio之后的架構(gòu)。從搜推平臺生成索引之后，會把這個事件發(fā)送到消息隊列，智能緩存管理服務(wù)訂閱了該消息隊列，收到相應(yīng)的加載緩存事件后，就會去加載索引?，F(xiàn)在的加載流程和之前就不一樣了，之前是通過專線傳輸過來存到本地磁盤，現(xiàn)在是加載到Alluxio集群里，然后再告知索引服務(wù)，去Alluxio集群把數(shù)據(jù)再加載到索引服務(wù)的內(nèi)存，從而對外進(jìn)行服務(wù)。這里的關(guān)鍵點是把本地磁盤變成了Alluxio集群，那為什么采用Alluxio之后解決了以上問題呢？首先，把磁盤上浮到了一個遠(yuǎn)程的集群，實現(xiàn)了索引的存算分離，把原來來自云盤的存儲瓶頸，轉(zhuǎn)換成了宿主機(jī)的網(wǎng)絡(luò)瓶頸。云盤的帶寬通常在云廠商相對還比較好350MB/s32Gbps以上，合4GB/s，這兩者的差距超過10倍，因此下載索引數(shù)據(jù)這個過程就能提速10倍以上。第二，Alluxio并不會把文件存儲在固定的一臺機(jī)器上（和本地盤不一樣），一個文件會被切成block存儲。比如一個集群有100臺機(jī)器，一個文件能切100個block，那每個機(jī)器只會存1個block，這時候整個集群的帶寬就是這個文件的吞吐極限。所以，對于一些熱點的索引文件或者其他場景都是非常友好的。但這樣直接用Alluxio還是會遇到問題，所以還加入了一些增強(qiáng)的功能，這也是為什么引入了智能緩存管理服務(wù)的原因。比如load太快會把專線打爆，需要Alluxio支持限速，以保障核心服務(wù)的穩(wěn)定性?，F(xiàn)在已經(jīng)支持了限速，當(dāng)限制20-30GbpsUFS這套架構(gòu)主要有三點收益：Alluxio將云盤帶寬瓶頸變成了宿主機(jī)的網(wǎng)卡瓶頸，索引拉取速度帶來10倍以上的提升。如果宿主機(jī)的核數(shù)越大，附帶的帶寬也會更大，帶來的提升倍數(shù)還會增大。索引下發(fā)的整體業(yè)務(wù)體感（含業(yè)務(wù)邏輯）3載，還有一些業(yè)務(wù)邏輯在這個索引下發(fā)的過程里。高性能云盤替換成對象存儲，節(jié)省80%成本。此優(yōu)化是通過Alluxio把云盤全部省掉，變成了Alluxio的集群本地盤，而這些本地盤可以選擇一些更廉價的介質(zhì)，比如單副本的HDD盤。對于小紅書的推薦場景，由于索引數(shù)據(jù)量很大，云盤成本的節(jié)省量也是非?？捎^的。大模型下載場景小紅書也有大模型的場景，大模型下載的解決方案和推薦索引幾乎一模一樣，面臨的同樣是云盤帶寬限制和冗余存儲高成本以及跨云同步穩(wěn)定性問題。3-4年前大家通常只做單機(jī)訓(xùn)練，現(xiàn)在已經(jīng)演進(jìn)到了幾乎都是分布式訓(xùn)練的狀態(tài)。那一定會需要通過遠(yuǎn)端的存儲集群來解決本地數(shù)據(jù)存放不下的問題，這塊架構(gòu)與收益跟推薦索引一樣，就不贅述了。AI訓(xùn)練場景面對的挑戰(zhàn)：有60億+級別的小文件訓(xùn)練場景，如果把這些元信息存儲在一個集中式的元信息服務(wù)里，成本非常高，本身技術(shù)挑戰(zhàn)也很大。對象存儲作為很多存儲的底座，最終數(shù)據(jù)會穿透到對象存儲，會面臨著存儲帶寬，或是IOPS比較有限的情況（尤其是小文件），云廠商通常一個桶提供幾萬IOPS，每PB存儲量的帶寬配額也很低，尤其在小文件場景下，這點IOPSGPU利用率就會很低。解決方法：引入Alluxio緩存訓(xùn)練需要的數(shù)據(jù)。Alluxio3.0版本提供了一個可擴(kuò)展的元信息能力，讓擴(kuò)展性大幅提升。此外，Alluxio本身支持POSIX協(xié)議，之前如果訓(xùn)練是在本地盤上，現(xiàn)在會把Alluxio集群mount到GPU機(jī)器上，由于Alluxio是透明嵌入，讓業(yè)務(wù)方看其實還是訪問的本地盤，背后其實是Alluxio集群。然后，通過Alluxio集群去對象存儲里取數(shù)據(jù)，基于Alluxio的緩存機(jī)制，可以有效的避免數(shù)據(jù)穿透到對象存儲。因為通常AI訓(xùn)練是多輪的epoch，Alluxio只會讓第一輪epoch走對象存儲，后面都可以命中這些緩存。甚至理想情況下，可以錯峰把這些數(shù)據(jù)預(yù)加載到Alluxio，這樣真正訓(xùn)練的時候，完全不需要走對象存儲。因為GPU機(jī)器上很多磁盤是閑置的，為了避免額外的支出成本，會把Alluxio和GPU機(jī)器混合部署，讓這些磁盤都可以被充分使用，也不會有額外的成本支出。Alluxio相對于別的產(chǎn)品打造的非常成熟的能力是ClusterCache。在同樣的總磁盤容量，ClusterCache相對于LocalCache的命中率可以做到更高，比如有兩個訓(xùn)練任務(wù)讀同樣的文件，如果落在兩個不同的機(jī)器上，對于LocalCache會把數(shù)據(jù)讀兩遍，而對于ClusterCache只需要讀一遍，第二次可以通過網(wǎng)絡(luò)來傳輸，而GPU機(jī)器之間的網(wǎng)絡(luò)帶寬也常非常高，通常有百Gbps，同時Alluxio也支持LocalCache，組合起來使用更佳。Alluxio為什么能加速AI訓(xùn)練可以在業(yè)務(wù)訓(xùn)練之前提前把數(shù)據(jù)加載到緩存中，突破IO限制，相比穿透對象存儲讀取性能更高；讀取數(shù)據(jù)時通過智能判定是隨機(jī)讀還是順序讀。如果是順序讀可以提前預(yù)讀數(shù)據(jù)，從而達(dá)到更高的讀吞吐；如果是隨機(jī)讀，可以精準(zhǔn)地控制要讀哪個位置，避免讀的放大；無集中式的元信息服務(wù)，全量元信息在對象存儲，只有熱數(shù)據(jù)及其元數(shù)據(jù)在緩存中，對海量小文件友好，相比于集中式元信息服務(wù)，成本極低；可異步寫checkpoint到本地磁盤，再異步上傳至對象存儲，通過有效縮短負(fù)載時長，從而大幅縮短GPUGPU技術(shù)問題及解法在與Alluxio的合作過程中，小紅書也一起參與解決了非常多的技術(shù)問題，這里有幾個比較典型的場景：讀放大問題解決：主要表現(xiàn)在S3協(xié)議里會有一些range讀，以及Alluxioclient、fuse或者其他一些觸發(fā)隨機(jī)讀的場景。放大主要存在兩個環(huán)節(jié)：一個是S3proxy到worker之間；另一個是worker去對象存儲（UFS）取數(shù)據(jù)的時候，都會有一個讀放大的情況。比如一個數(shù)據(jù)是熱讀（指數(shù)據(jù)緩存已經(jīng)在worker里），原來的實現(xiàn)里prox會直接去worker取，雖然S3協(xié)議里的range參數(shù)已經(jīng)指明了截止位，但并沒有透傳過去。因為這里可能認(rèn)為需要做一些預(yù)加載來加速后續(xù)的讀取，實際上業(yè)務(wù)如果指定了一個endOffset，后面的數(shù)據(jù)則是沒必要讀取的。雖然預(yù)讀能幫助吞吐的提升，但在這種情況下后面的數(shù)據(jù)會被完全廢掉，反而會轉(zhuǎn)化成帶寬的放大?！鉀Q辦法：worker傳輸數(shù)據(jù)當(dāng)傳輸?shù)絜ndOffset，后面的字節(jié)不需要傳輸過來，這樣是更經(jīng)濟(jì)，更高效的辦法。第二個放大的問題是因為Alluxio初衷在讀數(shù)據(jù)時，會把需讀取數(shù)據(jù)范圍涉及的block全部緩存下來，好處是之后再讀這些數(shù)據(jù)就不需要走帶寬了。比如在一個隨機(jī)讀的場景，在一個block里只需要1-2M數(shù)據(jù)，但Alluxio會緩存整個block的大小（默認(rèn)為64M）?！鉀Q辦法：如果是非緩存block的數(shù)據(jù)請求，因為協(xié)議中本身傳了endOffset，需要將其作為訪問對象存儲的參數(shù)，只需要讀取必要的數(shù)據(jù)即可。endOffset之后的數(shù)據(jù)本身也會被丟棄掉，讀出來就會變成worker機(jī)器上網(wǎng)絡(luò)帶寬的開銷，從而影響成本和效果。第三個是冷讀NoCache的場景。NoCache是指經(jīng)過Alluxio讀取但不緩存對應(yīng)的數(shù)據(jù)，通常發(fā)生在對于延遲太久的任務(wù)或者讀取大量冷數(shù)據(jù)的任務(wù)，不需要將其緩存下來，否則會將本身的熱數(shù)據(jù)給擠掉?！鉀Q辦法：以前的實現(xiàn)里，通過S3proxy直接NoCache讀，它會通過worker去UFS取數(shù)據(jù)。修改和打磨之后，Proxy會繞過worker直接去UFS取數(shù)據(jù)。這樣可以節(jié)省worker傳輸?shù)絧roxy的帶寬，可以省一倍的帶寬，對應(yīng)到機(jī)器成本上就是省一倍的機(jī)器成本。專線帶寬限流：UFS這一層增加了流控能力，保護(hù)了專線帶寬。在多云環(huán)境，業(yè)務(wù)通常會就近讀取，一定不會跨專線訪問Alluxio集群，所有跨云專線的流量只有從worker到UFS這一層，所以只需要在訪問UFS的地方加限流就可以控制住專線。而客戶端和S3Proxy的交互，以及S3Proxy與worker的交互都是同機(jī)房的一個流量，理論上也需要保護(hù)，但不影響專線。讀寫性能優(yōu)化：在讀性能優(yōu)化方面，通常是識別了讀的特征之后做預(yù)讀，通過預(yù)讀能夠明顯提升讀的性能，尤其是在冷讀數(shù)據(jù)的情況下。在Checkpoint寫方面，一定不能阻塞訓(xùn)練，所以支持了WriteBack能力，WriteBack是指先異步寫到磁盤甚至內(nèi)存中，然后就可以開始后續(xù)訓(xùn)練，通過后臺線程異步上傳。同樣也有一些線程模型的優(yōu)化，整體對讀寫的性能也有非常大的提升。四、未來規(guī)劃未來小紅書會把數(shù)據(jù)加速層做成什么樣子以及還有哪些待解決的問題呢？打造統(tǒng)一的多云數(shù)據(jù)存儲產(chǎn)品因為小紅書的數(shù)據(jù)存儲在多云里，業(yè)務(wù)需要關(guān)心數(shù)據(jù)到底在哪個云上，是不是會跨專線，到底要用哪個SDK去讀取，報錯了都是什么原因，該去找誰，業(yè)務(wù)感知的東西非常多。期望打造一個統(tǒng)一的多云數(shù)據(jù)存儲產(chǎn)品，讓業(yè)務(wù)方再也不需要在代碼中關(guān)注數(shù)據(jù)到底在哪里，專線能否控制好等問題。AI訓(xùn)練：多地域GPU利用率提升在AI訓(xùn)練場景，因為GPU眾所周知的供應(yīng)問題，從各個廠商購買或租賃的GPU是分散在非常多的地域。這會造成一個非常嚴(yán)重的問題，有些地方有GPU，但沒數(shù)據(jù)，有些地方有數(shù)據(jù)，但沒有GPU，GPU的分配率不高。后面會探索如何基于Alluxio來提升GPU利用率，解決數(shù)據(jù)和GPU在不同地域如何充分利用GPU的問題。大數(shù)據(jù)查詢加速大數(shù)據(jù)查詢加速在Alluxio社區(qū)里的案例非常多，但小紅書需要探索出一個如何在極低成本的情況下去實現(xiàn)大數(shù)據(jù)查詢的加速。同樣的查詢效率提升，需要增加的Alluxio的成本要小于直接擴(kuò)容查詢引擎節(jié)點的成本才行。低效節(jié)點資源利用率提升現(xiàn)在Alluxio集群規(guī)模比較大，與此同時，CPU利用率是非常低的，每天平均大概3%的利用率，但磁盤容量和帶寬全是占滿的。如何將這些CPU去充分使用是一個非常大的問題，而公司出于成本考慮，也會要求這些低效節(jié)點能夠被充分利用，從而發(fā)揮更多價值。知乎|AlluxioAI助力知乎千卡模型訓(xùn)練一、混合云架構(gòu)，帶來便捷與挑戰(zhàn)知乎目前是典型的混合云架構(gòu)，數(shù)據(jù)和服務(wù)都分布在不同的機(jī)房：離線機(jī)房：專為滿足大數(shù)據(jù)相關(guān)業(yè)務(wù)方需求而設(shè)計的離線計算服務(wù)中心。其主要職能是部署離線調(diào)度、離線存儲以及調(diào)度平臺等服務(wù)。這些服務(wù)的目標(biāo)是提供高效的離線數(shù)據(jù)處理和計算能力。在離線機(jī)房中，大數(shù)據(jù)業(yè)務(wù)方可以安心進(jìn)行批量數(shù)據(jù)處理和計算任務(wù)，從而滿足他們對數(shù)據(jù)處理、存儲和調(diào)度的要求。在線機(jī)房：此機(jī)房專為知乎主站提供直接面向用戶的服務(wù)而設(shè)計。其中包括評論、回答、搜索、推薦等核心服務(wù)。在線機(jī)房的重點在于實時性和響應(yīng)速度，以確保用戶能夠在最短的時間內(nèi)獲得穩(wěn)定、高效的服務(wù)體驗。知乎主站作為一個知識社區(qū)，其在線機(jī)房是為了保障用戶對知識和信息的交流與分享能夠得到優(yōu)質(zhì)、連續(xù)的支持。GPU機(jī)房：此機(jī)房專門用于部署機(jī)器學(xué)習(xí)平臺，主要服務(wù)于算法用戶。其主要特點是提供強(qiáng)大的GPU資源管理、模型訓(xùn)練、數(shù)據(jù)集導(dǎo)入導(dǎo)出等一站式解決方案。GPU機(jī)房的核心任務(wù)是為算法用戶提供高性能計算資源，以滿足機(jī)器學(xué)習(xí)模型訓(xùn)練和推理的要求。這樣的設(shè)計能夠使算法用戶更專注于模型的研發(fā)與優(yōu)化，而不必?fù)?dān)心計算資源的供給。架構(gòu)圖如下所示：混合云架構(gòu)給知乎帶來了成本，容災(zāi)等各方面的優(yōu)勢，但是也對存儲提出了新的挑戰(zhàn)。相比于數(shù)據(jù)都存在在單一機(jī)房，在混合云的架構(gòu)下，算法平臺在調(diào)度訓(xùn)練任務(wù)時，還需要額外考慮訪問存儲時，專線帶來的網(wǎng)絡(luò)延遲以及網(wǎng)絡(luò)吞吐的限制。二、知乎的探索歷程探索：知乎自研UnionStore聯(lián)合存儲為了解決模型訓(xùn)練及模型分發(fā)場景跨云讀取數(shù)據(jù)的痛點，知乎在早期自研了一個緩存系統(tǒng)—UnionStore。顧名思義，UnionStore是聯(lián)合存儲的意思，它聯(lián)合了對象存儲與HDFS，利用對象存儲來對外提供本機(jī)房緩存。它支持對象存儲協(xié)議，這AWSS3SDKUnionStore的緩存工作流程可描述如下：用戶在向UnionStore請求讀取文件時，會先檢查對象存儲上是否已經(jīng)有該文件了；如果對象存儲已經(jīng)存在該文件，則直接從對象存儲讀取文件返回給用戶；如果對象存儲不存在該文件，UnionStore會先將離線HDFS上的文件上傳到在線機(jī)房的對象存儲上，再從對象存儲上讀取文件，返回給用戶，緩存期間用戶的請求是被卡住的。這里相當(dāng)于是利用對象存儲做了一層跨機(jī)房緩存。挑戰(zhàn)：面對大語言模型訓(xùn)練，UnionStore捉襟見肘UnionStore在知乎運行了兩年，期間沒有出現(xiàn)任何問題，但是隨著2023年知乎開始布局大語言模型，UnionStore在面對大語言模型訓(xùn)練時，有些捉襟見肘：沒有元數(shù)據(jù)緩存，元數(shù)據(jù)強(qiáng)依賴HDFS與對象存儲，特別是對象存儲，元數(shù)據(jù)訪問和首字節(jié)延遲在幾十毫秒，而大語言模型在進(jìn)行訓(xùn)練，讀取語料時，往往都是隨機(jī)讀取，對吞吐要求低，但是對時延敏感，而UnionStore只能從對象存儲隨機(jī)讀取數(shù)據(jù)，延遲極高；訓(xùn)練任務(wù)在啟動時需要讀取模型的checkpoint，大語言模型的checkpoint動輒上百GB，而對象存儲單線程的讀取性能只有10-100MB/secUnionStore也做了一些加速手段，但是也只能加速到200-300MB/sec的速度，遠(yuǎn)遠(yuǎn)不能滿足大模型的checkpoint讀取需求；對象存儲能力有上限，在模型分發(fā)時，往往單文件會有上百，甚至上千并發(fā)同時讀取，對象存儲容易面臨性能瓶頸和帶寬限制；無法做到邊緩存邊返回文件，導(dǎo)致首次讀取文件的時間偏長，這也會影響大模型checkpoint的讀取速度。以上痛點使得知乎面臨兩個選擇：一是繼續(xù)迭代UnionStore，讓UnionStore具備高性能緩存能力，比如支持本地SSD以及內(nèi)存緩存；二是尋找合適的開源解決方案，完美替代UnionStore的使用場景?；谌肆Y源的寶貴，選擇了其二。探索：社區(qū)版Alluxio調(diào)研上線從UnionStore的使用場景來看，知乎需要的AI存儲必須滿足以下幾個需求：協(xié)議兼容：必須要具有對象存儲協(xié)議和POSIX協(xié)議，目前知乎的模型分發(fā)場景使用的是UnionStore的對象存儲協(xié)議，模型訓(xùn)練場景使用的是UnionStore+S3FS-FUSE來提供POSIX協(xié)議。性能優(yōu)秀：選擇替換UnionStore的最重要的原因就是對象存儲的性能和延遲遠(yuǎn)遠(yuǎn)不能滿足算法業(yè)務(wù)的需求，所以知乎需要的AI存儲必須要有足夠優(yōu)秀的性能；透明緩存：因為目前知乎的數(shù)據(jù)都是存放在HDFS上，不希望用戶在接入新存儲的時候，需要對訪問數(shù)據(jù)的路徑做比較大的修改，最好是路徑能夠與HDFS一一對應(yīng)，有透明緩存的能力，這樣能夠最大程度上減少業(yè)務(wù)方的改造工作。基于以上需求，調(diào)研了市面上大多數(shù)的存儲，發(fā)現(xiàn)只有Alluxio能夠滿足需求，嚴(yán)格意義上來說，Alluxio并不是一個標(biāo)準(zhǔn)的存儲，它是一個多功能低侵入的高性能緩存，它的一些能力能夠很好地滿足需求：透明緩存：相較于其他文件系統(tǒng)，Alluxio可僅作為緩存使用，用于編排數(shù)據(jù)，業(yè)務(wù)方無需將模型文件寫入到其他的文件系統(tǒng)，只需要維持現(xiàn)狀，寫入HDFS元數(shù)據(jù)與數(shù)據(jù)緩存：Alluxio支持自定義緩存元數(shù)據(jù)與數(shù)據(jù)，這樣在讀取已緩存文件時，可完全不受HDFS影響；目前知乎UnionStore的QPS大約在20K-30KNameNode的壓力，反哺離線場景；UFSHDFSUFS，比如對象存儲，在未來可能對數(shù)據(jù)湖場景也可以提供強(qiáng)有力的支撐；即席查詢加速：知乎Adhoc引擎采用的是Spark與Presto，Alluxio對這兩個引擎都有較好的支持；訪問接口豐富：Alluxio提供的S3Proxy組件完全兼容S3協(xié)議，模型上線場景從UnionStore遷移至Alluxio付出的成本幾乎可忽略不計；另外Alluxio提供的AlluxioFuse也具備本地元數(shù)據(jù)緩存與數(shù)據(jù)緩存，比業(yè)務(wù)之前使用的S3FS-FUSE此外知乎對Alluxio進(jìn)行了一些性能上的測試，AlluxioFuse的單線程順序讀取速度能夠達(dá)到500+MB/sec，AlluxioS3Proxy的單線程順序讀取性能能夠達(dá)到1GB/sec上線的過程比較順利，幾乎是無感遷移，在短短三個月內(nèi)就將UnionStore完全替換成了Alluxio，并且拿到了不錯的收益：模型分發(fā)的速度得到了2-3倍的提升；訓(xùn)練任務(wù)等待數(shù)據(jù)的延遲幾乎消失，訓(xùn)練時長降低至原來的40%。挑戰(zhàn)：任務(wù)規(guī)模擴(kuò)大，社區(qū)版難以為繼隨著訓(xùn)練任務(wù)的規(guī)模不斷擴(kuò)大，也發(fā)現(xiàn)了Alluxio社區(qū)版中存在的各種問題?？偨Y(jié)起來可以描述如下：Fuse穩(wěn)定性問題：社區(qū)版AlluxioFuse會經(jīng)常出現(xiàn)OOM相關(guān)的故障，經(jīng)常導(dǎo)致訓(xùn)練任務(wù)失敗重啟；Master元數(shù)據(jù)性能瓶頸：社區(qū)版的AlluxioMaster是一個單點的服務(wù)，在緩存文件增加的情況下，會遇到性能瓶頸，并且無法擴(kuò)展；寫場景性能不足：社區(qū)版的Alluxio同步寫入UFS時，性能較差，不能滿足業(yè)務(wù)做checkpoint的需求；高昂的運維成本：社區(qū)版的Alluxio部署，需要自己打鏡像，以及寫k8s的yaml文件進(jìn)行部署，沒有operator相關(guān)的運維工具。以上問題在社區(qū)版需要投入極大的人力和精力來修復(fù)和維護(hù)，并且需要一個比較長的周期，而此時知乎的算法業(yè)務(wù)發(fā)展的勢頭很猛，根本等不及。正好聽說Alluxio也在企業(yè)版重構(gòu)了他們的架構(gòu)，在提升性能的同時，也修復(fù)了很多社區(qū)版已存在的問題。于是正式開啟的Alluxio企業(yè)版的調(diào)研與試用。探索：Alluxio企業(yè)版攻克四大問題AlluxioFuse穩(wěn)定性問題首先是AlluxioFuse穩(wěn)定性的問題，F(xiàn)use在長時間運行后，很容易出現(xiàn)OOM相關(guān)的故障，如下圖所示：這是知乎真實生產(chǎn)環(huán)境中AlluxioFuse的重啟監(jiān)控，可以看到Fuse的重啟十分頻繁，幾乎每隔幾小時就有一次。一旦Fuse重啟，訓(xùn)練任務(wù)就會因讀取數(shù)據(jù)錯誤而失敗，需要從上一次checkpoint開始訓(xùn)練，這就導(dǎo)致了無效訓(xùn)練，會浪費相當(dāng)GPU在社區(qū)版中，定位到問題來自AlluxioFuse的native內(nèi)存泄露。社區(qū)版的Alluxio使用GRPC傳輸數(shù)據(jù)，在遇到問題時，AlluxioFuse對于GRPC的處理不太優(yōu)雅，導(dǎo)致了native內(nèi)存泄露。企業(yè)版數(shù)據(jù)傳輸用Netty全部重寫了，不僅避免了使用GRPC，也具有更好性能，相當(dāng)于曲線救國了。下圖是使用企業(yè)版時，AlluxioFuse的重啟監(jiān)控：可以看到企業(yè)版的AlluxioFuse幾乎沒有出現(xiàn)重啟的現(xiàn)象。此外，由于AlluxioWorker在知乎是和和GPU節(jié)點綁定部署的，而GPU節(jié)點的機(jī)器故障率比較高，也造成了AlluxioWorker的故障率偏高。在這種情況下，企業(yè)版支持在某臺AlluxioWorker出現(xiàn)問題時，重試到其他的Worker讀取數(shù)據(jù)，或者是直接從UFS讀取數(shù)據(jù)，這也提高了AlluxioFuse的穩(wěn)定性。Alluxio企業(yè)版自上線以來，一共完成了300+訓(xùn)練任務(wù)，包括知乎最重要的千卡大模型訓(xùn)練任務(wù)，訓(xùn)練期間沒有因為Fuse的穩(wěn)定性導(dǎo)致訓(xùn)練任務(wù)重啟，相比于社區(qū)版，企業(yè)版極大減少了無效訓(xùn)練的出現(xiàn)。AlluxioMaster元數(shù)據(jù)問題AlluxioMaster是Alluxio社區(qū)版中一個比較明顯的瓶頸：雖然AlluxioMaster支持HA，但是對外提供服務(wù)的Master只有一個，有單點性能問題，Master在3億元數(shù)據(jù)下可以相對穩(wěn)定運行，但是超過3億就需要進(jìn)行調(diào)優(yōu)，需要有豐富的經(jīng)驗；隨著元數(shù)據(jù)增多，占用的內(nèi)存也會變高，而內(nèi)存在單節(jié)點上總是有上限的，不可能無限擴(kuò)展；在metadatasync比較頻繁的時候，較小的元數(shù)據(jù)量也會出現(xiàn)比較嚴(yán)重的鎖競爭問題，導(dǎo)致Master卡住。在2023年，因為Master的性能問題，出現(xiàn)過幾次比較嚴(yán)重的故障，多虧及時搶修（手動切主+重啟），才沒有造成比較大的損失。Alluxio的企業(yè)版對整個Alluxio集群架構(gòu)進(jìn)行了重構(gòu)，不再使用Master管理元數(shù)據(jù)，而是將元數(shù)據(jù)用一致性Hash打散到每一臺Worker，理論上集群越大，可管理的元數(shù)據(jù)越多，元數(shù)據(jù)的規(guī)模隨著Worker的增長可以達(dá)到近乎無限的擴(kuò)展。由于元數(shù)據(jù)分散到不同的Worker，元數(shù)據(jù)請求的QPS也能隨著Worker數(shù)量的增加，得到線性增長。這里需要注意的是，Alluxio企業(yè)版引入了一個輕量的服務(wù)發(fā)現(xiàn)組件，目前是基于ETCD實現(xiàn)的，用于存放Worker列表。寫場景需求寫場景的需求主要體現(xiàn)在模型訓(xùn)練時做checkpoint。在訓(xùn)練過程中，往往會因為一些意外導(dǎo)致訓(xùn)練任務(wù)失敗，比如機(jī)器故障，GPU卡之間的通信故障等。而大型訓(xùn)練任務(wù)往往都是持續(xù)好幾個月的，在訓(xùn)練過程中出問題的概率接近100%，為了避免在訓(xùn)練任務(wù)失敗時從零開始訓(xùn)練，訓(xùn)練任務(wù)就需要在訓(xùn)練的過程中定期做checkpoint，這樣任務(wù)失敗了就可以從上一次checkpoint恢復(fù)，而不必從頭開始整個訓(xùn)練。做checkpoint越頻繁，每次訓(xùn)練任務(wù)重啟時，損失的訓(xùn)練時長就越短。但是對于一個大型訓(xùn)練而言，checkpoint的大小往往在數(shù)百GB，保存并持久化巨大的checkpoint文件也會花費比較長的時間。訓(xùn)練任務(wù)在做checkpoint的時候，整個訓(xùn)練任務(wù)是停止的，GPU處于等待狀態(tài)。也就是說，如果想用Alluxio保存checkpoint，Alluxio必須要有一個比較GPU在Alluxio社區(qū)版時，采用的是同步寫模式寫入數(shù)據(jù)，直接穿透寫到UFS上，只200MB/secHDFS每隔3小時做200GB的checkpoint，每天光是花費在做checkpoint上的時間1208GPU8%，很明顯這個速度是不能滿足需求的。Alluxio企業(yè)版支持了更高的寫入性能，在測試中，單線程同步寫入HDFS能達(dá)到1.2-1.4GB/sec的速度，如果還是按照每隔3小時做200GB的checkpoint來算，每天花費的時間將減少至20分鐘，只占到全天時長的1.4%，這能夠大大減少模型訓(xùn)練做checkpoint的時長，提高GPU利用率。目前Alluxio寫入的上線正在內(nèi)部測試，還沒有正式上線。除了同步寫入，后續(xù)知乎還計劃上線企業(yè)版的異步寫功能，在提升寫入性能的同時，節(jié)省專線帶寬。運維成本在社區(qū)版時，需要自己打包Alluxio的鏡像，并且自己寫yaml文件將Alluxio部k8s出錯，下圖是部署社區(qū)版所使用的腳本和配置文件的集合，可以看到一共有十幾個文件。Alluxio企業(yè)版不僅提供了現(xiàn)成的k8s鏡像，還提供了operator部署工具，可以一鍵啟動集群，在operator安裝好的情況下，部署一個Alluxio集群只需要一個配置文件，極大節(jié)省了我們的運維成本。三、持續(xù)合作，保持探索首先，Alluxio社區(qū)版為知乎帶來了混合云下AI存儲的通用解決方案，能夠在短時間內(nèi)從自研組件無縫切換到Alluxio高性能緩存上，支持實現(xiàn)跨云訓(xùn)練；其次，在更加核心的場景下，Alluxio企業(yè)版帶來了更高的穩(wěn)定性，更好的性能，更便捷的運維，更是支持了知乎內(nèi)部千卡大模型的訓(xùn)練穩(wěn)定高效運行。感謝Alluxio團(tuán)隊在上線過程中提供的幫助，后續(xù)也將繼續(xù)保持合作，共同深入挖掘Alluxio的潛力，探索更多的應(yīng)用場景，為知乎的技術(shù)發(fā)展貢獻(xiàn)更多的力量。B站|Alluxio在B站AI訓(xùn)練場景的應(yīng)用一、B站AI的訓(xùn)練場景機(jī)器學(xué)習(xí)平臺介紹首先，簡單介紹一下B站AI的訓(xùn)練場景，整個機(jī)器學(xué)習(xí)平臺的架構(gòu)如下圖所示：它具備了一個常規(guī)機(jī)器學(xué)習(xí)平臺的能力，比如交互式建模、數(shù)據(jù)集管理、模型訓(xùn)練、模型部署等基礎(chǔ)能力，用戶也會有一些精確的數(shù)據(jù)集、業(yè)務(wù)團(tuán)隊以及資源運營相關(guān)的能力，同時對機(jī)器學(xué)習(xí)框架（比如業(yè)界流行的TensorFlow、PyTorch、DeepSeed以及自研的一些框架等）都需要兼容。同時，為了加速整個訓(xùn)練的收益，B站與Alluxio進(jìn)行了很多合作，搭建了一個在AI訓(xùn)練場景的訓(xùn)練集群，調(diào)度器主要是Volcano，是現(xiàn)在機(jī)器學(xué)習(xí)平臺常用的。已有存儲方案介紹下圖是搭建Alluxio之前的存儲方案，HDFS主要針對大數(shù)據(jù)的分析場景，B站自O(shè)SSBOSS，NAS存儲的系統(tǒng)，當(dāng)然每個存儲系統(tǒng)都有自己的優(yōu)缺點，這里也簡單的做了個對比。AI訓(xùn)練場景介紹搜推一個是搜推，比如商業(yè)、廣告、流量推薦，這種場景就是很明顯的大數(shù)據(jù)存儲的場景，跟HDFS這一套就非常的親和。CV/大模型場景這個場景也是目前使用Alluxio的一個主要業(yè)務(wù)場景，這里有一個特點，單數(shù)據(jù)集的規(guī)模很大，比如最近在用的一個數(shù)據(jù)集，已經(jīng)達(dá)到了PB級，文件數(shù)量大概在億級別，基本都是小文件。CV訓(xùn)練以圖片、音頻等為主，基本都是100KB、1M大小，數(shù)據(jù)比較多樣，有圖片、視頻、音頻、文本等。AI訓(xùn)練存儲痛點在訓(xùn)練過程中發(fā)現(xiàn)了幾個存儲方面的痛點：存儲容量：因為現(xiàn)在隨著大模型的引入，數(shù)據(jù)量會越來越大，對數(shù)據(jù)容量的要求會越來越高，像現(xiàn)在大數(shù)據(jù)集，可能會達(dá)到上百T；這是一個快速增長的過程，而且特別是最近的Sora帶火了TTV這種場景，所以視頻的規(guī)模會非常大，存儲系統(tǒng)需要具備高擴(kuò)展性以應(yīng)對不斷增加的數(shù)據(jù)需求。性能瓶頸：高吞吐：AI訓(xùn)練需要頻繁讀取和寫入數(shù)據(jù)，存儲系統(tǒng)需要支持高吞吐量以保證數(shù)據(jù)加載速度低延遲：數(shù)據(jù)讀取的延遲應(yīng)盡可能低，否則會影響訓(xùn)練效率，導(dǎo)致GPU/NPU等計算資源的浪費。正如大家所熟知的，現(xiàn)在買卡非常難，如果GPU由于IO導(dǎo)致利用率低，那肯定是不劃算的成本、安全：高成本：存儲大量數(shù)據(jù)尤其是高分辨率圖像和視頻數(shù)據(jù)，存儲成本很高，需要平衡性能和成訪問控制：需要對數(shù)據(jù)訪問進(jìn)行細(xì)粒度的權(quán)限管理，確保數(shù)據(jù)安全?；贏lluxio的訓(xùn)練存儲架構(gòu)為了解決這些痛點，在調(diào)研之后，采用了Alluxio的方案，主要有三大吸引點：統(tǒng)一命名空間：將不同存儲系統(tǒng)（如HDFS、BOSS、云存儲）抽象為一個統(tǒng)一文件系統(tǒng)接口，對用戶來說不用感知底層的HDFS，只需要掛Fuse；內(nèi)存或NVMe緩存：結(jié)合內(nèi)存和NVMe存儲緩存，提升訪問速度，降低I/ONVMeGPUNVMe；多存儲后端：兼容HDFS、對象存儲等多種存儲后端，擴(kuò)展性強(qiáng)。二、Alluxio在AI訓(xùn)練場景的應(yīng)用為什么選擇Alluxio？這里先介紹一下Alluxio的主要優(yōu)勢：性能高：低延遲高吞吐的數(shù)據(jù)緩存能力，對于AI訓(xùn)練尤其重要；兼容性強(qiáng)：支持S3/HDFS后端，提供了廣泛的數(shù)據(jù)源兼容性；兼容POSIX協(xié)議；運維成本低：運維成本在大規(guī)模數(shù)據(jù)存儲和處理環(huán)境中尤為重要，有助于減少整體運維投入；大規(guī)模數(shù)據(jù)處理：Alluxio支持億級的數(shù)據(jù)量規(guī)模，能滿足AI訓(xùn)練需求。在做技術(shù)選型的時候，也對業(yè)界常用的幾個系統(tǒng)做了調(diào)研和分析，基于B站的體量，B站沒有人力單獨為AI做存儲的維護(hù)，所以第一個優(yōu)先考慮的就是成本，需要投入更低的成本、更低的運維，支持更強(qiáng)的性能。在調(diào)研過程中Alluxio各方面表現(xiàn)優(yōu)勢明顯，最終選擇了Alluxio。單集群or多集群？在部署的時候Alluxio采用的是一種多Master、多Worker的方式。但B站在大數(shù)據(jù)集場景是一種單集群部署的模式，優(yōu)勢是：一個集群可以集中管理、運維成本比較低，可以實現(xiàn)資源的高效利用；缺點是現(xiàn)在社區(qū)版2.9.4的元數(shù)據(jù)存儲在Master，很容易碰到天花板，擴(kuò)展性比較有限，如果單個集群出現(xiàn)了問題，對業(yè)務(wù)的影響是比較大的，所以在AI場景最終采用的是多集群部署的方案。基于整個集群的存儲規(guī)模，集群的劃分會按照業(yè)務(wù)或者是數(shù)據(jù)集，好處是某個業(yè)務(wù)或者數(shù)據(jù)集需要更強(qiáng)的能力，則會投入更多的資源，而對于那些不怎么重要的業(yè)務(wù)，或者是低優(yōu)先級的業(yè)務(wù)，則需要把它隔離開，從而不至于讓低優(yōu)先級的業(yè)務(wù)影響到高優(yōu)先級的業(yè)務(wù)，這是最終采用的方式。通過多集群的方式，在部署運維方面會增加更多的成本，那么如何解決這個問題？基于Fluid的云原生多集群部署方案這里引入了Fluid。Alluxio是對底層存儲的抽象，F(xiàn)luid又是對Alluxio這一層Runtime的抽象。通過Fluid之后，可以更好的在K8s上，更自動化的部署多集群的方案，目前B站應(yīng)該有百機(jī)規(guī)模的集群。調(diào)度優(yōu)化另一個問題是，在實際應(yīng)用中使用的是volcano調(diào)度器，主要是binpack為主，binpack的策略是盡可能的把單臺機(jī)器塞滿，對IO密集型的業(yè)務(wù)，如果把所有的節(jié)點都調(diào)度到單臺機(jī)器上，很容易造成單點故障，給IO造成瓶頸，另外也會帶來網(wǎng)絡(luò)擁塞、資源利用不均等問題。解決辦法：結(jié)合了業(yè)務(wù)特點以及本身的緩存加速場景，采用的是拓?fù)涓兄恼{(diào)度策略。首先，會盡可能的讓Alluxio的節(jié)點分散到集群的每臺機(jī)器上，盡可能的把IO打散。其次，在任務(wù)調(diào)度的時候，也會去感知Alluxio的拓?fù)浞植?，盡可能做到任務(wù)與Alluxio節(jié)點的親和，這樣親和之后相當(dāng)于在讀本地硬盤。元數(shù)據(jù)同步加速元數(shù)據(jù)同步的必要性:元數(shù)據(jù)同步在Alluxio中至關(guān)重要，因為它確保Alluxio文件系統(tǒng)與底層存儲系統(tǒng)中的數(shù)據(jù)保持一致，這個問題B站也同樣遇到過。當(dāng)數(shù)據(jù)量大了之后，如果按照官方的元數(shù)據(jù)同步方法，對整個集群的穩(wěn)定性和性能都會有很大的影響，所以最終采取了一種按需同步的方法。這里已經(jīng)把集群暴露給用戶，他可以直接操作他的集群，知道什么時候數(shù)據(jù)是更新的，由他來決定；另外，如果是那種億級別的數(shù)據(jù)集要做Meta同步，至少是小時級別，這個肯定是不可接受的，所以也在要求用戶最小化他的同步單元，盡可能的減少無效的同步計算。具體同步方式:基于時間的自動同步：設(shè)置erval屬性來定時同步；手動同步：使用loadMetadata命令或API手動觸發(fā)同步。加速方式：按需同步：只在需要時觸發(fā)；最小范圍同步：最小范圍同步，減少無效同步計算。超大規(guī)模小文件優(yōu)化很多場景的數(shù)據(jù)都是以小數(shù)據(jù)為主，如果只是簡單的把數(shù)據(jù)給到Alluxio，然后什么都不做，這樣就會有兩個問題，一個是Meta會很多，本身B站采用的就是Master的架構(gòu)，整個集群對Master的壓力會很大；另一個就是用戶會無組織的去用，因為他根本就不知道該做哪些組織才有利于數(shù)據(jù)的IO。這塊主要是做了數(shù)據(jù)合并，也是在訓(xùn)練場景用的比較多的一種方式，把一個圖片做成一個chunk，chunk里邊再做一個下浮，可以做到指數(shù)級的降低文件的Meta信息，并對整個訓(xùn)練的效果都不會有太大的影響。Alluxio帶來的效益在實際應(yīng)用過程中測下來，億級別的單節(jié)點性能基本能達(dá)到IOPS在3000+以上，整個業(yè)務(wù)包括審核、大模型，都在用這一套，現(xiàn)在已經(jīng)緩存的數(shù)據(jù)集大概在幾百T規(guī)模左右。三、未來規(guī)劃Alluxio之前介紹過知乎的推理場景，這個場景B站也有比較大的痛點，所以B站也在嘗試探索更多的可能。另外就是現(xiàn)在Master元數(shù)據(jù)管理是一個很痛的點，在這種場景下Alluxio最新的Dora框架可以帶來多大的收益，也是需要進(jìn)一步去調(diào)研的，同時，因為是一個機(jī)器學(xué)習(xí)平臺，應(yīng)用場景非常單一，同時也在跟B站的存儲專業(yè)團(tuán)隊做一個更大規(guī)模、更通用的Alluxio解決方案，這是現(xiàn)在在做的，也是后續(xù)打算去推的。輝羲智能 | Alluxio在自動駕駛模型訓(xùn)中的應(yīng)用與部署一、自動駕駛數(shù)據(jù)閉環(huán)首先分享一下自動駕駛中怎么樣構(gòu)建數(shù)據(jù)閉環(huán)，這個業(yè)務(wù)過程可能大家都有所了解。自動駕駛會包含多種車輛類型，比如數(shù)采車輛、帶著算法在路上跑的車。數(shù)據(jù)采集就是在跑的過程中采自動駕駛車上的各種數(shù)據(jù)：比如說camera的數(shù)據(jù)就是圖片，激光雷達(dá)的數(shù)據(jù)是點云。傳感器數(shù)據(jù)采回來，可能一輛車每天跑下來就有幾T的數(shù)據(jù)。這種數(shù)據(jù)通過基盤的方式或者其他上傳方式把它們整體存儲起來，傳到對象存儲里面。原始數(shù)據(jù)存儲之后會有一個pipeline做數(shù)據(jù)的解析預(yù)處理，比如把它切成一幀一幀的數(shù)據(jù)幀，每幀的不同傳感器數(shù)據(jù)之間可能還要做同步對齊的操作。完成數(shù)據(jù)解析之后，就要在上面做更多的挖掘。構(gòu)建一個一個的數(shù)據(jù)集。因為不管是在算法、仿真或者測試?yán)锩?，都要?gòu)建數(shù)據(jù)集。比如想要雨天的某一個晚上，某一個路口，或者一些密集形成區(qū)域的數(shù)據(jù)，那就會在整個系統(tǒng)里面有大量的這種數(shù)據(jù)需求，要做數(shù)據(jù)的打標(biāo)，打上一些標(biāo)簽。比如說在清華東門這個地方，需要去拿這個位置的經(jīng)緯度，解析周圍的POI。之后再對挖掘出來的數(shù)據(jù)做標(biāo)注。常見的標(biāo)注有：對象、行人、對象的類型等。這種做了標(biāo)注的數(shù)據(jù)，會被拿去做訓(xùn)練。典型的一些任務(wù)，比如目標(biāo)的檢測、車道線的檢測、或者更大的端到端的模型。模型訓(xùn)練好了之后，還要做一些仿真驗證。驗證完再把它部署到車上面，再去跑數(shù)據(jù)，在這個基礎(chǔ)上再去采更多的數(shù)據(jù)。就是這樣的一個循環(huán)，不斷的去豐富數(shù)據(jù)，不斷的去構(gòu)建性能更好的模型。這是整個訓(xùn)練，數(shù)據(jù)閉環(huán)要做的事情，也是現(xiàn)在自動駕駛研發(fā)里面較核心的事情。二、算法訓(xùn)練：NAS聚焦到模型訓(xùn)練來講：模型訓(xùn)練主要是通過數(shù)據(jù)挖掘拿到數(shù)據(jù)，從而生成一個數(shù)據(jù)集。數(shù)據(jù)集在內(nèi)部是一個pkl文件，包含數(shù)據(jù)、channel、存儲位置，最后數(shù)據(jù)算法訓(xùn)練的同學(xué)會自己寫下載腳本，把數(shù)據(jù)從對象存儲拉到本地。在選用Alluxio之前，是通過NAS系統(tǒng)充當(dāng)緩存的作用，把對象存儲的數(shù)據(jù)拉到NAS上面，最后再用不同的模型，把數(shù)據(jù)load進(jìn)來進(jìn)行訓(xùn)練。這是使用Alluxio之前，大概的訓(xùn)練流程。NAS第一是并發(fā)性能比較差——NAS可以理解成它就是一塊大的硬盤，當(dāng)只有幾個任務(wù)一起跑的時候，還是比較夠用的。但是當(dāng)有幾十個訓(xùn)練任務(wù)同時進(jìn)行、很多模型在訓(xùn)練的時候，往往就會出現(xiàn)卡死。曾經(jīng)有一段時間卡死非常嚴(yán)重，研發(fā)每天都叫苦不迭?？ǖ脟?yán)重以至于可用性非常差、并發(fā)性能很差。第二是管理困難——每一個人都用自己下載的腳本，然后把想要的數(shù)據(jù)下載到自己的目錄下面。另一個人可能又自己去下另外一堆數(shù)據(jù)，放到NAS的另外一個目錄下面，這樣就會造成NAS空間滿時很難做清理。當(dāng)時基本都是當(dāng)面或者微信群溝通。一方面是效率特別低，依靠群消息管理會滯后。另外一方面，也會因為手動remove，導(dǎo)致一些風(fēng)險。曾經(jīng)出現(xiàn)過remove數(shù)據(jù)時，把別人的數(shù)據(jù)集給刪掉的情況。這也會造成線上任務(wù)區(qū)域的報錯，這是另外一個痛點。第三是空間浪費——不同人下載的數(shù)據(jù)放在不同目錄下，有可能同樣一幀數(shù)據(jù)會出現(xiàn)在好幾個數(shù)據(jù)集，存在比較嚴(yán)重的空間浪費。第四是使用很復(fù)雜——因為pkl里面的文件格式不相同，使得下載邏輯也不一樣，每個人都要單獨去寫下載程序。這是之前用NAS會面臨的一些困難和問題，為了解決這些問題而做了一些調(diào)研。調(diào)研后聚焦到Alluxio上來。發(fā)現(xiàn)Alluxio它可以提供一個比較統(tǒng)一的緩存，緩存可以提升訓(xùn)練速度，同時也可以減少管理成本。還會用Alluxio的系統(tǒng)，處理雙機(jī)房的問題。通過統(tǒng)一的命名空間和訪問方式，一方面可以簡化了系統(tǒng)設(shè)計，另外在代碼實現(xiàn)上也會變得很簡單。三、算法訓(xùn)練引入Alluxio當(dāng)把NAS換成Alluxio之后，Alluxio能夠針對性的解決剛才提到的一些問題：在并發(fā)性方面NAS本身不是一個完全分布式的系統(tǒng)，而Alluxio是。NAS它訪問的IO達(dá)到一定的速度時會出現(xiàn)卡頓，可能達(dá)到幾個G/s的時候就會開始卡。而Alluxio的上限非常高，下面還有專門的測試來說明這一點。通過手動清理或者管理會非常麻煩Alluixo會配置緩存的逐出策略。一般是通過LRU，當(dāng)?shù)揭粋€threshold的時候（比如90%）它會自動做緩存的驅(qū)逐和清理。這樣做的效果：效率大大得提升；可以避免因為誤刪導(dǎo)致的安全性問題；解決了重復(fù)數(shù)據(jù)的問題。在Alluxio里面，一個UFS里面文件，對應(yīng)到Alluxio就是一個路徑，當(dāng)所有人都去訪問這個路徑時，就可以拿到對應(yīng)的數(shù)據(jù)，這樣就不會存在重復(fù)數(shù)據(jù)的問題。另外使用上面也比較簡單，只需要通過FUSE以上是從邏輯層面解決了剛才講的各種各樣問題。下面講一講，整個落地的歷程，怎么從0到1實現(xiàn)Alluxio從開始的POC測試，到各種性能的驗證，再到最后怎么樣部署、運維等的一些實踐經(jīng)驗。四、Alluxio部署：單機(jī)房首先可能會在單機(jī)房里部署，就是一定要臨近GPU，部署到GPU節(jié)點上。同時利用之前GPU上很少用的SSD，把每個節(jié)點都利用起來，然后把FUSE和worker部署在一起。FUSE就相當(dāng)于客戶端，worker就相當(dāng)于一個具有內(nèi)網(wǎng)通信的緩存小集群，做FUSE的服務(wù)。最后對應(yīng)的通過worker自己對底層的對象存儲做通信。五、Alluxio部署：跨機(jī)房但是由于各種各樣的原因，還會有跨機(jī)房的存在。現(xiàn)在有兩個機(jī)房，每一個機(jī)房里都會有對應(yīng)的S3服務(wù)，也會有相應(yīng)的GPU計算節(jié)點?；旧厦恳粋€機(jī)房都會部署一個Alluxio。同時在這個過程中也要注意，一個機(jī)房里可能是兩個Alluxio的對象存儲，另外一個機(jī)房如果也要做S3掛載，盡量做好bucket名字的統(tǒng)一規(guī)劃，不能把兩個搞重了。比如這里有個bucket1，那里又有一個bucket1，會導(dǎo)致Alluxio掛載時的一些問題。還要注意，不同的endpoint要注意內(nèi)網(wǎng)和外網(wǎng)的區(qū)分，比如集群1的Alluxio，掛載集群1的endpoint內(nèi)網(wǎng)，在另一邊就是外網(wǎng)，反之性能就會大打折扣。掛載之后可以通過同樣的路徑去訪問不同集群上面不同bucket的數(shù)據(jù)，這樣其實整個架構(gòu)就會變得非常簡單，這是跨機(jī)房部署方面。六、Alluxio測試：功能想要真正把NAS換成Alluxio，在部署之前要做很多功能測試。這種功能測試，目的是讓現(xiàn)有的算法流程通過最小程度的改造，讓算法同學(xué)也能用起來。這里可能要根據(jù)各位實際情況去操作。當(dāng)時和Alluxio做過接近2-3周的POC驗證，其中會涉及到如下內(nèi)容：K8SPVC數(shù)據(jù)集的組織方式；作業(yè)提交的配置；訪問路徑的替換；最終訪問的腳本接口。以上遇到的諸多問題可能都要做驗證，至少要通過它選一個典型任務(wù)，然后做一些改造，最后才能把NAS比較平穩(wěn)的換成Alluxio。七、Alluxio測試：性能接下來在這個基礎(chǔ)上，還要做一些性能測驗。在這個過程中，不管是單機(jī)還是多機(jī)，都做了比較充分的測試。在單機(jī)上，Alluxio和原來的NAS基本上性能是打平的。其實真正體現(xiàn)Alluxio優(yōu)勢的是多主機(jī)上、分布式的能力?？梢钥吹絅AS或者舉QTS，它有一個非常明顯的點：不穩(wěn)定。測試3G10G7/8G左右，就基本上穩(wěn)定了。而Alluxio這邊，整個測試過程，節(jié)點隨著運行實例的增加，可以達(dá)到一個非常高的上限，當(dāng)時設(shè)到20GB/s時，它都還是呈現(xiàn)出一直向上的趨勢。這說明Alluxio整個并發(fā)的、分布式的性能非常好。八、Alluxio落地：調(diào)參適配環(huán)境做完功能驗證和性能測試之后，就真正的要實際部署Alluxio集群，部署好之后，需要一個參數(shù)調(diào)參適配的過程。因為測試時，只采用了一些典型的任務(wù)，真的上Alluxio環(huán)境之后，會發(fā)現(xiàn)隨著任務(wù)增多，會有一個參數(shù)調(diào)參適配的過程。需要把Alluxio上面相應(yīng)的參數(shù)跟實際運