本文按照數據湖存儲加速方案的不同發展階段鋪開，比較了各類方案之間的異同，并深度剖析了這類方案的技術本質。

我們期望本文能夠幫助讀者對大數據和 AI 場景下的「數據湖存儲加速」這個主題建立一個整體把握，為選出適合自己業務的方案提供參考。

圖片

24 年初，我們和客戶 H 進行了交流。當 23 年大家都在訓練自己的大模型，H 客戶擴大了已有的 GPU 集群規模，加上既有自建 IT 基礎設施，開啟了大模型訓練之路。在大模型加持下，新的業務效果很快得到了證明。隨著時間推移，大模型業務的不斷擴大，基礎設施層面碰到了一些跟存儲相關的問題：

• 數據規模：要進一步提升模型效果，就要把更多數據喂給 GPU，但自建的小型文件系統已不足以承載這么多訓練數據。曾嘗試過 HDFS，雖然容量規模增大不少，但元數據量仍然存在上限，因此不得不將海量小文件打包存儲，訓練前再解壓展開，訓練后還得清理，使原本順暢的業務流變得復雜。
• 存儲成本：隨著多模態的引入，業務數據由幾十 TB、數百 TB 快速積累到數 PB，存儲成本越來越不容忽視。
• 訓練速度：算力規模逐步擴大，無論自建文件系統還是 HDFS，都開始跟不上算力需求，存儲成為拖慢訓練的主要因素。

類似客戶 H 遇到的這些問題的例子還有不少。他們中大多都經歷了從自建 IT 基礎設施到開源大數據生態的時期，并嘗試將以前的經驗復制到 AI 場景。

的確，過去由數據庫、數倉、ETL 等技術驅動的商業智能成為業務的強大助推器，但這種圍繞預定義 schema 層層裁剪模式所設計的存算架構在 AI 面前顯露出不少弊端，尤其是受系統擴展性和成本的制約，大量原始數據不得不被舍棄。

但是，數據正是大模型時代的黃金和石油，當業務希望從這些寶貴的原始數據中重新構建智能、提煉新的價值時，往往發現為時已晚。

1.數據湖存儲成為云原生時代的事實標準

對于這位 H 客戶，我們給的建議是擁抱云原生數據湖。其中最核心的主張就是將各類原始數據統一入湖，集中存儲到同一數據底座，再以開放統一的接口提供給各類上層計算和應用。這種方式最大限度保留了數據的 Single Source of Truth，同時也解決了這位客戶的困擾：

• 近乎無限的擴展能力：越來越多的數據湖存儲已由傳統的 HCFS 架構走向了對象存儲架構，其平坦元數據結構天然適合水平擴展，單個存儲桶輕松承載千億對象，尤其在 AI 這類海量小文件場景具有得天獨厚的優勢。
• 靈活的資源彈性：相對于 HCFS 的存算一體架構，云服務商提供的對象存儲通常基于存算分離的龐大資源池，客戶按量付費、按需擴縮容，同時還能借助資源池的規模效應滿足一定的突發性能需求。
• 極致的存儲成本：對象存儲一般采用糾刪碼技術，相對多副本可帶來數倍的空間節省，同時從標準、低頻、冷存到歸檔的分級存儲能力，也給原始數據的長期保存提供了進一步優化成本的方案。

當然，這些優勢不僅局限于 AI 場景，在大數據場景下同樣能發揮很大的價值。除了比 HCFS 擁有更好的擴展性、資源彈性和成本優勢外，類似 Hudi、Iceberg 等新一代存儲格式和計算范式也在圍繞對象存儲的這些特性進行設計優化。可以看到，基于對象存儲的數據湖已成為云原生時代的事實標準。

2.為什么還需要給數據湖存儲加速？

回到 H 客戶的例子。雖然對象存儲解決了他的海量數據規模和存儲成本的問題，但存儲拖慢訓練的問題仍然沒有解決，甚至在某些情況下可能更差！要弄清楚原因，我們仍以 AI 訓練為例展開分析。

