根据DPU云盘挂载的Spark优化解决方案
1. 计划布景和应战。
Apache Spark,作为当今大数据处理范畴的佼佼者,凭仗其高效的分布式核算才能、内存核算优化以及强壮的生态体系支撑,已牢固确立其在业界的标杆位置。Spark on Kuberne。te。s(简称K8s)作为Spark与Kubernetes这一抢先容器编列渠道深度交融的产品,不只承继了Spark的强壮数据处理才能,还充分运用了Kubernetes在资源管理、服务发现和弹性弹性方面的优势,正逐渐引领大数据处理迈向愈加灵敏、高效的新纪元。
与此一起,跟着。云核算。技能的飞速发展,NVMe/TCP云盘作为一种立异的高功用存储处理计划,凭仗其在低推迟、高吞吐量以及易于集成到现代云架构中的特色,日益遭到大规模数据。中心。和云环境用户的喜爱。这种存储计划经过TCP/IP协议完结长途NVMe设备的直接拜访,极大地拓宽了数据存取的鸿沟,但也随之带来了特定的技能应战。
详细而言,NVMe/TCP云盘在运用TCP/IP协议进行数据交互时,不可避免地触及到了杂乱的数据包处理流程,包含用户态与内核态之间的频频数据复制、。网络。报文的接纳、峰值流量的处理以及协议栈的深化解析等。这一系列操作大幅添加了。CPU。的担负,尤其是在高并发、大数据量场景下,很多CPU资源被非事务中心的数据包处理工作所占用,导致CPU资源运用率低下,乃至成为功用瓶颈。
当Apache Spark企图挂载并运用NVMe/TCP云盘进行大规模数据处理时,上述应战便显得尤为杰出:
1、Spark作业在履行进程中,若频频遭受CPU资源被TCP/IP协议栈处理所抢占的状况,不只会直接约束Spark使命的处理速度,还或许导致使命履行推迟添加,然后影响整个数据处理流水线的吞吐率和功率。
2、因为CPU资源的抢夺,Spark本来有望进一步进步的磁盘I/O功用也遭到了约束,难以充分发挥NVMe/TCP云盘应有的高功用潜力。
为了处理Spark在挂载NVMe/TCP云盘时面对的CPU资源占用过高和磁盘吞吐功用受限的问题,亟需探究并施行一系列优化战略和技能计划。这或许包含但不限于:选用更高效的数据传输协议或技能(如R。DMA。),以削减CPU在数据复制和网络处理上的担负,进步数据传输功用;优化Spark作业的调度与履行战略,以愈加合理地分配CPU资源;以及针对NVMe/TCP云盘特性进行专门的功用调优,如调整TCP窗口巨细、优化网络行列装备等。
RDMA技能答应数据在长途主机的内存之间直接传输,无需经过CPU处理,然后极大地下降了数据传输的推迟并削减了CPU的负载。这一特性直接处理了Spark和Kubernetes集群中,尤其是在运用NVMe-oF云盘时,因网络传输功率低下而或许导致的功用瓶颈问题。
本计划经过DPU完结NVMe/RDMA的云盘挂载,然后进步Spark在云环境下处理大数据时的全体功用和功率。
2. 全体计划概述。
本计划选用云原生架构,Spark选用Spark on Kubernetes布置形式,而且引进DPU为集群之上的容器供给存储服务的卸载和加快,交融了云原生架构与高功用存储的优势。计划全体架构如下图所示:
l 存储集群把NVMe存储设备以裸盘办法布置,核算节点经过。硬件。模仿。向宿主机供给规范的nvme/virtio块设备,对存储协议的处理都卸载到DPU,供给硬件加快的NVMe over RDMA才能。
l K8S渠道经过yusur-。csi。存储插件供给根据DPU的云盘挂载才能。
l 将Spark运用布置在K8S集群之上,Spark Pod挂载DPU硬件加快的NVMe/RDMA云盘,以更低的资源耗费取得更高的读写功率。
3. 测验办法和成果。
3.1. 软件环境。
软件包/东西/数据集列表。
称号。 | 版别。 | 来历。 | 补白。 |
Spark。 | 3.4.2。 | 社区开源项目。 | 开源大数据处理结构。 |
Java。 | 17.0.10 (Eclipse。 Ad。op。ti。um)。 | 开源项目Spark自带。 | Spark镜像内置的依靠环境。 |
cont。ai。nerd。 | 1.6.21。 | 社区开源项目。 | 容器运转时。 |
Kubernetes。 | v1.26.5。 | 社区开源项目。 | 开源容器编列结构。 |
yusur-csi。 | V6.0。 | 自研。 | Kubernetes存储插件,为裸金属供给云盘挂载功用。 |
3.2. 测验计划。
Spark SQL是Spark开发常用的。编程。接口。,本计划运用Spark SQL运转一个。聚合。查询,SQL句子如下:
select count(1) from tblong where id=1。 |
Spark运用Spark on Kubernetes布置形式,为了数据加载的完整性,封闭Spark SQL的谓词下推机制。输入数据是Parquet文件,包含一个Long类型的数据列,一切输入文件巨细之和是4。5G。。
Spark 分配4个Executor(Pod),每个Executor分配8个core,Spark中心。参数。如下。
$SPARK_HOME/bin/spark-。sub。mit。 --master k8s://https://10.0.151.186:6443。 --deploy-mode cluster。 --driver-cores 4。 --driver-mem。or。y 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.namesp。ac。e=spark。 --conf spark.kubernetes.authent。ic。ate.driver.serviceAccountName=spark。 --conf spark.kubernetes.container.image=harbor.yusur.tech/bigdata/spark:spark3.2.0-hadoop3。 |
3.3. 节点网络拓扑。
测验环境包含一个存储节点和一个核算节点,各有一个DPU加快卡,两个节点之间经过100G。交换机。衔接。测验环境节点网络拓扑如下图所示:
关于NVMe/TCP云盘,DPU运用TCP协议衔接存储服务,不卸载存储协议的处理,这种状况下,DPU充任一般网卡。
关于NVMe/RDMA云盘,DPU运用RDMA协议衔接存储服务,把存储协议卸载到DPU硬件。
3.4. 重视目标。
本计划要点重视CPU资源的运用率,包含体系内核CPU运用率和用户态CPU运用率。
目标称号。 | 目标描绘。 |
数据加载时刻(单位:秒)。 | 关于Spark SQL使命,对应S。can。算子时刻。 |
E2E时刻(单位:秒)。 | 从数据加载开端到成果输出完毕的时刻距离。 |
磁盘吞吐量(单位:MB/s)。 | 磁盘在单位时刻内能够读写的数据总量,经过fio东西测验。 |
内核态CPU运用率。 | 主机CPU运转在用户态的时刻占比,经过top指令收集。 |
用户态CPU运用率。 | 主机CPU运转在用户态的时刻占比,经过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资源运用数据。
运转进程资源监控图如下图所示:
从监控图发现内存运用动摇较少,本计划内核态CPU运用率均匀削减17.14%,用户态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%。
从运转进程中的资源监控图来看,挂载NVMe/RDMA云盘,Spark耗费更少的内核态CPU资源。内核态CPU资源运用率削减17.14%,但数据加载功用更高,因而占用了更多的用户态CPU资源。这与RDMA自身的特色是相符的,RDMA 将协议栈的完结下沉至DPU硬件,绕过内核直接拜访长途内存中的数据。
归纳用户态CPU和内核态CPU运用状况,不管是挂载NVMe/TCP云盘仍是挂载NVMe/RDMA云盘,Spark的资源耗费都在一个水平上,可是挂载NVMe/RDMA云盘时,Spark运转速度更快,对资源占用时刻更短,所以全体来看,本计划现实上节省了体系CPU资源。
4. 优势总结。
本计划经过引进DPU(数据处理单元)完结NVMe/RDMA云盘挂载,以优化Spark在云环境下处理大数据的功用和功率,其优势能够总结为以下几点:
1、明显进步数据吞吐功用:
选用NVMe/RDMA技能比较于传统的NVMe/TCP,能够大幅进步数据在云环境中的传输速度。本计划测验成果显现,数据吞吐功用进步了22.2%,这意味着Spark作业在处理大规模数据集时能够更快地读取和写入数据,然后明显削减数据处理的总时刻。
2、大幅缩短数据加载时刻:
数据加载是大数据处理流程中的要害瓶颈之一。经过NVMe/RDMA云盘的挂载,数据加载时刻缩短了18.2%,这关于需求频频拜访很多数据集的Spark运用来说尤为重要,能够明显进步运用的响应速度和全体功率。
3、削减非事务负载对CPU资源的占用:
NVMe/RDMA技能经过削减数据传输进程中对CPU的依靠,将数据传输的负载从主机CPU转移到DPU上。这不只下降了主机CPU的负载,还使得CPU资源能够更多地用于数据处理等中心事务逻辑,然后进步全体的体系功率和功用。
4、优化资源运用率:
因为数据加载和传输速度的进步,Spark作业能够更快地完结数据处理使命,然后进步了云资源的运用率。云环境中的资源(如CPU、内存、存储)一般按运用量计费,因而更快的处理速度意味着更低的本钱。
综上所述,本计划经过引进DPU完结NVMe/RDMA云盘挂载,为Spark在云环境下处理大数据供给了全面的功用优化,明显进步了数据吞吐功用、缩短了数据加载时刻、削减了CPU资源占用,并优化了体系的资源运用率。
本计划来自于中科驭数软件研制团队,团队中心由一群在云核算、数据中心架构、高功用核算范畴深耕多年的业界资深架构师和技能专家组成,不只具有丰厚的实战经验,还对职业趋势具有敏锐的洞察力,该团队致力于探究、规划、开发、推行可落地的高功用云核算处理计划,协助终究客户加快数字化转型,进步事务效能,一起下降运营本钱。
审阅修改 黄宇。