在單機 CPU/GPU 內(nèi)存足以容納的數(shù)據(jù)，在規(guī)?；瘮?shù)據(jù)集面前已經(jīng)無法被內(nèi)存容納后，意味著每個大規(guī)模數(shù)據(jù)集的集群都需要面對大數(shù)據(jù)集的分區(qū)、緩存和節(jié)點通訊協(xié)同問題，更不用提其中的錯誤處理，意味著要像傳統(tǒng)大數(shù)據(jù)系統(tǒng)一樣構(gòu)建（但完全不同的性能需求）。
GPU 的存儲訪問
在數(shù)據(jù)訪問上，在幾年前就擁有了 GPUDirect Storage，意味著 GPU 可以直接通過 NVMe over Fabric 協(xié)議訪問存儲，而不需要通過 CPU 參與并帶來額外的內(nèi)存拷貝。在去年開始，GPUDirect Async Kernel Initiated Storage （GPUDirect 異步內(nèi)核啟動的存儲）技術(shù)更進一步減少了 CPU 和 GPU 的同步開銷，使得 GPU 可以直接向內(nèi)核發(fā)起請求，而不需要 CPU 代理發(fā)起。因此，GPU 對存儲的單次訪問來說，已經(jīng)非常高效。
在 Nvidia CUDA 生態(tài)中，已有 NVSHMEM（如下圖所示）實現(xiàn)了 GPU 之間的內(nèi)存數(shù)據(jù)通信，屏蔽了 NVLink/PCI/Infiniband/RoCE/Slingshot/EFA 的具體傳輸實現(xiàn)，極大幫助了 GPU 集群協(xié)同計算的效率，而在存儲方面仍舊沒有對應的 API 和實現(xiàn)，使得 GPU 總要面對十分具體的存儲傳輸和協(xié)同。這意味著需要提供一套新的 API 來處理大數(shù)據(jù)集的訪問問題。
每個 GPU 線程都是存儲訪問的單元，意味著隨著 GPU 并發(fā)度的不斷提高，在一些場景，例如目前 GPU 已經(jīng)直接支持的基于圖的數(shù)據(jù)節(jié)點遍歷，通過 PCIe 的存儲 IO 處理需要高效的手段才能應對。
GNN 訓練的限制
例如現(xiàn)有的 GNN 框架在遇到無法完全放入內(nèi)存的數(shù)據(jù)集時，會直接通過內(nèi)存映射特征向量文件到 CPU 虛擬地址空間，提供一種無限虛擬內(nèi)存的概念，使得 CPU 上的節(jié)點特征聚合計算可以在所請求的特征向量不在 CPU 內(nèi)存中時觸發(fā) page fault。如下圖所示，在節(jié)點特征聚合階段，CPU 訪問映射在其虛擬內(nèi)存空間的節(jié)點特征，當這些特征不在 Page Cache 中時，OS 會從存儲中將包含被訪問特征的頁面帶入 CPU 內(nèi)存。
不幸的是，MMAP 方法使得特征聚合成為整個訓練流程中最糟糕的瓶頸。針對 GNN 訓練執(zhí)行的每個階段的性能分析顯示，迭代時間明顯受到節(jié)點聚合階段的限制，正如下圖所示。例如在評估中使用的最大的兩個圖—— IGB-Full 和 IGBH-Full，其訓練階段幾乎看不見。這是因為對于大規(guī)模圖，OOM 的額外成本加劇了數(shù)據(jù)準備吞吐量和模型訓練吞吐量之間的差距。因此，改善 GNN 訓練性能的關(guān)鍵是大幅加速特征聚合階段（即數(shù)據(jù)準備階段）。
隨著新興的應用領(lǐng)域拓展，更多的應用場景都在面對類似的問題：
這些應用都形成了共同的需求：
SCADA 項目的提出
基于此，Nvidia 在 2022 年開始，基于大內(nèi)存和存儲系統(tǒng)的聯(lián)動，提出了 SCADA（Scaled accelerated data access ） 系統(tǒng)，面向 GPU 應用的大規(guī)模數(shù)據(jù)集訪問需求而設(shè)計。
SCADA 的設(shè)計面向以下四個原則：
針對這些方面，SCADA 主要實現(xiàn)了創(chuàng)新的數(shù)據(jù)加載和管理機制，這里有幾個關(guān)鍵因素：
上圖是整個 SCADA 的服務邏輯，首先 SCADA 會根據(jù)提供的頭文件里的數(shù)據(jù)結(jié)構(gòu)來初始化，目前支持 C++ 模版方式定義數(shù)據(jù)結(jié)構(gòu)，同時由應用自己來管理內(nèi)存，SCADA 提供分配和釋放數(shù)據(jù)結(jié)構(gòu)的 API。CPU 上的應用讀取所有數(shù)據(jù)，再通過 GPU 線程寫數(shù)據(jù)到私有的 NVMe。SCADA 會提供連續(xù)數(shù)組 API 來供應用讀取這些數(shù)據(jù)。
下圖展示了一個利用 SCADA 的系統(tǒng)整體架構(gòu)示例，通過 cuGraph 適配了 SCADA 框架，無需修改應用。整個訓練數(shù)據(jù)無論大小都可以得到執(zhí)行，且無需管理內(nèi)存、緩存、分區(qū)等問題。
性能評估
在一個基準測試中，對比 MMAP 方法，啟用 SCADA 后，整體性能提升達到了 26 倍以上。同時，相比之前 CPU 驅(qū)動的 IO 并發(fā)度，SCADA 極大提升了針對存儲設(shè)備的并發(fā) 10-100X，甚至達到了 10000 的 IO 并發(fā)度。
從 IO 角度來分析，下表展示了通過 SCADA 的緩存和 IO 匯聚成果，成功將瓶頸從存儲 IO 能力轉(zhuǎn)移到了 GPU 節(jié)點本身：
XSKY 觀點
SCADA 目前仍然是 Nvidia CUDA 體系的實驗性項目，正在跟應用開發(fā)者協(xié)作更多的數(shù)據(jù)結(jié)構(gòu)，如 KV、VectorDB、dataframe。在存儲方面，通過 SCADA 帶來了更高并發(fā) IO 后，可以提供更高效和細粒度的事務支持。另外，塊和文件系統(tǒng)的統(tǒng)一使用也成為必需，靈活運用塊的高性能 IO 和文件系統(tǒng)的共享能力使得 GPU 應用的大數(shù)據(jù)集問題大大緩解。另外，SCADA 實際上是過去 Big Memory 的 GPU 場景衍生，其差異是充分考慮了 GPU 的生態(tài)能力，使得跟 GPU 應用結(jié)合后會有更顯著的性能提升。
這些對于 XSKY 的全共享架構(gòu)（XSEA）都是極好的匹配，更好的支持 GPU 的高并發(fā)、大帶寬的場景需求。