如圖展示了一個典型的 AI 訓練過程。每一輪訓練首先需要對原始數據進行遍歷和打散，然后以多個 batch 喂給 GPU 完成訓練迭代，多次迭代間還會保存 checkpoint 用于中斷恢復。

圖片

我們注意到大多數訓練尤其是視覺、多模態訓練往往依賴大量小文件作為輸入。因此除讀寫 checkpoint 外，訓練與存儲的交互主要集中在兩個方面：一是大目錄下海量文件的遍歷，對應對象存儲的 LIST 操作；二是小文件的高頻重復讀，對應 HEAD 和 READ 操作。

圖片

再從對象存儲側來看。雖然其平坦目錄結構、糾刪碼編碼方式和存算分離架構解決了擴展性、成本和彈性問題，但也導致 LIST 和對小文件的 HEAD、READ 性能可能比不上傳統的 HCFS 架構：

• 元數據性能：平坦目錄下 LIST 操作需要掃描整個子樹并折疊不需要的深層子項，導致訓練數據的遍歷耗時較長。
• 小 I/O 性能：采用 HTTP 協議，每個 LIST、HEAD、READ 操作都需經過 LoadBalancer、WebService 等很長的鏈路才能到達底層的元數據和數據集群，且糾刪碼還可能導致小文件讀放大。這些因素疊加造成訓練數據小 I/O 延時并不理想，很可能會拖 GPU 的后腿。
• 帶寬限速：存算分離架構下，計算往往位于 overlay 虛擬網絡，訪問對象存儲需先穿透到 underlay 網絡，且計算與存儲間可能還存在跨機房的物理網絡距離。因此大量重復讀不僅產生可觀的帶寬成本，而且很容易觸發各環節的限速，進一步制約訓練效率。

類似地，對大數據場景進行分析也會看到同樣的問題。我們將 AI 和大數據各類典型場景總結如下，發現部分場景依靠對象存儲自身能力就能很好地滿足，但另一些場景則需要額外的存儲加速，才能保證計算效率，減少算力和帶寬資源的浪費。

圖片

3.數據湖存儲加速的誕生和發展

早在數據湖被提出之前，隨著高性能計算（HPC）需求的產生，存儲性能的提升就已經得到了廣泛關注。這一階段，HPC 等應用開始由 NAS 類容量型存儲轉向以并行文件系統為代表的高性能存儲。

3.1并行文件系統

并行文件系統，代表產品如 GPFS、Lustre、BeeGFS，最初面向復雜多媒體處理、氣象分析、工程計算、生命科學等超算場景設計。通過客戶端到后端數據節點的直連、數據條帶化、MPI-I/O 等機制實現并行讀寫，從而在當時主流的 HDD 上也能提供出眾的存儲性能。后來基于 SSD 實現了更極致的性能，被廣泛應用于 HPC 和 AI 場景，成為很長時間內性能場景下近乎唯一的選擇。

不難想象，假如經費無限，將所有數據全部放入并行文件系統，幾乎就能滿足應用對高性能存儲的所有訴求。但實際上對于數據密集型業務來說，完全基于一套大容量的并行文件系統，存儲成本勢必成為不容忽視的問題。

面對巨大的成本問題，研發工程師們會提出什么樣的方案來解決呢？

圖片

3.2兼顧成本：并行文件系統 + 對象存儲

在 HPC 和 AI 場景，近年來開始將并行文件系統與對象這類低成本存儲組合使用。在這套組合中，兩者并不是對等的，而是處于上下兩層。根據數據入口和存儲中心所屬層級的變遷，可細分為兩個階段。

第一階段，數據入口和存儲中心仍然在并行文件系統，對象存儲只作為其過期數據沉降或備份的冷存儲層。

第二階段，隨著數據湖進入大家的視野，數據入口和存儲中心開始下移至對象存儲底座，而計算所需的熱數據向上導入并行文件系統。這種形態下，我們已經可以把并行文件系統視為對象存儲的緩存加速層。不過這種加速方案有兩個問題需要改進：

