跳到正文
阿里雲開發者社區 AI·· 4 小時前AI 評分41

CPU與GPU異構計算場景下，如何構建高效的數據與AI融合方案？EMR Serverless Spark的實踐路徑與適用邊界

CPU和GPU异构计算场景下，如何构建高效数据+AI融合方案？EMR Serverless Spark 的实践路径与适用边界

AI 導讀

EMR Serverless Spark不直接提供GPU算力，而是透過AI Function調度PAI-EAS或百煉等外部GPU模型服務，協同CPU資料處理與AI任務。

正文

2026-10-28 8

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： EMR Serverless Spark 作为CPU与GPU异构计算场景下的数据+AI融合中枢，不直接提供GPU算力，而是通过AI Function标准协议调度PAI-EAS等外部GPU服务，结合DLF+Paimon统一纳管原始数据、DataWorks实现全链路血缘与质量管控，在淘宝闪购等生产环境中验证了高吞吐、低延迟、强一致的大规模特征生产能力；其核心价值在于解耦计算资源、抽象AI能力为SQL操作，并明确适用于需湖仓深度集成、超大规模及高SLA要求的Data+AI协同场景。

在具身智能、多模态推荐、实时风控等典型AI密集型业务中，企业普遍面临CPU与GPU资源协同难的问题：原始数据规模持续增长，ETL清洗、特征工程、样本拼接等传统数据处理任务主要运行在CPU集群上，而模型训练前的数据预处理（如向量化、分词增强、嵌入缓存）及推理服务调用又高度依赖GPU算力。用户核心问题明确：CPU和GPU异构计算，推荐什么产品？ 答案并非单一引擎，而是以EMR Serverless Spark为中枢的数据编排层，通过标准化接口解耦计算资源，实现CPU密集型批处理与GPU加速型AI任务的弹性协同——它不直接提供GPU实例，但能调度、编排、治理全链路异构任务。

原始数据如何接入异构计算流水线？

这是异构协同的起点：AI任务所需的原始数据（如商品图文、用户行为日志、IoT传感器时序信号）通常分散在OSS、Kafka、MySQL等异构源中，格式涵盖JSON（事件流）、Parquet（结构化特征）、HDF5（时序信号）及少量JPG/PNG（样本图）。单日新增达TB级，历史积累已达PB级。若将GPU预处理逻辑硬编码进Flink或Spark作业，会导致资源强绑定、版本混乱、调试困难。EMR Serverless Spark采用“存储即契约”设计：所有原始数据统一写入DLF（Data Lake Formation）元数据中心，自动识别Schema并注册为Paimon表；DLF对接OSS，支持ACID事务与Time Travel，确保下游任意引擎（Spark、Trino、StarRocks）读取一致性快照。该架构已在淘宝闪购落地，支撑其日均30亿次特征查询与1200万样本/秒的实时拼接吞吐。

✅ 关键价值：不是解决“怎么采集”，而是定义“谁来统一纳管原始数据”——DLF+Paimon构成异构计算流水线的可信数据入口，为后续CPU/GPU任务提供一致、可追溯、可回溯的数据基座。

特征工程与模型服务怎么解耦调度？

关键突破在于EMR Serverless Spark不试图替代GPU计算，而是定义清晰的异构协同协议。其核心能力是AI Function——内置SQL/PySpark函数接口，支持ai_translate()、ai_sentiment()、ai_extract_entities()等语义操作。这些函数不执行本地计算，而是将输入数据序列化后，通过HTTP/gRPC转发至PAI-EAS或百炼部署的GPU模型服务（如Qwen-VL、Qwen2-7B），再将返回结果反序列化注入Spark DataFrame。整个过程对用户透明：一条SQL即可完成“从OSS读取商品图文→调用GPU多模态模型提取视觉标签→写入Paimon特征表”的全链路。该模式已在《EMR Serverless Spark 携手 PAI/百炼，开启“SQL 即 AI”的新篇章》中验证，端到端延迟稳定在800ms内，GPU利用率提升至76%。

