最近我们团队做了一个挺大的动作把核心的 Apache Spark 批处理作业从自建 CPU 集群整体迁到了云端 GPU 实例上。整个过程用了一套内部代号叫 Project Aether 的迁移框架从资源评估、代码改写、调度适配到灰度切换跑了整整两个月。今天把这段实操经验整理出来给打算做 Spark GPU 迁移的朋友一个参考。这事看起来不复杂网上一搜就是一堆“Spark on GPU”的分享但真到了大规模生产环境坑比想象中多得多。你面对的不仅是驱动装不装得上、算子能不能跑的问题而是几百个作业怎么评估、分成几批切换、按什么指标验证以及账单会不会在下个月爆掉。如果你也在纠结要不要迁、怎么迁这篇应该能帮你省下不少试错时间。1. 为什么要把 Spark 作业搬到 GPU 上1.1 CPU 集群的瓶颈不是算力而是成本和扩展方式我们的业务场景属于典型的批处理密集型负载每天凌晨有几十个 Spark 作业跑历史数据回刷白天还有实时链路触发的小型聚合任务。CPU 集群规模最大时到了上百节点看起来能处理但账单很难看。原因在于 Spark 的扩展方式主要是横向加节点节点一多网络洗牌shuffle和数据传输就成了大头线性扩展系数根本达不到理想值。我见过很多团队以为加机器就能解决问题结果 CPU 利用率上去了集群吞吐率却没有对等提升。另一个隐藏瓶颈是 JVM 本身。Spark 的数据在堆内和堆外之间来回倒GC 一频繁整个作业的尾部延迟就变得不可控。尤其是大表 join 和 groupBy 这类操作中间结果全部要落地CPU 架构下每次扫描和排序都是逐条处理成千上万条记录里其实有大量并行机会但 CPU 核心数量有限单核再快也顶不住这种规模的数据。1.2 GPU 擅长的事情恰好是 Spark 最耗时的部分GPU 适合做高吞吐、向量化、矩阵类运算而 Spark 里的排序、聚合、join、窗口函数本质上都是对一批数据做同一种操作。这些操作放在 GPU 上运行核心并行度可以从几十个核提升到几千个核吞吐量完全不是一个量级。我们在 TPC-DS 风格的测试集上做过对比同样的 SQL 逻辑GPU 实例上跑完的时间大约是 CPU 集群的三分之一到五分之一这个数据因作业而异但如果你的作业里有几个大 shuffle 或者大 join收益会非常明显。不过 GPU 不是万能药。JVM 里的对象模型和 GPU 端的显存模型不匹配数据先得从 Java 对象转成连续内存块再拷到显存这个过程如果处理不好光序列化和拷贝就能吃掉所有性能优势。所以单纯把 Spark 跑在 GPU 机器上是不够的必须有一个中间层去优化数据管道和执行计划这就是我们用 Project Aether 的初衷。1.3 Project Aether 在迁移里解决什么问题Project Aether 是一套面向 Spark on GPU 的迁移与调度框架至少在我们的方案里它承担了三个核心任务。第一它对现有作业做静态扫描和成本预判能自动标出哪些算子适合下沉到 GPU哪些应该留在 CPU 上兜底。第二它在 Catalyst 优化器层面扩展了执行计划把 DataFrame/SQL 里的 sort、agg、join 等操作改写为 GPU 算子同时控制显存的生命周期。第三它接管了 Spark 的 GPU 资源调度让一个 executor 可以申请多块 GPU或者多个 task 共享一块 GPU避免资源空转。你可能觉得这不就是 NVIDIA RAPIDS Accelerator 那套思路吗确实底层很多理念是相通的。但 Project Aether 更偏重“迁移过程管理”它会在切换前做资源预估在运行中做性能基线对比还会在异常时自动回退到 CPU 执行。对于生产环境这种“不允许失败”的场景这一层保障比单纯的算子加速重要得多。1.4 云端 GPU 是划算的选择但要会算账选云端而不是自建 GPU 集群核心原因是弹性和试错成本。GPU 硬件更新快自建一批 V100 没过两年可能就被 A100、H100 甩开折旧压力很大。云端可以按小时租可以先拿小实例做功能验证确认性能提升后再上大规格这个节奏对团队非常友好。另一个优势是云端存储和计算分离Spark 的数据源可以直接走对象存储GPU 实例只需要本地盘放临时 shuffle 数据任务结束后释放即可。但要提醒一句云端 GPU 的账单不是“实例单价乘以运行时间”这么简单。数据读取费用、跨可用区流量、快照和日志存储都会产生额外成本。我们在迁移前专门写了一个成本模型把作业的历史运行数据代入进去算才得出“哪些作业适合迁、迁过去能省多少”的结论。不要听厂商说“GPU 快”就冲一定要用自己真实的数据算一遍。2. 迁移前的评估与方案设计2.1 先判断哪些作业值得迁移哪些碰都别碰迁移前最重要的一步是把现有作业摸个底。我们当时从 Spark History Server 和 YARN 日志里导了最近三个月的作业清单统计每个作业的日均运行时间、输入数据量、shuffle 量、失败率、调度优先级然后给作业打标签。标签分三类可迁移、需改造、不建议迁移。适合迁移的作业通常有几个特点运行时间长、单个算子消耗大、数据量在 TB 级别以上、重复扫描同一份数据的频率高。比如每天凌晨的 UV 汇总、用户行为 session 拼接、特征宽表生成都是典型的可迁移对象。需改造的作业往往是用了大量自定义 UDF尤其是 Python UDF代码要重写。不建议迁移的是那些几十秒就跑完的小任务迁移过去光初始化 GPU 上下文的时间可能比任务本身还长完全没必要。我还建议把“作业稳定性”作为一个参考指标。有些作业虽然慢但一直很稳定这类适合做第一批试点那些三天两头失败的作业不要放到迁移批次里否则出问题了你分不清是代码问题还是 GPU 环境问题。2.2 作业改造的五步走扫描、打标、转换、验证、灰度我们把迁移过程拆成五个阶段每个阶段都有明确的输入输出。第一步是扫描。用历史日志和代码仓库把作业使用的 API 类型、算子占比、资源申请量全部拉出来形成一张迁移清单。第二步是打标按上面说的标准分成三档确定每一批迁哪些。第三步是转换把 RDD 代码改造成 DataFrame/SQL把 Python UDF 改成向量化实现把宽依赖重的逻辑改成更适合 GPU 执行的写法。第四步是验证在测试环境跑同样的数据对比迁移前后的结果除了看行数是否一致还要做字段级别的 diff防止精度问题。第五步是灰度。我们不搞“星期六全量切换”这种操作而是选两三个低峰期的作业先上跑一周看稳定性再把同一逻辑的兄弟作业批量切过去。灰度期间保留回退开关一旦指标恶化立刻切回 CPU。整套流程走下来准确率和稳定性都有保障。2.3 代码层面最关键的三类改动第一类改动是统一算子风格。Spark 里同一个需求可以有十种写法但 GPU 执行计划对“标准写法”更友好。我们内部定了一个规范能用 DataFrame API 就不写 RDD能用内置 SQL 函数就不写自定义 UDF能一次聚合就不分多次聚合。比如df.groupBy(user_id).count()这种教科书写法在 GPU 上基本不需要改Project Aether 会自动优化。第二类改动是处理 UDF。生产环境有大量历史遗留的 Python UDF尤其是用pandas_udf写的迁移时可以直接走向量化接口性能提升很大。但如果是纯 Python 循环的 UDF那就必须重写否则数据在 JVM 和 Python 进程之间往返一次代价比 GPU 省下的还多。第三类改动是控制中间结果大小。GPU 显存不像 CPU 内存那样可以随便溢出到磁盘一个超大 shuffle 文件落到显存里就 OOM。我们采取的办法是把大任务拆成多个小批次或者在关键节点做 checkpoint把中间结果落盘释放显存空间。这种调整看起来不起眼但实际效果立竿见影。2.4 云端资源方案怎么搭我从成本角度讲云端的 GPU 实例规格很多T4、V100、A10G、A100各有各的定位。我们第一轮测试用了 T4因为它便宜适合验证功能确认迁移收益后大作业逐步换到 A10G 和 A100。我的经验是不要一上来就挑最大的实例Spark 作业的资源需求是立体的CPU 和内存可能先成为瓶颈GPU 再强也没用所以先拿中等规格跑一遍 profiling再决定是否上调。存储方面我们把数据源全部放到对象存储计算节点只保留本地 NVMe 盘作为 shuffle 临时目录。这样做的好处是计算集群可以随时缩容到零存储成本另算不会互相拖累。网络方面GPU 实例之间尽量选高带宽的机型因为大 shuffle 在网络上的时间占比不比计算少。如果预算充足可以开通弹性网卡和专用带宽但初期不用过度投入。实例规格GPU 型号显存适合场景成本特征入门型T416 GB功能验证、小作业单价低适合测试均衡型A10G24 GB中型 ETL、特征工程性价比高主力实例高性能型V10016/32 GB复杂 join、大聚合老牌稳定生态成熟旗舰型A10040/80 GB超大规模训练/ETL成本高需严格评估架构上我们用的还是常见的 Spark on K8s好处是资源隔离和弹性伸缩都现成GPU 调度可以通过 device plugin 直接透传。不用刻意上太复杂的调度系统先把作业跑稳比什么都重要。3. 实操过程与核心环节实现3.1 环境准备驱动、CUDA 和 Spark 运行时我拿一套标准的 Spark 3.4 K8s 环境举例。首先创建 GPU 节点池这个操作在云控制台上就能完成也可以走命令行自动创建。如果是 AWS类似eksctl create nodegroup --cluster spark-gpu --node-type g4dn.12xlarge --nodes 4如果是国内云厂商控制台里选 GPU 计算型实例即可差别不大。关键是节点起来之后第一件事跑nvidia-smi确认 GPU 能被识别。接下来装驱动和 CUDA。这一步最容易踩坑的是版本匹配Spark 的 GPU driver 版本、CUDA 版本、底层 cuDNN 版本只要有一个不对后面就会出各种稀奇古怪的报错。我们当时踩了一个很隐蔽的坑驱动装的是最新版但 Project Aether 依赖的 CUDA 库是 12.x结果运行时报找不到libcudart.so。排查半天才发现是 CUDA 路径没写进LD_LIBRARY_PATH。# 安装 NVIDIA 驱动和 CUDA以 Ubuntu 22.04 为例 sudo apt-get update sudo apt-get install -y nvidia-driver-535 sudo apt-get install -y cuda-toolkit-12-2 # 验证 nvidia-smi nvcc --version # 确认 CUDA 库路径后续需要写进 Spark 配置 ls /usr/local/cuda/lib64/libcudart.so3.2 安装并初始化 Project Aether 运行时Project Aether 不是一个独立服务它更像一个 Spark 插件和调度扩展的组合安装方式取决于你用的发行版。我们是从内部制品库拉了一个 jar 包放到 Spark 的 jars 目录下然后在spark-defaults.conf里启用插件。如果你用的是社区版也要确认和当前 Spark 大版本兼容我们当时用的是 Spark 3.4对应的 Aether 版本是 0.9.x这个组合实测比较稳。启用插件后可以通过 Spark UI 的 “Executors” 页面看到 GPU 资源和显存占用情况这一步能直接验证插件是否生效。如果页面里 GPU 信息显示为空优先检查 spark 配置里的资源名称对不对以及节点上有没有启动 GPU discovery script。# 确认 Project Aether 的 jar 包位置 ls $SPARK_HOME/jars/ | grep aether # 启动 spark-shell 验证插件加载 spark-shell \ --jars /opt/aether/aether-spark-0.9.0.jar \ --conf spark.pluginscom.aether.sql.GpuPlugin \ --conf spark.aether.enabledtrue3.3 Spark 配置里三个必须调好的参数第一组参数是 GPU 资源映射告诉 Spark 一个 executor 能拿多少 GPU一个 task 能分多少资源。我们踩过一个大坑刚开始只配置了spark.executor.resource.gpu.amount1但没配 task 级别的资源量结果明明有 4 个 task 并发全部挤到了一块 GPU 上显存直接爆掉。第二组参数是 Java 库路径和 CUDA 路径不加的话运行时可能找不到原生库。第三组参数是 Aether 自己的开关包括是否启用自动回退、是否打印 GPU 执行计划、中间结果是否允许落盘。这些参数建议先在测试环境跑通再上生产别直接拿生产配置试错。spark.executor.resource.gpu.amount1 spark.task.resource.gpu.amount0.25 spark.executor.extraJavaOptions-Djava.library.path/usr/local/cuda/lib64 spark.pluginscom.aether.sql.GpuPlugin spark.aether.enabledtrue spark.aether.plan.fallback.enabledtrue spark.aether.plan.verbosetrue把task.resource.gpu.amount设成 0.25意味着 4 个 task 共享一块 GPU这个值需要根据任务实际显存需求来调。显存需求小的任务可以设 0.5 甚至 1大任务则可能要独占整块 GPU不能一概而论。我先用 0.25 跑了一圈观察显存峰值后再逐步上调。3.4 一段典型的迁移代码对比拿一个常见的用户行为聚合作业举例。迁移前的代码是这样的val result spark.read.parquet(s3://data-bucket/user_events) .filter($event_time.between(startTime, endTime)) .groupBy(user_id) .agg( count(*).as(event_cnt), approx_count_distinct(item_id).as(item_cnt) ) .orderBy(desc(event_cnt))这段代码是标准的 DataFrame 写法Project Aether 集群里基本不用改框架会在 Catalyst 优化阶段自动把groupBy、agg、orderBy下沉到 GPU 算子。你只需要在提交作业时加上相关配置即可代码层面保持整洁。但如果业务里有自定义 UDF就得多做一步。比如原来的 Python UDF 是逐行算一个会话内的时间间隔性能很差改成pandas_udf之后数据变成 Pandas Series 传入GPU 端一次处理一个批次效率高非常多。UDF 的迁移是我们整个项目里耗时最长的部分建议排期时多留一些 buffer。3.5 性能验证和成本对比用数据说话迁移不是“能跑就行”必须跑完一轮量化对比。我们在同一份数据上分别跑了 CPU 集群和 GPU 集群记录执行时间、CPU 利用率、GPU 利用率和成本。对比结果很有意思有些作业 GPU 执行时间只有 CPU 的三分之一但也有一个作业执行时间差不多仔细看发现是 shuffle 数据量太大网络传输成了瓶颈GPU 的算力优势被抵消了。作业名CPU 耗时GPU 耗时提升倍数CPU 单价GPU 单价成本变化user_session_agg42 min11 min3.8x0.8 元/时2.4 元/时略降item_embedding_etl76 min20 min3.8x1.2 元/时3.6 元/时略降log_clean_small8 min9 min0.9x0.2 元/时0.6 元/时上升user_profile_join126 min38 min3.3x2.4 元/时4.8 元/时基本持平从上表能看出来GPU 不是所有作业都便宜。小作业迁移后成本反而上升所以最终保留了一部分作业在 CPU 集群。成本模型的核心是“单位数据量的处理成本”而不是单纯看实例单价。我们最后定了一个规则执行时间超过 30 分钟、且 shuffle 量占输入比例不超过 50% 的作业才进入 GPU 迁移名单。4. 常见问题与排查技巧实录4.1 GPU 显存不足任务 OOM 是怎么排查的这应该是迁移后遇到最多的报错。现象是任务跑一半有的 executor 直接挂掉Spark UI 里显示 Container 失败日志里写着CUDA out of memory。我排查时先看 Spark UI 里每个 task 的显存占用曲线发现很多 task 的显存峰值都顶到了 16 GB刚好是 T4 的上限。解决办法有两个方向。一是降低并发把spark.task.resource.gpu.amount调大让更少的 task 共享显存二是优化执行计划看是不是某个阶段把全量中间结果都放进了显存。Project Aether 提供一个参数可以把中间结果落盘代价是增加一定的磁盘 IO但在显存不足时非常管用。不要试图通过加机器硬扛先看代码层面能否减少中间结果。4.2 调度配置错误导致 GPU 资源争抢还有一个高频问题配置了 GPU 资源但 task 调度没生效导致多个 task 挤在一块 GPU 上。这种现象在 Spark UI 里看每块 GPU 的利用率能明显发现某个 GPU 利用率接近 100%其他 GPU 空着。排查思路是先看spark.task.resource.gpu.amount是否大于 0再看节点上的 GPU discovery script 是否正常输出 JSON 格式的资源信息。如果 discovery script 没配好Spark 根本不知道节点上有几块 GPU自然无法正确调度。这个配置在 YARN 和 K8s 模式下写法不同切换资源管理器时一定要重新检查。4.3 序列化和数据传输反而拖慢了性能有段时间我们的作业任务切换后不仅没变快反而更慢了。查了执行计划发现数据从 Spark 引擎传输到 GPU 算子时走的还是 Java 序列化一条一条处理完全没过 GPU 的执行计划。说白了就是算子没真正落到 GPU 上框架在 CPU 和 GPU 之间反复拷贝性能自然更差。解决方式是把数据转成列式格式用 Arrow 或 cuDF 作为传输介质一次把一批数据拷到显存。Project Aether 对 DataFrame 的列式传输支持得比较好但前提是作业必须走 DataFrame/SQL 接口如果还有大量 RDD 代码就得先改造。这也解释了为什么代码改造阶段那么重要不改造的话迁移没有任何意义。4.4 成本失控月底账单比预期高了两倍有一轮灰度测试后我们惊喜地发现作业快了很多但月底云账单出来时傻眼了GPU 实例的成本高过预期一倍多。原因是 GPU 节点在任务结束后没有自动缩容一直保持运行状态白白烧了十几个小时。另外有些任务把大量中间结果写到了对象存储这部分存储费和请求费也被忽略了。后面我们给集群加了自动缩容策略空闲超过 10 分钟的节点自动释放同时调整了 shuffle 临时目录策略尽量用本地盘而不是对象存储。成本控制不是上线那一刻才考虑的而是在写配置和调度策略时就要设好“安全阀”。4.5 版本兼容性导致的诡异报错汇总最后把版本兼容性这个老大难单独列出来。常见的诡异报错包括Spark 插件明明加载了却提示找不到类、CUDA 版本和驱动版本不匹配导致内核加载失败、GPU 驱动升级后原有的 Aether 执行计划异常。这些问题的共同点是没有统一管理版本组合。我们后来把所有环境的镜像都做成标准版本组合驱动、CUDA、Spark、Aether jar 全部指定版本不允许单独升级某一个组件。每次升级先在测试环境跑一遍全量用例通过后再灰度到生产。这套流程看着保守但确实帮我们避开了大量诡异问题。5. 作为迁移主导者我想再强调几件事5.1 迁移不是一条命令的事而是一整套工程流程刚开始接手这个项目时我也以为 Spark on GPU 就是“把 Spark 装到带 GPU 的机器上”这么简单。真正做下来才发现工具只是最表层的部分。你需要理解作业的执行计划、数据在 JVM 和 GPU 之间的流动方式、调度系统怎么感知 GPU 资源以及团队怎么维护一套新的运维体系。我在整轮迁移中最受益的一个经验是把每个作业的迁移当成一个小项目来做明确改动点、验证方式、回滚方案和责任人。别怕流程重越重的流程在出问题时越能救命。我们第一批评测的 5 个作业全部成功切换靠的不是运气而是前期把该踩的坑都预演过一遍。5.2 先记录一切再谈优化迁移的前两周我几乎没写任何优化代码只做了一件事记录每个作业的 CPU 耗时、GPU 耗时、显存峰值、shuffle 量、数据读取量。这些数据后面成了我们判断“该不该迁移、怎么迁移”的最强依据。没有这些数据你只能靠感觉做决策而在生产环境感觉是最不靠谱的东西。5.3 说句实话不是所有作业都需要 GPU很多人听到 Spark on GPU 就想到“快”但我的观点是先想清楚你的瓶颈在哪里。如果瓶颈在 shuffle 网络传输或者数据读取GPU 帮不了你反而增加成本。我们最终迁移率大约在六七成剩下的作业仍然跑在 CPU 集群上。这个比例在性价比上是合理的因为单个 GPU 实例的成本比 CPU 实例高不少必须让收益大于成本。迁移完成后我个人的建议是每季度复查一次作业清单新上线的作业如果符合迁移条件尽早接入 GPU 通道别等积累了几个月再回头改。