2154
1.? 方案背景和挑戰(zhàn)
Apache Spark，作為當今大數據處理領域的佼佼者，憑借其高效的分布式計算能力、內存計算優(yōu)化以及強大的生態(tài)系統(tǒng)支持，已牢固確立其在業(yè)界的標桿地位。Spark on Kubernetes（簡稱K8s）作為Spark與Kubernetes這一領先容器編排平臺深度融合的產物，不僅繼承了Spark的強大數據處理能力，還充分利用了Kubernetes在資源管理、服務發(fā)現和彈性伸縮方面的優(yōu)勢，正逐步引領大數據處理邁向更加靈活、高效的新紀元。
與此同時，隨著云計算技術的飛速發(fā)展，NVMe/TCP云盤作為一種創(chuàng)新的高性能存儲解決方案，憑借其在低延遲、高吞吐量以及易于集成到現代云架構中的特點，日益受到大規(guī)模數據中心和云環(huán)境用戶的青睞。這種存儲方案通過TCP/IP協(xié)議實現遠程NVMe設備的直接訪問，極大地拓展了數據存取的邊界，但也隨之帶來了特定的技術挑戰(zhàn)。
具體而言，NVMe/TCP云盤在利用TCP/IP協(xié)議進行數據交互時，不可避免地涉及到了復雜的數據包處理流程，包括用戶態(tài)與內核態(tài)之間的頻繁數據拷貝、網絡報文的接收、峰值流量的處理以及協(xié)議棧的深入解析等。這一系列操作大幅增加了CPU的負擔，尤其是在高并發(fā)、大數據量場景下，大量CPU資源被非業(yè)務核心的數據包處理工作所占用，導致CPU資源利用率低下，甚至成為性能瓶頸。
當Apache Spark試圖掛載并利用NVMe/TCP云盤進行大規(guī)模數據處理時，上述挑戰(zhàn)便顯得尤為突出：
1、Spark作業(yè)在執(zhí)行過程中，若頻繁遭遇CPU資源被TCP/IP協(xié)議棧處理所擠占的情況，不僅會直接限制Spark任務的處理速度，還可能導致任務執(zhí)行延遲增加，進而影響整個數據處理流水線的吞吐率和效率。
2、由于CPU資源的爭奪，Spark原本有望進一步提升的磁盤I/O性能也受到了限制，難以充分發(fā)揮NVMe/TCP云盤應有的高性能潛力。
為了解決Spark在掛載NVMe/TCP云盤時面臨的CPU資源占用過高和磁盤吞吐性能受限的問題，亟需探索并實施一系列優(yōu)化策略和技術方案。這可能包括但不限于：采用更高效的數據傳輸協(xié)議或技術（如RDMA），以減少CPU在數據拷貝和網絡處理上的負擔，提升數據傳輸性能；優(yōu)化Spark作業(yè)的調度與執(zhí)行策略，以更加合理地分配CPU資源；以及針對NVMe/TCP云盤特性進行專門的性能調優(yōu)，如調整TCP窗口大小、優(yōu)化網絡隊列配置等。
RDMA技術允許數據在遠程主機的內存之間直接傳輸，無需經過CPU處理，從而極大地降低了數據傳輸的延遲并減少了CPU的負載。這一特性直接解決了Spark和Kubernetes集群中，尤其是在使用NVMe-oF云盤時，因網絡傳輸效率低下而可能導致的性能瓶頸問題。
本方案通過DPU實現NVMe/RDMA的云盤掛載，從而提升Spark在云環(huán)境下處理大數據時的整體性能和效率。
2.? 整體方案概述
本方案采用云原生架構，Spark采用Spark on Kubernetes部署模式，并且引入DPU為集群之上的容器提供存儲服務的卸載和加速，融合了云原生架構與高性能存儲的優(yōu)勢。方案整體架構如下圖所示：
l? 存儲集群把NVMe存儲設備以裸盤方式部署，計算節(jié)點通過硬件模擬向宿主機提供標準的nvme/virtio塊設備，對存儲協(xié)議的處理都卸載到DPU，提供硬件加速的NVMe over RDMA能力。
l? K8S平臺通過yusur-csi存儲插件提供基于DPU的云盤掛載能力。
l? 將Spark應用部署在K8S集群之上，Spark Pod掛載DPU硬件加速的NVMe/RDMA云盤，以更低的資源消耗獲得更高的讀寫效率。
3.? 測試方法和結果
3.1. 軟件環(huán)境
軟件包/工具/數據集列表
| 名稱 | 版本 | 來源 | 備注 |
| Spark | 3.4.2 | 社區(qū)開源項目 | 開源大數據處理框架 |
| Java | 17.0.10 (Eclipse Adoptium) | 開源項目Spark自帶 | Spark鏡像內置的依賴環(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部署模式，為了數據加載的完整性，關閉Spark SQL的謂詞下推機制。輸入數據是Parquet文件，包含一個Long類型的數據列，所有輸入文件大小之和是45G。
Spark 分配4個Executor（Pod）,每個Executor分配8個core，Spark核心參數如下
| $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é)點網絡拓撲
測試環(huán)境包含一個存儲節(jié)點和一個計算節(jié)點，各有一個DPU加速卡，兩個節(jié)點之間通過100G交換機連接。測試環(huán)境節(jié)點網絡拓撲如下圖所示：
對于NVMe/TCP云盤，DPU使用TCP協(xié)議連接存儲服務，不卸載存儲協(xié)議的處理，這種情況下，DPU充當普通網卡。
對于NVMe/RDMA云盤，DPU使用RDMA協(xié)議連接存儲服務，把存儲協(xié)議卸載到DPU硬件。
3.4. 關注指標
本方案重點關注CPU資源的使用率，包括系統(tǒng)內核CPU使用率和用戶態(tài)CPU使用率。
| 指標名稱 | 指標描述 |
| 數據加載時間(單位：秒) | 對于Spark SQL任務，對應Scan算子時間 |
| E2E時間(單位：秒) | 從數據加載開始到結果輸出結束的時間間隔 |
| 磁盤吞吐量(單位：MB/s) | 磁盤在單位時間內能夠讀寫的數據總量,通過fio工具測試 |
| 內核態(tài)CPU使用率 | 主機CPU運行在用戶態(tài)的時間占比，通過top命令采集 |
| 用戶態(tài)CPU使用率 | 主機CPU運行在用戶態(tài)的時間占比，通過top命令采集 |
3.5. 測試結果
3.4.1性能數據
Spark 分配4個Executor（Pod）,每個Executor分配8個core。 相比于掛載云盤，掛載NVMe/RDMA云盤，Spark數據吞吐性能提升22.2%，數據加載時間縮短18.2%。
不同存儲云盤下，數據加載時間及E2E時間對比如下圖所示：
Spark磁盤吞吐性能對比如下圖所示：
具體數據見下表：
| 對比指標 | NVMe/TCP云盤 | DPU NVMe/RDMA云盤 |
| 數據加載時間(秒) | 11 | 9 |
| E2E時間(秒) | 12 | 10 |
| 磁盤吞吐(MB/s) | 4179.78 | 5108.62 |
3.4.2資源使用數據
運行過程資源監(jiān)控圖如下圖所示：
從監(jiān)控圖發(fā)現內存使用波動較少，本方案內核態(tài)CPU使用率平均減少17.14%，用戶態(tài)CPU使用率平均增加7.39%，平均CPU資源消耗如下圖所示：
平均CPU資源占用數據如下表所示
| 存儲云盤類型 | sys_cpu（均值） | user_cpu（均值） | 合計 |
| ?NVMe/TCP云盤 | 12.66% | 26.25% | 38.91% |
| NVMe/RDMA云盤 | 10.49% | 28.19% | 38.68% |
3.4.3測試數據分析
本次試驗通過測試Spark SQL讀取Parquet文件做聚合計算，分配4個Executor（Pod）,每個Executor分配8個core，也就是說實際運行過程中并行度為32。
相比于掛載NVMe/TCP云盤，掛載NVMe/RDMA云盤可使Spark數據吞吐性能提升22.2%，數據加載時間縮短18.2%。
從運行過程中的資源監(jiān)控圖來看，掛載NVMe/RDMA云盤，Spark消耗更少的內核態(tài)CPU資源。內核態(tài)CPU資源使用率減少17.14%，但數據加載性能更高，因此占用了更多的用戶態(tài)CPU資源。這與RDMA本身的特點是相符的，RDMA 將協(xié)議棧的實現下沉至DPU硬件，繞過內核直接訪問遠程內存中的數據。
綜合用戶態(tài)CPU和內核態(tài)CPU使用情況，不管是掛載NVMe/TCP云盤還是掛載NVMe/RDMA云盤，Spark的資源消耗都在一個水平上，但是掛載NVMe/RDMA云盤時，Spark運行速度更快，對資源占用時間更短，所以整體來看，本方案事實上節(jié)省了系統(tǒng)CPU資源。
4.? 優(yōu)勢總結
本方案通過引入DPU（數據處理單元）實現NVMe/RDMA云盤掛載，以優(yōu)化Spark在云環(huán)境下處理大數據的性能和效率，其優(yōu)勢可以總結為以下幾點：
1、顯著提升數據吞吐性能：
采用NVMe/RDMA技術相比于傳統(tǒng)的NVMe/TCP，能夠大幅提升數據在云環(huán)境中的傳輸速度。本方案測試結果顯示，數據吞吐性能提升了22.2%，這意味著Spark作業(yè)在處理大規(guī)模數據集時能夠更快地讀取和寫入數據，從而顯著減少數據處理的總時間。
2、大幅縮短數據加載時間：
數據加載是大數據處理流程中的關鍵瓶頸之一。通過NVMe/RDMA云盤的掛載，數據加載時間縮短了18.2%，這對于需要頻繁訪問大量數據集的Spark應用來說尤為重要，可以顯著提高應用的響應速度和整體效率。
3、減少非業(yè)務負載對CPU資源的占用：
NVMe/RDMA技術通過減少數據傳輸過程中對CPU的依賴，將數據傳輸的負載從主機CPU轉移到DPU上。這不僅降低了主機CPU的負載，還使得CPU資源能夠更多地用于數據處理等核心業(yè)務邏輯，從而提升整體的系統(tǒng)效率和性能。
4、優(yōu)化資源利用率：
由于數據加載和傳輸速度的提升，Spark作業(yè)可以更快地完成數據處理任務，從而提高了云資源的利用率。云環(huán)境中的資源（如CPU、內存、存儲）通常按使用量計費，因此更快的處理速度意味著更低的成本。
綜上所述，本方案通過引入DPU實現NVMe/RDMA云盤掛載，為Spark在云環(huán)境下處理大數據提供了全面的性能優(yōu)化，顯著提升了數據吞吐性能、縮短了數據加載時間、減少了CPU資源占用，并優(yōu)化了系統(tǒng)的資源利用率。
本方案來自于中科馭數軟件研發(fā)團隊，團隊核心由一群在云計算、數據中心架構、高性能計算領域深耕多年的業(yè)界資深架構師和技術專家組成，不僅擁有豐富的實戰(zhàn)經驗，還對行業(yè)趨勢具備敏銳的洞察力，該團隊致力于探索、設計、開發(fā)、推廣可落地的高性能云計算解決方案，幫助最終客戶加速數字化轉型，提升業(yè)務效能，同時降低運營成本。
下載ECAD模型
