EMR Serverless Ray + Lance：从十亿级向量检索到 Python 多模态数据处理

在自动驾驶、图像检索和多模态内容理解等场景中，找到相似数据只是第一步。原始图片需要解码、清洗和标注，模型需要生成向量表示（embedding），召回结果还要经过重排与质量评估，才能进入训练集或业务系统。

这些环节大多依赖 Python 数据处理与模型生态。当数据规模增长到十亿级，平台既要支持大规模存储与高效检索，也要让算法代码顺畅地运行在分布式 CPU、GPU 资源上。

EMR Serverless Ray + Lance 将数据存储、向量检索和 Python 计算连接成一套工作流。 Lance 承载数据与索引，Lance-Ray 连接存储与计算，Ray 负责分布式执行，EMR Serverless Ray 提供托管的集群与作业运行环境。

国内某智能驾驶解决方案厂商基于该方案，在真实十亿级数据集上的测试结果显示：EMR Serverless Ray + pylance 实现了秒级检索，纯向量检索 P50 为 1.23 秒，"向量检索＋多条件过滤"的 P50 为 3.95 秒。 测试采用 768 维向量、L2 距离度量、Top-K 20,000，未使用缓存，直接读取 OSS。上述结果为单查询的引擎检索耗时，不含完整结果集的对外输出，完整测试配置与结果见第 3 节。

Ray 是面向 AI 与 Python 应用的开源分布式计算框架。其核心提供 Task、Actor 和分布式对象存储：Task 用于表达可并行执行的函数，Actor 用于承载需要保留状态的计算，例如在多个批次间复用同一份模型。Ray Data 在这些基础能力之上提供数据读取、转换和批量推理接口。

Ray Actor 官方文档：https://docs.ray.io/en/latest/ray-core/actors.html

对于图像 embedding 生成任务，开发者可以用 Python 函数完成解码与预处理，再用持有模型的 Actor 执行批量推理。通过 map_batches 组织计算时，模型可在 Actor 初始化阶段加载，随后复用于多个批次，减少重复初始化的开销。

Ray Data 批处理接口：https://docs.ray.io/en/latest/data/api/doc/ray.data.Dataset.map_batches.html

Ray Data 还采用流式批处理执行方式，让数据以分块、分批的形式流经各个处理阶段。其反压机制会在下游处理跟不上时限制上游继续提交任务，控制中间数据的积压。这为串联读取、CPU 预处理与 GPU 推理提供了基础；实际内存占用仍取决于批大小、并行度和模型本身的需求。

Ray Data 执行机制：https://docs.ray.io/en/latest/data/data-internals.html

EMR Serverless Ray 在开源 Ray 之上提供面向生产的托管计算能力。 平台将 Ray Cluster、Ray Job、Ray Serve 和 History Server 纳入统一运行环境，支持图片、视频、音频和文本等多模态数据处理，以及模型推理任务。开发者可通过 Notebook、作业提交和 SDK / API 使用计算资源，也可接入 DataWorks 调度。

EMR Serverless Ray 官方文档：https://help.aliyun.com/zh/emr/emr-serverless-spark/what-is-rayDataWorks 

集成说明：https://www.alibabacloud.com/help/zh/dataworks/user-guide/bind-emr-serverless-ray-computing-resource

在 Lance 数据处理场景中，EMR Serverless Ray 的平台能力主要体现在以下方面：

Lance 是面向 AI 数据的开源列式存储格式，可在同一数据集中组织业务属性、向量和多模态数据，兼顾批量扫描与随机访问，适用于批量生成 embedding、向量检索后按需读取候选样本等场景。通过 Python 包 pylance，开发者可以完成数据读写、检索、索引构建与版本管理，将数据存储与后续模型计算衔接起来。

Lance 文件格式说明：https://lance.org/format/file/

数据读写指南：https://lance.org/guide/read_and_write/

Lance-Ray 将 Lance 数据集接入 Ray：通过 read_lance 读取后得到 Ray Dataset，完成处理后可通过 write_lance 写回 Lance。官方集成还提供过滤下推、分布式列回填与数据文件整理等能力，让数据准备、模型计算和数据维护能够在同一套 Python 作业中组织。

Lance-Ray 官方说明：https://lance.org/integrations/ray/

例如，作业可选择待处理的列与记录，在 Ray 中生成新一版 embedding，再将结果回填到 Lance 数据集。

Lance-Ray 读取指南：https://lance.org/integrations/ray/read/

数据演进与列回填：https://lance.org/integrations/ray/data-evolution/

下图按业务入口、托管平台、异构计算和数据存储四个层次展示组件分工。CPU 和 GPU 队列按任务需要组织计算；Lance-Ray 在 Python 作业中连接 Lance 数据与处理逻辑。

图 1：EMR Serverless Ray + Lance 平台整体架构

