借助 Apache Spark 与 GPU 加速数据科学进程
by Canonical on 24 July 2025
一直以来,Apache Spark 始终以通过分区机制实现多节点分布式计算调度而著称,而 CPU 核心则始终在单个分区内完成处理任务。
鲜为人知的是,Spark 同样可通过 GPU 实现计算加速。在恰当场景中启用 GPU 加速将带来显著优势:基础设施成本与服务器需求大幅降低,查询完成速度相比传统 CPU 计算最高提升 7 倍,且所有加速过程在后台静默完成,无需改造现有 Spark 应用代码。我们激动地宣布,Canonical 团队已借助 NVIDIA RAPIDS 加速器实现 Spark 作业的 GPU 支持,此项技术突破专为破解大规模数据处理中的真实性能瓶颈而研发。
本博客将阐述 Spark 在 GPU 上所提供的优势、实现原理、GPU 的不适用场景,并为您提供如何通过 GPU 启动 Spark 作业的相关指导。
数据科学家为何应关注 Spark 与 GPU 技术
在 GPU 上运行 Apache Spark,是通过发挥 GPU 特定优势来加速大数据分析与处理工作负载的绝佳机会。
与传统 CPU(通常仅配备少量专为顺序处理设计的核心)不同,GPU 由数千个节能型小型核心组成,这些核心专为同步执行数千条并行线程而设计。这种架构差异使得 GPU 非常适合处理 Spark 工作负载中常见的高度分布式操作。通过将这些操作下放至 GPU,Spark 能够显著提升性能,与纯 CPU 环境相比,查询执行时间可减少数个数量级,通常可将数据处理速度提升 2 到 7 倍。这大幅缩短了组织获取洞察所需的时间,带来质的提升。
就此而言,Apache Spark 的 GPU 加速能力为数据科学家带来了重大优势,尤其是在他们从传统分析转向 AI 应用的过程中。标准的 Spark 工作负载属于 CPU 密集型任务,其分布式特性确实能提供极为强劲的计算能力,但对于 AI 驱动的分析工作负载而言,这种能力可能仍显不足。
另一方面,借助 GPU,数据科学家能够以更高的速度开展工作,处理更大规模的数据,并提升工作效率。这意味着数据科学家能够更快迭代,以交互方式探索数据,并在几乎实时内提供可行见解,这在当今快节奏的决策环境中至关重要。
在加速处理的同时,GPU 加速还能通过将数据工程与机器学习工作负载整合于单一平台,简化数据科学工作流。借助 GPU 加速的 Spark 技术,用户可在一个环境中高效完成数据准备、特征工程、模型训练及推理全流程,无需独立基础设施,也无需在系统间进行复杂的数据迁移。整合工作流既能降低操作复杂性,又可加速端到端数据科学项目的进程。
在 GPU 上运行 Spark 的第三大优势在于可显著降低运营支出。凭借 GPU 强大的单机吞吐性能,企业可用更少的服务器实现媲美甚至超越原有表现的成果。不仅降低成本,同时减少了功耗。这使得大数据分析更具经济可行性与环境可持续性,这些日益凸显的双重优势正成为企业运营的关键所在。
最终,上述所有优势均可通过 NVIDIA RAPIDS 等技术与 Spark 无缝集成而实现,无需代码重写或修改工作流程。这显著降低了 GPU 技术的应用门槛,使用户能全力投入价值快速交付,突破核心效能瓶颈。
何时应依赖传统 CPU?
必须明确指出,并非所有 Spark 工作负载都能从 GPU 加速中同等获益。
首先,GPU 在处理小规模数据集工作负载时效率不高,因为 GPU 与 CPU 内存之间的数据传输开销可能超过 GPU 加速带来的性能收益。在处理小规模工作负载时,细粒度并行计算无法受益于 GPU 的优势特性。同样,涉及集群内持续性数据交换的工作负载也未必适配。这是因为数据交换过程会导致 CPU 与 GPU 内存间的高昂的数据传输代价,从而显著降低运算速度。
选择 CPU 的另一个充分理由是,当 Spark 作业严重依赖用户自定义函数,且这些函数无法在 GPU 上执行或未针对 GPU 优化时。
同样,如果工作负载涉及直接操作弹性分布式数据集(RDD),GPU 可能并非是最优选择。这是因为 RAPIDS 加速器目前尚不支持处理此类工作负载,将主动回退至 CPU 执行。最后,还需确保运行环境满足 GPU 加速所需的硬件规格与配置要求。
要确定 GPU 加速在选定环境中是否有效,必须对工作负载执行严格的性能剖析和基准测试双重验证。
如何使用 GPU 启动 Spark 作业
我们为 Apache Spark 设计的 Charm 组件兼容 Kubernetes 集群管理器,因此要在 Apache Spark 上启用 GPU,必须通过 Pod 和容器进行配置。
首先,您需要部署支持 Apache Spark Rapids 插件的 Charmed Apache Spark OCI 镜像。请参阅我们的指南了解具体方法。
完成部署并准备启动首个作业时,您需创建 Pod 模板以限制每个容器的 GPU 用量。为此,请编辑 Pod 清单文件(gpu_executor_template.yaml),添加以下内容:
edit the pod manifest file (gpu_executor_template.yaml) by adding the following content:
apiVersion: v1
kind: Pod
spec:
containers:
- name: executor
resources:
limits:
nvidia.com/gpu: 1
使用 Spark 客户端快照,我们可以提交所需的 Spark 作业,添加一些配置选项以启用 GPU 加速:
spark-client.spark-submit \
... \
--conf spark.executor.resource.gpu.amount=1 \
--conf spark.task.resource.gpu.amount=1 \
--conf spark.rapids.memory.pinnedPool.size=1G \
--conf spark.plugins=com.nvidia.spark.SQLPlugin \
--conf spark.executor.resource.gpu.discoveryScript=/opt/getGpusResources.sh \
--conf spark.executor.resource.gpu.vendor=nvidia.com \
--conf spark.kubernetes.container.image=ghcr.io/canonical/charmed-spark-gpu:3.4-22.04_
edge\
--conf spark.kubernetes.executor.podTemplateFile=gpu_executor_template.yaml
…
通过 Spark 客户端快照,您可在服务账户层级配置 Apache Spark 设置,使其自动应用于所有作业。请参阅我们的指南,了解如何在服务账户层级管理配置选项。
Spark 搭配 GPU:关键要点总结
简而言之,NVIDIA RAPIDS GPU 加速技术可为 Apache Spark 带来显著性能提升,实现更快的数据处理能力并节省成本,且无需修改代码即可实现。这意味着数据科学家能够更高效地处理更大规模的数据集和更复杂的模型,从而以前所未有的速度生成见解。然而,并非所有工作负载都能同等受益;小规模数据集、过度数据交换或不支持的函数可能导致无法充分发挥 GPU 优势。必须通过细致的性能剖析,才能判定何时采用 GPU 才是性价比最高的选择。总体而言,在 GPU 上运行 Spark,为加速数据科学提供了强大助力,推动创新发展。
- 【白皮书】轻松构建在线数据中心
- 【白皮书】掌握大数据与AI前沿趋势
订阅博客文章
查看更多内容
使用 MAAS 部署 VMware 虚拟机管理程序
多数现代数据中心本身均为异构架构。VMware 环境常与容器平台、数据库及其他裸机业务负载共存,多年运行于同一套硬件之上。服务器一次性采购,但会随业务需求变化调整承载业务。 然而,ESXi(VMware 虚拟机管理程序)的配置通常由独立流程负责。主机通过 VMware 工具、自定义脚本或专为将部署 ESXi 到机器中开发的自动化程序完成安装。这些工作流单独运行虽行之有效,却未必能与物理基础设施的其他部分实现统一的追踪与管理。 由此导致了脱节:即便归属同一硬件资源池,ESXi 主机的管理方式仍与数据中心其他设备脱离。随着环境规模扩大、架构日趋多元化,这种割裂式管理会形成业务瓶颈。 将 ESXi 纳入统一裸机平台进行统筹管理将是更具扩展性的方案。这使得 ESXi 的配置流程, […]
什么是 Ubuntu Pro?与标准版有不同吗?功能及内容详解
Ubuntu Pro 是 Canonical 推出的全方位订阅服务,提供开源安全防护、技术支持与合规保障。从长达 15 年的安全维护、全天候技术支持,到面向 IT 管理员的自动化加固工具,深入了解 Ubuntu Pro 订阅包含的全部服务。 Ubuntu Pro 具备哪些功能? Ubuntu Pro 是一套安全合规订阅服务,可为操作系统、应用程序及 IT 运维各层级及时提供补丁与安全维护。它助力企业及其工程师保障软件与系统安全,并通过加固工具、自动化流程及一系列其他功能,为企业满足安全标准合规铺平道路。 了解关于 Ubuntu Pro 的更多信息 › Ubuntu Pro 与标准版 Ubuntu 有何不同? 很多人存在误区,误以为 Ubuntu Pro 是独立版本或全新操 […]
代码热风险 – 软件供应链视角下,容器交付前要先“冷却”
已遭遇的安全漏洞,与即将到来的威胁 2025 年 9 月,npm 软件仓库中包括 chalk 和 debug 在内的数十个热门 JavaScript 软件包遭入侵。这些软件包应用极为广泛,几乎无处不在:前端应用、后端微服务以及 CI 工具中均有使用。开发人员并无任何失误操作,他们只是执行了一贯使用的命令:npm install chalk。但恶意软件却悄无声息地侵入了。 这并非操作系统中的漏洞。也不是某台笔记本电脑上的病毒。这是一次供应链攻击:攻击者在开发者构建软件所使用的组件中植入了恶意代码。手段并不复杂,仅仅是一名开发者遭到钓鱼攻击、一次恶意发布,数百万下游用户便因看似是合法更新而将恶意代码引入系统。 而这确实是一次合法的更新。发布者并非有意植入恶意软件,也对此毫不知 […]