基于DPU云盤掛載的Spark優(yōu)化解決方案

1.? 方案背景和挑戰(zhàn)

Apache Spark，作為當(dāng)今大數(shù)據(jù)處理領(lǐng)域的佼佼者，憑借其高效的分布式計(jì)算能力、內(nèi)存計(jì)算優(yōu)化以及強(qiáng)大的生態(tài)系統(tǒng)支持，已牢固確立其在業(yè)界的標(biāo)桿地位。Spark on Kubernetes（簡稱K8s）作為Spark與Kubernetes這一領(lǐng)先容器編排平臺(tái)深度融合的產(chǎn)物，不僅繼承了Spark的強(qiáng)大數(shù)據(jù)處理能力，還充分利用了Kubernetes在資源管理、服務(wù)發(fā)現(xiàn)和彈性伸縮方面的優(yōu)勢，正逐步引領(lǐng)大數(shù)據(jù)處理邁向更加靈活、高效的新紀(jì)元。

與此同時(shí)，隨著云計(jì)算技術(shù)的飛速發(fā)展，NVMe/TCP云盤作為一種創(chuàng)新的高性能存儲(chǔ)解決方案，憑借其在低延遲、高吞吐量以及易于集成到現(xiàn)代云架構(gòu)中的特點(diǎn)，日益受到大規(guī)模數(shù)據(jù)中心和云環(huán)境用戶的青睞。這種存儲(chǔ)方案通過TCP/IP協(xié)議實(shí)現(xiàn)遠(yuǎn)程N(yùn)VMe設(shè)備的直接訪問，極大地拓展了數(shù)據(jù)存取的邊界，但也隨之帶來了特定的技術(shù)挑戰(zhàn)。

具體而言，NVMe/TCP云盤在利用TCP/IP協(xié)議進(jìn)行數(shù)據(jù)交互時(shí)，不可避免地涉及到了復(fù)雜的數(shù)據(jù)包處理流程，包括用戶態(tài)與內(nèi)核態(tài)之間的頻繁數(shù)據(jù)拷貝、網(wǎng)絡(luò)報(bào)文的接收、峰值流量的處理以及協(xié)議棧的深入解析等。這一系列操作大幅增加了CPU的負(fù)擔(dān)，尤其是在高并發(fā)、大數(shù)據(jù)量場景下，大量CPU資源被非業(yè)務(wù)核心的數(shù)據(jù)包處理工作所占用，導(dǎo)致CPU資源利用率低下，甚至成為性能瓶頸。

當(dāng)Apache Spark試圖掛載并利用NVMe/TCP云盤進(jìn)行大規(guī)模數(shù)據(jù)處理時(shí)，上述挑戰(zhàn)便顯得尤為突出：

1、Spark作業(yè)在執(zhí)行過程中，若頻繁遭遇CPU資源被TCP/IP協(xié)議棧處理所擠占的情況，不僅會(huì)直接限制Spark任務(wù)的處理速度，還可能導(dǎo)致任務(wù)執(zhí)行延遲增加，進(jìn)而影響整個(gè)數(shù)據(jù)處理流水線的吞吐率和效率。

2、由于CPU資源的爭奪，Spark原本有望進(jìn)一步提升的磁盤I/O性能也受到了限制，難以充分發(fā)揮NVMe/TCP云盤應(yīng)有的高性能潛力。

為了解決Spark在掛載NVMe/TCP云盤時(shí)面臨的CPU資源占用過高和磁盤吞吐性能受限的問題，亟需探索并實(shí)施一系列優(yōu)化策略和技術(shù)方案。這可能包括但不限于：采用更高效的數(shù)據(jù)傳輸協(xié)議或技術(shù)（如RDMA），以減少CPU在數(shù)據(jù)拷貝和網(wǎng)絡(luò)處理上的負(fù)擔(dān)，提升數(shù)據(jù)傳輸性能；優(yōu)化Spark作業(yè)的調(diào)度與執(zhí)行策略，以更加合理地分配CPU資源；以及針對(duì)NVMe/TCP云盤特性進(jìn)行專門的性能調(diào)優(yōu)，如調(diào)整TCP窗口大小、優(yōu)化網(wǎng)絡(luò)隊(duì)列配置等。

RDMA技術(shù)允許數(shù)據(jù)在遠(yuǎn)程主機(jī)的內(nèi)存之間直接傳輸，無需經(jīng)過CPU處理，從而極大地降低了數(shù)據(jù)傳輸?shù)难舆t并減少了CPU的負(fù)載。這一特性直接解決了Spark和Kubernetes集群中，尤其是在使用NVMe-oF云盤時(shí)，因網(wǎng)絡(luò)傳輸效率低下而可能導(dǎo)致的性能瓶頸問題。

