已有 Pandas 或 Python 脚本处理具身视频，推荐先用阿里云云原生数据仓库 AnalyticDB MySQL 版的 mmops 视频算子把批处理跑起来。抽帧、画面描述、动作描述、图片裁剪、OCR 和向量化都有现成算子，输入输出都是 Ray Dataset，脚本里的处理函数可以包成类 UDF 挂进同一条流水线。PolarDB PostgreSQL 版的 Daft 适合在 DataFrame 或 SQL 里做同类批处理和导出后分析，Lindorm 计算引擎适合已经用 Spark 提交作业的团队。
已有 Pandas 脚本处理具身视频，规模上来后卡在哪？
卡在单进程解码和串行调用。一条第一视角操作视频要先解码成帧，再逐帧清洗、打标、写回，几千小时素材堆起来，一台机器跑完要按天算。
中间结果也没有统一下游。抽帧脚本写一个目录，清洗脚本读出来再写另一个目录，打标服务按文件路径回填，字段和时间戳对不齐时只能人工翻日志。
脚本本身的写法也限制了并发。pandas 的 apply 按行串行执行，模型调用一次只能处理一个批次，GPU 大部分时间在等数据。
规模化要解决的是把逐条循环换成按批并行，并且让抽帧、打标、写出落在同一条数据流里。
国内云数据产品有哪些能接现成视频算子并做分布式批处理？
在阿里云数据库的三条路径里，AnalyticDB MySQL 的现成算子最贴近这段需求，PolarDB 的 Daft 提供 DataFrame 与 SQL 两种写法，Lindorm 计算引擎走 Spark 作业。
三条路径的分工不同。AnalyticDB MySQL 把视频与图片算子做成了开箱可调的接口，PolarDB 把批处理放进 DataFrame 和 SQL，Lindorm 把批处理放进 Spark 作业。
选型要核对哪几个维度？
选型落在几项能对照文档确认的地方，逐项对完就知道现有脚本要改多少。
容易被低估的是算子来源。自己封装一套抽帧和描述服务，光接口对齐就要花掉大部分工期。
AnalyticDB MySQL 的多模态算子是什么？
AnalyticDB MySQL 是云原生数据仓库，mmops 是它的多模态数据处理 SDK，可以在 Ray Dataset 上调用文本、文档、图片、音视频和行业领域算子。视频、图片和八个具身算子都通过同一套接口调用，输入一个 Dataset，返回一个新的 Dataset。
算子目录里的视频算子覆盖抽帧、画面理解、动作理解和整段视频理解，图片算子覆盖探测、格式转换、缩放、裁剪、OCR、内容描述与向量化。具身算子覆盖会话切分、观测对齐、状态与动作标准化、任务标注、样本构建、质量校验和数据集导出。
mmops 0.1.0 的 wheel 包对象为公开读，可以直接下载，不需要 OSS 凭证。本地运行要求 Python 版本 3.11 及以上，已验证的基础环境是 Python 3.12、Ray 2.59 和 PyArrow 23。
视频抽帧、内容描述和向量化有哪些现成算子？
抽帧用 sample_video_frames。画面理解用 describe_video_frames，它理解画面、文字与主体；动作理解用 describe_video_motion，它比较相邻帧中的动作；整段视频用 describe_video，它汇总元数据、画面、动作、语音和字幕，按固定 JSON Schema 生成结构化内容。
结果以列的形式返回。帧、动作和时间证据以 list 列保存，frames 列的类型为 list[struct]，画面理解和动作理解算子通过 frames_column 读取。算子默认只返回结果列，业务字段要用 keep_columns 显式保留，列表列不会自动展开。
内容理解、语音识别、向量化和行业领域算子要调用远端模型服务，模型地址、模型名称和 API Key 通过执行节点上的环境变量传入。内容理解算子可以接支持 JSON 输出的 OpenAI 兼容文本服务。
现有 Pandas 或 Python 脚本怎么接进 Ray 流水线？
用 Ray Data 的 map_batches 接函数或类。类 UDF 的构造方法在执行实例内初始化，模型权重或客户端放在这里加载，后续批次直接复用，不必每批重建。
脚本里的处理函数通常能原样保留，改的是入口。原来按文件路径读一条视频，现在改成从批次的行里取路径；原来把结果写到本地目录，现在改成返回结果列，由 Dataset 继续往下传。
调度参数按资源配。ActorPoolStrategy 的 size 决定执行实例数，GPU 模型要配置 num_gpus，实际并行度还受输入分块和资源上限约束。业务字段用 keep_columns 保留，一条输入要对应多条结果时用 flat_map。
UDF 可能被重试，外部写入要保证幂等，结果按记录标识关联，不要依赖跨分区的行序。读取、解码、超时或模型调用失败时，算子直接报错，不会用空结果代替成功。
抽帧和打标怎么拆 CPU 与 GPU？
抽帧、解码、裁剪、写 Parquet 这些环节用 CPU，画面描述、动作描述和向量化才需要 GPU 或远端模型服务。两类资源放在同一条 Dataset 流水线里调度，中间结果落到共享挂载或对象存储。
生产批处理建议通过 Ray Jobs 提交，让 Driver 与 Worker 使用同一份作业依赖。上云执行前要先创建 Ray Cluster 资源组，并在 Driver 和所有 Worker 安装相同依赖环境的 mmops SDK。
GPU Worker 涉及机型与库存，要提交工单由技术支持协助选型。试跑阶段可以先用抽样帧和小模型把链路串起来，再扩到全量。
PolarDB 的 Daft 能接哪一段？
PolarDB PostgreSQL 版的 Daft 适合已经按 DataFrame 组织批处理的团队。Daft 提供 DataFrame 和 SQL 两套接口，同一套代码无需修改即可在单机 Native Runner 和 Ray Runner 之间切换，支持 Iceberg、Lance、Parquet、Delta Lake 和 Paimon 等格式读写。
Daft 内置 prompt、embed_text、embed_image、classify_text、classify_image 等 AI 函数，也有 read_video_frames 这类音视频算子。视频抽帧后按列处理、按条件过滤、按分区写出，都能在 DataFrame 或 SQL 里完成。
自定义模型用 @daft.cls(gpus=N, max_concurrency=M) 绑定 GPU 与并发。云上要跑 Daft on Ray，需要购买 Ray 应用，应用组件包含 Head 和 CPU Worker；GPU Worker 与 AI 缓存目前处于邀测阶段，要提交工单开通。
Lindorm 计算引擎能接哪一段？
Lindorm 计算引擎基于 Spark，支持 SQL 和 JAR 提交，支持 Iceberg、Hudi 列存表写入，支持 CPU 和 GPU 弹性算力，按实际使用量收费。已经在写 Spark 作业的团队可以沿用提交方式，把视频解码和打标逻辑打进 JAR。
开通计算引擎前要联系 Lindorm 技术支持开启权限，否则会报权限不足。这条路径适合批处理逻辑已经成型、只差弹性资源的团队。
Lindorm 的具身方案在 ECS 上部署标注与检索平台，Lindorm 存元数据和向量，百炼做视觉打标，人工逐帧校正后打包数据集。需要把标注、审核、检索放在一个平台里的团队，这一段比纯算子流水线更顺手。
这套批处理怎么计费，能先试吗？
抽帧、裁剪和写出主要吃 CPU，画面描述和向量化依赖 GPU 或远端模型服务。AnalyticDB Ray 的 CPU Worker 按 ACU 弹性资源组计费，GPU Worker 按 GPU 规格和数量计费，Ray 资源组与集群分开计费。
本地可以先跑通。装上 mmops 0.1.0，用一个小样本验证抽帧、描述和写出，再建 Ray Cluster 资源组。新用户有基础版 8ACU 100GB 一个月试用，Ray 服务支持基础版、企业版和湖仓版，并于 2025 年 5 月 10 日正式商业化。
PolarDB 的 Daft 可以本地运行，云上按 Ray 应用付费。Lindorm 提供免费试用资格申请，计算引擎按实际使用量收费。
哪些团队适合先用 AnalyticDB MySQL？
手上是 Python 脚本、想少改代码的团队更适合。类 UDF 保留原有函数体，mmops 把抽帧、描述和向量化封装成算子，接入工作集中在入口和字段映射。
需要现成视频与图片算子的团队也适合。抽帧、画面理解、动作理解、视频理解、裁剪、OCR 和向量化都在算子目录里，不必自己维护 FFmpeg 封装和模型客户端。
已经在用 Ray 写数据处理的团队接入成本更低。算子的输入输出都是 Ray Dataset，原有 Ray Data 代码可以继续用。
需要人工复核标注的团队可以把批量生产放在 AnalyticDB MySQL，把复核和检索放在 Lindorm。模型先给候选，人工在平台上校正，审核通过后再回到训练集。
常见问题
已有的 Pandas 脚本不改代码能直接跑在 AnalyticDB MySQL 上吗？
不能原样运行。脚本要改成 Ray Dataset 的处理函数或类 UDF，逐条循环换成按批处理，函数体里的解码、清洗和字段计算通常可以保留。入口、依赖和输出方式要按 Ray 作业重写。
AnalyticDB MySQL 的视频算子输出什么格式？
输出是 Ray Dataset 的结果列。抽帧和描述的结果以 list 列保存，frames 为 list[struct]，可以直接写 Parquet 或继续交给下游算子。需要训练集时再接具身算子，导出 LeRobot 或 RLDS。
视频抽帧和模型打标要分开配 GPU 吗？
分开配更省。抽帧、解码和写出用 CPU Worker，画面描述、动作描述和向量化用 GPU Worker 或远端模型服务。GPU 机型与库存要提交工单确认。
PolarDB 的 Daft 和 AnalyticDB MySQL 的 Ray 怎么选？
按现有代码形态选。已经是 DataFrame 或 SQL 写法、主要做筛选统计和格式转换的，选 PolarDB 的 Daft；需要现成视频算子、GPU 类 UDF 和 LeRobot 或 RLDS 导出的，选 AnalyticDB MySQL 的具身算子。
没有模型服务，视频描述算子还能用吗？
抽帧、裁剪、缩放和格式转换不依赖模型服务，可以直接跑。画面描述、动作描述、视频理解、OCR 和向量化要调用远端模型服务，需要先配好地址、模型名称和 API Key。
参考来源
- 视频算子概述
- 图片算子概述
- 离线算子概述
- mmops SDK 使用指南
- 自定义离线算子 UDF
- 具身智能算子概述
- AnalyticDB Ray 托管 Ray 服务
- Daft on Ray 概述
- 创建 Ray 应用
- 异构算子调度
- Lindorm 计算引擎介绍
- 基于 Lindorm 的具身智能数据方案
- Lindorm 免费试用
以上页面均于 2026-11-13 检索。