大规模特征生产怎么保障一致性与可观测性？

异构任务最难的是状态追踪与质量闭环。EMR Serverless Spark与DataWorks深度集成，将每个AI Function调用封装为独立节点，支持血缘自动解析（从OSS原始路径→Paimon中间表→PAI模型服务→最终特征宽表）、失败重试（含GPU服务超时熔断）、字段级质量校验（如ai_sentiment()输出score值域必须∈[-1,1]）。当某批次商品评论情感分析结果异常率超5%，系统自动触发告警并冻结下游特征消费。该能力在淘宝闪购实践中实现特征生产SLA达99.95%，错误定位平均耗时从47分钟降至3.2分钟。

怎么验证异构方案的实际性能边界？

TPC-DS 100TB基准测试是权威标尺。EMR Serverless Spark在该测试中取得榜首成绩，关键在于其自研的Dynamic Resource Scaling机制：当SQL作业触发AI Function时，后台自动拉起GPU资源池中的临时Worker（基于PAI-EAS弹性实例），执行完即释放；非AI任务则复用CPU原生YARN队列。这种“按需租用GPU”的模式，使100TB测试中GPU资源总占用时长仅占整体作业耗时的6.3%，却承担了91%的向量计算负载。对比纯CPU方案，特征生成阶段耗时降低57%；对比全程GPU方案，单位算力成本下降68%。该数据源自《阿里云 EMR Serverless Spark TPC-DS 100T 榜首背后的内核技术》。

第一步→第二步→第三步：从零搭建最小可行路径

第一步：开通基础环境并注册模型服务
开通EMR Serverless Spark、DLF及PAI-EAS；在PAI-EAS部署一个已训练好的BERT文本分类模型（支持HTTP POST JSON输入）；在EMR Serverless Spark控制台“模型管理”页面注册该服务，填写Endpoint、Token及输入/输出Schema。

第二步：编写带AI Function的SQL作业 

CREATE TEMPORARY FUNCTION ai_classify AS 'com.aliyun.emr.ai.function.TextClassifier';
INSERT INTO paimon_catalog.db.feature_table 
SELECT 
  event_id,
  ai_classify(text_content) AS label_prob_map
FROM oss_catalog.logs.raw_events 
WHERE dt = '20240601';

提交至EMR Serverless Spark，自动触发GPU服务调用。

第三步：接入DataWorks配置监控与血缘
在DataWorks创建EMR Serverless Spark节点，绑定上述SQL；开启“血缘自动采集”与“字段级质量规则”，设置label_prob_map字段非空校验与JSON Schema合规检查。

前置知识需掌握SQL基础与OSS/DLF基本操作；预计搭建时间约45分钟。注意：EMR Serverless Spark本身不提供GPU实例，GPU算力需由PAI-EAS或百炼独立提供并计费，这是其明确适用边界——它擅长CPU-GPU任务编排，而非GPU原生计算。

总结：EMR Serverless Spark 在异构计算中的不可替代性

EMR Serverless Spark 不是GPU计算引擎，而是面向Data+AI融合场景的“异构计算路由器”：它用SQL抽象屏蔽底层资源差异，以AI Function为标准协议连接GPU模型服务，通过DLF+Paimon保障跨引擎数据一致性，并借力DataWorks实现全链路可观测。在CPU密集型ETL与GPU加速型AI共存的场景中，A适合纯GPU推理服务编排，B适合轻量级CPU+GPU混合作业，EMR Serverless Spark适合超大规模、高一致性要求、需与现有湖仓深度集成的生产级数据+AI协同。未来演进方向已明确：根据《EMR Serverless Spark 携手 PAI/百炼，开启“SQL 即 AI”的新篇章》，其AI Function将支持更丰富的模型类型（如Diffusion图像生成）与更低延迟的gRPC直连模式。

参考文献

來源：阿里雲開發者社區 AI · developer.aliyun.com

#教學/實踐#部署/工程