本方案通過DPU實(shí)現(xiàn)NVMe/RDMA的云盤掛載，從而提升Spark在云環(huán)境下處理大數(shù)據(jù)時(shí)的整體性能和效率。

2.? 整體方案概述

本方案采用云原生架構(gòu)，Spark采用Spark on Kubernetes部署模式，并且引入DPU為集群之上的容器提供存儲(chǔ)服務(wù)的卸載和加速，融合了云原生架構(gòu)與高性能存儲(chǔ)的優(yōu)勢。方案整體架構(gòu)如下圖所示：

l? 存儲(chǔ)集群把NVMe存儲(chǔ)設(shè)備以裸盤方式部署，計(jì)算節(jié)點(diǎn)通過硬件模擬向宿主機(jī)提供標(biāo)準(zhǔn)的nvme/virtio塊設(shè)備，對(duì)存儲(chǔ)協(xié)議的處理都卸載到DPU，提供硬件加速的NVMe over RDMA能力。

l? K8S平臺(tái)通過yusur-csi存儲(chǔ)插件提供基于DPU的云盤掛載能力。

l? 將Spark應(yīng)用部署在K8S集群之上，Spark Pod掛載DPU硬件加速的NVMe/RDMA云盤，以更低的資源消耗獲得更高的讀寫效率。

3.? 測試方法和結(jié)果

3.1. 軟件環(huán)境

軟件包/工具/數(shù)據(jù)集列表

3.2. 測試方案

Spark SQL是Spark開發(fā)常用的編程接口，本方案使用Spark SQL運(yùn)行一個(gè)聚合查詢，SQL語句如下：

Spark使用Spark on Kubernetes部署模式，為了數(shù)據(jù)加載的完整性，關(guān)閉Spark SQL的謂詞下推機(jī)制。輸入數(shù)據(jù)是Parquet文件，包含一個(gè)Long類型的數(shù)據(jù)列，所有輸入文件大小之和是45G。

Spark 分配4個(gè)Executor（Pod）,每個(gè)Executor分配8個(gè)core，Spark核心參數(shù)如下

3.3. 節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)?/h3>

測試環(huán)境包含一個(gè)存儲(chǔ)節(jié)點(diǎn)和一個(gè)計(jì)算節(jié)點(diǎn)，各有一個(gè)DPU加速卡，兩個(gè)節(jié)點(diǎn)之間通過100G交換機(jī)連接。測試環(huán)境節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)?/a>如下圖所示：

對(duì)于NVMe/TCP云盤，DPU使用TCP協(xié)議連接存儲(chǔ)服務(wù)，不卸載存儲(chǔ)協(xié)議的處理，這種情況下，DPU充當(dāng)普通網(wǎng)卡。

對(duì)于NVMe/RDMA云盤，DPU使用RDMA協(xié)議連接存儲(chǔ)服務(wù)，把存儲(chǔ)協(xié)議卸載到DPU硬件。

3.4. 關(guān)注指標(biāo)

本方案重點(diǎn)關(guān)注CPU資源的使用率，包括系統(tǒng)內(nèi)核CPU使用率和用戶態(tài)CPU使用率。

3.5. 測試結(jié)果

3.4.1性能數(shù)據(jù)

Spark 分配4個(gè)Executor（Pod）,每個(gè)Executor分配8個(gè)core。 相比于掛載云盤，掛載NVMe/RDMA云盤，Spark數(shù)據(jù)吞吐性能提升22.2%，數(shù)據(jù)加載時(shí)間縮短18.2%。

不同存儲(chǔ)云盤下，數(shù)據(jù)加載時(shí)間及E2E時(shí)間對(duì)比如下圖所示：

Spark磁盤吞吐性能對(duì)比如下圖所示：

具體數(shù)據(jù)見下表：

3.4.2資源使用數(shù)據(jù)

運(yùn)行過程資源監(jiān)控圖如下圖所示：

從監(jiān)控圖發(fā)現(xiàn)內(nèi)存使用波動(dòng)較少，本方案內(nèi)核態(tài)CPU使用率平均減少17.14%，用戶態(tài)CPU使用率平均增加7.39%，平均CPU資源消耗如下圖所示：

平均CPU資源占用數(shù)據(jù)如下表所示

3.4.3測試數(shù)據(jù)分析

