• 正文
    • 1.? 方案背景和挑戰(zhàn)
    • 2.? 整體方案概述
    • 3.? 測試方法和結(jié)果
    • 4.? 優(yōu)勢總結(jié)
  • 推薦器件
  • 相關(guān)推薦
申請入駐 產(chǎn)業(yè)圖譜

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

2024/08/14
2178
加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點資訊討論

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

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

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

具體而言,NVMe/TCP云盤在利用TCP/IP協(xié)議進(jìn)行數(shù)據(jù)交互時,不可避免地涉及到了復(fù)雜的數(shù)據(jù)包處理流程,包括用戶態(tài)與內(nèi)核態(tài)之間的頻繁數(shù)據(jù)拷貝、網(wǎng)絡(luò)報文的接收、峰值流量的處理以及協(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ù)處理時,上述挑戰(zhàn)便顯得尤為突出:

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

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

為了解決Spark在掛載NVMe/TCP云盤時面臨的CPU資源占用過高和磁盤吞吐性能受限的問題,亟需探索并實施一系列優(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資源;以及針對NVMe/TCP云盤特性進(jìn)行專門的性能調(diào)優(yōu),如調(diào)整TCP窗口大小、優(yōu)化網(wǎng)絡(luò)隊列配置等。

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

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

2.? 整體方案概述

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

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

l? K8S平臺通過yusur-csi存儲插件提供基于DPU的云盤掛載能力。

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

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

3.1. 軟件環(huán)境

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

名稱 版本 來源 備注
Spark 3.4.2 社區(qū)開源項目 開源大數(shù)據(jù)處理框架
Java 17.0.10 (Eclipse Adoptium) 開源項目Spark自帶 Spark鏡像內(nèi)置的依賴環(huán)境
containerd 1.6.21 社區(qū)開源項目 容器運行時
Kubernetes v1.26.5 社區(qū)開源項目 開源容器編排框架
yusur-csi V6.0 自研 Kubernetes存儲插件,為裸金屬提供云盤掛載功能。

3.2. 測試方案

Spark SQL是Spark開發(fā)常用的編程接口,本方案使用Spark SQL運行一個聚合查詢,SQL語句如下:

select count(1) from tblong where id=1

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

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

$SPARK_HOME/bin/spark-submit

--master k8s://https://10.0.151.186:6443

--deploy-mode cluster

--driver-cores 4

--driver-memory 40G

--executor-cores 8

--executor-memory 40G

--num-executors 4

--conf spark.executor.memoryOverhead=2G

--conf spark.dynamicAllocation.enabled=false

--conf spark.sql.parquet.filterPushdown=false

--conf spark.kubernetes.namespace=spark

--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark

--conf spark.kubernetes.container.image=harbor.yusur.tech/bigdata/spark:spark3.2.0-hadoop3

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

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

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

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

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

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

指標(biāo)名稱 指標(biāo)描述
數(shù)據(jù)加載時間(單位:秒) 對于Spark SQL任務(wù),對應(yīng)Scan算子時間
E2E時間(單位:秒) 從數(shù)據(jù)加載開始到結(jié)果輸出結(jié)束的時間間隔
磁盤吞吐量(單位:MB/s) 磁盤在單位時間內(nèi)能夠讀寫的數(shù)據(jù)總量,通過fio工具測試
內(nèi)核態(tài)CPU使用率 主機(jī)CPU運行在用戶態(tài)的時間占比,通過top命令采集
用戶態(tài)CPU使用率 主機(jī)CPU運行在用戶態(tài)的時間占比,通過top命令采集

3.5. 測試結(jié)果

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

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

不同存儲云盤下,數(shù)據(jù)加載時間及E2E時間對比如下圖所示:

Spark磁盤吞吐性能對比如下圖所示:

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

對比指標(biāo) NVMe/TCP云盤 DPU NVMe/RDMA云盤
數(shù)據(jù)加載時間(秒) 11 9
E2E時間(秒) 12 10
磁盤吞吐(MB/s) 4179.78 5108.62

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

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

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

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

存儲云盤類型 sys_cpu(均值) user_cpu(均值) 合計
?NVMe/TCP云盤 12.66% 26.25% 38.91%
NVMe/RDMA云盤 10.49% 28.19% 38.68%

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

本次試驗通過測試Spark SQL讀取Parquet文件做聚合計算,分配4個Executor(Pod),每個Executor分配8個core,也就是說實際運行過程中并行度為32。

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

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

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

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

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

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ù)據(jù),從而顯著減少數(shù)據(jù)處理的總時間。

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

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

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

NVMe/RDMA技術(shù)通過減少數(shù)據(jù)傳輸過程中對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)存、存儲)通常按使用量計費,因此更快的處理速度意味著更低的成本。

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

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

推薦器件

更多器件
器件型號 數(shù)量 器件廠商 器件描述 數(shù)據(jù)手冊 ECAD模型 風(fēng)險等級 參考價格 更多信息
AT89C51CC03CA-SLSUM 1 Microchip Technology Inc IC MCU 8BIT 64KB FLASH 44PLCC

ECAD模型

下載ECAD模型
$7.71 查看
STM32F427VIT6 1 STMicroelectronics High-performance advanced line, Arm Cortex-M4 core with DSP and FPU, 2 Mbytes of Flash memory, 180 MHz CPU, ART Accelerator, Chrom-ART Accelerator,FSMC

ECAD模型

下載ECAD模型
$22.31 查看
MCIMX535DVV1C 1 Freescale Semiconductor i.MX53 32-bit MPU, ARM Cortex-A8 core, 1GHz, PBGA 529
$36.91 查看
中科馭數(shù)

中科馭數(shù)

中科馭數(shù)致力于專用處理器研發(fā),為智能計算提供芯片和產(chǎn)品解決方案。圍繞DPU芯片打造了智能網(wǎng)卡系列產(chǎn)品和解決方案。

中科馭數(shù)致力于專用處理器研發(fā),為智能計算提供芯片和產(chǎn)品解決方案。圍繞DPU芯片打造了智能網(wǎng)卡系列產(chǎn)品和解決方案。收起

查看更多

相關(guān)推薦