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

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

圖片

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

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

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

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

但是，數(shù)據(jù)正是大模型時代的黃金和石油，當(dāng)業(yè)務(wù)希望從這些寶貴的原始數(shù)據(jù)中重新構(gòu)建智能、提煉新的價值時，往往發(fā)現(xiàn)為時已晚。

1.數(shù)據(jù)湖存儲成為云原生時代的事實標(biāo)準(zhǔn)

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

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

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

2.為什么還需要給數(shù)據(jù)湖存儲加速？

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

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

圖片

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

圖片

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

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

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

圖片

3.數(shù)據(jù)湖存儲加速的誕生和發(fā)展

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

3.1并行文件系統(tǒng)

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

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

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

圖片

3.2兼顧成本：并行文件系統(tǒng) + 對象存儲

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

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

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

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

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

圖片

3.3透明流轉(zhuǎn)：對象存儲 + 緩存系統(tǒng)

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

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

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

Alluxio 這類真正的緩存系統(tǒng)用于對象存儲加速，相對于采用并行文件系統(tǒng)的加速方案，最大的區(qū)別在于兩層間的數(shù)據(jù)關(guān)聯(lián)和雙向流轉(zhuǎn)完全透明化，從而能做到：

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

當(dāng)然，緩存系統(tǒng)也有其固有的問題，在使用中需要注意：

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

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

圖片

3.4完備語義

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

3.4.1解法一：云原生文件系統(tǒng) + 對象存儲

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

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

不過在實際應(yīng)用中還需要考慮由此帶來的數(shù)據(jù)侵入性問題。

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

3.4.2解法二：文件對象融合 + 緩存系統(tǒng)

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

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

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

4.數(shù)據(jù)湖存儲加速都在解決哪些關(guān)鍵問題？

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

4.1元數(shù)據(jù)加速

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

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

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

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

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

4.2數(shù)據(jù)讀寫加速

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

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

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

第二，采用高規(guī)格硬件和優(yōu)化的存儲引擎：加速層通常采用 NVME SSD 存儲介質(zhì)、與之匹配的高性能單機引擎和 RDMA 高性能網(wǎng)絡(luò)，相對于直接訪問對象存儲可帶來數(shù)量級的時延降低。而在對象存儲層內(nèi)部，一些產(chǎn)品也通過原生支持流式存儲引擎，相對過去的 Blob 引擎提供了更接近文件系統(tǒng)的讀寫表現(xiàn)。

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

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

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

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

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

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

4.3端到端提效

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

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

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

第二，單個業(yè)務(wù)環(huán)節(jié)內(nèi)如何高效數(shù)據(jù)流轉(zhuǎn)：對于業(yè)務(wù)流中的某個具體節(jié)點，只有讓數(shù)據(jù)在合適的時機出現(xiàn)在合適的位置，才能發(fā)揮好存儲加速的作用。在這一點上，緩存系統(tǒng)通常能提供最為靈活的機制和策略，通過與上下層配合來優(yōu)化數(shù)據(jù)調(diào)度和緩存效率。

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

第三，多個業(yè)務(wù)環(huán)節(jié)間如何做到數(shù)據(jù)暢通：實際業(yè)務(wù)往往涉及上下游多個環(huán)節(jié)的配合。例如大數(shù)據(jù) ETL 將一級輸出作為下一級的輸入，數(shù)據(jù)預(yù)處理的輸出作為 AI 訓(xùn)練的輸入，訓(xùn)練產(chǎn)出的模型作為推理的輸入等。這些業(yè)務(wù)節(jié)點間的數(shù)據(jù)流動和共享就是貫穿其中的關(guān)鍵。

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

圖片

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