《Alluxio：2024年Alluxio助力AI模型訓練加速寶典2.0（實戰篇）（80頁）.pdf》由會員分享，可在線閱讀，更多相關《Alluxio：2024年Alluxio助力AI模型訓練加速寶典2.0（實戰篇）（80頁）.pdf（80頁珍藏版）》請在三個皮匠報告上搜索。

1、引言背景&Alluxio賦能AI場景小紅書|加速云端機器學習-Alluxio在小紅書的實踐一、面臨的挑戰二、多云數據加速層三、小紅書實踐案例四、未來規劃知乎|Alluxio AI助力知乎千卡模型訓練一、混合云架構，帶來便捷與挑戰二、知乎的探索歷程三、持續合作，保持探索B站|Alluxio 在B站AI訓練場景的應用一、B站AI的訓練場景二、Alluxio 在 AI 訓練場景的應用三、未來規劃輝羲智能|Alluxio在自動駕駛模型訓練中的應用與部署一、自動駕駛數據閉環二、算法訓練：NAS三、算法訓練引入 Alluxio四、Alluxio 部署：單機房01目錄15050315161829313132

2、40414152525145535556五、Alluxio 部署：跨機房六、Alluxio 測試：功能七、Alluxio 測試：性能八、Alluxio 落地：調參適配環境九、Alluxio 落地：運維十、Alluxio 落地：共同進步十一、小結中汽創智|Alluxio在自動駕駛數據閉環中的應用一、自動駕駛業務介紹二、數據平臺架構以及存儲選型三、自動駕駛數據平臺使用場景四、未來規劃關于Alluxio02目錄575859606162636565677078在當今這個人工智能飛速發展的時代，諸多企業正站在一個充滿挑戰與機遇的路口。隨著AI模型訓練的熱潮不斷升溫，企業在追求更高性能計算的同時，也不得不

3、面對GPU資源緊張、模型部署緩慢以及存儲成本失控等問題。這些問題不僅加劇了技術團隊的工作壓力，也對企業的業務發展和市場競爭力構成了嚴峻考驗。本電子書將深入剖析Alluxio如何在AI/ML場景中發揮其分布式緩存的作用，助力企業突破IO瓶頸。Alluxio作為一個高效的數據訪問層，優化了數據在存儲與計算引擎間的流動，顯著提升了數據訪問速度和操作便捷性。文章詳盡地列舉了企業在探索AI過程中遇到的挑戰，細致闡釋了Alluxio在技術架構中的關鍵角色，以及其如何通過優化AI框架的IO性能，提升整體數據處理能力。同時，文中通過小紅書、知乎、B站、輝羲智能以及中汽創智等知名企業的實戰案例，生動展示了All

4、uxio如何助力企業在解決技術難題的同時，實現更快的模型開發周期、更及時的數據更新、更高的模型準確性和可追溯性，以及更好地適應數據集的迅猛增長。本電子書將幫助用戶迅速把握Alluxio如何助力企業應對AI模型訓練的多重挑戰，捕捉行業發展的脈搏，實現技術上的飛躍和業務上的持續增長。引言03用戶收益實戰經驗借鑒：通過小紅書、B站、知乎、輝羲智能等企業案例，了解如何將Alluxio應用于實際場景，解決具體的業務挑戰。1.多云架構優化：了解如何在多云環境中利用Alluxio實現數據的高效管理和訪問，從而優化多云架構下的數據使用和存儲成本。2.性能與成本的雙重優化：掌握如何通過Alluxio提升數據處理

5、性能，同時實現成本優化。3.前沿技術洞察：獲得對未來技術發展趨勢的洞察，為技術選型和業務布局提供參考。4.靈活性與擴展性實踐：了解Alluxio如何支持不同技術棧和框架，增強現有系統的靈活性和擴展性，以適應不斷變化的技術需求。5.適用人群數據科學家與機器學習工程師、AI研發團隊、技術架構師、基礎設施團隊、技術平臺團隊、云計算與存儲團隊、IT運維與系統管理員、業務分析師與決策者、學術研究人員、技術愛好者、產品經理、行業解決方案顧問04一、企業在嘗試AI時面臨的挑戰1.GPU短缺其實從幾年前就已經呈現了一些趨勢，不管是在云上使用GPU還是自己購買GPU搭建IDC（數據倉庫），AI基礎設施都比較困難

6、，原因大概可以分為3種情況：很多公司無法買到GPU；部分公司即使買到了GPU，量也不是很大，很難滿足業務需求；部分公司或許可以在阿里云或者騰訊云上買到GPU，但如何把這些GPU形成一個系統的計算池，供上層業務使用，是比較困難的。2.模型上線慢公司現有數倉/存儲方案較陳舊，很難迭代，進行GPU訓練后，如何把模型上線到推理的集群中，是必不可少的一個環節，也是困難重重的一個環節：很多數倉、底層的存儲都還是公司里比較傳統的存儲方案，比如HDFS，可能十幾年前就開始用了，現在很難調整存儲的設置；數據在云上，限流情況嚴重，使用限制較多。后面也會深入聊一下，如何解決這個問題。3.GPU使用率低現在很多公司模

7、型訓練過程GPU利用率普遍比較低，當然這個不是Alluxio一家就能解決的問題，普遍現象是：企業的數據大多在數倉中，這些數據如何引入GPU集群，存在非常多的挑戰。后文也會分享在不同云廠商、國內外的大型企業中，Alluxio是如何解決這一問題的：背景&Alluxio賦能AI場景05前面所提到的更多都是業務的壓力或者是商業上業務決策的壓力，這些壓力反映到基礎上對工程人員來說就會變成技術壓力，為了能夠更快進行模型開發，Alluxio其實是有一些期望的：更快的模型開發時間；更頻繁的模型數據更新；更高的準確性和可追溯性；適應快速增長的數據集。這些壓力反映到技術側大概可以概括為3點：1.廣泛的數據拷貝任務

8、管理比如以現在的應用，如何做這套系統，很多時候需要進行一些復雜的數據拷貝任務，從數據倉庫往GPU的訓練集群中進行數據拷貝，無論是拷貝到本地的NAS、NFS系統，或者是拷貝到本地的磁盤中進行數據管理，都是比較復雜的2.專用存儲為了滿足AI場景的需求，對性能的要求會比較高，可以這么理解：20-30年前，GPU是和HPC（高性能計算）一起發展起來的，所以那時候大家普遍傾向于要有一套IB的網絡，并且是有一套高性能存儲（全閃）支撐業務的發展，其實現在在云上或者是IDC里，這個問題是非常難解決的，因為大部分公司/云上設施沒有辦法提供這么高的專用存儲支持模型訓練或者是模型分發的任務。063.云和基礎設施成本

9、失控模型上線以后，隨著業務規模的增長，云和基礎設施的成本是非常容易失控的，可以看到非常多的場景，比如3年增加5倍的云上成本都是很正常的。二、Alluxio在技術棧中的位置在進入詳細技術討論之前，再系統介紹一下Alluxio在AI/ML技術棧中的位置。07首先，Alluxio不是一個持久化的存儲層，持久化存儲比較依賴云上S3 Storage、Ceph或者是HDFS這種分布式存儲，這些都是Alluxio下面的一個接口，和Alluxio不是同一個概念。再往上，Alluxio在AI領域是一個高性能的接入層，因為對于持久化存儲層來講，大部分公司追求的是價格和性能效率，而這個效率就意味著要有一個非常便宜的

10、存儲池，可以存儲很多資源，并不期望有一套非常昂貴的高性能存儲來做持久化存儲，之所以會這樣是因為很多互聯網廠商或者是傳統企業的數據量有幾百個PB甚至是EB級別的，但同時需要訓練的數據并沒有那么多，可能就是幾十個TB，甚至高一點的也就1PB左右，如果可以把這些數據放到一個高性能存儲向上進行對接，對用戶來說這個性價比是非常低的，所以Alluxio比較依賴這種持久化存儲層進行非常簡單的對接，或者現在已經有了持久化存儲層，不改變它的架構，可以直接進行數據對接。08再往上，Alluxio對Pytorch、TensorFlow的IO性能做了非常多優化，包括緩存策略、調度的優化/如何與它對接、Kubernet

11、es的部署等。再往上就是Ray或者是MLFlow這種AI/ML的編排層。Alluxio是一個從大數據場景發展起來的公司，在這波AICG浪潮中逐漸被用戶轉移使用場景到支持AI/ML的workload，從使用Alluxio的客戶/用戶環境中總結的價值是有非常多的，大概可以概括成4點：1.更高性能、可擴展的AI/ML管道Alluxio不改變現有的集群部署，比如已有的對象存儲、HDFS等，同時又想擴展業務，這里其實有兩個關鍵點：一般大數據和AI兩個Team雖然在一個大的架構下，但其實技術棧是非常不同的，比如大數據技術棧會有Spark、Trino、Hive、HBase等，向下對接的是HDFS、云上的一些

12、對象存儲等，這些數據是一直在的，數據量可能有幾百個PB甚至EB級別的，同時需要搭建一個AI Infra的平臺，AI技術棧其實是Pytorch、TensorFlow，下面對接比較多的是對象存儲，比如Ceph、MinIO等，其它的會有一些專用存儲，比如提供NFS、NAS的這些系統向上對接；其實這兩個系統的存在就產生了對接的問題，就是數據在數倉中，但是處理是到AI Infra里，這就變成一套非常復雜的系統了，而Alluxio可以幫助打通這套系統，不需要每次都進行非常復雜的數據遷移。2.隨時獲取及時、準確的模型數據模型的數據從訓練集群出來，需要先落到存儲中，然后再向上拉取到推理集群，這個過程很多時候是

13、非常復雜的，比如Data Pipeline，之前遇到很多互聯網公司都有一個臨時的checkpoint store，然后還有一個持久化的checkpoint store，他們進行低性能和高性能的互相拉取是一個非常復雜的過程。3.避免復雜的數據遷移4.模型上線時間相比對象存儲與傳統數倉快2-4倍09底層存儲一般都是對象存儲或者是傳統HDFS，比如傳統的HDFS大家都是給大量數據存儲設計的，這個不是為了性能而設計的，大部分情況是為了保障容錯，同時針對云上的存儲，在跟諸多云廠商交流后了解到，他們很多情況下沒辦法直接在云上用對象存儲支持AI的業務，原因在于限流的問題，拉取數據的速度很快，所以沒辦法處理。

14、下面詳細介紹Alluxio是如何做這套系統的，里面有很多場景的沉淀，此處分享一下Alluxio架構設計的初衷：首先在很多互聯網廠商群體中，大部分的客戶/用戶，他們的數據大概率是在數據湖中（有90-95%），他們的數據并不是以一個單獨的數據集群來做這個事，而是有非常多的數據，包括傳統的Hive Meta store、現在比較流行的數據湖里的數據，同時還有很多Streaming Data的數據直接進來，也有很多非結構化的數據是放在數據湖里的。那么Alluxio是如何在其中發揮作用的呢？現在比較流行的就是用Spark或者Ray的架構，把這個數據預處理完，放回數據湖中，后面的TensorFlow、Py

15、torch會拉取這里的數據進行訓練，比如看左邊這個圖，如果不用Alluxio拉取數據會產生什么問題呢？比如原來的數倉用的是HDFS集群，AI訓練會用一個Ceph的集群：10首先要把處理好/未處理好的數據拉到Ceph的集群中，再向上serving這些拉取的data，在這里就會出現一些問題：首先這套拉取的流程會非常復雜，很多公司會自己開發一套數據管理系統完成，會有幾套不同的流程在里邊，比如用meta store對應這些表/數據在哪里；其次需要增量的拉取數據；最后需要對數據進行檢驗，查看是否有問題。這套流程下來從拉取到可用有很長的延遲，而Alluxio緩存的功能幫助大家解決這個問題。首先可以預先將部

16、分數據加載到 Alluxio 中，放到更靠近計算的存儲中，從而降低帶寬消耗。同時，即使沒有預加載數據，Alluxio 的緩存機制也能幫助快速拉取數據到訓練集群中。這種方式類似于股票交易中的 T+1（T+0）交易，即從一開始訪問數據的瞬間，數據就可以被迅速提供，不需要等待數小時再傳遞數據上去，從而節省了大量時間。其次，Alluxio 還能減少用戶自行開發而產生的數據治理問題。如果用戶已經有一套數據治理系統，Alluxio也提供了多種 API，包括原始數據更新的 API，方便用戶進行定制化開發。此外，Alluxio還著重關注：在訓練集群上如何降低成本并提高效率。過去很多公司使用高性能的存儲集群進行