本次测试使用 Lance-Ray 0.5.0、pylance 10.0.0。下表梳理社区 Lance-Ray 的主要能力，具体接口以所用版本为准；第 3 节仅测试向量检索性能。

Lance-Ray 的向量索引创建入口覆盖 IVF_FLAT、IVF_PQ、IVF_RQ、IVF_SQ、IVF_HNSW_FLAT、IVF_HNSW_PQ 和 IVF_HNSW_SQ。标量索引的分布式字符串类型入口支持 BTREE、BITMAP、INVERTED/FTS 和 ZONEMAP。

实际使用时，还需注意以下能力边界：

本次测试覆盖纯向量召回，以及叠加设备、时间、车型和地理位置等条件的检索场景，分别观察单查询延迟和批量并行查询表现。测试范围为引擎检索，不包含 GPU 模型任务与在线服务的端到端性能。

测试数据为该厂商自动驾驶采集图像生成的 CN_CLIP 向量，维度为 768，距离度量为 L2，查询返回目标为 top-20,000。本次测试使用 10e表。

EMR Serverless Ray 通过 pylance 直接查询 OSS 中的 Lance 数据，测试环境如下。

2～8 个弹性 Worker 表示节点伸缩范围，各轮实际使用的节点数可能不同。

Ray 作业按向量索引 segment 组织 Actor。10e 表使用 64 段 IVF_PQ 索引，由 16 个 Actor 执行，每个 Actor 处理 4 个 segment。Actor 是作业执行单元，与弹性 Worker 节点数量不同。检索任务的逻辑组织方式如下。

图 2：16 个 Actor 处理 64 个索引 segment，图中仅展开首尾两组。Actor 到 Worker 的分配由运行时调度决定；合并后的 top-k 为近似检索结果，不保证精确最近邻或满召回。

下表展示 EMR Serverless Ray + pylance 10.0.0 的单查询延迟，统计指标为 P50，单位为秒 。

本次采用分布式候选查询的引擎检索口径，不包含完整业务结果集的对外输出，因此这些延迟不能视为应用端到端响应时间。

（1）测试口径

测试设置了每批 20、40、80 条查询三档负载。Ray 批处理的共享扫描收益范围为 1.4～1.8 倍，但这一范围没有 10e 表的单独测量值作为对应验证。批次摊薄耗时不等于单请求响应时间。

（2）20 条批处理档： 表

下表展示 S1、S2、S3 和 S6 的批处理每查询摊薄耗时，单位为秒。

S2 过滤命中不足 top-20,000，不能作为满额查询的 SLO 证据。

10e 表的 40/80 档逐场景延迟及 20 档 S4、S5 延迟数据尚不完整，本节仅展示已有明细。

（3）吞吐表现：S1 纯向量、80 条批处理档

Ray 批处理从 20 档提高到 80 档时，吞吐基本趋于稳定，批次耗时随批量增加而增长；各过滤场景中的吞吐变化较小，S6 与 S1 接近。

（4）场景差异与稳定性

在未使用缓存、直读 OSS 的条件下，EMR Serverless Ray + Lance 已实现10e表的秒级引擎检索。 单查询覆盖纯向量到多条件过滤场景；20 条批处理档中，已列出的场景每查询摊薄耗时为 0.77～0.83 秒，过滤场景之间的波动较小。批量继续增大时，吞吐趋于稳定，后续优化可重点关注资源使用与数据访问瓶颈。

接入 EMR Serverless 缓存集群，可通过复用热点数据与索引、减少 OSS 重复读取，进一步释放检索性能。内部测试中，使用缓存可实现 20% 以上的检索加速，为热点查询、多轮样本挖掘等场景的预期提升提供了参考；本文 10e 表尚未启用缓存，具体收益取决于缓存命中率和实际负载。

在检索基础上，候选样本可继续进入 Python 数据加工与模型计算流程，完成重排、标注与结果回填，形成完整的多模态处理链路。

在图像处理、模型推理和自定义重排场景中，Ray + pylance 能将检索与算法代码纳入同一套 Python 作业，便于统一开发、分布式执行和持续迭代。

算法团队已有的 Python 函数、模型和工具，可以与 pylance 的数据访问及检索接口组合使用，再通过 Ray Task、Actor 或 Ray Data 扩展到多个节点。

实际业务往往需要在向量召回之后继续判断"哪些结果更有价值"。例如，智驾团队寻找"夜间、雨天、存在施工障碍物"的画面时，可以在 Python 中组织以下流程：

图 3：智驾样本挖掘流程。CPU 负责数据准备与后处理，GPU Actor 按需承担推理，Lance 保存数据与处理结果。

