如果你在做一个 AI 项目，你的数据流大概率长这样：
Spark 集群跑 ETL，清洗完写到 OSS → AI 团队从 OSS 拉数据到 GPU 集群 → 做特征工程 → 训练 → 模型推回 OSS → 推理服务再从 OSS 读模型上线。
中间至少三次搬运，两次格式转换，三套权限同步。数据量一大，光是搬数据就吃掉一半时间。
这不是某个团队的问题，是整个行业的默认架构。
问题出在哪
Spark 和 Ray 本质上是两套计算框架，设计目标完全不同：Spark 为大规模数据并行而生，Ray 为分布式 AI 训练推理而生。它们各自有自己的调度器、资源管理器、容错机制。
过去几年，几乎所有云厂商的做法都是"两个平台并排放"——数据平台跑 Spark，AI 平台跑 Ray，中间靠对象存储做数据中转。看起来各司其职，实际带来三个问题：
数据搬运成本。 每一次 ETL 到训练的切换，都意味着数据落盘、序列化、网络传输、反序列化。TB 级数据搬一次就是小时级开销。
元数据割裂。 Spark 侧的表 schema 在数据目录里，Ray 侧的特征和模型在另一个地方管理。数据血缘断了，权限要同步两套，治理成本翻倍。
资源浪费。 两套集群各自预留资源，Spark 集群白天跑批晚上空着，GPU 集群训练完也空着。算力不能共享，成本不能摊薄。
同一平台，一份算力
答案其实很简单：让 Spark 和 Ray 跑在同一个平台上，共享同一份数据和同一套权限。
Spark 写完的 Iceberg 表，Ray Data 直接读，零拷贝、零格式转换。ETL 完了接着跑训练，中间数据不落盘。CPU 和 GPU 在同一个资源池里弹性调度，谁需要谁用。
这不是新概念。Databricks 在美国已经在做——Spark 和 Ray on Lakehouse，同一份数据湖底座，同一套计算资源。但国内一直没有生产级的落地方案。
统一的工程门槛
"把 Spark 和 Ray 放一起"说起来一句话，做起来要解决一堆工程问题：
- 两套调度器怎么协同？Spark 的 DAG 调度和 Ray 的 Actor 模型怎么统一
- 资源怎么分？CPU 跑 Spark、GPU 跑 Ray，同一个 K8s 集群里怎么隔离又怎么共享
- 数据怎么读？Spark 写 Iceberg，Ray 能不能直接读，还是又要转格式
- 多模态数据怎么处理？文档、图像、音视频能不能在同一套引擎里跑
- 运维谁来做？两套框架的监控、告警、日志、扩缩容怎么统一
这些问题不解决，"统一平台"就是 PPT 上的口号。
7月25日，腾讯云的答案
7 月 25 日上午，DataFun Agentic AI Summit · 腾讯云大数据专场，腾讯云将正式发布智能数据湖计算 AI DLC——国内首个在同一平台上同时提供生产级 Spark + Ray 全托管服务的产品。
现场不只是讲架构，还会直接演示：同一个 Notebook 里，先跑 Spark SQL 做数据清洗，再跑 Ray 做模型训练，中间数据不搬、格式不转、权限不变。
技术解读环节会逐一拆解三大核心引擎——TCRay（Ray 全托管与 GPU 弹性调度）、Xpark（多模态高性能算子层）、Meson（复杂计算加速引擎）——看每个引擎具体解决什么问题。
博世也将到场分享两场实战：一场讲 Ray on TKE 如何纳管异构算力、实现双通道调度与在线离线混合复用；一场讲智驾海量训练数据的多模态治理与数据飞轮构建。这是国内少有的、从行业客户视角讲 Ray 落地的案例。
如果你正在被"两套集群、数据搬运"的问题困扰，或者想看看国内有没有对标 Databricks 的落地方案，这场专场值得来。
7 月 25 日（周六）上午 9:30-12:05
深圳机场凯悦酒店
DataFun Agentic AI Summit · 腾讯云大数据专场
扫描下方海报二维码预约席位。
现场参与互动抽奖，赢取马年公仔。席位有限，请提前预约。
END
