怀古游戏宅SIR声明：本文仅从工程应用与行业实践角度，对Apache Spark与开源Ray项目进行技术特性与适用场景的客观讨论，不涉及任何特定厂商或产品的商业评价。
过去十年，如果你跟人聊分布式计算，大概率绕不开一个词：Spark。从离线ETL到数仓分析，Spark几乎成了“分布式数据处理”的代名词，Java、Scala、Python社区的简历上，不带点Spark经验都不好意思说自己搞过大数据。但从2023年开始，风向明显变了——越来越多团队在聊Ray：做AI训练编排的用它，做超参数搜索的用它，甚至有人开始把Ray Serve直接推到生产环境里处理在线推理。
这篇文章就围绕“Spark与Ray对比”展开，不站队，也不替谁背书。我会从架构设计的底层逻辑讲起，再结合我自己在真实集群上跑批处理和训练任务时踩过的坑，把这俩框架的定位差异、适用场景、资源调度和内存管理讲透。无论你是刚接触分布式计算、在纠结技术选型，还是已经在生产环境里用其中一个、想评估要不要引入另一个，这篇都值得你花十分钟看完。
简单说结论：Spark面向数据，Ray面向计算；Spark擅长把“固定的数据处理流程”跑得又快又稳，Ray擅长把“动态的计算逻辑”编排得灵活高效。 理解了这句话，后面所有细节都好办了。
1. 为什么Spark独大的局面，突然多了个“新选择”
1.1 从热搜词看用户真实需求的变化
先看一个有意思的现象：在近期的分布式计算相关热词里，“spark数据分析案例”“spark安装详细步骤”“spark集群搭建”这类经典需求依然坚挺，但同时出现了“dgx spark”“dgx spark部署qwen”这类让老Spark工程师都愣一下的组合。
“DGX Spark”这个名字听起来像Spark的某个发行版，其实是NVIDIA推出的个人AI超算，专门面向本地大模型训练和推理场景。用户拿它来部署Qwen这类开源模型，本质上已经不是在跑传统的数据处理作业，而是AI推理和微调任务。这类任务的共同点是：逻辑控制流极其动态，算子之间不是简单的一进一出，而是频繁的循环、分支、嵌套调用，而且所有步骤都围绕GPU资源展开。
如果只用Spark硬扛这些任务，你会发现两个尴尬：第一，Spark的编程模型是基于RDD和DataFrame的粗粒度算子，一个map一个reduce，天然是为“数据分阶段转换”设计的，硬塞动态控制流进去，代码会扭曲得不成样子；第二，Spark的作业调度以“阶段”为单位，每个阶段之间通过shuffle落盘衔接，这种为海量数据容错而生的设计，在AI训练这种每步都要快速迭代的场景里，显得过于笨重。
1.2 Ray当初是怎么冒出来的
Ray最初出自UC Berkeley的RISELab，这个实验室的前身就是搞Spark的AMPLab。研发团队在做下一代分布式计算研究时，发现了同一个尴尬：学术界和工业界的AI负载越来越复杂，而现有的分布式框架都是围绕“数据并行”设计的，对“任务并行”“ Actor模型 ”这类更底层的计算模式支持得很别扭——你不是要让一万条数据各走各的map函数，而是要让一百个互相有依赖关系的计算任务并行跑起来，任务之间还要动态通信。
于是Ray的定位从一开始就非常明确：做分布式计算领域的“操作系统内核”。它提供两层能力：一层是底层的动态任务调度和分布式对象存储，另一层是构建在底层之上的生态库，比如用于超参数搜索的Ray Tune、用于强化学习的Ray RLlib、用于模型推理的Ray Serve。开发者可以像写单机程序一样写分布式逻辑，系统自动帮你做任务的调度、容错和资源分配。
这也是为什么Ray火了之后，很多人问“Ray是不是要取代Spark”时，我的回答永远是：这不叫取代，这叫分工。Spark解决的是“给我一份数据，我把它按规则算完”；Ray解决的是“给我一个算法，我帮你在分布式环境里跑起来”。前者偏数据工程，后者偏AI平台。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 底层架构差异：理解两者的关键钥匙
2.1 Driver/Executor 与 Head/Worker 的逻辑对比
很多人上来就对比这俩框架的API哪个好用，其实这是本末倒置。API只是表面，底下那套架构设计逻辑，才是决定它们各自适合什么场景的根本原因。
Spark的架构是经典的Driver-Executor模型。一个Application提交后，Driver进程负责任务的分解、调度和协调，Executor进程负责真正干活。Driver会先把你写的代码翻译成一棵逻辑执行计划树，再经过Catalyst优化器生成物理执行计划，最终分解成一批Task下发到Executor上执行。整个作业的DAG（有向无环图）在作业启动前就已经完全确定了。
Ray的架构跟Spark有本质不同。它也分Head节点和Worker节点，但Head节点上运行的是一套GCS（Global Control Store，全局控制存储），负责维护整个集群的元数据；每个Worker节点上运行着一个Raylet进程，负责本节点的资源管理和任务调度。关键差异在于：Ray的任务依赖关系不是在启动时一次性确定的，而是运行时动态展开的。你在一个Task里创建了子Task，或是在一个Actor里动态调用了另一个Actor的方法，系统会实时把这些依赖关系注册进来，再实时调度。这种设计让Ray能处理带有循环、递归、条件分支的复杂计算图，而Spark在静态DAG模型下，这类动态计算要么写不了，要么得用很别扭的方式凑合。
2.2 内存管理模型：Tungsten 的血腥 shuffle 与 Ray 的零拷贝共享
Spark的内存管理经过多年迭代，已经发展成一套极其精细的分区控制体系。Executors上的内存被划分为两个大区：ExecutionMemory（给shuffle、join、sort这类操作使用）和StorageMemory（缓存RDD和DataFrame）。它们之间通过spark.memory.storageFraction动态抢占，Spark的Tungsten项目还把数据结构直接编码成二进制，绕过JVM对象开销直接操作内存。
这套模型好归好，但有个绕不过去的硬伤：跨节点数据传输的成本极重。在Spark里，一个Stage的数据要交给下一个Stage处理，必须把中间结果写到磁盘（也就是shuffle），再由下游Task去拉取。这个过程涉及序列化、磁盘IO、网络传输、反序列化，哪怕你的数据全在内存里能放下，框架为了容错仍然倾向于物化中间结果。数据量大时这是一种稳健的取舍，但数据量小、计算步数多时，纯粹就是浪费。
Ray的内存模型则走了另一条路。集群里每个节点的对象存储（Object Store）就是一份分布式共享内存，一个Task产出的对象会被放进本地Object Store，其他节点上的Task可以直接通过内存地址引用，配合Apache Arrow的零拷贝机制，跨节点传数据不需要经历“序列化-网络-反序列化”的完整链路。如果你把一个小型DataFrame从一个Task传到另一个Task，Ray的传输延迟可以低到亚毫秒级别，这在Spark里几乎是不可能的。
注意：Ray这套高效传输的代价是，它默认假定数据能放进内存，并不像Spark那样对超大数据集做太多自动溢出设计。如果Ray集群的对象存储撑爆，任务一样会崩，后面我会专门讲这块的坑。
2.3 容错设计：谁更适合跑三天三夜的大作业
分布式框架绕不开一个话题：某个节点挂了怎么办？
Spark的容错策略非常成熟。RDD的血统设计记录了一条数据从源头到结果的完整演变链，某个分区的数据在计算过程中丢了，系统只需要根据血统重新计算出这一个分区就行，不需要整个作业重来。对于那种要跑几个小时的超大ETL作业，这个能力是命根子。
Ray的容错机制也在不断完善：任务因异常退出会自动重试（max_retries），Actor崩溃后可以配置重建（max_restarts），对象丢失时可以根据创建任务重新计算。但这种容错理念更贴近“云原生微服务”的思路：坏了就重启，重启不行就换个节点，而不是像Spark那样针对大规模数据做精细的“只算丢失的那一块”。这决定了在超大离线作业场景下，Spark的稳定性依然是行业标杆；但在大量短小任务并行、失败后快速重试即可的场景里，Ray的粗粒度容错反而效率更高，因为它不需要维护一套血统关系。
3. 编程模型与适用场景：数据处理和AI计算的分野
3.1 数据分析案例中Spark为什么很难被替代
搜“spark数据分析案例”，你能找到的典型场景几乎长一个样：从HDFS或者数据仓库里拉出一大张表，经过清洗、过滤、join、聚合，得到一张结果表，再写回存储系统。这类作业的核心特征是：数据量大、计算模式固定、对吞吐要求远高于对延迟的要求。
Spark的DataFrame API是为这类作业量身定做的。它借鉴了关系型数据库的优化经验，Catalyst优化器会帮你做谓词下推、列剪枝、join重排这些常规优化；Tungsten则把热点算子编译为直接操作二进制数据的代码，省掉大量序列化开销。更关键的是，Spark SQL对SQL的支持极为成熟，这意味着你不需要写代码，直接扔一段标准SQL给Spark，它就能完成绝大多数数仓分析任务。
这也是为什么Spark在数据分析、数据仓库场景下几乎无法被撼动。你用Ray也能实现类似的group by join，甚至代码量也不大，但你需要自己管理DataFrame的分布方式、考虑数据传输的排布、手动优化执行计划——这些在Spark里全部是框架自动完成的。对一个数据分析师来说，用Spark SQL写SELECT a.*, b.name FROM orders a JOIN users b ON a.user_id=b.id是几十秒的事，用Ray你得重新发明一遍轮子。
3.2 Spark读取Redis这类特殊场景说明了生态的力量
还有一类热搜词特别有意思：“spark读取redis”“达梦数据库与apache spark的适配集成”。这些词背后的真实需求是：企业数据并不全在HDFS和数仓里，Redis里有缓存数据，达梦这类国产数据库里有业务数据，他们希望能用Spark把分散在不同存储里的数据统一拉起来做分析。
这种“数据源适配”的生态广度，是Spark经过十余年积累形成的巨大护城河。你几乎找不到一种主流存储系统，它没有对应的Spark Connector；只要写一句spark.read.format("redis").option(...)，Spark就能把Redis里的键值对拉出来当表用。类似的连接器在Ray社区也有，但数量、成熟度、维护活跃度都完全不在一个量级上。如果你要做的是数据集成和湖仓分析，Spark全家桶就是工业标准，不需要纠结。
3.3 从训练到推理：为什么AI团队普遍从Spark转向Ray
但要说到AI负载，事情就反过来了。
先拿超参数搜索举例。用Spark做超参搜索，传统做法是把搜索任务包装成一个Spark作业，每个Executor跑一组参数组合，然后通过Spark的accumulator把结果汇总回Driver。这种方式能跑，但体验很痛苦：每个训练任务的状态必须自己维护，任务之间的通信得靠外部存储中转，想让某个跑得好的实验动态产生下一组参数更是难以实现。
Ray Tune做这事就顺溜得多。它有现成的tune.run()接口，你用任何深度学习框架写一个训练函数，然后指定参数搜索空间，Tune会帮你调度N个并行试验，实时收集每个试验的指标，还能根据早期结果自动杀掉表现差的试验（早停机制），把资源集中给有希望的组合。整个过程动态性极强，而Ray的底层动态任务调度天然支持这种“边训练边决策”的逻辑。
再看强化学习（RL）。一个典型的RL训练任务是“环境采样-模型训练-参数同步”的无限循环，环境采样的进程要动态地开N个并行Actor，每个Actor各自跑一套环境的模拟，然后定期把数据汇入训练器。这种有状态、高通信、动态伸缩的工作负载，用Spark写就是灾难；用Ray RLlib，rllib.train()的一个内置算法就已经把环境和训练器的分布式调度处理好了。
还有一个高频场景是大模型部署。回到热搜里的“dgx spark部署qwen3.8 flash next”——在DGX这类GPU机器上部署大模型做推理服务时，你需要的不只是把模型加载到显存，还有动态batch、请求级别的优先级调度、多模型之间的GPU时间片分配。Ray Serve的架构就是把模型部署成一个个Actor，配合自动伸缩策略管理GPU资源。Spark在这类纯在线、实时性强的场景里，压根没有对应的能力槽位。
4. 框架选型决策指南：别听人扯淡，看自己的负载类型
4.1 一张决策表帮你理清思路
我自己经历过不止一次技术选型讨论，最后发现争论往往源于双方手里的场景不一样。这里把选型逻辑总结成一张表，希望对你有参考价值：
| 负载类型 | 更推荐 | 原因简述 |
|---|---|---|
| 超大规模离线ETL（T+1数仓构建） | Spark | 成熟稳定，血统容错，天然对接HDFS/Hive/Iceberg等数仓生态 |
| 交互式SQL/即席查询 | Spark（或Presto系） | SQL优化最成熟，查询引擎性能经过大规模验证 |
| 中小规模的并行计算任务 | 两者皆可 | 数据量大优先Spark，计算模式复杂优先Ray |
| 超参数搜索/模型调优 | Ray | Ray Tune的并行调度和早停能力远超Spark之上 |
| 强化学习训练 | Ray | RLlib的Actor模式和动态控制流完美契合RL范式 |
| 大模型分布式微调/推理 | Ray | 动态GPU调度、Serve推理管线和模型生命周期管理 |
| 数据科学家的日常脚本并行化 | Ray | 无需重写代码逻辑，加两行.remote就能并行执行 |
4.2 真实工作中我的一种选型路径
我的习惯是：先画负载画像，再决定用哪个框架。问自己几个问题：数据量级是多少，每天处理几百GB还是几百TB？作业结构是固定的Spark SQL链，还是有复杂的循环依赖？计算对象是数据表，还是模型权重和梯度？核心瓶颈是磁盘IO和shuffle，还是GPU利用率和任务间通信？
如果数据处理作业占80%以上、模型训练只是其中一环，那我会把Spark留作数据平台的主力，在它旁边并行部署一套Ray集群专门承担训练和推理任务。两个框架走同一套K8s或YARN集群，资源池分好，互不干扰。这正是当前很多中型公司里“大数据平台+AI平台”双轨制背后真正的原因：不是技术团队闲得慌要维护两套系统，而是单一框架确实吃不下全部负载。
4.3 工程化成熟度：YARN与K8s的选择也不容忽视
如果你的企业运行着成熟的大数据集群，Hadoop YARN作为资源管理器是标配，那么Spark on YARN的集成成熟度堪称完美——你只要把Jar包提交上去，资源分配、队列管理、日志聚合全部交给YARN搞定，运维侧省心得多。
相反，如果你们的IT底座已经全面容器化和K8s化，那么Ray的云原生基因会是更大优势。Ray官方推荐部署方式就是在K8s上跑Ray Operator，手动扩缩容、节点池管理、GPU调度都可以通过声明式API来操作。反观Spark on K8s，虽然社区支持已进入生产可用状态，但在Pod重启、动态资源申请这些细节上仍然没有YARN模式那么顺滑。“选框架，也要跟着你的运行环境走”——这是一个常被忽略、但关键时刻决定部署难度的要素。
5. 实操中的资源调度与运维痛点：这两个框架各有各的坑
5.1 Spark on YARN只分配一个vCore的问题
最近有个热搜问题非常典型：“spark on yarn cpu只能用1个是为什么”。问的夸张了一点，但真实情况是：在某些Spark作业中，Executor在YARN上运行时每个Container只分配一个vCore。如果各节点资源是够的，出现这种现象大概率是配置没对上。Spark Executor真正能用的并发度由spark.executor.cores决定，而YARN上给Container申请的核数由spark.yarn.executor.memoryOverhead之外的spark.executor.cores或者spark.yarn.max.executor.failures这些无关参数坑到。
最常犯的错是：只设置了spark.executor.instances和spark.executor.memory，没设置spark.executor.cores。Spark默认值按不同发布版本可能落到1，于是每个Executor只分到一个核，一个Executor同一时间只能跑一个Task，整作业并发自然拉胯。正确做法是显式指定，比如spark.executor.cores=4，同时在YARN侧确认yarn.nodemanager.resource.cpu-vcores和容器内存有足够余量。
还有一个隐藏坑：如果你在Spark on YARN模式中动态资源分配打开（spark.dynamicAllocation.enabled=true），Executor的数量会随着任务积压情况动态增减，但如果和spark.executor.cores配合不当，很容易出现任务排队而Executor不再增加的诡异现象。排查方式很直接：看YARN ResourceManager的Web UI，点开你的Application，观察每个Container实际请求的资源是多少，再对比Spark配置是否一致。
5.2 Spark OOM与内存调优的真实排查思路
再聊一个几乎每支Spark团队都会碰到的问题：Spark OOM。搜“spark oom”能翻出来成千上万条帖子，因为它实在太常见了。我见过最典型的一次生产故障：一个每天处理数百GB数据的DataFrame作业，某天数据量暴增后开始频繁OOM，最后把Executor内存调到32G依然报错。后来定位到根因不是数据量大，而是spark.sql.shuffle.partitions默认的200个分区完全不够，某个join操作要在一个分区里处理3G数据，单Task内存爆了。
一个标准可落地的调优路径是：先算单Task的数据量——如果单个shuffle分区大小超过Executor内存的1/4，就提高spark.sql.shuffle.partitions；然后动态调整执行内存占比，spark.memory.fraction默认0.6是把60%的堆内存交给执行和存储共用，如果作业是纯shuffle型，可以建议把spark.memory.storageFraction调低，让更多内存留给执行区。更关键的思路是防止数据倾斜：加盐、重新分区、广播小表，才是OOM问题真正的解药，堆内存只是兜底。
5.3 Ray集群里更容易被忽略的共享内存与对象存储风险
Ray的内存模型虽然好，但坑起来也够喝一壶。Ray的每个节点上都有一个共享内存区域用于对象传输，默认上限是可用内存的30%或按配置指定。如果你的代码里创建了很多大对象引用，而没有显式释放，Object Store会被填满，然后Ray会开始做Object Spilling——把对象溢写到磁盘上。听着像Spark的shuffle对吧？但它没有Spark那么成熟的磁盘管理策略，高频溢写时性能断崖式下滑。
在部署Ray的生产服务时，有两点建议给到你。第一，在ray.init()或集群启动命令里显式设置object_store_memory参数，别让它用默认值，因为默认值在多个大型Job共享一个集群时，会让某个Job的对象占用拖垮整个节点。第二，给大对象及时删引用：在循环里创建对象时，如果明确后续不再需要使用，可以显式del对象引用，或者用ray.object_store.delete释放，避免Ray的引用计数机制因循环引用导致内存永远不回收。
5.4 从“spark读取redis”和“dgx spark”看混合负载趋势
“spark读取redis”和“dgx spark”这两个热搜词，如果并联起来看，能看出一条清晰的行业趋势：传统数据平台和AI平台不再是两张皮，而是开始互相渗透。一方面，Teams想在数仓分析里实时关联Redis里的用户状态数据；另一方面，AI团队想把Spark的SQL能力用作数据预处理，然后把喂好的数据直接交给Ray和GPU集群做训练。这种混合负载很考验工程师的框架组合能力，但同时也证明了，熟练度停留在单一框架上的工程师，未来遇到的挑战会越来越大。
6. 集群搭建与实战落地建议
6.1 快速搭建一套可用于测试的多节点环境
实操环节，很多人搜“spark集群搭建”“spark安装详细步骤”后发现网上的教程都是单机模式或standalone模式，跟生产环境脱节。自己测试分布式特性时，可以用Docker Compose或Kind在单机拉三个容器当节点，分别充作master和worker。判断一套Spark集群能不能走上生产的第一道门槛，先看三件事：HDFS的NameNode是否高可用？YARN的ResourceManager是否配了HA？提交任务时是否走的是YARN模式而非local[8]？很多“我刚装好Spark”的人，其实只是跑通了local模式，离真正的分布式还差着YARN、HDFS、日志收集和监控告警那一整套东西。
跑Ray测试环境则轻量得多：在一个节点上ray start --head，其他节点执行ray start --address=<head节点IP>:6379，然后在Python里ray.init(address="auto")即可。如果你不想搭集群，也可以在单机跑init()模拟多核并行，先体验API，再平滑过渡到多节点。但注意：Ray单机模式和真正的分布式在共享内存和串行化行为上有细微差别，上线前务必在真实多节点环境压测一遍，省得到生产中才发现节点间网络带宽根本无法支撑训练通信。
6.2 一套经典的Spark on YARN提交参数参考
下面给出一个我在生产环境验证过的Spark on YARN参数模板。注意这是模板不是银弹，具体数值要根据你集群的物理资源做适配。假设每台机器有16 vCore、64G内存，跑一个中期ETL作业：
bash复制spark-submit \
--master yarn \
--deploy-mode cluster \
--num-executors 10 \
--executor-cores 4 \
--executor-memory 12G \
--conf spark.yarn.executor.memoryOverhead=2G \
--conf spark.sql.shuffle.partitions=80 \
--conf spark.sql.autoBroadcastJoinThreshold=104857600 \
--conf spark.memory.fraction=0.7 \
--conf spark.memory.storageFraction=0.3 \
--class com.example.ETLJob my-etl-job.jar
解释几个关键点：executor-memory=12G不是让Spark把整个Container的堆拿满，而是留出给YARN overhead的余量；executor-cores=4保证每个Executor能并行跑4个Task；autoBroadcastJoinThreshold设到100M是让小于100MB的表自动走广播join，避免大表和小表join时产生shuffle；shuffle.partitions建议设为目标数据量除以每个分区目标大小（约200MB），比如16G最终结果就设成80个分区左右。
6.3 Ray Serve生产部署检查清单
如果你决定在生产环境跑Ray Serve提供推理服务，我建议按这份清单逐项过一遍再上线：
- 集群内Head节点和Worker节点的Ray版本必须完全一致，否则会出现协议不兼容导致的无头苍蝇式报错；
- 给Object Store设置上限（
object_store_memory），防止请求并发上来后内存膨胀拖垮整个节点； - 给每个Deployment单独设置
num_replicas和max_concurrent_queries，这两者配合自动扩缩容策略决定真实的吞吐上限； - 在Gateway前加一层负载均衡，别让单个请求把某个Worker的GPU占满后其他请求排队排到超时；
- 开启Ray的Dashboard监控，重点盯
object store memory和GPU utilization两个指标，前者涨太快是内存泄漏，后者长期不高是调度问题。
6.4 两套框架在一个集群里共存的经验
当两条技术线在同一个团队里并行推进时，资源分配的“隔离”是关键。我见过一种方案非常有效：底层用K8s把集群切成两个资源池——大数据池和AI池——SPARK应用跑在大数据池，RAY跑在AI池，中间通过K8s的ResourceQuota做硬隔离，避免某个框架的内存溢出影响另一个。如果你的底层是YARN，也可以借助YARN的队列机制把资源切成team-a/b，Spark任务的优先级则通过队列的容量调度器配置。物理上做不做隔离都行，但逻辑上绝不建议两个框架毫无规矩地混在一棵树上调度，最后谁的资源都保证不了。
7. 踩坑记：分布式计算中最容易被忽视的三个细节
7.1 集群时间同步比想象中更致命
第一个容错点跟框架本身无关，却能把两个框架都干废：集群节点间的时间不同步。如果某台Worker的时钟比Head偏了哪怕几十秒，Spark的shuffle元数据过期、Ray的心脏丢失、K8s的Pod调度判定异常，这些奇怪问题会接踵而至。排查方式很简单：登录每一个节点跑date看时间，如果差太多，直接配置NTP服务让所有节点自动同步。别小看这一步，我接手过的至少两个分布式集群“疑难杂症”，根因都是时钟漂移。
7.2 Python版本与依赖隔离是Ray灾难重灾区
如果你用Spark 3.x跑PySpark，提交机上Python 3.8还是3.10影响有限；但Ray跟Python的关系极其亲密——它自身就是一个Python原生系统，任务的序列化、Actor的调度全部依赖Python运行时的类型体系。生产中最常见的问题是：Driver机上Python版本是3.10，而某个Worker节点上是3.8，Ray在反序列化任务时直接崩掉。搭建Ray集群前务必用ray status确认各节点版本一致，并且用虚拟环境或容器把依赖锁死再部署。依赖项如果版本冲突，需要把conda环境打包并在ray.init()里指定runtime_env，这个是Ray官方推荐的依赖隔离姿势——但一定注意打包环境的体积，太大的包会让每次任务调度都先花几十秒解压依赖，严重拖慢吞吐。
7.3 调参不能靠感觉：可观测性是第一工程
最后仍要强调一个认知：无论选Spark还是Ray，可观测性永远是分布式的第一工程。Spark有一套完善的History Server，spark-submit完成之后，在History页面能看到每个Stage的运行耗时、shuffle读写量、GC时间、执行器负载曲线；Ray有Dashboard，能按Task纬度看耗时和对象引用。而太多人当作业跑挂了才点开UI看图，其间白白消耗的计算成本早远超一台仪表盘服务器的成本。上线之前就把监控告警拉好，比你把任何一个框架的参数调到完美都重要。
回到最开始的结论：如果你要处理的是海量数据的加工清洗、报表生成和加工链路的稳定可靠，Spark仍是铁打的基本盘；如果你的负载重心正在向模型训练、推理和更动态的并行算法迁移，Ray已经是一个足够成熟的生产选项。比押注某一个框架更稳妥的思路，是让团队同时留出能力给两边——一边处理数据，一边驱动模型，它们不是替代关系，而是接力关系。 这既是未来数据智能平台的趋势，也是每个分布在计算工程师值得认真思考的课题。