• 其一，兩者仍然相對獨立，通過副本式的拷貝來建立數據的弱關聯，任意一側的數據變更無法透明地傳遞到另一側。因此業務需要提前規劃數據冷熱，仔細控制兩層間的數據交換。有研發能力的企業通常會在業務層額外建設一套專用的數據流轉管理系統。
• 其二，正是由于這種不透明性，不能做到按需加載，因此需要把即將用到的數據全部載入并行文件系統。因此，業務所需的并行文件系統規模，只能由數據量和所需 I/O 能力兩者的最大值來決定，很難做到各類場景下 I/O 和容量均不浪費。目前只能通過不斷細分的產品規格來滿足差異化需求。

面對不透明性問題，研發工程師又是如何解決的？

圖片

3.3透明流轉：對象存儲 + 緩存系統

出于對上述兩個問題的改進，大家開始思考更透明、性價比更高的方案。誕生于 UC Berkeley 的 Alluxio 就提供了其中一條演進思路。

Alluxio 最初的思想是在計算側構建一層虛擬的分布式文件系統，從而對各類上層業務屏蔽底層存儲差異。這種統一訪問界面之下的數據編排能力，可實現底層異構存儲間的數據流動，因此被大量用于跨系統、跨云的統一存儲業務架構。實際上這跟 VFS 在 Linux 操作系統中的角色非常相似。

Alluxio 的另一個貢獻則是促進了近計算分布式緩存的發展。這讓大家意識到如果將計算節點空閑的內存、SSD 等資源統一托管起來，用作對象存儲的透明緩存，不僅不增加成本，還能獲得非常好的加速效果。相對于對象存儲引擎內部的緩存機制，這類近計算緩存直接工作在業務 VPC 的 overlay 網絡中，時延能降低一個數量級，同時與計算框架配合實現數據協同調度的發揮空間也更大。因此近年來，各大云服務商紛紛推出了自己的緩存加速產品，比如 AWS 的 FileCache、百度智能云的 RapidFS、阿里云的 JindoFS、騰訊云的 GooseFS 等，在 AI 和大數據的大部分場景下都能取得接近并行文件系統的加速效果。

Alluxio 這類真正的緩存系統用于對象存儲加速，相對于采用并行文件系統的加速方案，最大的區別在于兩層間的數據關聯和雙向流轉完全透明化，從而能做到：

• 基于同一套存儲底座，避免數據反復拷貝，最大程度發揮對象存儲在打通業務上下游上的優勢。
• 透明緩存降低了運維人員在業務規劃、控制數據流轉上的心智負擔，內置流轉能力就能滿足 80% 以上的需求。
• 通過 pipeline 換入換出，更好地解耦了熱數據性能和容量成本，I/O 和容量的配比可根據場景靈活定制。

當然，緩存系統也有其固有的問題，在使用中需要注意：

• 其一，雖然緩存的透明性能避免數據加載不完整引發的讀失敗，但是 cache miss 還是會導致明顯的性能波動甚至降級。因此對這類產品的緩存算法、調度策略和數據流轉效率提出了比較高的要求，這也是各產品持續深耕的重要能力。當然，不同場景對數據的需求總是不盡相同的，如果產品既提供了完善的內置策略，又能將自定義策略的能力開放出來，則能更加貼合業務需求，保證長尾數據的加速效果。
• 其二，緩存系統的寫操作通常還是基于對象存儲的原生能力，因此類似追加寫、邊寫邊讀、子樹 rename 等操作仍然會受對象存儲的限制。一般來說，AI 場景這類需求較少，但大數據場景對此存在比較強的依賴。

為了解決對象存儲在大數據場景寫能力上不足的問題，研發工程師是如何設計新的解決方案的？

圖片

3.4完備語義

事實上，上面提到的緩存系統寫操作的局限性來自元數據和數據語義兩個層面。元數據層面，對象存儲平坦目錄結構導致 rename 這類子樹操作實際上需要對子樹下所有對象依次操作，非原子、耗時長。而數據層面，底層存儲引擎只提供一次寫入能力，不支持流式追加寫。針對這兩個問題，業界提供了兩類解法。