17、訓練，但這種成本可能非常昂貴，限制了業務的擴展。如果僅在 GPU 計算節點上配備磁盤，與 GPU 集群整體成本相比，這個成本通常不會超過 3-5%。此外，許多公司擁有大量存儲資源，但如何充分利用這些資源仍然是一個挑戰。Alluxio 在這方面提供了很多結合點?？梢詫?Alluxio 集群直接部署到訓練節點上，這樣的消耗非常?。s 30-40GB 內存），卻能提供高性能的訓練支持。用戶只需要付出整個計算集群成本的 3-5%，就可以充分利用 GPU 集群，幫助用戶克服IO瓶頸達到 GPU 100%使用率。11除了訓練集群，Alluxio也特別關注推理集群的成本和效率問題。隨著推理集群的擴展，成本可

18、能遠高于訓練集群。因此Alluxio致力于解決如何快速將訓練產生的模型部署到線上集群的問題。在傳統方式中，訓練結果會寫回到一個 Ceph 存儲，然后線上集群可能位于同一個或不同的 IDC 中，涉及到復雜的管理。很多公司會開發一套自己的存儲網關(storage Gateway）來解決跨域或跨 IDC 的問題，但是網關解決的是一個跨域或者是跨IDC問題，實際上沒有解決的是高性能和跨域的問題，簡單理解就是可以把訓練集群和線上的ML打通，但如果在AWS里這個Gateway是完全沒有辦法支撐推理集群的，比如擴展到100個甚至1000個節點的推理集群后，上線的時候會抖動的非常厲害，再比如：Alluxio可

19、以在2-3分鐘內把整個模型全都部署到推理集群上面，一般這種系統需要耗費的時間是它的10倍，而且它的P95和P99會非常長。三、Alluxio在模型訓練&模型上線場景的應用接下來會詳細講解不同場景中，Alluxio是如何做的：12第一個就是之前說到的問題，在GPU非常短缺的情況下，很多公司其實之前都不是多云戰略，不是IDC融合或者是云上、本地都有的架構，但為了滿足GPU資源的部署，很多時候被迫變成這樣，舉個例子：很多客戶/用戶，數據都是在AWS上，根本就不想用Azure、Google Cloud等其他云，但今年，Azure把所有GPU都買了，在這種情況下其實很難說在AWS上可以找到所有集群，然后

20、這些集群就必須在Azure里，就必須得有個方法直接去訪問AWS里的數據，這個問題就導致如果直接去獲取，數據性能就會非常低，如果是在網絡帶寬非常低的情況下，GPU的利用率通常不會超過10%，好一點的網絡（比如有專線）情況下，可以達到20-30%。第二個問題是如果要建一個多集群數據管理是非常復雜的，包括要保證數據的一致性，如何更新、拉取這些數據，但Alluxio做了很多的集成，就可以直接使用Alluxio解決這些問題。其次就是不希望大家專門買一套硬件解決方案，之前接觸過的實驗室有在做HPC的，HPC有一個很大的問題就是成本非常高，買1套HPC通?？梢再I10套Hadoop硬件，或者是云上的存儲硬件，

21、所以如果需要購買一套專有的硬件搭建AI Infra 架構，是事倍功半的，成本非常昂貴，看到這個場景后，Alluxio提出還是希望可以直接在數據湖上構建AI和ML的數據通路，可以不更改存儲系統，同時可以利用已有的，不需要額外購買IDMA這種硬件，就可以支撐訓練的需求。同時不用考慮和原數倉中任務進行數據隔離的問題（所謂隔離就是需要進行數據遷移，然后運行成兩套非常獨立的系統，這對數據的拉取、獲取是非常有問題的）。13上圖就是前面提到的，Alluxio提供的一些功能，比如自動數據湖加載/卸載、更新數據功能，從而提高數據工程團隊的生產力，一個比較常見的場景就是：如果基于原有的系統搭建，加一個Ceph，基

22、本時間線會拉長到3-6個月，在國外公司拉長到6個月以上是非常常見的，但是用了Alluxio整套系統拉取后，基本就可以在1-2個月內把整個Data Pipeline建起來，如果大家感興趣可以去詳細了解一下知乎的應用案例，里邊有非常詳細的解讀，告訴大家如何去搭建這套系統。上圖是前面提到的另一個問題：模型部署受限于底層的存儲，包括帶寬的問題，還受限于IDC不同位置的問題，Alluxio可以做一個多云多架構，不管是從公有云到私有云，還是不同公有云之間進行模型部署，都會非?？焖俚慕鉀Q這個問題，同時會提供一個高并發的緩存系統，支持業務高并發拉取。稍微總結一下，Alluxio在AI架構中處于怎樣的位置？Al

23、luxio幫助大家解決什么問題？第一個就是降低改造和適配的成本，幫助大家更聚焦在模型上線的邏輯上；第二個就是消除了專用存儲架構，比如原來必須要用NAS、NFS這些系統來做的，用了Alluxio之后就不再需用，Alluxio和下面原來已有的HDFS，對象存儲配合就可以搭建AI平臺；14第三個就是需要添加緩存，就可以把GPU利用率提高到較高的水平；第四個就是滿足公司自由部署GPU的需求，不管是云上還是云下買的GPU，不論數據在哪，都可以實現很高效的數據適配，后面會提供一個具體案例。關于Alluxio在AI場景是如何助力企業解決問題的，詳細分享幾個備受關注的案例：一、面臨的挑戰首看看小紅書的業務都碰

24、到了哪些挑戰。小紅書作為云上的原住民，從成立之初就構建在公有云上，下圖是小紅書多云架構的示意圖：小紅書|加速云端機器學習-Alluxio在小紅書的實踐15圖中的三個圈代表兩個云廠商的不同 Zone（區域），云廠商1是在 ZoneA 與ZoneB，云廠商2是在 ZoneC。核心業務分別分布在多個云廠商的不同可用區，核心業務如搜廣推、社區通常在主要機房都會存在，是多活架構；主要業務如電商直播及部分大數據服務，是雙活架構；其他如訓練等服務，是單活架構，這個只是個簡化后的示意圖，真實情況遠比這復雜。多云架構對小紅書帶來了非常明顯的成本優勢和可用性優勢，但業務的通信鏈路也隨之復雜，各種跨專線調用；還有個

25、特點是不同 region 之間 rt 差異比較大，且專線容量非常稀缺，因此帶來了一些業務使用上的痛點。多云架構下有哪些典型的問題機器學習訓練在小紅書是資源大戶，屬于公司 Top 級別，但海量的 CPU 和GPU 資源的利用率不及預期，訓練速度上不去，業務體感比較差。1.推薦服務是小紅書最核心的服務之一。它的核心邏輯是推薦召回需要有索引分發的過程，比如刷小紅書刷到的個性化的筆記列表，就主要用到了索引。索引服務因為索引分發慢，從而導致穩定性比較差，且因為索引數據存儲在云盤里，成本也很高。2.在AI場景下，有業務面臨 60 億+的元信息小文件場景，需要有一個低成本的解決方案。而且隨著AI的飛速發展，

26、AI 模型從之前的百 GB 級發展到如今的 TB級別。原來的架構通常先把模型拉到本地盤，再從本地盤加載到內存，才可以進行在線推理。這個過程在模型增大到 TB 級之后，會有兩個嚴重的問題：一個是加載過程非常緩慢，另一個是模型存儲在本地盤的成本非常高昂。3.多云架構本身帶來的網絡鏈路復雜，跨專線傳輸數據量非常大，專線單價也是非常高昂，有成本和穩定性的雙重挑戰。4.二、多云數據加速層接下來介紹下小紅書是如何通過構建多云統一數據加速層來解決這些痛點的。16上圖是小紅書業務架構的示意圖。最上層是業務層，主要包括社區、搜廣推、直播、電商這些核心服務。接下來是平臺層，這里只列了一些和數據強相關的，如機器學習

27、平臺、AI 訓練平臺，模型發布平臺、推薦索引平臺、數據平臺等。最底層是公有云的存儲產品，這里只列了主要依賴的對象存儲，其實包括異構的 HDFS 等產品都可以適用于這個通用的解決方案。在平臺層和存儲層之間，基于 Alluxio 構建了一層多云統一數據加速層并研發了對應的智能緩存服務。為什么選擇 Alluxio 作為多云統一的加速層首先基于面臨的問題，抽象出了選型的重點目標：需要能夠復用業務歷史上已經存儲的數據，不需要再次搬遷或者導入到其他高速存儲或文件系統就能享受到數據的加速。以典型的搜廣推和訓練業務為例，這些業務的存儲量大概是數百PB級別，搬遷一遍才能使用不太可行。需要支持 S3 和 POSI

28、X 協議，以便于與其他平臺無縫對接。如機器學習訓練通常是 S3 協議，AI 訓練通常是 POSIX 協議，如果加速層能夠兼容這類協議，業務方就不需要改代碼，遷移成本也會低很多。需要實現跨云專線傳輸的帶寬控制和節省。因為跨云本身業務是多活、多云的。但多云之間本身就有實時的數據同步，如果把帶寬打爆，那穩定性問題就會立馬出來，所以一定要能夠控制住帶寬。能夠支撐百億級別的 AI 訓練，小紅書有單個訓練任務就有60億+元信息的場景需要支持。能夠支持常見的云存儲產品，以主流云廠商的對象存儲為主。經過調研發現，業界目前唯一能同時滿足上述訴求的產品，就是 Alluxio。17Alluxio主要特性18特性一：

29、格式透明，不侵入業務數據存儲格式。數據湖里的數據量非常大，是不可能再導入進來重復存儲的，有了Alluxio，只需要在原來存儲上加一層Alluxio，就可以直接去訪問那些數據了，讓業務直接享受到加速收益，這是非常關鍵的特性。特性二：協議兼容。Alluxio 支持非常豐富的S3POSIXHDFSJava FileAPIREST API等協議，幫助Alluxio上層AI/ML訓練引擎（如Pytorch、Ray、TensorFlow）和查詢引擎（如Presto、Spark、Trino）與底層存儲進行無縫對接。特性三：多云統一視圖。不管底層存儲是HDFS、Ceph還是各云廠商的對象存儲，對于用戶，只要通

30、過Alluxio，任何API都可以去訪問不同存儲位置的數據，從而可以實現多云統一視圖的效果。特性四：數據僅需通過專線傳輸一次，后續可通過緩存就近讀取，不需要再次跨專線，這個關鍵特性對小紅書專線的保護意義重大。通過合理地利用這些特性，就能夠解決上述提到的小紅書多云架構的業務痛點。三、小紅書實踐案例機器學習訓練場景19機器學習訓練原架構機器學習訓練最初的架構是直接從對象存儲拉取數據（主要是訓練樣本），拉取完這些訓練樣本就開始在TensorFlow框架做訓練。主要問題：訓練速度不太符合預期，導致一些任務訓練很慢，以及其他人排隊調度不上，體驗很差。海量的集群資源利用率太低對成本也帶來了很大挑戰。主要原

31、因是一些熱點的數據集（如小紅書的筆記樣本），是公共的樣本，總量非常大（大概每天幾百TB）。這些公共數據集會被很多任務使用，在小紅書的場景下大概是 20 倍的扇出，如果是幾百TB的數據會有 20 倍的扇出，這個總傳輸數據量是非常大的，整體流量達到了Tbps級，觸達到了對象存儲桶的帶寬瓶頸。如果數據集大、扇出也大的話，一定會有額外的帶寬需要，云廠商的解決方案通常是要么增加存儲量，要么對增加帶寬進行額外收費，兩種方式都不太友好。因為業務會直連對象存儲，而對象存儲本身是高吞吐的產品，并不會過分強調單線程有多快，這就需要業務不斷的去調優，才能達到適合的吞吐?；谝陨先齻€問題，機器學習訓練架構經過了升級改

32、造，最新架構如下圖所示。20新架構對于普通數據還是直接會去對象存儲讀取，對于筆記這種熱點的訓練數據集，會把它緩存到 Alluxio，當業務來 Alluxio 訪問的時候，如果第一次數據不存在，就會去對象存儲透傳，然后把數據返回給訓練框架，如果數據已經在Alluxio上，那就可以命中緩存，直接由 Alluxio 返回數據。雖然第一遍讀完數據，Alluxio 一定會去緩存數據，但這還很難解決業務的問題。第一種情況是 Alluxio 緩存是用到本地磁盤把數據緩存下來，但磁盤容量是有限的，如果總訓練的樣本空間遠大于磁盤緩存容量，就會不斷的淘汰緩存數據，可能第一個任務緩存了，第二個任務就沒有空間緩存了，

33、或是會把別的緩存數據給擠掉。第二種情況是有些訓練任務可能因為計算資源或者故障的原因帶來嚴重的延遲，之后這個業務一旦跑上來，可能需要訓練 30 天之前的數據，或者直接回溯很老的數據去訓練，那這 30 天的數據很容易就把所有的緩存空間全部用掉。以上兩種場景通過研發了智能緩存管理服務來解決。智能存儲管理服務智能緩存管理服務主要是基于任務的歷史運行規律，可以基于任務的歷史運行規律，更加智能的把數據提前做預加載，這樣通常第一次訓練就能夠命中緩存，而且可以更及時地淘汰掉不使用的緩存。不僅如此，還對緩存淘汰場景進行了評估，比如發現最近 1-2 天的筆記訓練樣本是非常重要的，就會把這些數據用 Pin 機制固定

34、在磁盤里，就不會被自動淘汰，從而實現重要數據的淘汰完全由智能緩存管理服務去控制。通過這兩個措施的共同保障，緩存命中率能跑到90%以上，很好節省了對象存儲的帶寬。同時，Alluxio 也提供了load任務的管理和執行能力，但目前還不完全符合小紅書的需求。具體的業務中需要監控到任務粒度的 load 進展，比如有 10 個任務（有幾個是重要的），在按小時提前預加載數據，結果集群故障了，但故障時間也較長，第二天馬上又要用新的樣本去訓練數據，那該如何止損呢？措施是通過實現 load 進度的可觀測機制，能夠觀察到每個任務當前正在加載第幾小時的數據。當在不及預期的時候，會馬上發出告警并做止損。當止損的時候，

35、會基于任務的優先級去判斷優先補償哪些任務，并提供一鍵補償的能力，看看這些任務已經錯過了哪些小時的緩存數據，然后全部加載進來，從而規避帶寬全部透傳到對象存儲所造成的的穩定性風險。第三是為穩定性實現了一個探針服務，它可以完全模擬業務的讀寫行為，是一個端到端的探活服務。探活實踐下來非常好用，無論是代碼本身有問題，還是機器磁盤、網絡等出現問題，都能反映在探針里，方便快速介入。目前能達到3分鐘發現和1分鐘止損的效率。經過將近一年時間的運行，故障告警的準確率幾乎達到了100%。訓練速度提升效果2122上圖展示的是一個非常典型的筆記訓練大任務，其他業務訓練效果都差不多。在遷移之前，訓練時長達到9小時36分，

36、單一任務就需要消耗2000核，非常消耗資源，而平均 CPU 利用率只有30%，只是到了最后面會有一些上升，這是因為這時候大部分任務已經訓練完成，對象存儲的帶寬有些緩解了。在遷移到 Alluxio 之后，訓練時長直接縮減到了 5 小時 42 分，從圖中可以看到，CPU 利用率可以非常均勻的維持在75%，并且再也沒有被限流影響到。整體訓練速度在時長上優化了41%，雖然很多業務比這個效果更好，但這個例子是一個非常典型的大任務，更具有代表性。推薦召回索引下載場景23索引對于推薦非常核心，穩定性是非常重要的問題。上圖是未引入 Alluxio 之前的架構圖。最上面是搜推平臺，會對搜推的索引做一些生成或者更

37、新，更新完了之后會存儲到索引存儲（一般是就近機房的對象存儲）。存儲索引之后，搜推平臺會通知其他服務下發索引，下發索引的服務會把數據通過專線從原來索引存儲的對象存儲桶傳輸到另外一個多云機房的本地磁盤，也就是索引服務的本地磁盤上。以圖中的架構為例，共有兩個跨區域的機房，當把索引數據下載到本地盤后索引服務就能夠把數據加載到內存中，對外提供一些索引的服務。這樣的架構帶來的問題很大：以推薦場景下的索引讀取速度來說，通常發布一個機房的服務需要 3-4 個小時，因為是多活設計，發布完四個機房整整需要一整天，這是非常令人頭疼的問題。同樣，當單機房發生故障，止損時長同樣也需要 3-4 小時，如果你要把很老的一個

38、索引回滾，就需要重新走這個流程，四個機房就需要一天時間。磁盤存儲成本非常高。因為索引服務本身是一個主從架構，典型的場景是一主兩從。同一個索引會有三副本的云盤存儲，而云盤本身就是三副本冗余存儲，那整體下來就是九副本，而云盤的單價通常比對象存儲貴得多，這樣計算下來整體成本是非常高的。下圖是引入 Alluxio 之后的架構。從搜推平臺生成索引之后，會把這個事件發送到消息隊列，智能緩存管理服務訂閱了該消息隊列，收到相應的加載緩存事件后，就會去加載索引?，F在的加載流程和之前就不一樣了，之前是通過專線傳輸過來存到本地磁盤，現在是加載到 Alluxio 集群里，然后再告知索引服務，去 Alluxio 集群把

39、數據再加載到索引服務的內存，從而對外進行服務。這里的關鍵點是把本地磁盤變成了 Alluxio 集群，那為什么采用 Alluxio 之后解決了以上問題呢？24首先，把磁盤上浮到了一個遠程的集群，實現了索引的存算分離，把原來來自云盤的存儲瓶頸，轉換成了宿主機的網絡瓶頸。云盤的帶寬通常在云廠商相對還比較好的規格是 350 MB/s，但是宿主機不一樣，推薦可用的一些機器至少都是 32 Gbps以上，合4GB/s，這兩者的差距超過10 倍，因此下載索引數據這個過程就能提速10倍以上。第二，Alluxio 并不會把文件存儲在固定的一臺機器上（和本地盤不一樣），一個文件會被切成 block 存儲。比如一個集

40、群有 100 臺機器，一個文件能切 100 個block，那每個機器只會存1個block，這時候整個集群的帶寬就是這個文件的吞吐極限。所以，對于一些熱點的索引文件或者其他場景都是非常友好的。但這樣直接用 Alluxio 還是會遇到問題，所以還加入了一些增強的功能，這也是為什么引入了智能緩存管理服務的原因。比如 load 太快會把專線打爆，需要Alluxio 支持限速，以保障核心服務的穩定性?，F在已經支持了限速，當限制20-30Gbps的帶寬從 UFS 下載數據，就不會把專線帶寬占滿。這套架構主要有三點收益：Alluxio 將云盤帶寬瓶頸變成了宿主機的網卡瓶頸，索引拉取速度帶來 10 倍以上的提

41、升。如果宿主機的核數越大，附帶的帶寬也會更大，帶來的提升倍數還會增大。1.索引下發的整體業務體感（含業務邏輯）達到 3 倍的提升。主要是因為除了下載，還有一些業務邏輯在這個索引下發的過程里。2.高性能云盤替換成對象存儲，節省80%成本。此優化是通過 Alluxio 把云盤全部省掉，變成了Alluxio 的集群本地盤，而這些本地盤可以選擇一些更廉價的介質，比如單副本的 HDD 盤。對于小紅書的推薦場景，由于索引數據量很大，云盤成本的節省量也是非?？捎^的。3.大模型下載場景小紅書也有大模型的場景，大模型下載的解決方案和推薦索引幾乎一模一樣，面臨的同樣是云盤帶寬限制和冗余存儲高成本以及跨云同步穩定性

42、問題。3-4年前大家通常只做單機訓練，現在已經演進到了幾乎都是分布式訓練的狀態。那一定會需要通過遠端的存儲集群來解決本地數據存放不下的問題，這塊架構與收益跟推薦索引一樣，就不贅述了。25AI 訓練場景面對的挑戰：有 60 億+級別的小文件訓練場景，如果把這些元信息存儲在一個集中式的元信息服務里，成本非常高，本身技術挑戰也很大。對象存儲作為很多存儲的底座，最終數據會穿透到對象存儲，會面臨著存儲帶寬，或是 IOPS 比較有限的情況（尤其是小文件），云廠商通常一個桶提供幾萬 IOPS，每PB存儲量的帶寬配額也很低，尤其在小文件場景下，這點 IOPS承載不了多少訪問，因此 GPU 利用率就會很低。解決

43、方法：26引入 Alluxio 緩存訓練需要的數據。Alluxio 3.0 版本提供了一個可擴展的元信息能力，讓擴展性大幅提升。此外，Alluxio 本身支持 POSIX 協議，之前如果訓練是在本地盤上，現在會把 Alluxio 集群 mount 到 GPU 機器上，由于 Alluxio 是透明嵌入，讓業務方看其實還是訪問的本地盤，背后其實是 Alluxio 集群。然后，通過Alluxio 集群去對象存儲里取數據，基于 Alluxio 的緩存機制，可以有效的避免數據穿透到對象存儲。因為通常 AI 訓練是多輪的 epoch，Alluxio 只會讓第一輪epoch 走對象存儲，后面都可以命中這些緩

44、存。甚至理想情況下，可以錯峰把這些數據預加載到 Alluxio，這樣真正訓練的時候，完全不需要走對象存儲。因為 GPU 機器上很多磁盤是閑置的，為了避免額外的支出成本，會把 Alluxio 和GPU 機器混合部署，讓這些磁盤都可以被充分使用，也不會有額外的成本支出。Alluxio 相對于別的產品打造的非常成熟的能力是ClusterCache。在同樣的總磁盤容量，ClusterCache 相對于Local Cache的命中率可以做到更高，比如有兩個訓練任務讀同樣的文件，如果落在兩個不同的機器上，對于 Local Cache 會把數據讀兩遍，而對于 ClusterCache 只需要讀一遍，第二次可

45、以通過網絡來傳輸，而GPU 機器之間的網絡帶寬也常非常高，通常有百Gbps，同時 Alluxio 也支持LocalCache，組合起來使用更佳。Alluxio 為什么能加速 AI 訓練可以在業務訓練之前提前把數據加載到緩存中，突破IO限制，相比穿透對象存儲讀取性能更高；讀取數據時通過智能判定是隨機讀還是順序讀。如果是順序讀可以提前預讀數據，從而達到更高的讀吞吐；如果是隨機讀，可以精準地控制要讀哪個位置，避免讀的放大；無集中式的元信息服務，全量元信息在對象存儲，只有熱數據及其元數據在緩存中，對海量小文件友好，相比于集中式元信息服務，成本極低；可異步寫 checkpoint 到本地磁盤，再異步上傳

46、至對象存儲，通過有效縮短 IO負載時長，從而大幅縮短GPU 等待時間，并顯著提升 GPU 利用率。27技術問題及解法在與 Alluxio 的合作過程中，小紅書也一起參與解決了非常多的技術問題，這里有幾個比較典型的場景：讀放大問題解決：主要表現在 S3 協議里會有一些 range 讀，以及 Alluxio client、fuse 或者其他一些觸發隨機讀的場景。放大主要存在兩個環節：一個是 S3 proxy 到 worker 之間；另一個是worker 去對象存儲（UFS）取數據的時候，都會有一個讀放大的情況。比如一個數據是熱讀（指數據緩存已經在 worker里），原來的實現里 proxy會直接去

47、 worker 取，雖然S3協議里的 range 參數已經指明了截止位，但并沒有透傳過去。因為這里可能認為需要做一些預加載來加速后續的讀取，實際上業務如果指定了一個 endOffset，后面的數據則是沒必要讀取的。雖然預讀能幫助吞吐的提升，但在這種情況下后面的數據會被完全廢掉，反而會轉化成帶寬的放大。解決辦法：worker 傳輸數據當傳輸到 endOffset，后面的字節不需要傳輸過來，這樣是更經濟，更高效的辦法。第二個放大的問題是因為 Alluxio 初衷在讀數據時，會把需讀取數據范圍涉及的block 全部緩存下來，好處是之后再讀這些數據就不需要走帶寬了。比如在一個隨機讀的場景，在一個blo

48、ck 里只需要 1-2M 數據，但Alluxio會緩存整個 block 的大?。J為 64M）。解決辦法：如果是非緩存block的數據請求，因為協議中本身傳了 endOffset，需要將其作為訪問對象存儲的參數，只需要讀取必要的數據即可。endOffset 之后的數據本身也會被丟棄掉，讀出來就會變成 worker 機器上網絡帶寬的開銷，從而影響成本和效果。第三個是冷讀 NoCache 的場景。NoCache 是指經過 Alluxio讀取但不緩存對應的數據，通常發生在對于延遲太久的任務或者讀取大量冷數據的任務，不需要將其緩存下來，否則會將本身的熱數據給擠掉。解決辦法：以前的實現里，通過 S3p

49、roxy 直接 NoCache 讀，它會通過 worker 去UFS取數據。修改和打磨之后，Proxy 會繞過 worker 直接去 UFS 取數據。這樣可以節省 worker 傳輸到 proxy的帶寬，可以省一倍的帶寬，對應到機器成本上就是省一倍的機器成本。28專線帶寬限流：在 UFS 這一層增加了流控能力，保護了專線帶寬。在多云環境，業務通常會就近讀取，一定不會跨專線訪問 Alluxio集群，所有跨云專線的流量只有從 worker 到UFS 這一層，所以只需要在訪問 UFS 的地方加限流就可以控制住專線。而客戶端和 S3 Proxy 的交互，以及 S3 Proxy 與 worker的交互都

50、是同機房的一個流量，理論上也需要保護，但不影響專線。讀寫性能優化：在讀性能優化方面，通常是識別了讀的特征之后做預讀，通過預讀能夠明顯提升讀的性能，尤其是在冷讀數據的情況下。在Checkpoint寫方面，一定不能阻塞訓練，所以支持了WriteBack 能力，WriteBack 是指先異步寫到磁盤甚至內存中，然后就可以開始后續訓練，通過后臺線程異步上傳。同樣也有一些線程模型的優化，整體對讀寫的性能也有非常大的提升。四、未來規劃未來小紅書會把數據加速層做成什么樣子以及還有哪些待解決的問題呢？打造統一的多云數據存儲產品因為小紅書的數據存儲在多云里，業務需要關心數據到底在哪個云上，是不是會跨專線，到底要

51、用哪個 SDK 去讀取，報錯了都是什么原因，該去找誰，業務感知的東西非常多。期望打造一個統一的多云數據存儲產品，讓業務方再也不需要在代碼中關注數據到底在哪里，專線能否控制好等問題。AI訓練：多地域GPU利用率提升在 AI 訓練場景，因為 GPU 眾所周知的供應問題，從各個廠商購買或租賃的 GPU是分散在非常多的地域。這會造成一個非常嚴重的問題，有些地方有 GPU，但沒數據，有些地方有數據，但沒有 GPU，這會導致 GPU 的分配率不高。后面會探索如何基于 Alluxio 來提升 GPU 利用率，解決數據和 GPU 在不同地域如何充分利用GPU 的問題。29大數據查詢加速大數據查詢加速在 All

52、uxio 社區里的案例非常多，但小紅書需要探索出一個如何在極低成本的情況下去實現大數據查詢的加速。同樣的查詢效率提升，需要增加的Alluxio 的成本要小于直接擴容查詢引擎節點的成本才行。低效節點資源利用率提升現在 Alluxio 集群規模比較大，與此同時，CPU 利用率是非常低的，每天平均大概3%的利用率，但磁盤容量和帶寬全是占滿的。如何將這些 CPU 去充分使用是一個非常大的問題，而公司出于成本考慮，也會要求這些低效節點能夠被充分利用，從而發揮更多價值。30一、混合云架構，帶來便捷與挑戰知乎目前是典型的混合云架構，數據和服務都分布在不同的機房：離線機房：專為滿足大數據相關業務方需求而設計的

53、離線計算服務中心。其主要職能是部署離線調度、離線存儲以及調度平臺等服務。這些服務的目標是提供高效的離線數據處理和計算能力。在離線機房中，大數據業務方可以安心進行批量數據處理和計算任務，從而滿足他們對數據處理、存儲和調度的要求。在線機房：此機房專為知乎主站提供直接面向用戶的服務而設計。其中包括評論、回答、搜索、推薦等核心服務。在線機房的重點在于實時性和響應速度，以確保用戶能夠在最短的時間內獲得穩定、高效的服務體驗。知乎主站作為一個知識社區，其在線機房是為了保障用戶對知識和信息的交流與分享能夠得到優質、連續的支持。GPU 機房：此機房專門用于部署機器學習平臺，主要服務于算法用戶。其主要特點是提供強

54、大的 GPU 資源管理、模型訓練、數據集導入導出等一站式解決方案。GPU 機房的核心任務是為算法用戶提供高性能計算資源，以滿足機器學習模型訓練和推理的要求。這樣的設計能夠使算法用戶更專注于模型的研發與優化，而不必擔心計算資源的供給。31知乎|Alluxio AI助力知乎千卡模型訓練32混合云架構給知乎帶來了成本，容災等各方面的優勢，但是也對存儲提出了新的挑戰。相比于數據都存在在單一機房，在混合云的架構下，算法平臺在調度訓練任務時，還需要額外考慮訪問存儲時，專線帶來的網絡延遲以及網絡吞吐的限制。二、知乎的探索歷程探索：知乎自研UnionStore聯合存儲為了解決模型訓練及模型分發場景跨云讀取數據

55、的痛點，知乎在早期自研了一個緩存系統 UnionStore。顧名思義，UnionStore 是聯合存儲的意思，它聯合了對象存儲與 HDFS，利用對象存儲來對外提供本機房緩存。它支持對象存儲協議，這樣用戶可以使用 AWS S3 的 SDK 來訪問數據。UnionStore 的緩存工作流程可描述如下：用戶在向 UnionStore 請求讀取文件時，會先檢查對象存儲上是否已經有該文件了；架構圖如下所示：33如果對象存儲已經存在該文件，則直接從對象存儲讀取文件返回給用戶；如果對象存儲不存在該文件，UnionStore 會先將離線 HDFS 上的文件上傳到在線機房的對象存儲上，再從對象存儲上讀取文件，返

56、回給用戶，緩存期間用戶的請求是被卡住的。這里相當于是利用對象存儲做了一層跨機房緩存。挑戰：面對大語言模型訓練，UnionStore 捉襟見肘UnionStore 在知乎運行了兩年，期間沒有出現任何問題，但是隨著 2023 年知乎開始布局大語言模型，UnionStore 在面對大語言模型訓練時，有些捉襟見肘：沒有元數據緩存，元數據強依賴 HDFS 與對象存儲，特別是對象存儲，元數據訪問和首字節延遲在幾十毫秒，而大語言模型在進行訓練，讀取語料時，往往都是隨機讀取，對吞吐要求低，但是對時延敏感，而 UnionStore 只能從對象存儲隨機讀取數據，延遲極高；1.訓練任務在啟動時需要讀取模型的 che

57、ckpoint，大語言模型的 checkpoint 動輒上百 GB，而對象存儲單線程的讀取性能只有 10-100MB/sec，盡管UnionStore 也做了一些加速手段，但是也只能加速到 200-300MB/sec 的速度，遠遠不能滿足大模型的 checkpoint 讀取需求；2.對象存儲能力有上限，在模型分發時，往往單文件會有上百，甚至上千并發同時讀取，對象存儲容易面臨性能瓶頸和帶寬限制；3.無法做到邊緩存邊返回文件，導致首次讀取文件的時間偏長，這也會影響大模型 checkpoint 的讀取速度。4.以上痛點使得知乎面臨兩個選擇：一是繼續迭代 UnionStore，讓 UnionStore

58、 具備高性能緩存能力，比如支持本地 SSD 以及內存緩存；二是尋找合適的開源解決方案，完美替代 UnionStore 的使用場景?；谌肆Y源的寶貴，選擇了其二。探索：社區版Alluxio調研上線從 UnionStore 的使用場景來看，知乎需要的 AI 存儲必須滿足以下幾個需求：34協議兼容：必須要具有對象存儲協議和 POSIX 協議，目前知乎的模型分發場景使用的是 UnionStore 的對象存儲協議，模型訓練場景使用的是 UnionStore+S3FS-FUSE 來提供 POSIX 協議。性能優秀：選擇替換 UnionStore 的最重要的原因就是對象存儲的性能和延遲遠遠不能滿足算法業務

59、的需求，所以知乎需要的 AI 存儲必須要有足夠優秀的性能；透明緩存：因為目前知乎的數據都是存放在 HDFS 上，不希望用戶在接入新存儲的時候，需要對訪問數據的路徑做比較大的修改，最好是路徑能夠與 HDFS一一對應，有透明緩存的能力，這樣能夠最大程度上減少業務方的改造工作?；谝陨闲枨?，調研了市面上大多數的存儲，發現只有 Alluxio 能夠滿足需求，嚴格意義上來說，Alluxio 并不是一個標準的存儲，它是一個多功能低侵入的高性能緩存，它的一些能力能夠很好地滿足需求：透明緩存：相較于其他文件系統，Alluxio 可僅作為緩存使用，用于編排數據，業務方無需將模型文件寫入到其他的文件系統，只需要維

60、持現狀，寫入HDFS 即可；元數據與數據緩存：Alluxio 支持自定義緩存元數據與數據，這樣在讀取已緩存文件時，可完全不受 HDFS 影響；目前知乎 UnionStore 的 QPS 大約在20K-30K，緩存元數據可極大降低 NameNode 的壓力，反哺離線場景；豐富的 UFS 支持：支持除 HDFS 外的多種 UFS，比如對象存儲，在未來可能對數據湖場景也可以提供強有力的支撐；即席查詢加速：知乎 Adhoc 引擎采用的是 Spark 與 Presto，Alluxio 對這兩個引擎都有較好的支持；訪問接口豐富：Alluxio 提供的 S3 Proxy 組件完全兼容 S3 協議，模型上線場

61、景從 UnionStore 遷移至 Alluxio 付出的成本幾乎可忽略不計；另外 Alluxio提供的 Alluxio Fuse 也具備本地元數據緩存與數據緩存，比業務之前使用的S3FS-FUSE 具有更好的性能，正好能滿足模型訓練場景。35此外知乎對 Alluxio 進行了一些性能上的測試，Alluxio Fuse 的單線程順序讀取速度能夠達到 500+MB/sec，Alluxio S3 Proxy 的單線程順序讀取性能能夠達到1GB/sec 以上，這個性能完全能夠滿足需求場景。上線的過程比較順利，幾乎是無感遷移，在短短三個月內就將 UnionStore 完全替換成了 Alluxio，并且

62、拿到了不錯的收益：模型分發的速度得到了 2-3 倍的提升；訓練任務等待數據的延遲幾乎消失，訓練時長降低至原來的 40%。挑戰：任務規模擴大，社區版難以為繼隨著訓練任務的規模不斷擴大，也發現了 Alluxio 社區版中存在的各種問題?？偨Y起來可以描述如下：Fuse 穩定性問題：社區版 Alluxio Fuse 會經常出現 OOM 相關的故障，經常導致訓練任務失敗重啟；Master 元數據性能瓶頸：社區版的 Alluxio Master 是一個單點的服務，在緩存文件增加的情況下，會遇到性能瓶頸，并且無法擴展；寫場景性能不足：社區版的 Alluxio 同步寫入 UFS 時，性能較差，不能滿足業務做

63、checkpoint 的需求；高昂的運維成本：社區版的 Alluxio 部署，需要自己打鏡像，以及寫 k8s 的yaml 文件進行部署，沒有 operator 相關的運維工具。以上問題在社區版需要投入極大的人力和精力來修復和維護，并且需要一個比較長的周期，而此時知乎的算法業務發展的勢頭很猛，根本等不及。正好聽說 Alluxio也在企業版重構了他們的架構，在提升性能的同時，也修復了很多社區版已存在的問題。于是正式開啟的 Alluxio 企業版的調研與試用。探索：Alluxio企業版攻克四大問題Alluxio Fuse 穩定性問題1.首先是 Alluxio Fuse 穩定性的問題，Fuse 在長時

64、間運行后，很容易出現 OOM 相關的故障，如下圖所示：這是知乎真實生產環境中 Alluxio Fuse 的重啟監控，可以看到 Fuse 的重啟十分頻繁，幾乎每隔幾小時就有一次。一旦 Fuse 重啟，訓練任務就會因讀取數據錯誤而失敗，需要從上一次 checkpoint 開始訓練，這就導致了無效訓練，會浪費相當多的 GPU 算力。在社區版中，定位到問題來自 Alluxio Fuse 的 native 內存泄露。社區版的Alluxio 使用 GRPC 傳輸數據，在遇到問題時，Alluxio Fuse 對于 GRPC 的處理不太優雅，導致了 native 內存泄露。企業版數據傳輸用 Netty 全部重

65、寫了，不僅避免了使用 GRPC，也具有更好性能，相當于曲線救國了。下圖是使用企業版時，Alluxio Fuse 的重啟監控：36可以看到企業版的 Alluxio Fuse 幾乎沒有出現重啟的現象。此外，由于 Alluxio Worker 在知乎是和和 GPU 節點綁定部署的，而 GPU 節點的機器故障率比較高，也造成了 Alluxio Worker 的故障率偏高。在這種情況下，企業版支持在某臺 Alluxio Worker 出現問題時，重試到其他的 Worker 讀取數據，或者是直接從 UFS 讀取數據，這也提高了 Alluxio Fuse 的穩定性。Alluxio 企業版自上線以來，一共完成

66、了 300+訓練任務，包括知乎最重要的千卡大模型訓練任務，訓練期間沒有因為 Fuse 的穩定性導致訓練任務重啟，相比于社區版，企業版極大減少了無效訓練的出現。2.Alluxio Master 元數據問題37Alluxio Master 是 Alluxio 社區版中一個比較明顯的瓶頸：雖然 Alluxio Master 支持 HA，但是對外提供服務的 Master 只有一個，有單點性能問題，Master 在 3 億元數據下可以相對穩定運行，但是超過 3 億就需要進行調優，需要有豐富的經驗；隨著元數據增多，占用的內存也會變高，而內存在單節點上總是有上限的，不可能無限擴展；在 metadata sy

67、nc 比較頻繁的時候，較小的元數據量也會出現比較嚴重的鎖競爭問題，導致 Master 卡住。在 2023 年，因為 Master 的性能問題，出現過幾次比較嚴重的故障，多虧及時搶修（手動切主+重啟），才沒有造成比較大的損失。Alluxio 的企業版對整個 Alluxio 集群架構進行了重構，不再使用 Master 管理元數據，而是將元數據用一致性 Hash 打散到每一臺 Worker，理論上集群越大，可管理的元數據越多，元數據的規模隨著 Worker 的增長可以達到近乎無限的擴展。由于元數據分散到不同的 Worker，元數據請求的 QPS 也能隨著 Worker 數量的增加，得到線性增長。這里

68、需要注意的是，Alluxio 企業版引入了一個輕量的服務發現組件，目前是基于 ETCD 實現的，用于存放 Worker 列表。383.寫場景需求寫場景的需求主要體現在模型訓練時做 checkpoint。在訓練過程中，往往會因為一些意外導致訓練任務失敗，比如機器故障，GPU 卡之間的通信故障等。而大型訓練任務往往都是持續好幾個月的，在訓練過程中出問題的概率接近 100%，為了避免在訓練任務失敗時從零開始訓練，訓練任務就需要在 訓 練 的 過 程 中 定 期 做 checkpoint，這 樣 任 務 失 敗 了 就 可 以 從 上 一 次checkpoint 恢復，而不必從頭開始整個訓練。做 ch

69、eckpoint 越頻繁，每次訓練任務重啟時，損失的訓練時長就越短。但是對于一個大型訓練而言，checkpoint的大小往往在數百 GB，保存并持久化巨大的 checkpoint 文件也會花費比較長的時間。訓練任務在做 checkpoint 的時候，整個訓練任務是停止的，GPU 處于等待狀態。也就是說，如果想用 Alluxio 保存 checkpoint，Alluxio 必須要有一個比較好的寫入性能，否則會造成 GPU 利用率不足。在 Alluxio 社區版時，采用的是同步寫模式寫入數據，直接穿透寫到 UFS 上，只能達到 200MB/sec 的速度，與 HDFS 單線程寫入的速度接近。假如以

70、這個速度，每隔 3 小時做 200GB 的 checkpoint，每天光是花費在做 checkpoint 上的時間就達到了 120+分鐘，占到全天時長的 8%，也就相當于 GPU 利用率直接降低了8%，很明顯這個速度是不能滿足需求的。Alluxio 企業版支持了更高的寫入性能，在測試中，單線程同步寫入 HDFS 能達到1.2-1.4GB/sec 的速度，如果還是按照每隔 3 小時做 200GB 的 checkpoint 來算，每天花費的時間將減少至 20 分鐘，只占到全天時長的 1.4%，這能夠大大減少模型訓練做 checkpoint 的時長，提高 GPU 利用率。目前 Alluxio 寫入的

71、上線正在內部測試，還沒有正式上線。除了同步寫入，后續知乎還計劃上線企業版的異步寫功能，在提升寫入性能的同時，節省專線帶寬。4.運維成本在社區版時，需要自己打包 Alluxio 的鏡像，并且自己寫 yaml 文件將 Alluxio 部署到 k8s 上，上線的流程十分復雜，有很多步驟需要手動操作，費時費力，還容易出錯，下圖是部署社區版所使用的腳本和配置文件的集合，可以看到一共有十幾個文件。39Alluxio 企業版不僅提供了現成的 k8s 鏡像，還提供了 operator 部署工具，可以一鍵啟動集群，在 operator 安裝好的情況下，部署一個 Alluxio 集群只需要一個配置文件，極大節省了

72、我們的運維成本。40三、持續合作，保持探索首先，Alluxio 社區版為知乎帶來了混合云下 AI 存儲的通用解決方案，能夠在短時間內從自研組件無縫切換到 Alluxio 高性能緩存上，支持實現跨云訓練；其次，在更加核心的場景下，Alluxio 企業版帶來了更高的穩定性，更好的性能，更便捷的運維，更是支持了知乎內部千卡大模型的訓練穩定高效運行。感謝 Alluxio 團隊在上線過程中提供的幫助，后續也將繼續保持合作，共同深入挖掘 Alluxio 的潛力，探索更多的應用場景，為知乎的技術發展貢獻更多的力量。一、B站AI的訓練場景機器學習平臺介紹首先，簡單介紹一下B站 AI 的訓練場景，整個機器學習平

73、臺的架構如下圖所示：B站|Alluxio 在B站AI訓練場景的應用41它具備了一個常規機器學習平臺的能力，比如交互式建模、數據集管理、模型訓練、模型部署等基礎能力，用戶也會有一些精確的數據集、業務團隊以及資源運營相關的能力，同時對機器學習框架（比如業界流行的 TensorFlow、PyTorch、DeepSeed 以及自研的一些框架等）都需要兼容。同時，為了加速整個訓練的收益，B站與 Alluxio 進行了很多合作，搭建了一個在 AI 訓練場景的訓練集群，調度器主要是 Volcano，是現在機器學習平臺常用的。已有存儲方案介紹下圖是搭建 Alluxio 之前的存儲方案，HDFS 主要針對大數據

74、的分析場景，B站自研的 OSS 存儲叫 BOSS，還有一些 NAS 存儲的系統，當然每個存儲系統都有自己的優缺點，這里也簡單的做了個對比。AI 訓練場景介紹搜推1.一個是搜推，比如商業、廣告、流量推薦，這種場景就是很明顯的大數據存儲的場景，跟 HDFS 這一套就非常的親和。42432.CV/大模型場景這個場景也是目前使用 Alluxio 的一個主要業務場景，這里有一個特點，單數據集的規模很大，比如最近在用的一個數據集，已經達到了 PB 級，文件數量大概在億級別，基本都是小文件。CV 訓練以圖片、音頻等為主，基本都是100KB、1M大小，數據比較多樣，有圖片、視頻、音頻、文本等。AI 訓練存儲痛

75、點在訓練過程中發現了幾個存儲方面的痛點：存儲容量：1.因為現在隨著大模型的引入，數據量會越來越大，對數據容量的要求會越來越高，像現在大數據集，可能會達到上百T；這是一個快速增長的過程，而且特別是最近的 Sora 帶火了 TTV 這種場景，所以視頻的規模會非常大，存儲系統需要具備高擴展性以應對不斷增加的數據需求。2.性能瓶頸：高吞吐：AI 訓練需要頻繁讀取和寫入數據，存儲系統需要支持高吞吐量以保證數據加載速度低延遲：數據讀取的延遲應盡可能低，否則會影響訓練效率，導致 GPU/NPU等計算資源的浪費。正如大家所熟知的，現在買卡非常難，如果 GPU 由于 IO 導致利用率低，那肯定是不劃算的3.成本

76、、安全：高成本：存儲大量數據尤其是高分辨率圖像和視頻數據，存儲成本很高，需要平衡性能和成訪問控制：需要對數據訪問進行細粒度的權限管理，確保數據安全?；?Alluxio 的訓練存儲架構44為了解決這些痛點，在調研之后，采用了 Alluxio 的方案，主要有三大吸引點：統一命名空間：將不同存儲系統（如 HDFS、BOSS、云存儲）抽象為一個統一文件系統接口，對用戶來說不用感知底層的 HDFS，只需要掛 Fuse；內存或 NVMe 緩存：結合內存和 NVMe 存儲緩存，提升訪問速度，降低 I/O延遲，用的比較多的是 NVMe 的場景，大量 GPU 都會高配這種 NVMe；多存儲后端：兼容 HDFS

77、、對象存儲等多種存儲后端，擴展性強。二、Alluxio 在 AI 訓練場景的應用為什么選擇 Alluxio？這里先介紹一下 Alluxio 的主要優勢：性能高：低延遲高吞吐的數據緩存能力，對于 AI 訓練尤其重要；兼容性強：支持 S3/HDFS 后端，提供了廣泛的數據源兼容性；兼容 POSIX 協議；運維成本低：運維成本在大規模數據存儲和處理環境中尤為重要，有助于減少整體運維投入；大規模數據處理：Alluxio 支持億級的數據量規模，能滿足 AI 訓練需求。45在做技術選型的時候，也對業界常用的幾個系統做了調研和分析，基于B站的體量，B站沒有人力單獨為 AI 做存儲的維護，所以第一個優先考慮的

78、就是成本，需要投入更低的成本、更低的運維，支持更強的性能。在調研過程中 Alluxio各方面表現優勢明顯，最終選擇了 Alluxio。單集群 or 多集群？在部署的時候 Alluxio 采用的是一種多 Master、多 Worker 的方式。但B站在大數據集場景是一種單集群部署的模式，優勢是：一個集群可以集中管理、運維成本比較低，可以實現資源的高效利用；缺點是現在社區版2.9.4的元數據存儲在 Master，很容易碰到天花板，擴展性比較有限，如果單個集群出現了問題，對業務的影響是比較大的，所以在 AI 場景最終采用的是多集群部署的方案。46基于整個集群的存儲規模，集群的劃分會按照業務或者是數據

79、集，好處是某個業務或者數據集需要更強的能力，則會投入更多的資源，而對于那些不怎么重要的業務，或者是低優先級的業務，則需要把它隔離開，從而不至于讓低優先級的業務影響到高優先級的業務，這是最終采用的方式。通過多集群的方式，在部署運維方面會增加更多的成本，那么如何解決這個問題？基于 Fluid 的云原生多集群部署方案47這里引入了 Fluid。Alluxio 是對底層存儲的抽象，Fluid 又是對 Alluxio 這一層Runtime 的抽象。通過 Fluid 之后，可以更好的在 K8s 上，更自動化的部署多集群的方案，目前B站應該有百機規模的集群。調度優化48另一個問題是，在實際應用中使用的是 v

80、olcano 調度器，主要是 binpack 為主，binpack 的策略是盡可能的把單臺機器塞滿，對 IO 密集型的業務，如果把所有的節點都調度到單臺機器上，很容易造成單點故障，給 IO 造成瓶頸，另外也會帶來網絡擁塞、資源利用不均等問題。解決辦法：結合了業務特點以及本身的緩存加速場景，采用的是拓撲感知的調度策略。首先，會盡可能的讓 Alluxio 的節點分散到集群的每臺機器上，盡可能的把IO 打散。其次，在任務調度的時候，也會去感知 Alluxio 的拓撲分布，盡可能做到任務與 Alluxio 節點的親和，這樣親和之后相當于在讀本地硬盤。元數據同步的必要性:元數據同步在 Alluxio 中

81、至關重要，因為它確保 Alluxio 文件系統與底層存儲系統中的數據保持一致，這個問題B站也同樣遇到過。當數據量大了之后，如果按照官方的元數據同步方法，對整個集群的穩定性和性能都會有很大的影響，所以最終采取了一種按需同步的方法。這里已經把集群暴露給用戶，他可以直接操作他的集群，知道什么時候數據是更新的，由他來決定；另外，如果是那種億級別的數據集要做 Meta 同步，至少是小時級別，這個肯定是不可接受的，所以也在要求用戶最小化他的同步單元，盡可能的減少無效的同步計算。具體同步方式:基于時間的自動同步：設置alluxio.user.file.metadata.sync.interval 屬性來定時

82、同步；手動同步：使用 loadMetadata 命令或 API 手動觸發同步。元數據同步加速49加速方式：按需同步：只在需要時觸發；最小范圍同步：最小范圍同步，減少無效同步計算。超大規模小文件優化50很多場景的數據都是以小數據為主，如果只是簡單的把數據給到 Alluxio，然后什么都不做，這樣就會有兩個問題，一個是 Meta 會很多，本身B站采用的就是Master 的架構，整個集群對 Master 的壓力會很大；另一個就是用戶會無組織的去用，因為他根本就不知道該做哪些組織才有利于數據的 IO。這塊主要是做了數據合并，也是在訓練場景用的比較多的一種方式，把一個圖片做成一個 chunk，chunk

83、 里邊再做一個下浮，可以做到指數級的降低文件的 Meta 信息，并對整個訓練的效果都不會有太大的影響。51Alluxio 帶來的效益在實際應用過程中測下來，億級別的單節點性能基本能達到 IOPS 在 3000+以上，整個業務包括審核、大模型，都在用這一套，現在已經緩存的數據集大概在幾百T規模左右。三、未來規劃Alluxio 之前介紹過知乎的推理場景，這個場景B站也有比較大的痛點，所以B站也在嘗試探索更多的可能。另外就是現在 Master 元數據管理是一個很痛的點，在這種場景下 Alluxio 最新的 Dora 框架可以帶來多大的收益，也是需要進一步去調研的，同時，因為是一個機器學習平臺，應用場

84、景非常單一，同時也在跟B站的存儲專業團隊做一個更大規模、更通用的 Alluxio 解決方案，這是現在在做的，也是后續打算去推的。輝羲智能|Alluxio在自動駕駛模型訓練中的應用與部署52一、自動駕駛數據閉環首先分享一下自動駕駛中怎么樣構建數據閉環，這個業務過程可能大家都有所了解。自動駕駛會包含多種車輛類型，比如數采車輛、帶著算法在路上跑的車。數據采集就是在跑的過程中采自動駕駛車上的各種數據：比如說 camera 的數據就是圖片，激光雷達的數據是點云。傳感器數據采回來，可能一輛車每天跑下來就有幾T的數據。這種數據通過基盤的方式或者其他上傳方式把它們整體存儲起來，傳到對象存儲里面。原始數據存儲之

85、后會有一個 pipeline 做數據的解析預處理，比如把它切成一幀一幀的數據幀，每幀的不同傳感器數據之間可能還要做同步對齊的操作。53完成數據解析之后，就要在上面做更多的挖掘。構建一個一個的數據集。因為不管是在算法、仿真或者測試里面，都要構建數據集。比如想要雨天的某一個晚上，某一個路口，或者一些密集形成區域的數據，那就會在整個系統里面有大量的這種數據需求，要做數據的打標，打上一些標簽。比如說在清華東門這個地方，需要去拿這個位置的經緯度，解析周圍的 POI。之后再對挖掘出來的數據做標注。常見的標注有：對象、行人、對象的類型等。這種做了標注的數據，會被拿去做訓練。典型的一些任務，比如目標的檢測、車

86、道線的檢測、或者更大的端到端的模型。模型訓練好了之后，還要做一些仿真驗證。驗證完再把它部署到車上面，再去跑數據，在這個基礎上再去采更多的數據。就是這樣的一個循環，不斷的去豐富數據，不斷的去構建性能更好的模型。這是整個訓練，數據閉環要做的事情，也是現在自動駕駛研發里面較核心的事情。二、算法訓練：NAS聚焦到模型訓練來講：模型訓練主要是通過數據挖掘拿到數據，從而生成一個數據集。數據集在內部是一個 pkl 文件，包含數據、channel、存儲位置，最后數據算法訓練的同學會自己寫下載腳本，把數據從對象存儲拉到本地。54在選用 Alluxio 之前，是通過 NAS 系統充當緩存的作用，把對象存儲的數據拉

87、到NAS 上面，最后再用不同的模型，把數據 load 進來進行訓練。這是使用 Alluxio之前，大概的訓練流程。其中最大的問題在 NAS：第一是并發性能比較差NAS 可以理解成它就是一塊大的硬盤，當只有幾個任務一起跑的時候，還是比較夠用的。但是當有幾十個訓練任務同時進行、很多模型在訓練的時候，往往就會出現卡死。曾經有一段時間卡死非常嚴重，研發每天都叫苦不迭?？ǖ脟乐匾灾劣诳捎眯苑浅２?、并發性能很差。1.第二是管理困難每一個人都用自己下載的腳本，然后把想要的數據下載到自己的目錄下面。另一個人可能又自己去下另外一堆數據，放到NAS的另外一個目錄下面，這樣就會造成 NAS 空間滿時很難做清理。當時

88、基本都是當面或者微信群溝通。一方面是效率特別低，依靠群消息管理會滯后。另外一方面，也會因為手動 remove，導致一些風險。曾經出現過 remove 數據時，把別人的數據集給刪掉的情況。這也會造成線上任務區域的報錯，這是另外一個痛點。2.第三是空間浪費不同人下載的數據放在不同目錄下，有可能同樣一幀數據會出現在好幾個數據集，存在比較嚴重的空間浪費。3.第四是使用很復雜因為 pkl 里面的文件格式不相同，使得下載邏輯也不一樣，每個人都要單獨去寫下載程序。4.這是之前用 NAS 會面臨的一些困難和問題，為了解決這些問題而做了一些調研。調研后聚焦到Alluxio上來。發現 Alluxio 它可以提供一

89、個比較統一的緩存，緩存可以提升訓練速度，同時也可以減少管理成本。還會用 Alluxio 的系統，處理雙機房的問題。通過統一的命名空間和訪問方式，一方面可以簡化了系統設計，另外在代碼實現上也會變得很簡單。55三、算法訓練引入 Alluxio當把 NAS 換成 Alluxio 之后，Alluxio 能夠針對性的解決剛才提到的一些問題：1.在并發性方面NAS 本身不是一個完全分布式的系統，而 Alluxio 是。NAS 它訪問的 IO 達到一定的速度時會出現卡頓，可能達到幾個 G/s 的時候就會開始卡。而 Alluxio 的上限非常高，下面還有專門的測試來說明這一點。562.通過手動清理或者管理會非

90、常麻煩Alluixo 會配置緩存的逐出策略。一般是通過 LRU，當到一個 threshold 的時候（比如90%）它會自動做緩存的驅逐和清理。這樣做的效果：效率大大得提升；可以避免因為誤刪導致的安全性問題；解決了重復數據的問題。在 Alluxio 里面，一個 UFS 里面文件，對應到 Alluxio 就是一個路徑，當所有人都去訪問這個路徑時，就可以拿到對應的數據，這樣就不會存在重復數據的問題。另外使用上面也比較簡單，只需要通過 FUSE 的接口方式訪問，不再需要下載文件。以上是從邏輯層面解決了剛才講的各種各樣問題。下面講一講，整個落地的歷程，怎么從 0 到 1 實現 Alluxio 從開始的

91、POC 測試，到各種性能的驗證，再到最后怎么樣部署、運維等的一些實踐經驗。四、Alluxio 部署：單機房57首先可能會在單機房里部署，就是一定要臨近 GPU，部署到 GPU 節點上。同時利用之前 GPU 上很少用的 SSD，把每個節點都利用起來，然后把 FUSE 和 worker部署在一起。FUSE 就相當于客戶端，worker 就相當于一個具有內網通信的緩存小集群，做FUSE 的服務。最后對應的通過 worker 自己對底層的對象存儲做通信。五、Alluxio 部署：跨機房但是由于各種各樣的原因，還會有跨機房的存在?，F在有兩個機房，每一個機房里都會有對應的 S3 服務，也會有相應的 GPU

92、 計算節點?；旧厦恳粋€機房都會部署一個 Alluxio。同時在這個過程中也要注意，一個機房里可能是兩個 Alluxio 的對象存儲，另外一個機房如果也要做 S3 掛載，盡量做好 bucket 名字的統一規劃，不能把兩個搞重了。比如這里有個 bucket 1，那里又有一個 bucket 1，會導致 Alluxio 掛載時的一些問題。58還要注意，不同的 endpoint 要注意內網和外網的區分，比如集群1的 Alluxio，掛載集群1的 endpoint 內網，在另一邊就是外網，反之性能就會大打折扣。掛載之后可以通過同樣的路徑去訪問不同集群上面不同 bucket 的數據，這樣其實整個架構就會變

93、得非常簡單，這是跨機房部署方面。六、Alluxio 測試：功能想要真正把 NAS 換成 Alluxio，在部署之前要做很多功能測試。這種功能測試，目的是讓現有的算法流程通過最小程度的改造，讓算法同學也能用起來。這里可能要根據各位實際情況去操作。當時和 Alluxio 做過接近2-3周的 POC 驗證，其中會涉及到如下內容：K8S 上訪問 PVC 的配置；數據集的組織方式；作業提交的配置；訪問路徑的替換；最終訪問的腳本接口。59以上遇到的諸多問題可能都要做驗證，至少要通過它選一個典型任務，然后做一些改造，最后才能把 NAS 比較平穩的換成 Alluxio。七、Alluxio 測試：性能接下來在這

94、個基礎上，還要做一些性能測驗。在這個過程中，不管是單機還是多機，都做了比較充分的測試。在單機上，Alluxio 和原來的 NAS 基本上性能是打平的。其實真正體現 Alluxio 優勢的是多主機上、分布式的能力?？梢钥吹?NAS 或者舉例的 QTS，它有一個非常明顯的點：不穩定。測試3G 到 10G 間波動會比較大，同時它有一個明顯的瓶頸，達到 7/8G 左右，就基本上穩定了。60而 Alluxio 這邊，整個測試過程，節點隨著運行實例的增加，可以達到一個非常高的上限，當時設到 20GB/s時，它都還是呈現出一直向上的趨勢。這說明 Alluxio整個并發的、分布式的性能非常好。八、Alluxi

95、o 落地：調參適配環境做完功能驗證和性能測試之后，就真正的要實際部署 Alluxio 集群，部署好之后，需要一個參數調參適配的過程。因為測試時，只采用了一些典型的任務，真的上Alluxio 環境之后，會發現隨著任務增多，會有一個參數調參適配的過程。需要把Alluxio 上面相應的參數跟實際運行環境做匹配，然后才能夠把它性能給發揮好。所以會有邊運行、邊運維、邊調參的過程。其中經歷了一些典型的調參過程，比如說：ETCD 的節點：一開始是 1 后來增加至3節點，這樣就保證即便某個ETCD節點掛了，整個集群不會受到影響。與 S3 相關的：比如說 Alluxio 在實現的時候，他會讓 S3 生成一個訪問

96、比較長的路徑，會在中間的路徑節點，默認寫一些空白，以至于讓它具有更好的性能。但是這種情況下，訓練任務下面的 S3，是做了權限管控的，不允許他們去寫這種數據。面對這種沖突，也需要調參。61FUSE 節點本身能忍受的并發強度的能力：包括它要使用的 Direct Memory 的大小，實際上也和整個業務實際運行并發的強度多少有很大關系。和能夠一次性訪問的數據量其實是有很大關系的，這也有一個調參的過程，不一而足?？赡軙诓煌h境下遇到不同的問題。這也是選擇 Alluxio 企業版的原因。因為在企業版的過程中 Alluxio 會有非常強的支持，7*24h 都可以做到遇到問題去調整、去配合。有了相互配合的

97、周期，才能夠讓整個集群比較順暢地運行起來。九、Alluxio 落地：運維團隊最早運維的同學只有一個人，他負責很多底層 Infra 的維護和相關工作，當我要把 Alluxio 部署上來的時候，其實運維那邊的資源是不夠的，所以相當于我也兼半個運維。從自己要去運維一個東西的角度來說，要做好很多運維方面的記錄和知識沉淀，特別是對一個新手來講很重要。比如下一次出現問題怎樣更好地解決，是不是之前已經有過這樣的經驗。針對當時的環境，會維護好三份文檔。運維的歷史記錄文檔：比如說哪一天出現了什么問題，這些問題我找到它根因是什么，它的解決方案是什么？具體操作是什么？62操作文檔：比如在 K8S 上運維，它的重啟是

98、哪幾步、操作是什么、出現問題怎樣去看日志、怎樣去排查、去看FUSE對應的數據是哪個任務、哪個 worker 上面去運行、監控等等。都是常用的一些操作。配置的變更：因為 Alluxio 具體在調參的過程中。不同的時候，可能遇到的配置文件、yaml 文件是不一樣的，可能還要做一些備份?？梢杂?Git 管理，也可以簡單地采用文檔管理。通過這種方式可以追溯到當前配置和歷史配置版本。在此基礎上，還會有一些相關的配套建設，就是為了更好地使用 Alluxio。研發同學使用下來認為 Alluxio 蠻好用的。但多任務的時候，就暴露出來一些配套建設的需求。比如要做圖片的 resize，把圖片從一開始高清4K，降

99、到 720P，以便支持更多的任務緩存。訓練數據集做跨集群同步，以便更好的做數據預加載。這些都是圍繞著 Alluxio 要做的系統化建設。十、Alluxio 落地：共同進步在不斷使用 Alluxio 的過程中，也會發現一些值得改進的地方，通過給 Alluxio 反饋，促進了整個產品的迭代，從研發算法同學那邊，他們 care 的是：穩定性：一定要在運行過程中穩定，不能因為 Alluxio，一些東西 crash 了，讓整個系統訓練受阻。這里面可能有一些運維的小技巧，比如說盡可能不要讓FUSE 重啟。剛才也提到了 FUSE 重啟就意味著它的訪問路徑，讀數據文件的時候，會失敗、出現 IO 的 error

100、。確定性：比如 Alluxio 之前建議數據不需要做預加載，即不需要在預訓練之前讀一遍，只需要在第一個 epoch 過程中讀一遍。但是因為研發有發版周期，他要明確的知道預加載要多長的時間，如果通過第一個 epoch 去讀，很難預估整個訓練時間。這里面其實也會引申出來，怎樣通過一個 file list 做緩存這件事情，這個也給 Alluxio 提了一些需求。63可控性：雖然 Alluxio 是可以提供自動化的基于 LRU 的緩存驅逐清理緩存。但是實際上研發還是希望，一些已經緩存過的數據，能夠主動做一些清理。那么能不能也通過提供 file list，讓 Alluxio 把這塊數據給 free 掉。

101、這也是除了間接的用 Alluxio，還要直接的、非?？煽氐挠?Alluxio 的需求。從運維的這一端，也會提一些需求：配置中心：Alluxio 自己可以提供一個配置中心，把配置的歷史給保存下來。增加一個功能以便實現配置項更改時，提前預算到這個改動到底影響的是什么；Trace跟蹤一個命令的運行過程：另外一個比較現實一點的需求，比如現在發現一個問題：訪問底層的一個 UFS 文件時延時比較高，到底是什么原因？看FUSE 的日志可能看不出原因，得需要再去看 location 對應的worker日志。這其實是一個非常耗時、麻煩的過程，而且往往排查不了問題，還需要Alluxio的線上客服支持。Alluxi

102、o 能不能加一個 Trace 命令，在要做訪問的時候，把FUSE 耗時、worker 耗時、以及從 UFS 里面讀它的耗時，一個全鏈路的耗時問題給 Trace 出來。這樣其實對整個運維過程或者排查過程會有比較大的幫助。智能監控：有時候監控的東西是已經知道的東西。比如說 Direct Memory 有問題了，去配一個監控項。但是如果下一次一個新問題在我的日志里面出來了，它可能是一個隱藏的問題，在人不知道的情況下悄悄地發生。這種情況希望可以自動的監控出來。通過工單反饋的方式，給 Alluxio 提了各種各樣的建議。希望 Alluxio 能夠在產品迭代過程中，提供更強大的功能。把整個研發、運維 ca

103、re的事項，做到更好的滿足。十一、小結第一，從 Alluxio 在整個自動駕駛模型訓練的緩存加速方面，對比 NAS 它提供了很好的可用性。對輝羲來說它也會有10倍左右的提升。成本的降低來源于兩部分:64產品采購成本低；NAS可能會有20%-30%的冗余存儲，Alluxio 都可以解決掉。從可維護性的角度來講，它可以自動清理數據，更加及時，也更加安全。易用性方面，它通過 FUSE 可以更便捷的訪問數據。第二，我也分享了輝羲是怎么樣去從 0 到 1 部署 Alluxio，運維一個系統。中汽創智|Alluxio在自動駕駛數據閉環中的應用65一、自動駕駛業務介紹首先介紹一下中汽創智的自動駕駛整個開發業

104、務流程?，F在圍繞自動駕駛開發主要強調的是數據閉環：開始是數據采集，數據采集之后進行預處理/數據挖掘，包括一些大模型的預刷；接著進入數據標注環節，主要包括人工標注和一些自動化的標注；標注以后產生的帶有增值的數據集，提交給算法進行開發訓練，如模型訓練、評測和推理；最后再去迭代整個自動駕駛模型，模型經過上線進行實車部署。在數據采集環節，自動駕駛的采集車需要經過改裝，進行傳感器的標定，主要在標定廠里對車端的一些傳感器進行剛性位置的關系調教，改裝完的車去做實測采集，比如在城區的道路、高速公路進行采集。每天采集的數據量非常大，一天一輛車采集的數據大概在 1 TB 左右。而采集回來的數據量沒辦法通過線上傳輸

105、的方式上傳到私有云或者公有云里，一般是通過特殊的存儲介質拷貝帶回來。當然也有實時的采集，比如每隔多長時間需要去做一些采樣，這種數據是可以通過實時的采集傳輸到私有云里。66可以看到自動駕駛業務的每個流程里都有數據傳輸和拷貝的環節，這都是跟存儲加速強相關的。關于標注，公司內部研發了一個人工標注的數據平臺，主要把采集回來的數據進行預處理，因為原始的數據可能是一個 bag 包，如同現在機器人開發里基于 ros，里邊類似于 Java topic 機制，可以去訂閱包括點云、圖片、軌跡數據等，而這些數據是存儲在一個二進制的很大文件里。經過預處理要對應到每一個時間戳，比如它有一個頻率，每秒大概兩幀或者是幾幀，

106、然后把這些數據做參數時間戳上的對齊，包括做一些插值，去處理成算法或人工標注所能識別的數據集（可能包括一組文件，里面有 point cloud 這樣的文件夾。文件夾里是一幀幀的點云。車上可能有一系列前后左右一組傳感器camera，每個時間戳下面都有對應的一張2D圖片和一些軌跡，包括內外參的一些參數）。在處理成這種格式的數據之后，然后會把數據集上傳到數據標注平臺里進行增值的標注。標注包括多模態，如 3D 的點云，2D 圖片/camera。點云和圖片標注的時候會做 3D 到 2D 的轉換，這個過程從人工標注之后進入到人工審核驗收環節，最后流轉出來到導出層，就成為了算法所需要的數據集（主要是一些增值數

107、據，比如標注的box、車道線、車道線障礙物、錐桶、行人以及路上的設施）。在模型開發訓練階段，自動駕駛的主要算法模塊包括感知、預測、定位、規控。傳統是基于分層的架構開發，每個模塊有上下層的邏輯關系，現在比較流行的是端到端的模型訓練，類似于人腦，依靠眼睛、耳朵來接收外界的輸入信號，通過內容融合的大模型，最終輸出自動控制車輛的行為。對于模型訓練，我們與很多大型企業一樣有自己的智算中心，會有很大的投入去建設 GPU 集群用于訓練，然后數據集會源源不斷的進行輸入。最后是模型評測和模型上線。67數據存儲管理的痛點：在整個數據閉環中，數據存儲是影響整個開發的非常大的痛點。因為數據是自動駕駛的三要素之一，它像

108、血液一樣，能驅動算法，驅動整個業務流程。如果沒有數據，算法僅僅是一堆代碼，模型根本無法支撐自動駕駛。在自動駕駛場景，數據是海量的，包括有采集車數據，一年的規模在幾個PB，如果是長年累月的積攢，這個量是無法估量的，還有座艙數據、平臺的業務數據和指標數據，這些都需要管理和治理。數據閉環過程中，往往存在重復性的拷貝，重復讀寫相同數據，造成效率低下。平臺和算法都存在大量數據上傳下載的業務邏輯，并且讀寫的效率低下。二、數據平臺架構以及存儲選型存儲類型方案1：JuiceFS之前也調研過 JuiceFS，并且在數智化部門也有使用的案例。由于中汽創智數據湖底座是在 OBS 上，對象存儲里的數據有多種使用方式，

109、JuiceFS 是自己實現了分布式文件系統的元數據層，按照自己的協議把數據寫入 UFS，雖然通過gateway方式也支持多種協議的讀寫，但是算法還保留著對象存儲 API 使用方式，所以出于數據可用性考慮放棄。方案 2：Alluxio（最終采用）接觸Alluxio是在使用 JuiceFS 之后，在多個平臺里面共享存儲這樣的需求，涉及到采集、數據篩選/數據挖掘、合規、標注、訓練推理、仿真等相關業務，希望有統一底層 UFS 數據接入，讀寫加速、把讀寫 UFS 的能力下沉到中間件層，提升業務的效率；Alluxio 開源版本2.9.3的功能特性能夠滿足當前的需求。Alluxio 介紹Alluxio 作為

110、機器學習生態系統大數據中的新增數據訪問層，可位于任何持久化存儲 系 統（如 Amazon S3、Microsoft Azure 對 象 存 儲、Apache HDFS 或OpenStack Swift）和計算框架（如 Pytorch、TensorFlow、Apache Spark、Presto或Hadoop MapReduce）之間，但是 Alluxio 本身并非持久化存儲系統。使用 Alluxio 作為數據訪問層可帶來諸多優勢：對于用戶應用和計算框架而言，Alluxio 提供的快速存儲可以讓任務（無論是否在同一計算引擎上運行）進行數據共享，并且在同時將數據緩存在本地計算集群。因此，當數據在本

111、地時，Alluxio 可以提供內存級別的數據訪問速度；當數據在Alluxio中時，Alluxio 將提供計算集群網絡帶寬級別的數據訪問速度。數據只需在第一次被訪問時從底層存儲系統中讀取一次即可。因此，即使底層存儲的訪問速度較慢，也可以通過 Alluxio 顯著加速數據訪問。為了獲得最佳性能，建議將Alluxio 與集群的計算框架部署在一起。就底層存儲系統而言，Alluxio 將 AI 應用和不同的存儲系統連接起來，因此擴充了能夠利用數據的可用工作負載集。由于Alluxio 和底層存儲系統的集成對于應用程序是透明的，因此任何底層存儲都可以通過 Alluxio支持數據訪問的應用和框架。此外，當同時

112、掛載多個底層存儲系統時，Alluxio 可以作為任意數量的不同數據源的統一層。內部架構如下：68數據平臺架構69中汽創智的海量數據主要是非結構化數據，有別于傳統的數倉是結構化的數據（語義直接在數據里），而自駕的數據都是非結構化的，如你光看這些文件（圖片、視頻或者是點云）并不清楚里面是什么，只有通過挖掘之后才知道它表達的是什么語義，蘊含什么信息。這些需要抽象出來在數據庫和數倉里去表達。架構中數據湖架構底層由對象存儲和 HDFS 組成，上面是分布式緩存加速層，如Alluxio；再往上會將抽象出來的非結構化數據元數據，業務數據存儲在 OLTP/OLAP 數據庫中，通過流式 cdc 或者數據集成工具同

113、步寫入數據湖，采用Hudi/Iceberg/Delta Lake 這樣的 tableformat 數據格式，也是為了解決早期 Hive 在upsert 場景上的性能問題；往上是元數據層，接著再往上集成了如 Clickhouse 和Doris等 OLAP 引擎對業務層進行查詢，數據湖則通過 Trino 進行交互式分析。整個數據湖架構為上層業務平臺以及算法、工具鏈提供 DataOps 支撐。70三、自動駕駛數據平臺使用場景當前方案目前部署了 3 Master+10 Worker，客戶端隨應用側使用sidecar 方式部署，應用 pod 中業務容器和 sidecar 容器通過存儲卷的共享傳播機制實現

114、掛載。主要使用到的 Allluxio 3大特性：簡化數據管理：Alluxio 提供對多數據源的單點訪問，能夠對多個獨立存儲系統提供單點訪問，無論這些存儲系統的物理位置在何處。這提供了所有數據源的統一視圖和應用程序的標準接口。內存速度 I/O：Alluxio 能夠用作分布式共享緩存服務，這樣與 Alluxio 通信的計算應用程序可以透明地緩存頻繁訪問的數據（尤其是從遠程位置），以提供內存級 I/O 吞吐率。此外，Alluxio的層次化存儲機制能夠充分利用內存、固態硬盤或者磁盤，降低具有彈性擴張特性的數據驅動型應用的成本開銷。應用側實現數據本地掛載 Alluxio-fuse應用案例一在標注平臺有個

115、場景是上提數據集。數據集有大有小，一般上提數據集文件數處于較小規模時沒有問題，但如果有一個很大 BEV 數據集，1個包大概5至6GB，需要再上提的時候，把原始目錄下的文件做轉換，一些文件夾的處理。然后，按照每一幀組裝好元數據，因為如果是圖片可能比較大（幾 MB 至十幾 MB），特別是在標注平臺里，由于加載原始圖片比較大，會涉及到生成縮略圖。比如1幀可能會有 7個camera，每個圖片會生成大、中、小 3 個縮略圖，這樣就放大 3 倍。假如現在有3,000 幀，一個攝像頭就可能變成 9,000 張圖片，然后再加上 6 個攝像頭，那就再乘以 6 倍，這個數據量就蹭蹭上去了。之前為使用 Alluxi

116、o 的時候，還是通過傳統方式先在本地生成，接著通過對象存儲的 API 去上傳，但當上提較大數據集時（文件數在1w左右），則會出現 gc 問題，剛開始采用多線程并且加內存資源，也依然存在問題，出現 GCLocker 的告警，并且一直重試申請分配對象，最終導致 OOM。使用了 Alluxio之后，把這么多文件通過 MQ 分發到縮略圖服務里，然后把 OBS或者 MinIO 通過 sidecar 方式掛載到服務的 pod 里，這個時候可以看到速度非?？?，性能也好，沒有再出現之前的問題。之前讀寫方面的瓶頸問題，也通過Alluxio 解決了，非常能夠體現 Alluxio 的價值。應用案例二71第二個是合規

117、平臺場景?，F在企業里很多都要講究數據的合規，它是把采集回來的數據根據法律法規去做一些數據的糊化和轉換，首先是對數據進行分類分級，之后識別出敏感的數據，再通過數據抽幀，對于敏感的幀要進行識別和刪除。剩下的數據，比如點云或軌跡，里面會有一些地理性的坐標，這種精準的信息是不允許對外的，只有經過坐標偏轉之后才能對外提供服務。最后是個性脫敏，比如拍到的圖片里面有人臉、車牌這些屬于個人隱私的內容，需要通過算法推理做糊化，輸出的圖片才能交付給下游使用。這些服務是通過工作流串聯起來的，比如通過消息隊列，在每個服務側掛載了Alluxio，采用 Alluxio sidecar 方式將對象存儲掛載到本地，所有數據流

118、轉都通過寫入本地掛載路徑，通過 Alluxio 同步到 OBS。當 FUSE Client 開啟 cache，Alluxio Fuse 的讀取速度從 50MB/sec 提升到了 200MB/sec；敏感區識別和個人脫敏（人臉和車牌識別糊化）這些推理服務加載預熱后的 Alluxio 數據，推理性能提升了40%。應用案例三72第三個場景是仿真測試平臺案例。如圖左邊的集群是業務集群在 K8S 里，右邊是由 C+和 C#寫的仿真程序，名字叫Smartview。原先在仿真測試平臺有個播放bag 包的case，平臺需要獲取 OBS 上采集數據目錄，然后拉取 bag 包進行仿真程序的回放播包，給算法進行一些

119、 corner case 的定位以及回放；仿真程序單獨部署在一個工控機上，運行在 Docker 容器中，需要讓 k8s 集群外的 fuse 客戶端能訪問集群中的 Alluxio；這個時候需要對 Alluxio集群做修改，比如 worker 的配置，將 worker 中 hostNetwork 置為 true?，F在仿真測試也是在用這個環境，1個 bag 包大小都不一樣，最小的也超過1GB，屬于大文件的讀寫，在仿真程序里播包沒有任何的延遲，都很順暢。Sidecar 接入方法業務要接入 Alluxio 實現掛載 obs 需要在 k8s 部署 yaml 文件增加如下配置：比如 haohan-datai

120、nject 服務的 deploy.yaml 中增加：1.pod 配置中增加用戶權限配置：securityContext:runAsUser:0 runAsGroup:0 fsGroup:02.pod 增加存儲卷申明：volumes:-name:alluxio-fuse-volume emptyDir:3.增加 sidecar 容器配置：（resources 部分可以自行定義）734.業務容器增加掛載配置：74知識點-掛載卷的傳播：掛載卷的傳播能力允許將容器安裝的卷共享到同一 Pod 中的其他容器，甚至共享到同一節點上的其他 Pod。卷的掛載傳播特性由 Container.volumeMount

121、s 中的mountPropagation 字段控制。它的值包括：None-此卷掛載將不會感知到主機后續在此卷或其任何子目錄上執行的掛載變化。類似的，容器所創建的卷掛載在主機上是不可見的。這是默認模式。該模式等同于 mount(8)中描述的 rprivate 掛載傳播選項。然而，當 rprivate 傳播選項不適 用 時，CRI 運 行 時 可 以 轉 為 選 擇 rslave 掛 載 傳 播 選 項 （即HostToContainer）。當 掛 載 源 包 含 Docker 守 護 進 程 的 根 目 錄（/var/lib/docker）時，cri-dockerd(Docker)已知可以選擇

122、rslave 掛載傳播選項。HostToContainer-此卷掛載將會感知到主機后續針對此卷或其任何子目錄的掛載操作。換句話說，如果主機在此掛載卷中掛載任何內容，容器將能看到它被掛載在那里。類似的，配置了 Bidirectional 掛載傳播選項的 Pod 如果在同一卷上掛載了內容，掛載傳播設置為 HostToContainer 的容器都將能看到這一變化.該模式等同于 mount(8)中描述的 rslave 掛載傳播選項。Bidirectional-這種卷掛載和 HostToContainer 掛載表現相同。另外，容器創建的卷掛載將被傳播回至主機和使用同一卷的所有 Pod 的所有容器。該模式

123、等同于mount(8)中描述的 rshared 掛載傳播選項。AlluxioFuse 這里一共有三個掛載：AlluxioFuse 把 Alluxio 掛載到容器內的/mnt/alluxio-fuse 目錄下；k8s 把宿主機路徑/mnt 以 bi-direction 的方式掛載到 AlluxioFuse 容器內的/mnt 路徑；k8s把宿主機路徑/mnt 掛載到 application container 內任意路徑。75先 說 第 三 個 掛 載，application container，其 實 把 宿 主 機 的 /mnt 還 是/mnt/alluxio-fuse 掛進去都是可以的，只不

124、過容器內部會是不同的路徑訪問數據，多了一層子目錄 alluxio-fuse,前兩個掛載是有一點 tricky 的。如果 k8s 把目錄 /mnt/alluxio-fuse 掛 進 fuse container 的 /mnt/alluxio-fuse，然 后alluxioFuse 又把 Alluxio 掛到/mnt/alluxio-fuse，會把第一個掛載給擠掉。這個其實還算比較符合直覺，不可能把路徑A和路徑B都掛到路徑C上。擠掉之后這層宿主機和alluxio-fuse 的 connection 就沒有了，application 自然也就沒辦法讀到數據。當然用戶如果不想把一整個/mnt 都掛進f

125、use container 里面，也可以用/mnt/alluxio/alluxio-fuse 取 代 /mnt/alluxio-fuse，/mnt/alluxio 取 代/mnt。JAVA API 訪問 Alluxio應用 pom 文件添加依賴：76 org.alluxio alluxio-core-client-fs 2.9.3 數據預熱：Alluxio master 默認是存儲元數據的，掛載以后客戶端側默認能看到所有掛載路徑下的文件系統系統其實是通過 master load 到元數據，但是業務訪問文件系統實際上還要取load數據，數據塊是存儲在 worker 中的，如果 worker沒有則

126、會去底層的 UFS 即 obs 加載數據，這個在業務運營過程中其實對性能是有損的，所以通常我們慣用的方法就是提前數據預熱。Alluxio 的 Java api 中 FileSystem 接口提供大部分文件系統的操作 API,比如新建、刪除、掛載、讀取、加載元數據等等，當然也有通過 job service 方式提供了其他額外的接口，比如 LoadJob，即可實現 load 數據到 worker。代碼如下：77try AlluxioProperties properties=new AlluxioProperties();properties.set(PropertyKey.MASTER_HOST

127、NAME,10.79.180.14);properties.set(PropertyKey.MASTER_RPC_PORT,30619);AlluxioConfiguration conf=new InstancedConfiguration(properties);FileSystem fs=FileSystem.Factory.create(conf);AlluxioURI path=new AlluxioURI(/origin/101/1664083078340767745/CAIC_郁健峰_L42340_南京市_城區_晴天_天_20221104_rosbag_202211041650_

128、1667551809843);LoadJobPOptions.Builder options=alluxio.grpc.LoadJobPOptions .newBuilder().setPartialListing(true).setVerify(true);LoadJobRequest job=new LoadJobRequest(path.getPath(),options.build();Optional jobId=fs.submitJob(job);if(jobId.isPresent()System.out.printf(Load%s is successfully submitt

129、ed.JobId:%s%n,path,jobId.get();else System.out.printf(Load already running for path%s,updated the job with +new bandwidth:%s,verify:%s%n,path,unlimited,verify);catch(Exception e)System.out.println(Failed to submit load job +:+e.getMessage();遇到的問題中汽創智的場景有讀寫，讀其實沒有太大的問題，但是寫入目前2.9.3版本不支持追加寫目前寫的需求。目前是先寫臨

130、時目錄，然后復制到指定分發目錄；元數據同步，目前 Alluxio 是通過設置 metadata sync interval 設置相關UFS 的元數據同步,如果開啟設置固定時間間隔，主要擔心對 Alluxio 自身有性能影響，所以還是通過手動通過命令或者代碼觸發元數據同步。78四、未來規劃從基礎設施層去優化整個 Alluxio 集群的性能，賦能算法訓練推理將 Master 獨立部署穩定性保障將 Worker 與 GPU 節點混布降本增效將 Worker 與 Fuse 混布本地緩存書關于Alluxio（掃碼添加小助手）（掃碼關注Alluxio）Alluxio是全球首個分布式超大規模數據編排系統，孵

131、化于加州大學伯克利分校AMP實驗室。自項目開源以來，已有超過來自300多個組織機構的1200多位貢獻者參與開發，包括全球最頭部科技公司、最頂尖的計算機科研院所等。Alluxio聚焦于AI和數據分析場景，可加速企業Al產品價值變現，并最大化基礎設施的投資回報率。Alluxio 數據平臺位于計算與存儲系統之間，能夠在數據工作流的各個階段為數據平臺上的工作負載提供統一視圖。無論數據位于何處，該平臺均可提供高性能的數據訪問，簡化數據工程，提高GPU 利用率，并降低云計算和存儲成本。企業無需使用專用存儲，即可大幅加速模型訓練和模型服務，并在現有數據湖上構建Al基礎設施。Alluxio在頭部投資者的支持下，為全球科技、互聯網、金融和電信企業提供商業化服務，目前全球排名前10的互聯網公司中有9家在使用Alluxio。