本次試驗(yàn)通過測試Spark SQL讀取Parquet文件做聚合計(jì)算，分配4個(gè)Executor（Pod）,每個(gè)Executor分配8個(gè)core，也就是說實(shí)際運(yùn)行過程中并行度為32。

相比于掛載NVMe/TCP云盤，掛載NVMe/RDMA云盤可使Spark數(shù)據(jù)吞吐性能提升22.2%，數(shù)據(jù)加載時(shí)間縮短18.2%。

從運(yùn)行過程中的資源監(jiān)控圖來看，掛載NVMe/RDMA云盤，Spark消耗更少的內(nèi)核態(tài)CPU資源。內(nèi)核態(tài)CPU資源使用率減少17.14%，但數(shù)據(jù)加載性能更高，因此占用了更多的用戶態(tài)CPU資源。這與RDMA本身的特點(diǎn)是相符的，RDMA 將協(xié)議棧的實(shí)現(xiàn)下沉至DPU硬件，繞過內(nèi)核直接訪問遠(yuǎn)程內(nèi)存中的數(shù)據(jù)。

綜合用戶態(tài)CPU和內(nèi)核態(tài)CPU使用情況，不管是掛載NVMe/TCP云盤還是掛載NVMe/RDMA云盤，Spark的資源消耗都在一個(gè)水平上，但是掛載NVMe/RDMA云盤時(shí)，Spark運(yùn)行速度更快，對(duì)資源占用時(shí)間更短，所以整體來看，本方案事實(shí)上節(jié)省了系統(tǒng)CPU資源。

4.? 優(yōu)勢總結(jié)

本方案通過引入DPU（數(shù)據(jù)處理單元）實(shí)現(xiàn)NVMe/RDMA云盤掛載，以優(yōu)化Spark在云環(huán)境下處理大數(shù)據(jù)的性能和效率，其優(yōu)勢可以總結(jié)為以下幾點(diǎn)：

1、顯著提升數(shù)據(jù)吞吐性能：

采用NVMe/RDMA技術(shù)相比于傳統(tǒng)的NVMe/TCP，能夠大幅提升數(shù)據(jù)在云環(huán)境中的傳輸速度。本方案測試結(jié)果顯示，數(shù)據(jù)吞吐性能提升了22.2%，這意味著Spark作業(yè)在處理大規(guī)模數(shù)據(jù)集時(shí)能夠更快地讀取和寫入數(shù)據(jù)，從而顯著減少數(shù)據(jù)處理的總時(shí)間。

2、大幅縮短數(shù)據(jù)加載時(shí)間：

數(shù)據(jù)加載是大數(shù)據(jù)處理流程中的關(guān)鍵瓶頸之一。通過NVMe/RDMA云盤的掛載，數(shù)據(jù)加載時(shí)間縮短了18.2%，這對(duì)于需要頻繁訪問大量數(shù)據(jù)集的Spark應(yīng)用來說尤為重要，可以顯著提高應(yīng)用的響應(yīng)速度和整體效率。

3、減少非業(yè)務(wù)負(fù)載對(duì)CPU資源的占用：

NVMe/RDMA技術(shù)通過減少數(shù)據(jù)傳輸過程中對(duì)CPU的依賴，將數(shù)據(jù)傳輸?shù)呢?fù)載從主機(jī)CPU轉(zhuǎn)移到DPU上。這不僅降低了主機(jī)CPU的負(fù)載，還使得CPU資源能夠更多地用于數(shù)據(jù)處理等核心業(yè)務(wù)邏輯，從而提升整體的系統(tǒng)效率和性能。

4、優(yōu)化資源利用率：

由于數(shù)據(jù)加載和傳輸速度的提升，Spark作業(yè)可以更快地完成數(shù)據(jù)處理任務(wù)，從而提高了云資源的利用率。云環(huán)境中的資源（如CPU、內(nèi)存、存儲(chǔ)）通常按使用量計(jì)費(fèi)，因此更快的處理速度意味著更低的成本。

綜上所述，本方案通過引入DPU實(shí)現(xiàn)NVMe/RDMA云盤掛載，為Spark在云環(huán)境下處理大數(shù)據(jù)提供了全面的性能優(yōu)化，顯著提升了數(shù)據(jù)吞吐性能、縮短了數(shù)據(jù)加載時(shí)間、減少了CPU資源占用，并優(yōu)化了系統(tǒng)的資源利用率。

本方案來自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專家組成，不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，還對(duì)行業(yè)趨勢具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時(shí)降低運(yùn)營成本。