3.4.1解法一：云原生文件系統 + 對象存儲

這種方式是在對象存儲之上重新構建一層近計算的文件系統，用來解決文件語義和性能加速兩個問題。對象存儲層只提供持久化數據底座，繼續發揮其擴展性、彈性和成本優勢。

以 JuiceFS 為代表，上層重新組織層級目錄結構的文件元數據，并存儲在 Redis、TiKV 這類外部元數據引擎中。而數據切塊后寫入對象存儲，將以前對整個對象的更新縮小到對其中一個小數據塊的更新，從而滿足追加寫、邊寫邊讀等語義需求，因此這種方案在大數據場景得到了較為廣泛的應用。性能上，對于存在大量共享數據需要加速的高性能場景，可以使用其商業版提供的分布式緩存功能。

不過在實際應用中還需要考慮由此帶來的數據侵入性問題。

由于文件切塊后持久化，因此對象存儲層丟失了路徑、文件名中所包含的關鍵業務信息。這樣就很難再完全利用對象存儲的生態能力進行數據處理、數據管理、生命周期流轉和成本優化。為了緩解這個問題，JuiceFS 最近的版本支持了存量對象導入和文件到對象的導出，可以實現一次性的單向拷貝。不過，當建設多套業務系統時，需要同時建設多個近計算文件系統實例，因此可能需要多次導入導出才能滿足多套業務系統間數據交換的需求。

3.4.2解法二：文件對象融合 + 緩存系統

為了原生支持完備語義，一些云服務商又探索出第二種解法，即直接在對象存儲層內部實現元數據和數據兩個層面的文件對象融合。緩存系統仍然在近計算側提供性能加速。

• 元數據層面，構建可無限水平擴展的層級目錄服務，向上同時提供兩套接口，實現文件和對象兩種數據視圖的互融互通。
• 數據層面，在存儲引擎內部支持流式追加寫模型，消除對象存儲寫能力上的局限，從而更完整地滿足大多數存儲場景的需求。

采用這種文件對象融合存儲作為數據底座和數據流動的主管道，疊加各業務環節的近計算緩存，既能滿足完備語義、性能加速和透明流轉的需求，又能避免對業務數據的侵入，獲得更多對象存儲的豐富功能和原生體驗。

4.數據湖存儲加速都在解決哪些關鍵問題？

上面我們對數據湖存儲加速的誕生和發展進行了總結。雖然市面上各產品的思路和具體實現有差異，但在需要解決的關鍵問題上又是大致相同的，不外乎元數據加速、數據讀寫加速、數據流端到端提效三個方面。從這幾個方面一探究竟，可以幫助我們更好地理解其原理并挑選出適合自身業務的存儲加速方案。

4.1元數據加速

存儲系統的元數據是用來管理數據的數據，比如目錄結構、文件名稱、大小、修改時間等。業務發起讀寫操作前，都需要先與元數據交互，尤其在大數據 AD-HOC、AI 訓練等涉及大量小文件或小 I/O 的場景中，元數據耗時的占比甚至接近數據讀寫本身。因此其性能好壞對存儲的整體表現有很大影響。

大多數業務程序已習慣本地文件系統的用法和層級目錄視圖。而前面提到，對象存儲用平坦目錄來模擬層級目錄的開銷，以及較長的網絡距離和請求處理路徑都對元數據性能帶來負向影響。因此幾種加速方案都繞不開近計算原生層級目錄樹這一做法。

• 部署形態上：在業務 VPC 的 overlay 網絡中部署元數據服務，能大大縮短訪問路徑。同時一般還會利用內存作為熱點元數據緩存，從而將訪問時延從十毫秒量級縮短到毫秒以內。
• 元數據語義上：并行文件系統、云原生文件系統內置了層級目錄樹，LIST、RENAME、DELETE 等操作都是以操作子樹根結點的方式進行，避免了額外開銷和非原子性帶來的問題。緩存系統的層級目錄樹同樣能對 LIST、HEAD 這類讀操作進行加速，但更新操作通常采用寫穿透的方式來保證與對象存儲的一致視圖。因此對于大數據中某些更新操作較多的場景，一般會選擇在對象存儲中也采用層級目錄模式的桶，以保證穿透寫操作的效率。
• 元數據規模上：層級目錄結構的性能與擴展性往往相互制約，很難同時將兩者做到極致。幾種加速方案都是在兩者間權衡的結果，具體可分為橫向擴展和垂直分層兩種思路：

