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

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

圖片

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

圖片

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

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

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

圖片

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

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

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

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

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

面對(duì)巨大的成本問(wèn)題，研發(fā)工程師們會(huì)提出什么樣的方案來(lái)解決呢？

圖片

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

圖片

3.4完備語(yǔ)義

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

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

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

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

不過(guò)在實(shí)際應(yīng)用中還需要考慮由此帶來(lái)的數(shù)據(jù)侵入性問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3端到端提效

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

我們可從三個(gè)層面來(lái)分析這一問(wèn)題。

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

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

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

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

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

圖片

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