向量召回先缩小候选范围，视觉模型再识别天气、光照与施工障碍物，最后结合业务规则完成重排、去重和标签回写。开发者可在 Python 中加入条件分支、多轮召回和评估逻辑，减少查询系统与算法作业之间的接口适配。

EMR Serverless Ray 可将 Lance 数据读取与预处理分配到 CPU 队列，将 embedding 生成、视觉识别等模型计算分配到 GPU 队列，通过跨队列调度和独立扩缩容衔接各阶段负载，最终由 Lance-Ray 回填向量、标签和质量分数。

对于内容理解、分类和打标等模型 API 任务，Ray Data AI 通过 Dataset 上的 ai_query 接口组织批量调用，支持图片、视频帧等多模态输入，以及结构化输出、自适应并发、OSS 访问处理、单行错误隔离与重试，并提供 Token 消耗和执行耗时等指标观测。

Ray Data AI 也可对接 Ray Serve LLM 自建模型服务：CPU 侧的 ai_query 发起兼容 OpenAI 接口的请求，GPU 侧由 Ray Serve LLM 组织 vLLM 推理，配合流控、服务弹性和负载均衡完成批量计算。EMR 的现有方案示例将结果写入 Parquet；与 Lance-Ray 读写、列回填的端到端组合仍需适配验证。

EMR Serverless Ray 官方文档：https://help.aliyun.com/zh/emr/emr-serverless-spark/what-is-ray

模型更新后，团队可沿用处理流程重新计算结果，并通过 History Server、日志与资源监控追踪每轮任务。

当评分、打标或 embedding 模型需要被多个任务反复调用时，可以通过 Ray Serve 将模型部署为持续运行的服务，由数据处理作业复用。Ray Serve 支持通过 DeploymentHandle 在 Python 中调用部署，并将多个部署组合成处理链路，使模型服务与批处理流程能够分别维护。

Ray Serve 服务组合文档：https://docs.ray.io/en/latest/serve/model_composition.html

Ray Serve + Lance 可用于图片评分与标签回填。 作业从 Lance 按批读取图片及业务字段，调用 Ray Serve 中的模型获取评分、标签或向量，再通过 Lance-Ray 将结果作为新增列回填，供后续样本筛选和多模态训练使用。

图 4：Ray Serve 提供模型服务，Ray 批处理任务调用服务并组织回填，Lance 保存原始数据与新增结果列。

在智驾场景中，这一模式可用于图像质量评分、天气识别或 embedding 生成。不同加工任务可以复用同一模型服务，模型更新后再对目标数据重新计算、回填特征。具体实现需匹配模型输入输出、批处理方式和 Lance-Ray 接口版本；该方案未纳入第 3 节检索性能测试。

基于 Ray Serve 的部署组合能力，可以设计面向 Lance 的在线检索链路：接收请求后，调用 embedding 部署生成查询向量，由检索部署通过 pylance 查询 Lance，再调用重排部署并返回结果。这一链路属于待验证的架构扩展方案，尚未在本文版本与 EMR 环境下完成端到端性能验证。

Ray Serve 服务组合文档：https://docs.ray.io/en/latest/serve/model_composition.html

在这一方案中，Ray Serve 负责请求与服务部署的组织，Lance 提供数据和索引访问。增加 Serve 副本不等于自动完成索引分片或跨分片候选合并，这些仍需由检索实现负责。落地时还应验证数据版本刷新、每个副本的内存与缓存开销，以及完整请求链路的延迟、吞吐和召回率；第 3 节的引擎检索数据不能直接作为该在线服务的性能指标。

本次实测展示了 EMR Serverless Ray + Lance 在真实智驾数据上的秒级检索能力，也为后续样本挖掘和数据加工提供了基础。向量检索负责从大规模数据中找到候选，Python 处理与模型计算则进一步判断样本价值，将检索结果转化为标签、特征和训练数据。

这套架构的核心价值，是将检索与多模态加工组织在同一套 Python 工作流中。  Lance 保存数据与索引，Lance-Ray 衔接分布式读写和结果回填，EMR Serverless Ray 提供托管运行环境、弹性资源与任务观测能力。团队可以复用已有模型和算法代码，逐步串联数据清洗、向量生成、候选召回、重排评分与样本构建；对于反复使用的模型，还可通过 Ray Serve 提供共享服务，支持持续的数据加工与模型迭代。

EMR Serverless 缓存集群为现有检索能力提供了进一步加速空间。复用热点数据与索引。对于多轮训练、反复调试和模型评估等重复访问任务，缓存有助于减少 OSS 读取开销、缩短数据加载时间，并改善检索延迟，持续提升检索和多模态加工效率。

从已验证的向量检索出发，逐步叠加模型计算、服务复用与数据加速，EMR Serverless Ray + Lance 为多模态应用提供了一条可持续演进的实现路径，让同一份数据能够服务于检索、训练和业务决策。