加速層內橫向擴展：并行文件系統是按一定規則將全量元數據打散到多個數據節點來解決擴展問題，是完全去中心化的設計。緩存系統一般也支持類似子樹劃分的方式在多組元數據服務間擴展。但當集群規模很大、更新操作較多時，兩種做法都可能因節點間通信的增多而影響性能。云原生文件系統則取決于采用哪種元數據引擎，如果采用 Redis 這類引擎則規模上限通常只有一億左右，如果采用分布式 KV 引擎則可做到與對象存儲類似的擴展能力，但可能需要舍棄極致時延。

加速層與對象存儲間垂直分級：常見于緩存類方案，即加速層只緩存最熱的小部分元數據，較少訪問的大部分仍然保持在對象存儲層。這種做法整體擴展性接近對象存儲，不過當元數據不命中時時延波動較大。如果業務對元數據的訪問具有明顯的局部性特征，則適合采用這種方案。

4.2數據讀寫加速

數據讀寫是計算跟存儲交互最多的部分。如果讀寫慢于計算則會導致任務等待和算力浪費。尤其當面對價格不菲的 GPU 算力時，這個問題愈發受到關注。

對于對象存儲來說，影響讀寫性能的主要因素：一是存算分離架構導致的網絡距離和帶寬限速問題；二是 HDD 介質性能和存儲引擎能力的限制；三是較長的請求處理路徑對時延的影響。因此數據讀寫加速的思路也大致圍繞這幾個方面展開。

第一，近計算訪問：在分析元數據加速時已經提到，加速層近計算部署可以明顯縮短網絡距離，降低讀寫時延，對于數據面來說更是如此。并且對同一份數據的多次重復讀，可通過近計算緩存節省大量帶寬，避免對象存儲主動限速的影響。

第二，采用高規格硬件和優化的存儲引擎：加速層通常采用 NVME SSD 存儲介質、與之匹配的高性能單機引擎和 RDMA 高性能網絡，相對于直接訪問對象存儲可帶來數量級的時延降低。而在對象存儲層內部，一些產品也通過原生支持流式存儲引擎，相對過去的 Blob 引擎提供了更接近文件系統的讀寫表現。

第三，軟件架構和 I/O 鏈路優化：有了近計算網絡環境和高規格硬件，如何將它們充分利用起來，需要依靠加速層的軟件架構設計和 I/O 鏈路優化。在這一點上各產品的做法不盡相同，但基本思路不外乎兩點，提高擴展能力和縮短 I/O 路徑。以讀加速為例：

• 這里所說的擴展能力，指的是架構層面怎么將數據分布和讀請求均勻打散、充分并發，從而最大限度榨干所有硬件。

并行文件系統、緩存系統一般會將完整文件細粒度切分為若干數據塊或條帶，再按一定規則打散到多個存儲節點的多個盤。打散規則通常按哈希計算，因此能避免訪問鏈路上出現單點瓶頸。云原生文件系統也是將切塊后的數據寫到對象存儲，方便文件系統層以并發方式提高讀寫性能。

某些系統還支持多副本，客戶端可根據實時負載動態選擇合適的副本讀取。對于譬如超大規模詞典、模型分發等多實例啟動風暴的場景而言，多副本能進一步將 I/O 均勻擴散到整個資源池，避免因局部熱點導致的請求排隊和性能抖動。

