Alluxio助力AI模型訓練加速寶典+2-WN8

目錄引言0305背景&Alluxio賦能AI場景小紅書|加速云端機器學習-Alluxio在小紅書的實踐一、面臨的挑戰(zhàn)1515161829二、多云數(shù)據(jù)加速層三、小紅書實踐案例四、未來規(guī)劃知乎|AlluxioAI助力知乎千卡模型訓練一、混合云架構，帶來便捷與挑戰(zhàn)二、知乎的探索歷程31313240三、持續(xù)合作，保持探索414145B站|Alluxio在B站AI訓練場景的應用一、B站AI的訓練場景二、Alluxio在AI訓練場景的應用三、未來規(guī)劃51輝羲智能|Alluxio在自動駕駛模型訓練中的應用與部署一、自動駕駛數(shù)據(jù)閉環(huán)5252二、算法訓練：NAS5355三、算法訓練引入Alluxio四、Alluxio部署：單機房5601目錄五、Alluxio部署：跨機房575859六、Alluxio測試：功能七、Alluxio測試：性能八、Alluxio落地：調(diào)參適配環(huán)境九、Alluxio落地：運維十、Alluxio落地：共同進步十一、小結606162636565677078中汽創(chuàng)智|Alluxio在自動駕駛數(shù)據(jù)閉環(huán)中的應用一、自動駕駛業(yè)務介紹二、數(shù)據(jù)平臺架構以及存儲選型三、自動駕駛數(shù)據(jù)平臺使用場景四、未來規(guī)劃關于Alluxio02引言在當今這個人工智能飛速發(fā)展的時代，諸多企業(yè)正站在一個充滿挑戰(zhàn)與機遇的路口。隨著AI模型訓練的熱潮不斷升溫，企業(yè)在追求更高性能計算的同時，也不得不面對GPU資源緊張、模型部署緩慢以及存儲成本失控等問題。這些問題不僅加劇了技術團隊的工作壓力，也對企業(yè)的業(yè)務發(fā)展和市場競爭力構成了嚴峻考驗。本電子書將深入剖析Alluxio如何在AI/ML場景中發(fā)揮其分布式緩存的作用，助力企業(yè)突破IO瓶頸。Alluxio作為一個高效的數(shù)據(jù)訪問層，優(yōu)化了數(shù)據(jù)在存儲與計算引擎間的流動，顯著提升了數(shù)據(jù)訪問速度和操作便捷性。文章詳盡地列舉了企業(yè)在探索AI過程中遇到的挑戰(zhàn)，細致闡釋了Alluxio在技術架構中的關鍵角色，以及其如何通過優(yōu)化AI框架的IO性能，提升整體數(shù)據(jù)處理能力。同時，文中通過小紅書、知乎、B站、輝羲智能以及中汽創(chuàng)智等知名企業(yè)的實戰(zhàn)案例，生動展示了Alluxio如何助力企業(yè)在解決技術難題的同時，實現(xiàn)更快的模型開發(fā)周期、更及時的數(shù)據(jù)更新、更高的模型準確性和可追溯性，以及更好地適應數(shù)據(jù)集的迅猛增長。本電子書將幫助用戶迅速把握Alluxio如何助力企業(yè)應對AI模型訓練的多重挑戰(zhàn)，捕捉行業(yè)發(fā)展的脈搏，實現(xiàn)技術上的飛躍和業(yè)務上的持續(xù)增長。03用戶收益1.實戰(zhàn)經(jīng)驗借鑒：通過小紅書、B站、知乎、輝羲智能等企業(yè)案例，了解如何將Alluxio應用于實際場景，解決具體的業(yè)務挑戰(zhàn)。2.多云架構優(yōu)化：了解如何在多云環(huán)境中利用Alluxio實現(xiàn)數(shù)據(jù)的高效管理和訪問，從而優(yōu)化多云架構下的數(shù)據(jù)使用和存儲成本。3.性能與成本的雙重優(yōu)化：掌握如何通過Alluxio提升數(shù)據(jù)處理性能，同時實現(xiàn)成本優(yōu)化。4.前沿技術洞察：獲得對未來技術發(fā)展趨勢的洞察，為技術選型和業(yè)務布局提供參考。5.靈活性與擴展性實踐：了解Alluxio如何支持不同技術棧和框架，增強現(xiàn)有系統(tǒng)的靈活性和擴展性，以適應不斷變化的技術需求。適用人群數(shù)據(jù)科學家與機器學習工程師、AI研發(fā)團隊、技術架構師、基礎設施團隊、技術平臺團隊、云計算與存儲團隊、IT運維與系統(tǒng)管理員、業(yè)務分析師與決策者、學術研究人員、技術愛好者、產(chǎn)品經(jīng)理、行業(yè)解決方案顧問04背景&Alluxio賦能AI場景一、企業(yè)在嘗試AI時面臨的挑戰(zhàn)1.GPU短缺其實從幾年前就已經(jīng)呈現(xiàn)了一些趨勢，不管是在云上使用GPU還是自己購買GPU搭建IDC（數(shù)據(jù)倉庫），AI基礎設施都比較困難，原因大概可以分為3種情況：很多公司無法買到GPU；部分公司即使買到了GPU，量也不是很大，很難滿足業(yè)務需求；部分公司或許可以在阿里云或者騰訊云上買到GPU，但如何把這些GPU形成一個系統(tǒng)的計算池，供上層業(yè)務使用，是比較困難的。2.模型上線慢公司現(xiàn)有數(shù)倉/存儲方案較陳舊，很難迭代，進行GPU訓練后，如何把模型上線到推理的集群中，是必不可少的一個環(huán)節(jié)，也是困難重重的一個環(huán)節(jié)：很多數(shù)倉、底層的存儲都還是公司里比較傳統(tǒng)的存儲方案，比如HDFS，可能十幾年前就開始用了，現(xiàn)在很難調(diào)整存儲的設置；數(shù)據(jù)在云上，限流情況嚴重，使用限制較多。后面也會深入聊一下，如何解決這個問題。3.GPU使用率低現(xiàn)在很多公司模型訓練過程GPU利用率普遍比較低，當然這個不是Alluxio一家就能解決的問題，普遍現(xiàn)象是：企業(yè)的數(shù)據(jù)大多在數(shù)倉中，這些數(shù)據(jù)如何引入GPU集群，存在非常多的挑戰(zhàn)。后文也會分享在不同云廠商、國內(nèi)外的大型企業(yè)中，Alluxio是如何解決這一問題的：05前面所提到的更多都是業(yè)務的壓力或者是商業(yè)上業(yè)務決策的壓力，這些壓力反映到基礎上對工程人員來說就會變成技術壓力，為了能夠更快進行模型開發(fā)，Alluxio其實是有一些期望的：更快的模型開發(fā)時間；更頻繁的模型數(shù)據(jù)更新；更高的準確性和可追溯性；適應快速增長的數(shù)據(jù)集。這些壓力反映到技術側大概可以概括為3點：1.廣泛的數(shù)據(jù)拷貝任務管理比如以現(xiàn)在的應用，如何做這套系統(tǒng)，很多時候需要進行一些復雜的數(shù)據(jù)拷貝任務，從數(shù)據(jù)倉庫往GPU的訓練集群中進行數(shù)據(jù)拷貝，無論是拷貝到本地的NAS、NFS系統(tǒng)，或者是拷貝到本地的磁盤中進行數(shù)據(jù)管理，都是比較復雜的2.專用存儲為了滿足AI場景的需求，對性能的要求會比較高，可以這么理解：20-30年前，GPU是和HPC（高性能計算）一起發(fā)展起來的，所以那時候大家普遍傾向于要有一套IB的網(wǎng)絡，并且是有一套高性能存儲（全閃）支撐業(yè)務的發(fā)展，其實現(xiàn)在在云上或者是IDC里，這個問題是非常難解決的，因為大部分公司/云上設施沒有辦法提供這么高的專用存儲支持模型訓練或者是模型分發(fā)的任務。063.云和基礎設施成本失控模型上線以后，隨著業(yè)務規(guī)模的增長，云和基礎設施的成本是非常容易失控的，可以看到非常多的場景，比如3年增加5倍的云上成本都是很正常的。二、Alluxio在技術棧中的位置在進入詳細技術討論之前，再系統(tǒng)介紹一下Alluxio在AI/ML技術棧中的位置。首先，Alluxio不是一個持久化的存儲層，持久化存儲比較依賴云上S3Storage、Ceph或者是HDFS這種分布式存儲，這些都是Alluxio下面的一個接口，和Alluxio不是同一個概念。再往上，Alluxio在AI領域是一個高性能的接入層，因為對于持久化存儲層來講，大部分公司追求的是價格和性能效率，而這個效率就意味著要有一個非常便宜的存儲池，可以存儲很多資源，并不期望有一套非常昂貴的高性能存儲來做持久化存儲，之所以會這樣是因為很多互聯(lián)網(wǎng)廠商或者是傳統(tǒng)企業(yè)的數(shù)據(jù)量有幾百個PB甚至是EB級別的，但同時需要訓練的數(shù)據(jù)并沒有那么多，可能就是幾十個TB，甚至高一點的也就1PB左右，如果可以把這些數(shù)據(jù)放到一個高性能存儲向上進行對接，對用戶來說這個性價比是非常低的，所以Alluxio比較依賴這種持久化存儲層進行非常簡單的對接，或者現(xiàn)在已經(jīng)有了持久化存儲層，不改變它的架構，可以直接進行數(shù)據(jù)對接。07再往上，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)境中總結的價值是有非常多的，大概可以概括成4點：1.更高性能、可擴展的AI/ML管道Alluxio不改變現(xiàn)有的集群部署，比如已有的對象存儲、HDFS等，同時又想擴展業(yè)務，這里其實有兩個關鍵點：一般大數(shù)據(jù)和AI兩個Team雖然在一個大的架構下，但其實技術棧是非常不同的，比如大數(shù)據(jù)技術棧會有Spark、Trino、Hive、HBase等，向下對接的是HDFS、云上的一些對象存儲等，這些數(shù)據(jù)是一直在的，數(shù)據(jù)量可能有幾百個PB甚至EB級別的，同時需要搭建一個AIInfra的平臺，AI技術棧其實是Pytorch、TensorFlow，下面對接比較多的是對象存儲，比如Ceph、MinIO等，其它的會有一些專用存儲，比如提供NFS、NAS的這些系統(tǒng)向上對接；其實這兩個系統(tǒng)的存在就產(chǎn)生了對接的問題，就是數(shù)據(jù)在數(shù)倉中，但是處理是到AIInfra里，這就變成一套非常復雜的系統(tǒng)了，而Alluxio可以幫助打通這套系統(tǒng)，不需要每次都進行非常復雜的數(shù)據(jù)遷移。2.隨時獲取及時、準確的模型數(shù)據(jù)模型的數(shù)據(jù)從訓練集群出來，需要先落到存儲中，然后再向上拉取到推理集群，這個過程很多時候是非常復雜的，比如DataPipeline，之前遇到很多互聯(lián)網(wǎng)公司都有一個臨時的checkpointstore，然后還有一個持久化的checkpointstore，他們進行低性能和高性能的互相拉取是一個非常復雜的過程。3.避免復雜的數(shù)據(jù)遷移4.模型上線時間相比對象存儲與傳統(tǒng)數(shù)倉快2-4倍08底層存儲一般都是對象存儲或者是傳統(tǒng)HDFS，比如傳統(tǒng)的HDFS大家都是給大量數(shù)據(jù)存儲設計的，這個不是為了性能而設計的，大部分情況是為了保障容錯，同時針對云上的存儲，在跟諸多云廠商交流后了解到，他們很多情況下沒辦法直接在云上用對象存儲支持AI的業(yè)務，原因在于限流的問題，拉取數(shù)據(jù)的速度很快，所以沒辦法處理。下面詳細介紹Alluxio是如何做這套系統(tǒng)的，里面有很多場景的沉淀，此處分享一下Alluxio架構設計的初衷：首先在很多互聯(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ù)直接進來，也有很多非結構化的數(shù)據(jù)是放在數(shù)據(jù)湖里的。那么Alluxio是如何在其中發(fā)揮作用的呢？現(xiàn)在比較流行的就是用Spark或者Ray的架構，把這個數(shù)據(jù)預處理完，放回數(shù)據(jù)湖中，后面的TensorFlow、Pytorch會拉取這里的數(shù)據(jù)進行訓練，比如看左邊這個圖，如果不用Alluxio拉取數(shù)據(jù)會產(chǎn)生什么問題呢？比如原來的數(shù)倉用的是HDFS集群，AI訓練會用一個Ceph的集群：09userid:529794,docid:172662,date:2024-08-22,首先要把處理好/未處理好的數(shù)據(jù)拉到Ceph的集群中，再向上serving這些拉取的data，在這里就會出現(xiàn)一些問題：首先這套拉取的流程會非常復雜，很多公司會自己開發(fā)一套數(shù)據(jù)管理系統(tǒng)完成，會有幾套不同的流程在里邊，比如用metastore對應這些表/數(shù)據(jù)在哪里；其次需要增量的拉取數(shù)據(jù)；最后需要對數(shù)據(jù)進行檢驗，查看是否有問題。這套流程下來從拉取到可用有很長的延遲，而Alluxio緩存的功能幫助大家解決這個問題。首先可以預先將部分數(shù)據(jù)加載到Alluxio中，放到更靠近計算的存儲中，從而降低帶寬消耗。同時，即使沒有預加載數(shù)據(jù)，Alluxio的緩存機制也能幫助快速拉取數(shù)據(jù)到訓練集群中。這種方式類似于股票交易中的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，方便用戶進行定制化開發(fā)。此外，Alluxio還著重關注：在訓練集群上如何降低成本并提高效率。過去很多公司使用高性能的存儲集群進行訓練，但這種成本可能非常昂貴，限制了業(yè)務的擴展。如果僅在GPU計算節(jié)點上配備磁盤，與GPU集群整體成本相比，這個成本通常不會超過3-5%。此外，許多公司擁有大量存儲資源，但如何充分利用這些資源仍然是一個挑戰(zhàn)。Alluxio在這方面提供了很多結合點?？梢詫lluxio集群直接部署到訓練節(jié)點上，這樣的消耗非常小（約30-40GB內(nèi)存），卻能提供高性能的訓練支持。用戶只需要付出整個計算集群成本的3-5%，就可以充分利用GPU集群，幫助用戶克服IO瓶頸達到GPU100%使用率。10除了訓練集群，Alluxio也特別關注推理集群的成本和效率問題。隨著推理集群的擴展，成本可能遠高于訓練集群。因此Alluxio致力于解決如何快速將訓練產(chǎn)生的模型部署到線上集群的問題。在傳統(tǒng)方式中，訓練結果會寫回到一個Ceph存儲，然后線上集群可能位于同一個或不同的IDC中，涉及到復雜的管理。很多公司會開發(fā)一套自己的存儲網(wǎng)關(storageGateway）來解決跨域或跨IDC的問題，但是網(wǎng)關解決的是一個跨域或者是跨IDC問題，實際上沒有解決的是高性能和跨域的問題，簡單理解就是可以把訓練集群和線上的ML打通，但如果在AWS里這個Gateway是完全沒有辦法支撐推理集群的，比如擴展到100個甚至1000個節(jié)點的推理集群后，上線的時候會抖動的非常厲害，再比如：Alluxio可以在2-3分鐘內(nèi)把整個模型全都部署到推理集群上面，一般這種系統(tǒng)需要耗費的時間是它的10倍，而且它的P95和P99會非常長。三、Alluxio在模型訓練&模型上線場景的應用接下來會詳細講解不同場景中，Alluxio是如何做的：11第一個就是之前說到的問題，在GPU非常短缺的情況下，很多公司其實之前都不是多云戰(zhàn)略，不是IDC融合或者是云上、本地都有的架構，但為了滿足GPU資源的部署，很多時候被迫變成這樣，舉個例子：很多客戶/用戶，數(shù)據(jù)都是在AWS上，根本就不想用Azure、GoogleCloud等其他云，但今年，Azure把所有GPU都買了，在這種情況下其實很難說在AWS上可以找到所有集群，然后這些集群就必須在Azure里，就必須得有個方法直接去訪問AWS里的數(shù)據(jù)，這個問題就導致如果直接去獲取，數(shù)據(jù)性能就會非常低，如果是在網(wǎng)絡帶寬非常低的情況下，GPU的利用率通常不會超過10%，好一點的網(wǎng)絡（比如有專線）情況下，可以達到20-30%。第二個問題是如果要建一個多集群數(shù)據(jù)管理是非常復雜的，包括要保證數(shù)據(jù)的一致性，如何更新、拉取這些數(shù)據(jù)，但Alluxio做了很多的集成，就可以直接使用Alluxio解決這些問題。其次就是不希望大家專門買一套硬件解決方案，之前接觸過的實驗室有在做HPC的，HPC有一個很大的問題就是成本非常高，買1套HPC通?？梢再I10套Hadoop硬件，或者是云上的存儲硬件，所以如果需要購買一套專有的硬件搭建AIInfra架構，是事倍功半的，成本非常昂貴，看到這個場景后，Alluxio提出還是希望可以直接在數(shù)據(jù)湖上構建AI和ML的數(shù)據(jù)通路，可以不更改存儲系統(tǒng)，同時可以利用已有的，不需要額外購買IDMA這種硬件，就可以支撐訓練的需求。同時不用考慮和原數(shù)倉中任務進行數(shù)據(jù)隔離的問題（所謂隔離就是需要進行數(shù)據(jù)遷移，然后運行成兩套非常獨立的系統(tǒng)，這對數(shù)據(jù)的拉取、獲取是非常有問題的）。12上圖就是前面提到的，Alluxio提供的一些功能，比如自動數(shù)據(jù)湖加載/卸載、更新數(shù)據(jù)功能，從而提高數(shù)據(jù)工程團隊的生產(chǎn)力，一個比較常見的場景就是：如果基于原有的系統(tǒng)搭建，加一個Ceph，基本時間線會拉長到3-6個月，在國外公司拉長到6個月以上是非常常見的，但是用了Alluxio整套系統(tǒng)拉取后，基本就可以在1-2個月內(nèi)把整個DataPipeline建起來，如果大家感興趣可以去詳細了解一下知乎的應用案例，里邊有非常詳細的解讀，告訴大家如何去搭建這套系統(tǒng)。上圖是前面提到的另一個問題：模型部署受限于底層的存儲，包括帶寬的問題，還受限于IDC不同位置的問題，Alluxio可以做一個多云多架構，不管是從公有云到私有云，還是不同公有云之間進行模型部署，都會非常快速的解決這個問題，同時會提供一個高并發(fā)的緩存系統(tǒng)，支持業(yè)務高并發(fā)拉取。稍微總結一下，Alluxio在AI架構中處于怎樣的位置？Alluxio幫助大家解決什么問題？第一個就是降低改造和適配的成本，幫助大家更聚焦在模型上線的邏輯上；第二個就是消除了專用存儲架構，比如原來必須要用NAS、NFS這些系統(tǒng)來做的，用了Alluxio之后就不再需用，Alluxio和下面原來已有的HDFS，對象存儲配合就可以搭建AI平臺；13第三個就是需要添加緩存，就可以把GPU利用率提高到較高的水平；第四個就是滿足公司自由部署GPU的需求，不管是云上還是云下買的GPU，不論數(shù)據(jù)在哪，都可以實現(xiàn)很高效的數(shù)據(jù)適配，后面會提供一個具體案例。關于Alluxio在AI場景是如何助力企業(yè)解決問題的，詳細分享幾個備受關注的案例：14小紅書|加速云端機器學習-Alluxio在小紅書的實踐一、面臨的挑戰(zhàn)首看看小紅書的業(yè)務都碰到了哪些挑戰(zhàn)。小紅書作為云上的原住民，從成立之初就構建在公有云上，下圖是小紅書多云架構的示意圖：圖中的三個圈代表兩個云廠商的不同Zone（區(qū)域），云廠商1是在ZoneA與ZoneB，云廠商2是在ZoneC。核心業(yè)務分別分布在多個云廠商的不同可用區(qū)，核心業(yè)務如搜廣推、社區(qū)通常在主要機房都會存在，是多活架構；主要業(yè)務如電商直播及部分大數(shù)據(jù)服務，是雙活架構；其他如訓練等服務，是單活架構，這個只是個簡化后的示意圖，真實情況遠比這復雜。多云架構對小紅書帶來了非常明顯的成本優(yōu)勢和可用性優(yōu)勢，但業(yè)務的通信鏈路也隨之復雜，各種跨專線調(diào)用；還有個特點是不同region之間rt差異比較大，且專線容量非常稀缺，因此帶來了一些業(yè)務使用上的痛點。15多云架構下有哪些典型的問題1.機器學習訓練在小紅書是資源大戶，屬于公司Top級別，但海量的CPU和GPU資源的利用率不及預期，訓練速度上不去，業(yè)務體感比較差。2.推薦服務是小紅書最核心的服務之一。它的核心邏輯是推薦召回需要有索引分發(fā)的過程，比如刷小紅書刷到的個性化的筆記列表，就主要用到了索引。索引服務因為索引分發(fā)慢，從而導致穩(wěn)定性比較差，且因為索引數(shù)據(jù)存儲在云盤里，成本也很高。3.在AI場景下，有業(yè)務面臨60億+的元信息小文件場景，需要有一個低成本的解決方案。而且隨著AI的飛速發(fā)展，AI模型從之前的百GB級發(fā)展到如今的TB級別。原來的架構通常先把模型拉到本地盤，再從本地盤加載到內(nèi)存，才可以進行在線推理。這個過程在模型增大到TB級之后，會有兩個嚴重的問題：一個是加載過程非常緩慢，另一個是模型存儲在本地盤的成本非常高昂。4.多云架構本身帶來的網(wǎng)絡鏈路復雜，跨專線傳輸數(shù)據(jù)量非常大，專線單價也是非常高昂，有成本和穩(wěn)定性的雙重挑戰(zhàn)。二、多云數(shù)據(jù)加速層接下來介紹下小紅書是如何通過構建多云統(tǒng)一數(shù)據(jù)加速層來解決這些痛點的。16上圖是小紅書業(yè)務架構的示意圖。最上層是業(yè)務層，主要包括社區(qū)、搜廣推、直播、電商這些核心服務。接下來是平臺層，這里只列了一些和數(shù)據(jù)強相關的，如機器學習平臺、AI訓練平臺，模型發(fā)布平臺、推薦索引平臺、數(shù)據(jù)平臺等。最底層是公有云的存儲產(chǎn)品，這里只列了主要依賴的對象存儲，其實包括異構的HDFS等產(chǎn)品都可以適用于這個通用的解決方案。在平臺層和存儲層之間，基于Alluxio構建了一層多云統(tǒng)一數(shù)據(jù)加速層并研發(fā)了對應的智能緩存服務。為什么選擇Alluxio作為多云統(tǒng)一的加速層首先基于面臨的問題，抽象出了選型的重點目標：需要能夠復用業(yè)務歷史上已經(jīng)存儲的數(shù)據(jù)，不需要再次搬遷或者導入到其他高速存儲或文件系統(tǒng)就能享受到數(shù)據(jù)的加速。以典型的搜廣推和訓練業(yè)務為例，這些業(yè)務的存儲量大概是數(shù)百PB級別，搬遷一遍才能使用不太可行。需要支持S3和POSIX協(xié)議，以便于與其他平臺無縫對接。如機器學習訓練通常是S3協(xié)議，AI訓練通常是POSIX協(xié)議，如果加速層能夠兼容這類協(xié)議，業(yè)務方就不需要改代碼，遷移成本也會低很多。需要實現(xiàn)跨云專線傳輸?shù)膸捒刂坪凸?jié)省。因為跨云本身業(yè)務是多活、多云的。但多云之間本身就有實時的數(shù)據(jù)同步，如果把帶寬打爆，那穩(wěn)定性問題就會立馬出來，所以一定要能夠控制住帶寬。能夠支撐百億級別的AI訓練，小紅書有單個訓練任務就有60億+元信息的場景需要支持。能夠支持常見的云存儲產(chǎn)品，以主流云廠商的對象存儲為主。經(jīng)過調(diào)研發(fā)現(xiàn)，業(yè)界目前唯一能同時滿足上述訴求的產(chǎn)品，就是Alluxio。17Alluxio主要特性特性一：格式透明，不侵入業(yè)務數(shù)據(jù)存儲格式。數(shù)據(jù)湖里的數(shù)據(jù)量非常大，是不可能再導入進來重復存儲的，有了Alluxio，只需要在原來存儲上加一層Alluxio，就可以直接去訪問那些數(shù)據(jù)了，讓業(yè)務直接享受到加速收益，這是非常關鍵的特性。特性二：協(xié)議兼容。Alluxio支持非常豐富的S3\POSIX\HDFS\JavaFileAPI\RESTAPI等協(xié)議，幫助Alluxio上層AI/ML訓練引擎（如Pytorch、Ray、TensorFlow）和查詢引擎（如Presto、Spark、Trino）與底層存儲進行無縫對接。特性三：多云統(tǒng)一視圖。不管底層存儲是HDFS、Ceph還是各云廠商的對象存儲，對于用戶，只要通過Alluxio，任何API都可以去訪問不同存儲位置的數(shù)據(jù)，從而可以實現(xiàn)多云統(tǒng)一視圖的效果。特性四：數(shù)據(jù)僅需通過專線傳輸一次，后續(xù)可通過緩存就近讀取，不需要再次跨專線，這個關鍵特性對小紅書專線的保護意義重大。通過合理地利用這些特性，就能夠解決上述提到的小紅書多云架構的業(yè)務痛點。三、小紅書實踐案例機器學習訓練場景18機器學習訓練原架構機器學習訓練最初的架構是直接從對象存儲拉取數(shù)據(jù)（主要是訓練樣本），拉取完這些訓練樣本就開始在TensorFlow框架做訓練。主要問題：訓練速度不太符合預期，導致一些任務訓練很慢，以及其他人排隊調(diào)度不上，體驗很差。海量的集群資源利用率太低對成本也帶來了很大挑戰(zhàn)。主要原因是一些熱點的數(shù)據(jù)集（如小紅書的筆記樣本），是公共的樣本，總量非常大（大概每天幾百TB）。這些公共數(shù)據(jù)集會被很多任務使用，在小紅書的場景下大概是20倍的扇出，如果是幾百TB的數(shù)據(jù)會有20倍的扇出，這個總傳輸數(shù)據(jù)量是非常大的，整體流量達到了Tbps級，觸達到了對象存儲桶的帶寬瓶頸。如果數(shù)據(jù)集大、扇出也大的話，一定會有額外的帶寬需要，云廠商的解決方案通常是要么增加存儲量，要么對增加帶寬進行額外收費，兩種方式都不太友好。因為業(yè)務會直連對象存儲，而對象存儲本身是高吞吐的產(chǎn)品，并不會過分強調(diào)單線程有多快，這就需要業(yè)務不斷的去調(diào)優(yōu)，才能達到適合的吞吐?；谝陨先齻€問題，機器學習訓練架構經(jīng)過了升級改造，最新架構如下圖所示。19新架構對于普通數(shù)據(jù)還是直接會去對象存儲讀取，對于筆記這種熱點的訓練數(shù)據(jù)集，會把它緩存到Alluxio，當業(yè)務來Alluxio訪問的時候，如果第一次數(shù)據(jù)不存在，就會去對象存儲透傳，然后把數(shù)據(jù)返回給訓練框架，如果數(shù)據(jù)已經(jīng)在Alluxio上，那就可以命中緩存，直接由Alluxio返回數(shù)據(jù)。雖然第一遍讀完數(shù)據(jù)，Alluxio一定會去緩存數(shù)據(jù)，但這還很難解決業(yè)務的問題。第一種情況是Alluxio緩存是用到本地磁盤把數(shù)據(jù)緩存下來，但磁盤容量是有限的，如果總訓練的樣本空間遠大于磁盤緩存容量，就會不斷的淘汰緩存數(shù)據(jù)，可能第一個任務緩存了，第二個任務就沒有空間緩存了，或是會把別的緩存數(shù)據(jù)給擠掉。第二種情況是有些訓練任務可能因為計算資源或者故障的原因帶來嚴重的延遲，之后這個業(yè)務一旦跑上來，可能需要訓練30天之前的數(shù)據(jù)，或者直接回溯很老的數(shù)據(jù)去訓練，那這30天的數(shù)據(jù)很容易就把所有的緩存空間全部用掉。以上兩種場景通過研發(fā)了智能緩存管理服務來解決。智能存儲管理服務智能緩存管理服務主要是基于任務的歷史運行規(guī)律，可以基于任務的歷史運行規(guī)律，更加智能的把數(shù)據(jù)提前做預加載，這樣通常第一次訓練就能夠命中緩存，而且可以更及時地淘汰掉不使用的緩存。不僅如此，還對緩存淘汰場景進行了評估，比如發(fā)現(xiàn)最近1-2天的筆記訓練樣本是非常重要的，就會把這些數(shù)據(jù)用Pin機制固定在磁盤里，就不會被自動淘汰，從而實現(xiàn)重要數(shù)據(jù)的淘汰完全由智能緩存管理服務去控制。通過這兩個措施的共同保障，緩存命中率能跑到90%以上，很好節(jié)省了對象存儲的帶寬。同時，Alluxio也提供了load任務的管理和執(zhí)行能力，但目前還不完全符合小紅書的需求。具體的業(yè)務中需要監(jiān)控到任務粒度的load進展，比如有10個任務（有幾個是重要的），在按小時提前預加載數(shù)據(jù)，結果集群故障了，但故障時間也較長，第二天馬上又要用新的樣本去訓練數(shù)據(jù)，那該如何止損呢？20措施是通過實現(xiàn)load進度的可觀測機制，能夠觀察到每個任務當前正在加載第幾小時的數(shù)據(jù)。當在不及預期的時候，會馬上發(fā)出告警并做止損。當止損的時候，會基于任務的優(yōu)先級去判斷優(yōu)先補償哪些任務，并提供一鍵補償?shù)哪芰?，看看這些任務已經(jīng)錯過了哪些小時的緩存數(shù)據(jù)，然后全部加載進來，從而規(guī)避帶寬全部透傳到對象存儲所造成的的穩(wěn)定性風險。第三是為穩(wěn)定性實現(xiàn)了一個探針服務，它可以完全模擬業(yè)務的讀寫行為，是一個端到端的探活服務。探活實踐下來非常好用，無論是代碼本身有問題，還是機器磁盤、網(wǎng)絡等出現(xiàn)問題，都能反映在探針里，方便快速介入。目前能達到3分鐘發(fā)現(xiàn)和1分鐘止損的效率。經(jīng)過將近一年時間的運行，故障告警的準確率幾乎達到了100%。訓練速度提升效果21上圖展示的是一個非常典型的筆記訓練大任務，其他業(yè)務訓練效果都差不多。在遷移之前，訓練時長達到9小時36分，單一任務就需要消耗2000核，非常消耗資源，而平均CPU利用率只有30%，只是到了最后面會有一些上升，這是因為這時候大部分任務已經(jīng)訓練完成，對象存儲的帶寬有些緩解了。在遷移到Alluxio之后，訓練時長直接縮減到了5小時42分，從圖中可以看到，CPU利用率可以非常均勻的維持在75%，并且再也沒有被限流影響到。整體訓練速度在時長上優(yōu)化了41%，雖然很多業(yè)務比這個效果更好，但這個例子是一個非常典型的大任務，更具有代表性。推薦召回索引下載場景22索引對于推薦非常核心，穩(wěn)定性是非常重要的問題。上圖是未引入Alluxio之前的架構圖。最上面是搜推平臺，會對搜推的索引做一些生成或者更新，更新完了之后會存儲到索引存儲（一般是就近機房的對象存儲）。存儲索引之后，搜推平臺會通知其他服務下發(fā)索引，下發(fā)索引的服務會把數(shù)據(jù)通過專線從原來索引存儲的對象存儲桶傳輸?shù)搅硗庖粋€多云機房的本地磁盤，也就是索引服務的本地磁盤上。以圖中的架構為例，共有兩個跨區(qū)域的機房，當把索引數(shù)據(jù)下載到本地盤后索引服務就能夠把數(shù)據(jù)加載到內(nèi)存中，對外提供一些索引的服務。這樣的架構帶來的問題很大：以推薦場景下的索引讀取速度來說，通常發(fā)布一個機房的服務需要3-4個小時，因為是多活設計，發(fā)布完四個機房整整需要一整天，這是非常令人頭疼的問題。同樣，當單機房發(fā)生故障，止損時長同樣也需要3-4小時，如果你要把很老的一個索引回滾，就需要重新走這個流程，四個機房就需要一天時間。磁盤存儲成本非常高。因為索引服務本身是一個主從架構，典型的場景是一主兩從。同一個索引會有三副本的云盤存儲，而云盤本身就是三副本冗余存儲，那整體下來就是九副本，而云盤的單價通常比對象存儲貴得多，這樣計算下來整體成本是非常高的。下圖是引入Alluxio之后的架構。從搜推平臺生成索引之后，會把這個事件發(fā)送到消息隊列，智能緩存管理服務訂閱了該消息隊列，收到相應的加載緩存事件后，就會去加載索引?，F(xiàn)在的加載流程和之前就不一樣了，之前是通過專線傳輸過來存到本地磁盤，現(xiàn)在是加載到Alluxio集群里，然后再告知索引服務，去Alluxio集群把數(shù)據(jù)再加載到索引服務的內(nèi)存，從而對外進行服務。這里的關鍵點是把本地磁盤變成了Alluxio集群，那為什么采用Alluxio之后解決了以上問題呢？23首先，把磁盤上浮到了一個遠程的集群，實現(xiàn)了索引的存算分離，把原來來自云盤的存儲瓶頸，轉(zhuǎn)換成了宿主機的網(wǎng)絡瓶頸。云盤的帶寬通常在云廠商相對還比較好的規(guī)格是350MB/s，但是宿主機不一樣，推薦可用的一些機器至少都是32Gbps以上，合4GB/s，這兩者的差距超過10倍，因此下載索引數(shù)據(jù)這個過程就能提速10倍以上。第二，Alluxio并不會把文件存儲在固定的一臺機器上（和本地盤不一樣），一個文件會被切成block存儲。比如一個集群有100臺機器，一個文件能切100個block，那每個機器只會存1個block，這時候整個集群的帶寬就是這個文件的吞吐極限。所以，對于一些熱點的索引文件或者其他場景都是非常友好的。24但這樣直接用Alluxio還是會遇到問題，所以還加入了一些增強的功能，這也是為什么引入了智能緩存管理服務的原因。比如load太快會把專線打爆，需要Alluxio支持限速，以保障核心服務的穩(wěn)定性?，F(xiàn)在已經(jīng)支持了限速，當限制20-30Gbps的帶寬從UFS下載數(shù)據(jù)，就不會把專線帶寬占滿。這套架構主要有三點收益：1.Alluxio將云盤帶寬瓶頸變成了宿主機的網(wǎng)卡瓶頸，索引拉取速度帶來10倍以上的提升。如果宿主機的核數(shù)越大，附帶的帶寬也會更大，帶來的提升倍數(shù)還會增大。2.索引下發(fā)的整體業(yè)務體感（含業(yè)務邏輯）達到3倍的提升。主要是因為除了下載，還有一些業(yè)務邏輯在這個索引下發(fā)的過程里。3.高性能云盤替換成對象存儲，節(jié)省80%成本。此優(yōu)化是通過Alluxio把云盤全部省掉，變成了Alluxio的集群本地盤，而這些本地盤可以選擇一些更廉價的介質(zhì)，比如單副本的HDD盤。對于小紅書的推薦場景，由于索引數(shù)據(jù)量很大，云盤成本的節(jié)省量也是非常可觀的。大模型下載場景小紅書也有大模型的場景，大模型下載的解決方案和推薦索引幾乎一模一樣，面臨的同樣是云盤帶寬限制和冗余存儲高成本以及跨云同步穩(wěn)定性問題。3-4年前大家通常只做單機訓練，現(xiàn)在已經(jīng)演進到了幾乎都是分布式訓練的狀態(tài)。那一定會需要通過遠端的存儲集群來解決本地數(shù)據(jù)存放不下的問題，這塊架構與收益跟推薦索引一樣，就不贅述了。25AI訓練場景面對的挑戰(zhàn)：有60億+級別的小文件訓練場景，如果把這些元信息存儲在一個集中式的元信息服務里，成本非常高，本身技術挑戰(zhàn)也很大。對象存儲作為很多存儲的底座，最終數(shù)據(jù)會穿透到對象存儲，會面臨著存儲帶寬，或是IOPS比較有限的情況（尤其是小文件），云廠商通常一個桶提供幾萬IOPS，每PB存儲量的帶寬配額也很低，尤其在小文件場景下，這點IOPS承載不了多少訪問，因此GPU利用率就會很低。解決方法：26引入Alluxio緩存訓練需要的數(shù)據(jù)。Alluxio3.0版本提供了一個可擴展的元信息能力，讓擴展性大幅提升。此外，Alluxio本身支持POSIX協(xié)議，之前如果訓練是在本地盤上，現(xiàn)在會把Alluxio集群mount到GPU機器上，由于Alluxio是透明嵌入，讓業(yè)務方看其實還是訪問的本地盤，背后其實是Alluxio集群。然后，通過Alluxio集群去對象存儲里取數(shù)據(jù)，基于Alluxio的緩存機制，可以有效的避免數(shù)據(jù)穿透到對象存儲。因為通常AI訓練是多輪的epoch，Alluxio只會讓第一輪epoch走對象存儲，后面都可以命中這些緩存。甚至理想情況下，可以錯峰把這些數(shù)據(jù)預加載到Alluxio，這樣真正訓練的時候，完全不需要走對象存儲。因為GPU機器上很多磁盤是閑置的，為了避免額外的支出成本，會把Alluxio和GPU機器混合部署，讓這些磁盤都可以被充分使用，也不會有額外的成本支出。Alluxio相對于別的產(chǎn)品打造的非常成熟的能力是ClusterCache。在同樣的總磁盤容量，ClusterCache相對于LocalCache的命中率可以做到更高，比如有兩個訓練任務讀同樣的文件，如果落在兩個不同的機器上，對于LocalCache會把數(shù)據(jù)讀兩遍，而對于ClusterCache只需要讀一遍，第二次可以通過網(wǎng)絡來傳輸，而GPU機器之間的網(wǎng)絡帶寬也常非常高，通常有百Gbps，同時Alluxio也支持LocalCache，組合起來使用更佳。Alluxio為什么能加速AI訓練可以在業(yè)務訓練之前提前把數(shù)據(jù)加載到緩存中，突破IO限制，相比穿透對象存儲讀取性能更高；讀取數(shù)據(jù)時通過智能判定是隨機讀還是順序讀。如果是順序讀可以提前預讀數(shù)據(jù)，從而達到更高的讀吞吐；如果是隨機讀，可以精準地控制要讀哪個位置，避免讀的放大；無集中式的元信息服務，全量元信息在對象存儲，只有熱數(shù)據(jù)及其元數(shù)據(jù)在緩存中，對海量小文件友好，相比于集中式元信息服務，成本極低；可異步寫checkpoint到本地磁盤，再異步上傳至對象存儲，通過有效縮短IO負載時長，從而大幅縮短GPU等待時間，并顯著提升GPU利用率。27技術問題及解法在與Alluxio的合作過程中，小紅書也一起參與解決了非常多的技術問題，這里有幾個比較典型的場景：讀放大問題解決：主要表現(xiàn)在S3協(xié)議里會有一些range讀，以及Alluxioclient、fuse或者其他一些觸發(fā)隨機讀的場景。放大主要存在兩個環(huán)節(jié)：一個是S3proxy到worker之間；另一個是worker去對象存儲（UFS）取數(shù)據(jù)的時候，都會有一個讀放大的情況。比如一個數(shù)據(jù)是熱讀（指數(shù)據(jù)緩存已經(jīng)在worker里），原來的實現(xiàn)里proxy會直接去worker取，雖然S3協(xié)議里的range參數(shù)已經(jīng)指明了截止位，但并沒有透傳過去。因為這里可能認為需要做一些預加載來加速后續(xù)的讀取，實際上業(yè)務如果指定了一個endOffset，后面的數(shù)據(jù)則是沒必要讀取的。雖然預讀能幫助吞吐的提升，但在這種情況下后面的數(shù)據(jù)會被完全廢掉，反而會轉(zhuǎn)化成帶寬的放大?！鉀Q辦法：worker傳輸數(shù)據(jù)當傳輸?shù)絜ndOffset，后面的字節(jié)不需要傳輸過來，這樣是更經(jīng)濟，更高效的辦法。第二個放大的問題是因為Alluxio初衷在讀數(shù)據(jù)時，會把需讀取數(shù)據(jù)范圍涉及的block全部緩存下來，好處是之后再讀這些數(shù)據(jù)就不需要走帶寬了。比如在一個隨機讀的場景，在一個block里只需要1-2M數(shù)據(jù)，但Alluxio會緩存整個block的大小（默認為64M）?！鉀Q辦法：如果是非緩存block的數(shù)據(jù)請求，因為協(xié)議中本身傳了endOffset，需要將其作為訪問對象存儲的參數(shù)，只需要讀取必要的數(shù)據(jù)即可。endOffset之后的數(shù)據(jù)本身也會被丟棄掉，讀出來就會變成worker機器上網(wǎng)絡帶寬的開銷，從而影響成本和效果。第三個是冷讀NoCache的場景。NoCache是指經(jīng)過Alluxio讀取但不緩存對應的數(shù)據(jù)，通常發(fā)生在對于延遲太久的任務或者讀取大量冷數(shù)據(jù)的任務，不需要將其緩存下來，否則會將本身的熱數(shù)據(jù)給擠掉?！鉀Q辦法：以前的實現(xiàn)里，通過S3proxy直接NoCache讀，它會通過worker去UFS取數(shù)據(jù)。修改和打磨之后，Proxy會繞過worker直接去UFS取數(shù)據(jù)。這樣可以節(jié)省worker傳輸?shù)絧roxy的帶寬，可以省一倍的帶寬，對應到機器成本上就是省一倍的機器成本。28專線帶寬限流：在UFS這一層增加了流控能力，保護了專線帶寬。在多云環(huán)境，業(yè)務通常會就近讀取，一定不會跨專線訪問Alluxio集群，所有跨云專線的流量只有從worker到UFS這一層，所以只需要在訪問UFS的地方加限流就可以控制住專線。而客戶端和S3Proxy的交互，以及S3Proxy與worker的交互都是同機房的一個流量，理論上也需要保護，但不影響專線。讀寫性能優(yōu)化：在讀性能優(yōu)化方面，通常是識別了讀的特征之后做預讀，通過預讀能夠明顯提升讀的性能，尤其是在冷讀數(shù)據(jù)的情況下。在Checkpoint寫方面，一定不能阻塞訓練，所以支持了WriteBack能力，WriteBack是指先異步寫到磁盤甚至內(nèi)存中，然后就可以開始后續(xù)訓練，通過后臺線程異步上傳。同樣也有一些線程模型的優(yōu)化，整體對讀寫的性能也有非常大的提升。四、未來規(guī)劃未來小紅書會把數(shù)據(jù)加速層做成什么樣子以及還有哪些待解決的問題呢？打造統(tǒng)一的多云數(shù)據(jù)存儲產(chǎn)品因為小紅書的數(shù)據(jù)存儲在多云里，業(yè)務需要關心數(shù)據(jù)到底在哪個云上，是不是會跨專線，到底要用哪個SDK去讀取，報錯了都是什么原因，該去找誰，業(yè)務感知的東西非常多。期望打造一個統(tǒng)一的多云數(shù)據(jù)存儲產(chǎn)品，讓業(yè)務方再也不需要在代碼中關注數(shù)據(jù)到底在哪里，專線能否控制好等問題。AI訓練：多地域GPU利用率提升在AI訓練場景，因為GPU眾所周知的供應問題，從各個廠商購買或租賃的GPU是分散在非常多的地域。這會造成一個非常嚴重的問題，有些地方有GPU，但沒數(shù)據(jù)，有些地方有數(shù)據(jù)，但沒有GPU，這會導致GPU的分配率不高。后面會探索如何基于Alluxio來提升GPU利用率，解決數(shù)據(jù)和GPU在不同地域如何充分利用GPU的問題。29大數(shù)據(jù)查詢加速大數(shù)據(jù)查詢加速在Alluxio社區(qū)里的案例非常多，但小紅書需要探索出一個如何在極低成本的情況下去實現(xiàn)大數(shù)據(jù)查詢的加速。同樣的查詢效率提升，需要增加的Alluxio的成本要小于直接擴容查詢引擎節(jié)點的成本才行。低效節(jié)點資源利用率提升現(xiàn)在Alluxio集群規(guī)模比較大，與此同時，CPU利用率是非常低的，每天平均大概3%的利用率，但磁盤容量和帶寬全是占滿的。如何將這些CPU去充分使用是一個非常大的問題，而公司出于成本考慮，也會要求這些低效節(jié)點能夠被充分利用，從而發(fā)揮更多價值。30知乎|AlluxioAI助力知乎千卡模型訓練一、混合云架構，帶來便捷與挑戰(zhàn)知乎目前是典型的混合云架構，數(shù)據(jù)和服務都分布在不同的機房：離線機房：專為滿足大數(shù)據(jù)相關業(yè)務方需求而設計的離線計算服務中心。其主要職能是部署離線調(diào)度、離線存儲以及調(diào)度平臺等服務。這些服務的目標是提供高效的離線數(shù)據(jù)處理和計算能力。在離線機房中，大數(shù)據(jù)業(yè)務方可以安心進行批量數(shù)據(jù)處理和計算任務，從而滿足他們對數(shù)據(jù)處理、存儲和調(diào)度的要求。在線機房：此機房專為知乎主站提供直接面向用戶的服務而設計。其中包括評論、回答、搜索、推薦等核心服務。在線機房的重點在于實時性和響應速度，以確保用戶能夠在最短的時間內(nèi)獲得穩(wěn)定、高效的服務體驗。知乎主站作為一個知識社區(qū)，其在線機房是為了保障用戶對知識和信息的交流與分享能夠得到優(yōu)質(zhì)、連續(xù)的支持。GPU機房：此機房專門用于部署機器學習平臺，主要服務于算法用戶。其主要特點是提供強大的GPU資源管理、模型訓練、數(shù)據(jù)集導入導出等一站式解決方案。GPU機房的核心任務是為算法用戶提供高性能計算資源，以滿足機器學習模型訓練和推理的要求。這樣的設計能夠使算法用戶更專注于模型的研發(fā)與優(yōu)化，而不必擔心計算資源的供給。31架構圖如下所示：混合云架構給知乎帶來了成本，容災等各方面的優(yōu)勢，但是也對存儲提出了新的挑戰(zhàn)。相比于數(shù)據(jù)都存在在單一機房，在混合云的架構下，算法平臺在調(diào)度訓練任務時，還需要額外考慮訪問存儲時，專線帶來的網(wǎng)絡延遲以及網(wǎng)絡吞吐的限制。二、知乎的探索歷程探索：知乎自研UnionStore聯(lián)合存儲為了解決模型訓練及模型分發(fā)場景跨云讀取數(shù)據(jù)的痛點，知乎在早期自研了一個緩存系統(tǒng)—UnionStore。顧名思義，UnionStore是聯(lián)合存儲的意思，它聯(lián)合了對象存儲與HDFS，利用對象存儲來對外提供本機房緩存。它支持對象存儲協(xié)議，這樣用戶可以使用AWSS3的SDK來訪問數(shù)據(jù)。UnionStore的緩存工作流程可描述如下：用戶在向UnionStore請求讀取文件時，會先檢查對象存儲上是否已經(jīng)有該文件了；32如果對象存儲已經(jīng)存在該文件，則直接從對象存儲讀取文件返回給用戶；如果對象存儲不存在該文件，UnionStore會先將離線HDFS上的文件上傳到在線機房的對象存儲上，再從對象存儲上讀取文件，返回給用戶，緩存期間用戶的請求是被卡住的。這里相當于是利用對象存儲做了一層跨機房緩存。挑戰(zhàn)：面對大語言模型訓練，UnionStore捉襟見肘UnionStore在知乎運行了兩年，期間沒有出現(xiàn)任何問題，但是隨著2023年知乎開始布局大語言模型，UnionStore在面對大語言模型訓練時，有些捉襟見肘：1.沒有元數(shù)據(jù)緩存，元數(shù)據(jù)強依賴HDFS與對象存儲，特別是對象存儲，元數(shù)據(jù)訪問和首字節(jié)延遲在幾十毫秒，而大語言模型在進行訓練，讀取語料時，往往都是隨機讀取，對吞吐要求低，但是對時延敏感，而UnionStore只能從對象存儲隨機讀取數(shù)據(jù)，延遲極高；2.訓練任務在啟動時需要讀取模型的checkpoint，大語言模型的checkpoint動輒上百GB，而對象存儲單線程的讀取性能只有10-100MB/sec，盡管UnionStore也做了一些加速手段，但是也只能加速到200-300MB/sec的速度，遠遠不能滿足大模型的checkpoint讀取需求；3.對象存儲能力有上限，在模型分發(fā)時，往往單文件會有上百，甚至上千并發(fā)同時讀取，對象存儲容易面臨性能瓶頸和帶寬限制；4.無法做到邊緩存邊返回文件，導致首次讀取文件的時間偏長，這也會影響大模型checkpoint的讀取速度。以上痛點使得知乎面臨兩個選擇：一是繼續(xù)迭代UnionStore，讓UnionStore具備高性能緩存能力，比如支持本地SSD以及內(nèi)存緩存；二是尋找合適的開源解決方案，完美替代UnionStore的使用場景。基于人力資源的寶貴，選擇了其二。探索：社區(qū)版Alluxio調(diào)研上線從UnionStore的使用場景來看，知乎需要的AI存儲必須滿足以下幾個需求：33協(xié)議兼容：必須要具有對象存儲協(xié)議和POSIX協(xié)議，目前知乎的模型分發(fā)場景使用的是UnionStore的對象存儲協(xié)議，模型訓練場景使用的是UnionStore+S3FS-FUSE來提供POSIX協(xié)議。性能優(yōu)秀：選擇替換UnionStore的最重要的原因就是對象存儲的性能和延遲遠遠不能滿足算法業(yè)務的需求，所以知乎需要的AI存儲必須要有足夠優(yōu)秀的性能；透明緩存：因為目前知乎的數(shù)據(jù)都是存放在HDFS上，不希望用戶在接入新存儲的時候，需要對訪問數(shù)據(jù)的路徑做比較大的修改，最好是路徑能夠與HDFS一一對應，有透明緩存的能力，這樣能夠最大程度上減少業(yè)務方的改造工作?；谝陨闲枨螅{(diào)研了市面上大多數(shù)的存儲，發(fā)現(xiàn)只有Alluxio能夠滿足需求，嚴格意義上來說，Alluxio并不是一個標準的存儲，它是一個多功能低侵入的高性能緩存，它的一些能力能夠很好地滿足需求：透明緩存：相較于其他文件系統(tǒng)，Alluxio可僅作為緩存使用，用于編排數(shù)據(jù)，業(yè)務方無需將模型文件寫入到其他的文件系統(tǒng)，只需要維持現(xiàn)狀，寫入HDFS即可；元數(shù)據(jù)與數(shù)據(jù)緩存：Alluxio支持自定義緩存元數(shù)據(jù)與數(shù)據(jù)，這樣在讀取已緩存文件時，可完全不受HDFS影響；目前知乎UnionStore的QPS大約在20K-30K，緩存元數(shù)據(jù)可極大降低NameNode的壓力，反哺離線場景；豐富的UFS支持：支持除HDFS外的多種UFS，比如對象存儲，在未來可能對數(shù)據(jù)湖場景也可以提供強有力的支撐；即席查詢加速：知乎Adhoc引擎采用的是Spark與Presto，Alluxio對這兩個引擎都有較好的支持；訪問接口豐富：Alluxio提供的S3Proxy組件完全兼容S3協(xié)議，模型上線場景從UnionStore遷移至Alluxio付出的成本幾乎可忽略不計；另外Alluxio提供的AlluxioFuse也具備本地元數(shù)據(jù)緩存與數(shù)據(jù)緩存，比業(yè)務之前使用的S3FS-FUSE具有更好的性能，正好能滿足模型訓練場景。34此外知乎對Alluxio進行了一些性能上的測試，AlluxioFuse的單線程順序讀取速度能夠達到500+MB/sec，AlluxioS3Proxy的單線程順序讀取性能能夠達到1GB/sec以上，這個性能完全能夠滿足需求場景。上線的過程比較順利，幾乎是無感遷移，在短短三個月內(nèi)就將UnionStore完全替換成了Alluxio，并且拿到了不錯的收益：模型分發(fā)的速度得到了2-3倍的提升；訓練任務等待數(shù)據(jù)的延遲幾乎消失，訓練時長降低至原來的40%。挑戰(zhàn)：任務規(guī)模擴大，社區(qū)版難以為繼隨著訓練任務的規(guī)模不斷擴大，也發(fā)現(xiàn)了Alluxio社區(qū)版中存在的各種問題?？偨Y起來可以描述如下：Fuse穩(wěn)定性問題：社區(qū)版AlluxioFuse會經(jīng)常出現(xiàn)OOM相關的故障，經(jīng)常導致訓練任務失敗重啟；Master元數(shù)據(jù)性能瓶頸：社區(qū)版的AlluxioMaster是一個單點的服務，在緩存文件增加的情況下，會遇到性能瓶頸，并且無法擴展；寫場景性能不足：社區(qū)版的Alluxio同步寫入UFS時，性能較差，不能滿足業(yè)務做checkpoint的需求；高昂的運維成本：社區(qū)版的Alluxio部署，需要自己打鏡像，以及寫k8s的yaml文件進行部署，沒有operator相關的運維工具。以上問題在社區(qū)版需要投入極大的人力和精力來修復和維護，并且需要一個比較長的周期，而此時知乎的算法業(yè)務發(fā)展的勢頭很猛，根本等不及。正好聽說Alluxio也在企業(yè)版重構了他們的架構，在提升性能的同時，也修復了很多社區(qū)版已存在的問題。于是正式開啟的Alluxio企業(yè)版的調(diào)研與試用。探索：Alluxio企業(yè)版攻克四大問題1.AlluxioFuse穩(wěn)定性問題首先是AlluxioFuse穩(wěn)定性的問題，F(xiàn)use在長時間運行后，很容易出現(xiàn)OOM相關的故障，如下圖所示：35這是知乎真實生產(chǎn)環(huán)境中AlluxioFuse的重啟監(jiān)控，可以看到Fuse的重啟十分頻繁，幾乎每隔幾小時就有一次。一旦Fuse重啟，訓練任務就會因讀取數(shù)據(jù)錯誤而失敗，需要從上一次checkpoint開始訓練，這就導致了無效訓練，會浪費相當多的GPU算力。在社區(qū)版中，定位到問題來自AlluxioFuse的native內(nèi)存泄露。社區(qū)版的Alluxio使用GRPC傳輸數(shù)據(jù)，在遇到問題時，AlluxioFuse對于GRPC的處理不太優(yōu)雅，導致了native內(nèi)存泄露。企業(yè)版數(shù)據(jù)傳輸用Netty全部重寫了，不僅避免了使用GRPC，也具有更好性能，相當于曲線救國了。下圖是使用企業(yè)版時，AlluxioFuse的重啟監(jiān)控：可以看到企業(yè)版的AlluxioFuse幾乎沒有出現(xiàn)重啟的現(xiàn)象。36此外，由于AlluxioWorker在知乎是和和GPU節(jié)點綁定部署的，而GPU節(jié)點的機器故障率比較高，也造成了AlluxioWorker的故障率偏高。在這種情況下，企業(yè)版支持在某臺AlluxioWorker出現(xiàn)問題時，重試到其他的Worker讀取數(shù)據(jù)，或者是直接從UFS讀取數(shù)據(jù)，這也提高了AlluxioFuse的穩(wěn)定性。Alluxio企業(yè)版自上線以來，一共完成了300+訓練任務，包括知乎最重要的千卡大模型訓練任務，訓練期間沒有因為Fuse的穩(wěn)定性導致訓練任務重啟，相比于社區(qū)版，企業(yè)版極大減少了無效訓練的出現(xiàn)。2.AlluxioMaster元數(shù)據(jù)問題AlluxioMaster是Alluxio社區(qū)版中一個比較明顯的瓶頸：雖然AlluxioMaster支持HA，但是對外提供服務的Master只有一個，有單點性能問題，Master在3億元數(shù)據(jù)下可以相對穩(wěn)定運行，但是超過3億就需要進行調(diào)優(yōu)，需要有豐富的經(jīng)驗；隨著元數(shù)據(jù)增多，占用的內(nèi)存也會變高，而內(nèi)存在單節(jié)點上總是有上限的，不可能無限擴展；在metadatasync比較頻繁的時候，較小的元數(shù)據(jù)量也會出現(xiàn)比較嚴重的鎖競爭問題，導致Master卡住。37在2023年，因為Master的性能問題，出現(xiàn)過幾次比較嚴重的故障，多虧及時搶修（手動切主+重啟），才沒有造成比較大的損失。Alluxio的企業(yè)版對整個Alluxio集群架構進行了重構，不再使用Master管理元數(shù)據(jù)，而是將元數(shù)據(jù)用一致性Hash打散到每一臺Worker，理論上集群越大，可管理的元數(shù)據(jù)越多，元數(shù)據(jù)的規(guī)模隨著Worker的增長可以達到近乎無限的擴展。由于元數(shù)據(jù)分散到不同的Worker，元數(shù)據(jù)請求的QPS也能隨著Worker數(shù)量的增加，得到線性增長。這里需要注意的是，Alluxio企業(yè)版引入了一個輕量的服務發(fā)現(xiàn)組件，目前是基于ETCD實現(xiàn)的，用于存放Worker列表。3.寫場景需求寫場景的需求主要體現(xiàn)在模型訓練時做checkpoint。38在訓練過程中，往往會因為一些意外導致訓練任務失敗，比如機器故障，GPU卡之間的通信故障等。而大型訓練任務往往都是持續(xù)好幾個月的，在訓練過程中出問題的概率接近100%，為了避免在訓練任務失敗時從零開始訓練，訓練任務就需要在訓練的過程中定期做checkpoint，這樣任務失敗了就可以從上一次checkpoint恢復，而不必從頭開始整個訓練。做checkpoint越頻繁，每次訓練任務重啟時，損失的訓練時長就越短。但是對于一個大型訓練而言，checkpoint的大小往往在數(shù)百GB，保存并持久化巨大的checkpoint文件也會花費比較長的時間。訓練任務在做checkpoint的時候，整個訓練任務是停止的，GPU處于等待狀態(tài)。也就是說，如果想用Alluxio保存checkpoint，Alluxio必須要有一個比較好的寫入性能，否則會造成GPU利用率不足。在Alluxio社區(qū)版時，采用的是同步寫模式寫入數(shù)據(jù)，直接穿透寫到UFS上，只能達到200MB/sec的速度，與HDFS單線程寫入的速度接近。假如以這個速度，每隔3小時做200GB的checkpoint，每天光是花費在做checkpoint上的時間就達到了120+分鐘，占到全天時長的8%，也就相當于GPU利用率直接降低了8%，很明顯這個速度是不能滿足需求的。Alluxio企業(yè)版支持了更高的寫入性能，在測試中，單線程同步寫入HDFS能達到1.2-1.4GB/sec的速度，如果還是按照每隔3小時做200GB的checkpoint來算，每天花費的時間將減少至20分鐘，只占到全天時長的1.4%，這能夠大大減少模型訓練做checkpoint的時長，提高GPU利用率。目前Alluxio寫入的上線正在內(nèi)部測試，還沒有正式上線。除了同步寫入，后續(xù)知乎還計劃上線企業(yè)版的異步寫功能，在提升寫入性能的同時，節(jié)省專線帶寬。4.運維成本在社區(qū)版時，需要自己打包Alluxio的鏡像，并且自己寫yaml文件將Alluxio部署到k8s上，上線的流程十分復雜，有很多步驟需要手動操作，費時費力，還容易出錯，下圖是部署社區(qū)版所使用的腳本和配置文件的集合，可以看到一共有十幾個文件。39Alluxio企業(yè)版不僅提供了現(xiàn)成的k8s鏡像，還提供了operator部署工具，可以一鍵啟動集群，在operator安裝好的情況下，部署一個Alluxio集群只需要一個配置文件，極大節(jié)省了我們的運維成本。三、持續(xù)合作，保持探索首先，Alluxio社區(qū)版為知乎帶來了混合云下AI存儲的通用解決方案，能夠在短時間內(nèi)從自研組件無縫切換到Alluxio高性能緩存上，支持實現(xiàn)跨云訓練；其次，在更加核心的場景下，Alluxio企業(yè)版帶來了更高的穩(wěn)定性，更好的性能，更便捷的運維，更是支持了知乎內(nèi)部千卡大模型的訓練穩(wěn)定高效運行。感謝Alluxio團隊在上線過程中提供的幫助，后續(xù)也將繼續(xù)保持合作，共同深入挖掘Alluxio的潛力，探索更多的應用場景，為知乎的技術發(fā)展貢獻更多的力量。40B站|Alluxio在B站AI訓練場景的應用一、B站AI的訓練場景機器學習平臺介紹首先，簡單介紹一下B站AI的訓練場景，整個機器學習平臺的架構如下圖所示：它具備了一個常規(guī)機器學習平臺的能力，比如交互式建模、數(shù)據(jù)集管理、模型訓練、模型部署等基礎能力，用戶也會有一些精確的數(shù)據(jù)集、業(yè)務團隊以及資源運營相關的能力，同時對機器學習框架（比如業(yè)界流行的TensorFlow、PyTorch、DeepSeed以及自研的一些框架等）都需要兼容。同時，為了加速整個訓練的收益，B站與Alluxio進行了很多合作，搭建了一個在AI訓練場景的訓練集群，調(diào)度器主要是Volcano，是現(xiàn)在機器學習平臺常用的。已有存儲方案介紹下圖是搭建Alluxio之前的存儲方案，HDFS主要針對大數(shù)據(jù)的分析場景，B站自研的OSS存儲叫BOSS，還有一些NAS存儲的系統(tǒng)，當然每個存儲系統(tǒng)都有自己的優(yōu)缺點，這里也簡單的做了個對比。41AI訓練場景介紹1.搜推一個是搜推，比如商業(yè)、廣告、流量推薦，這種場景就是很明顯的大數(shù)據(jù)存儲的場景，跟HDFS這一套就非常的親和。422.CV/大模型場景這個場景也是目前使用Alluxio的一個主要業(yè)務場景，這里有一個特點，單數(shù)據(jù)集的規(guī)模很大，比如最近在用的一個數(shù)據(jù)集，已經(jīng)達到了PB級，文件數(shù)量大概在億級別，基本都是小文件。CV訓練以圖片、音頻等為主，基本都是100KB、1M大小，數(shù)據(jù)比較多樣，有圖片、視頻、音頻、文本等。AI訓練存儲痛點在訓練過程中發(fā)現(xiàn)了幾個存儲方面的痛點：1.存儲容量：因為現(xiàn)在隨著大模型的引入，數(shù)據(jù)量會越來越大，對數(shù)據(jù)容量的要求會越來越高，像現(xiàn)在大數(shù)據(jù)集，可能會達到上百T；43這是一個快速增長的過程，而且特別是最近的Sora帶火了TTV這種場景，所以視頻的規(guī)模會非常大，存儲系統(tǒng)需要具備高擴展性以應對不斷增加的數(shù)據(jù)需求。2.性能瓶頸：高吞吐：AI訓練需要頻繁讀取和寫入數(shù)據(jù)，存儲系統(tǒng)需要支持高吞吐量以保證數(shù)據(jù)加載速度低延遲：數(shù)據(jù)讀取的延遲應盡可能低，否則會影響訓練效率，導致GPU/NPU等計算資源的浪費。正如大家所熟知的，現(xiàn)在買卡非常難，如果GPU由于IO導致利用率低，那肯定是不劃算的3.成本、安全：高成本：存儲大量數(shù)據(jù)尤其是高分辨率圖像和視頻數(shù)據(jù)，存儲成本很高，需要平衡性能和成訪問控制：需要對數(shù)據(jù)訪問進行細粒度的權限管理，確保數(shù)據(jù)安全?；贏lluxio的訓練存儲架構44為了解決這些痛點，在調(diào)研之后，采用了Alluxio的方案，主要有三大吸引點：統(tǒng)一命名空間：將不同存儲系統(tǒng)（如HDFS、BOSS、云存儲）抽象為一個統(tǒng)一文件系統(tǒng)接口，對用戶來說不用感知底層的HDFS，只需要掛Fuse；內(nèi)存或NVMe緩存：結合內(nèi)存和NVMe存儲緩存，提升訪問速度，降低I/O延遲，用的比較多的是NVMe的場景，大量GPU都會高配這種NVMe；多存儲后端：兼容HDFS、對象存儲等多種存儲后端，擴展性強。二、Alluxio在AI訓練場景的應用為什么選擇Alluxio？這里先介紹一下Alluxio的主要優(yōu)勢：性能高：低延遲高吞吐的數(shù)據(jù)緩存能力，對于AI訓練尤其重要；兼容性強：支持S3/HDFS后端，提供了廣泛的數(shù)據(jù)源兼容性；兼容POSIX協(xié)議；運維成本低：運維成本在大規(guī)模數(shù)據(jù)存儲和處理環(huán)境中尤為重要，有助于減少整體運維投入；大規(guī)模數(shù)據(jù)處理：Alluxio支持億級的數(shù)據(jù)量規(guī)模，能滿足AI訓練需求。45在做技術選型的時候，也對業(yè)界常用的幾個系統(tǒng)做了調(diào)研和分析，基于B站的體量，B站沒有人力單獨為AI做存儲的維護，所以第一個優(yōu)先考慮的就是成本，需要投入更低的成本、更低的運維，支持更強的性能。在調(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，很容易碰到天花板，擴展性比較有限，如果單個集群出現(xiàn)了問題，對業(yè)務的影響是比較大的，所以在AI場景最終采用的是多集群部署的方案。46基于整個集群的存儲規(guī)模，集群的劃分會按照業(yè)務或者是數(shù)據(jù)集，好處是某個業(yè)務或者數(shù)據(jù)集需要更強的能力，則會投入更多的資源，而對于那些不怎么重要的業(yè)務，或者是低優(yōu)先級的業(yè)務，則需要把它隔離開，從而不至于讓低優(yōu)先級的業(yè)務影響到高優(yōu)先級的業(yè)務，這是最終采用的方式。通過多集群的方式，在部署運維方面會增加更多的成本，那么如何解決這個問題？基于Fluid的云原生多集群部署方案這里引入了Fluid。Alluxio是對底層存儲的抽象，F(xiàn)luid又是對Alluxio這一層Runtime的抽象。通過Fluid之后，可以更好的在K8s上，更自動化的部署多集群的方案，目前B站應該有百機規(guī)模的集群。47調(diào)度優(yōu)化另一個問題是，在實際應用中使用的是volcano調(diào)度器，主要是binpack為主，binpack的策略是盡可能的把單臺機器塞滿，對IO密集型的業(yè)務，如果把所有的節(jié)點都調(diào)度到單臺機器上，很容易造成單點故障，給IO造成瓶頸，另外也會帶來網(wǎng)絡擁塞、資源利用不均等問題。解決辦法：結合了業(yè)務特點以及本身的緩存加速場景，采用的是拓撲感知的調(diào)度策略。首先，會盡可能的讓Alluxio的節(jié)點分散到集群的每臺機器上，盡可能的把IO打散。其次，在任務調(diào)度的時候，也會去感知Alluxio的拓撲分布，盡可能做到任務與Alluxio節(jié)點的親和，這樣親和之后相當于在讀本地硬盤。48元數(shù)據(jù)同步加速元數(shù)據(jù)同步的必要性:元數(shù)據(jù)同步在Alluxio中至關重要，因為它確保Alluxio文件系統(tǒng)與底層存儲系統(tǒng)中的數(shù)據(jù)保持一致，這個問題B站也同樣遇到過。當數(shù)據(jù)量大了之后，如果按照官方的元數(shù)據(jù)同步方法，對整個集群的穩(wěn)定性和性能都會有很大的影響，所以最終采取了一種按需同步的方法。這里已經(jīng)把集群暴露給用戶，他可以直接操作他的集群，知道什么時候數(shù)據(jù)是更新的，由他來決定；另外，如果是那種億級別的數(shù)據(jù)集要做Meta同步，至少是小時級別，這個肯定是不可接受的，所以也在要求用戶最小化他的同步單元，盡可能的減少無效的同步計算。具體同步方式:基于時間的自動同步：設置erval屬性來定時同步；手動同步：使用loadMetadata命令或API手動觸發(fā)同步。49加速方式：按需同步：只在需要時觸發(fā)；最小范圍同步：最小范圍同步，減少無效同步計算。超大規(guī)模小文件優(yōu)化很多場景的數(shù)據(jù)都是以小數(shù)據(jù)為主，如果只是簡單的把數(shù)據(jù)給到Alluxio，然后什么都不做，這樣就會有兩個問題，一個是Meta會很多，本身B站采用的就是Master的架構，整個集群對Master的壓力會很大；另一個就是用戶會無組織的去用，因為他根本就不知道該做哪些組織才有利于數(shù)據(jù)的IO。這塊主要是做了數(shù)據(jù)合并，也是在訓練場景用的比較多的一種方式，把一個圖片做成一個chunk，chunk里邊再做一個下浮，可以做到指數(shù)級的降低文件的Meta信息，并對整個訓練的效果都不會有太大的影響。50Alluxio帶來的效益在實際應用過程中測下來，億級別的單節(jié)點性能基本能達到IOPS在3000+以上，整個業(yè)務包括審核、大模型，都在用這一套，現(xiàn)在已經(jīng)緩存的數(shù)據(jù)集大概在幾百T規(guī)模左右。三、未來規(guī)劃Alluxio之前介紹過知乎的推理場景，這個場景B站也有比較大的痛點，所以B站也在嘗試探索更多的可能。另外就是現(xiàn)在Master元數(shù)據(jù)管理是一個很痛的點，在這種場景下Alluxio最新的Dora框架可以帶來多大的收益，也是需要進一步去調(diào)研的，同時，因為是一個機器學習平臺，應用場景非常單一，同時也在跟B站的存儲專業(yè)團隊做一個更大規(guī)模、更通用的Alluxio解決方案，這是現(xiàn)在在做的，也是后續(xù)打算去推的。51輝羲智能|Alluxio在自動駕駛模型訓練中的應用與部署一、自動駕駛數(shù)據(jù)閉環(huán)首先分享一下自動駕駛中怎么樣構建數(shù)據(jù)閉環(huán)，這個業(yè)務過程可能大家都有所了解。自動駕駛會包含多種車輛類型，比如數(shù)采車輛、帶著算法在路上跑的車。數(shù)據(jù)采集就是在跑的過程中采自動駕駛車上的各種數(shù)據(jù)：比如說camera的數(shù)據(jù)就是圖片，激光雷達的數(shù)據(jù)是點云。傳感器數(shù)據(jù)采回來，可能一輛車每天跑下來就有幾T的數(shù)據(jù)。這種數(shù)據(jù)通過基盤的方式或者其他上傳方式把它們整體存儲起來，傳到對象存儲里面。原始數(shù)據(jù)存儲之后會有一個pipeline做數(shù)據(jù)的解析預處理，比如把它切成一幀一幀的數(shù)據(jù)幀，每幀的不同傳感器數(shù)據(jù)之間可能還要做同步對齊的操作。52完成數(shù)據(jù)解析之后，就要在上面做更多的挖掘。構建一個一個的數(shù)據(jù)集。因為不管是在算法、仿真或者測試里面，都要構建數(shù)據(jù)集。比如想要雨天的某一個晚上，某一個路口，或者一些密集形成區(qū)域的數(shù)據(jù)，那就會在整個系統(tǒng)里面有大量的這種數(shù)據(jù)需求，要做數(shù)據(jù)的打標，打上一些標簽。比如說在清華東門這個地方，需要去拿這個位置的經(jīng)緯度，解析周圍的POI。之后再對挖掘出來的數(shù)據(jù)做標注。常見的標注有：對象、行人、對象的類型等。這種做了標注的數(shù)據(jù)，會被拿去做訓練。典型的一些任務，比如目標的檢測、車道線的檢測、或者更大的端到端的模型。模型訓練好了之后，還要做一些仿真驗證。驗證完再把它部署到車上面，再去跑數(shù)據(jù)，在這個基礎上再去采更多的數(shù)據(jù)。就是這樣的一個循環(huán)，不斷的去豐富數(shù)據(jù)，不斷的去構建性能更好的模型。這是整個訓練，數(shù)據(jù)閉環(huán)要做的事情，也是現(xiàn)在自動駕駛研發(fā)里面較核心的事情。二、算法訓練：NAS聚焦到模型訓練來講：模型訓練主要是通過數(shù)據(jù)挖掘拿到數(shù)據(jù)，從而生成一個數(shù)據(jù)集。數(shù)據(jù)集在內(nèi)部是一個pkl文件，包含數(shù)據(jù)、channel、存儲位置，最后數(shù)據(jù)算法訓練的同學會自己寫下載腳本，把數(shù)據(jù)從對象存儲拉到本地。53在選用Alluxio之前，是通過NAS系統(tǒng)充當緩存的作用，把對象存儲的數(shù)據(jù)拉到NAS上面，最后再用不同的模型，把數(shù)據(jù)load進來進行訓練。這是使用Alluxio之前，大概的訓練流程。其中最大的問題在NAS：1.第一是并發(fā)性能比較差——NAS可以理解