• 而縮短 I/O 路徑，指的是怎么讓數據盡可能被就近獲取。
• 分布式層面，從對象存儲，到加速層數據節點的 SSD 和內存，再到計算節點本地的客戶端內存，數據會經歷從最慢到最快的多級流動。在各級配置合適的預取、預讀和緩存策略，讓可能被多次訪問的數據提前加載并駐留于更快一級，能夠降低后續讀取時延，減少帶寬消耗和觸發限速的可能性。
• 單機層面，過去為了實現簡單，一般直接基于內核提供的原生 FUSE、PageCache 等機制來實現客戶端讀寫邏輯。近年來的存儲加速系統越來越多地深入到與內核交互的地方進行優化，例如借助 virtiofs、零拷貝、用戶態緩存等機制大幅降低內核與用戶態文件系統間的通信開銷，本質上也可視為單機內部縮短 I/O 路徑的做法。

當然，對于寫加速也有類似的優化手段。例如緩存系統的單端寫，可先寫計算節點本地的內存和 SSD 即返回（縮短 I/O 路徑），然后異步將這些數據按不同區段并行寫入底層對象存儲的大資源池（提高擴展能力），從而成倍提升端到端寫吞吐。

4.3端到端提效

有了上面介紹的元數據和數據讀寫加速，還有一個關鍵問題是在業務流中如何將這些能力串起來、利用好，最終實現端到端提效。事實上，在對實際業務的長期觀察中發現，數據流轉不暢往往成為降低業務效率的更重要因素。

我們可從三個層面來分析這一問題。

第一，業務如何低成本接入：對象存儲通常提供 HTTP API 的訪問接口，但不論從性能還是兼容性來看，這種接口對大數據和 AI 業務都不夠友好。存儲加速產品往往會提供更低成本的接入方式。例如對于大數據，提供業界廣泛采用的 HCFS SDK 客戶端，可與 Hadoop 生態無縫對接；對于 AI，則提供 POSIX 兼容的掛載客戶端，使得基于本地盤和傳統自建存儲的數據科學家能將各類實驗和生產任務無感遷移上來，大大降低了業務的適配成本。

第二，單個業務環節內如何高效數據流轉：對于業務流中的某個具體節點，只有讓數據在合適的時機出現在合適的位置，才能發揮好存儲加速的作用。在這一點上，緩存系統通常能提供最為靈活的機制和策略，通過與上下層配合來優化數據調度和緩存效率。

• 向下與對象存儲深度集成，建立雙向數據關聯。早期產品只提供了手動指定目錄的數據加載和沉降方式，后來開始支持 Inventory 清單導入、周期性自動加載、增量同步、讀時按需加載、自動淘汰等豐富功能，有的產品進一步將策略開放給業務定制，例如根據文件名后綴、大小、路徑等規則實現更智能的數據流轉。
• 向上與計算引擎和調度框架配合，通過 pipeline 的方式進行數據調度。例如在大數據場景下，哪張表、哪些列需要載入加速層，可由計算引擎發起精準的調度指令。在 AI 場景下，訓練框架通過樣本列表，通知加速層提前準備下一輪需要用到的數據。在數據集超過加速層容量的情況下，通過這種方式可實現多輪訓練數據間的無感換入換出，從而利用有限資源實現透明的全量數據加速。

第三，多個業務環節間如何做到數據暢通：實際業務往往涉及上下游多個環節的配合。例如大數據 ETL 將一級輸出作為下一級的輸入，數據預處理的輸出作為 AI 訓練的輸入，訓練產出的模型作為推理的輸入等。這些業務節點間的數據流動和共享就是貫穿其中的關鍵。

• 并行文件系統、云原生文件系統這兩類方案以自身作為數據的訪問入口，通過副本式拷貝來建立與對象存儲數據的弱關聯。當多個業務節點需要從不同地域、不同入口分別訪問時，數據共享就不夠方便。
• 緩存系統這類方案，與對象存儲中的數據建立雙向強關聯，任何業務節點的寫入都可透傳到對象存儲底座。一些緩存產品還借助對象存儲的事件通知等機制讓這些更新近實時可見，這在需要頻繁交換數據的業務流中可帶來近乎透明的統一存儲底座使用體驗。

圖片

最后，回到本文開篇提到的案例，客戶 H 最終需要一個什么樣的數據湖存儲加速方案呢，除了技術因素之外，還有其他維度需要考慮嗎？