基于Ray构建企业级多模态数据智算平台与一体化实践

TBDS 基于 Ray 构建多模态数据智算平台，实现了数据处理与AI计算的全链路打通。平台支持 GPU、CPU 及信创芯片的异构资源统一调度，核心收益包括：GPU 利用率提升 40%，处理效率提升 100%，AI 落地周期从月级压缩至天级。

背景与挑战

多模态数据处理的挑战

企业核心数据由结构化表格转向文本、图像、音视频、文档、向量等多模态形态，体量由 TB 级增至 PB 级，多模态数据处理已成为 AI 规模化落地的主要瓶颈。多模态处理链路（解析、抽帧/OCR、清洗、推理、入库）是 CPU 与 GPU 交替的流水线，在传统架构下被割裂为三类问题：

• 系统割裂：预处理、训练、推理独立部署，数据在 HDFS、SSD、对象存储、显存间反复拷贝，迭代周期以天计；

• 数据落盘：CPU/GPU 环节依赖对象存储接力，中间结果反复落盘，GPU 空等上游，时延增加；

• 调度割裂：GPU 调度（K8s）与大数据调度（YARN）互不感知，任务争抢资源、无法错峰，集群利用率长期低于 40%。

TBDS解决方案

TBDS 以统一计算底座为核心，将割裂的多模态处理链路重构为完整 Pipeline，通过统一引擎、统一存储、统一调度，实现异构算力上的一体化处理：

• 统一引擎：基于 Ray 将解析、清洗、抽帧、推理、入库等算子编排于同一 Pipeline，消除跨系统切换；

• 统一存储：中间数据在内存中零拷贝流转，免除落盘与数据搬运，消除 CPU 与 GPU 环节间的等待；

• 统一调度：将 GPU、CPU、信创芯片纳入同一集群，CPU 与 GPU 算子于同一 Pipeline 内混合调度；调度层同时感知数据处理与 AI 计算需求，实现负载错峰复用，并兼容国产信创芯片、满足自主可控要求。

总体架构

TBDS 多模态数据处理平台基于云原生套件构建，上支持纳管第三方K8s，实现资源复用，无需迁移和重复建设，整体架构上采用分层架构，自下而上把"异构硬件"逐层抽象为"统一算力"，为多模态数据处理、模型训练与推理提供一站式的 AI 基础设施底座。

平台核心技术突破

支持国产信创芯片

TBDS Ray分布式计算平台已全面适配国产信创芯片，涵盖海光 Hygon DCU、昇腾 Ascend NPU、昆仑芯 Kunlun XPU 三大主流国产加速器。通过统一的资源抽象与调度层，三种芯片以 Custom Resources 方式接入 Ray 调度体系，AI 任务无需修改业务代码即可透明运行在指定芯片上。平台全组件支持私有化部署，集群控制、资源调度、模型服务均可在客户内网独立运行，无需外部云依赖。三种芯片的驱动、运行时与框架库以标准化容器镜像预装，支持离线环境一键部署与弹性伸缩，为党政、金融等信创重点行业提供从国产芯片到上层应用的全栈自主可控 AI 算力底座，确保数据不出域、算力自主可控。

HyperFrame计算框架

pandas 是数据科学与量化研究领域事实上的标准工具，但它的设计是单机、单核、全内存的：一旦数据量超过单机内存就会 OOM 崩溃，且默认无法利用多核并行。在金融、券商场景下，海量行情、交易、持仓数据动辄数十 GB 乃至 TB 级，研究员常常被迫在"改用不熟悉的大数据框架重写代码"和"忍受单机跑数小时"之间二选一。

HyperFrame 的定位： HyperFrame 是 TBDS 自研的分布式数据科学计算框架，目标只有一个：让用户以熟悉的 pandas 代码，直接获得分布式集群的算力。它对上完整兼容 pandas API，业务逻辑无需改写，仅需替换一行导入即可将原有单机脚本运行在集群上；对下由框架自动完成数据分片、多机多核并行调度与容错，从根本上突破 pandas 单机、单核、全内存的三重瓶颈。

• API 完全兼容，零成本迁移：保留 pandas 的使用习惯与全部算子语义，研究员无需学习新框架，既有代码可平滑迁移；

• 突破单机瓶颈，横向扩展：数据规模不再受单机内存约束，计算自动分摊到多机多核，将原本受限于单机的小时级任务压缩到分钟级；

• 屏蔽分布式细节：数据分片、并行调度、容错恢复全部由框架接管，算法工程师只需编写单机逻辑——"单机代码，分布式吞吐"。

面向金融、券商等数据密集场景，HyperFrame 的价值尤为突出：

• 量化与风控计算：海量行情、交易、持仓等时序数据的分布式清洗、因子计算与策略回测，在保留 pandas 表达力的同时大幅缩短计算耗时；

• 大规模数据处理与特征生产：面向风控建模、智能投研等场景，对 TB 级客户、交易、市场数据进行分布式的清洗、聚合与特征工程，让算法团队以熟悉的单机代码承接远超单机能力的数据规模。

高效的Object Store内存管理算法

Ray 的共享内存 Object Store 是零拷贝数据流转的基石，但它是有限的内存资源。在超大规模多模态作业中，视频帧、点云、图像张量等大对象会快速堆积——一旦 Object Store 内存耗尽，会频繁触发内存数据spill操作、影响吞吐，甚至会导致Worker OOM 导致作业失败、全量重跑。

TBDS 的自研 Spill 算法。 我们针对多模态大对象的访问特征，重写了 Object Store 的溢出（Spill）逻辑：

• 智能内存水位控制：动态感知 Object Store 内存水位，设置高低双水位线——逼近高水位时提前、有策略地把对象溢出到本地/远端存储，回落到低水位则停止Spill，避免在临界点反复抖动，也避免"硬 OOM"；

• 冷热分层与优先级溢出：结合对象的引用计数、访问频率与血缘关系，优先溢出"访问频率低、且后续不再被下游算子引用"的冷对象，最大化保留热对象在内存中的驻留，从根本上降低回读开销；

• 异步溢出、不阻塞计算：溢出过程与计算异步并行，落盘 IO 不打断正在执行的算子，把溢出对前台吞吐的影响降到最低；

• 配合零拷贝与 cache 回读：被溢出的对象在需要时通过 tbdsfs://cache 加速回读，跨算子传递仍"传引用不传数据"，回读路径也尽量走本地缓存。

集群高可用

Ray 集群的全部集群级元数据（节点信息、Actor 注册表、Placement Group、资源视图等）由 Head 节点上的 GCS（全局控制服务）统一管理，默认仅存于内存，使 Head 成为整个集群的单点故障——GCS 一旦崩溃，Head 宕机、集群随之雪崩。在私有化环境中，没有公有云托管服务兜底，这一风险尤为突出。

TBDS在管控层（控制平面）实现了 Redis Sentinel 集群的自动创建与编排能力：集群启动时，管控层自动拉起一套具备主从复制、哨兵监控与自动故障转移的 Redis Sentinel 集群，并自动将其对接为 Ray GCS 的持久化后端。整个过程对用户完全透明——无需手工部署 Redis、无需手工配置容错参数，集群启动即具备生产级的 Head 高可用能力。当 Head 崩溃时，GCS 从 Sentinel 集群恢复元数据，配合 Worker 侧更长的重连超时窗口，Worker 保持存活并无感重连，集群实现自愈。

Ray Flow Insight：分布式作业的全局可观测

一条典型的处理链路（如视频抽帧、图像预处理、批量推理、结果后处理）会被拆分为成百上千个算子，以 Actor 和 Task 的形式分散调度到不同节点上并行执行，海量中间数据以 Object 形式在节点间流转。随着链路复杂度和集群规模的增长，Ray 分布式作业的"黑盒"问题日益突出：

缺乏全局视图：一条多模态处理链路由抽帧、预处理、推理、后处理等多个阶段的算子构成，分散在不同节点上，开发者往往只能观察到自己负责的某个阶段，难以看清各阶段算子之间的调用关系与数据流向的全貌；

瓶颈定位困难：处理速度上不去时，问题可能来自某个阶段的算力不足、节点间数据搬运、资源争抢或负载不均，缺乏全局视图时只能依赖日志分析和经验猜测，定位耗时；

卡点排查低效：作业卡住时，卡点可能出现在任意节点的任意算子上，跨节点依赖导致无法像单机那样直接查看堆栈，只能手动逐节点排查。

资源利用率不透明：CPU/内存/GPU 分散在多节点，难以获得统一的资源利用率视图，各阶段算子对异构资源的占用与调度只能靠经验判断。

原生 Ray Dashboard 提供了基础的集群监控，但在应对上述复杂分布式作业时能力有限，缺乏深度透视系统内部结构、数据流向与资源分配的专业工具。

TBDS Ray 从 Ant-Ray 开源社区引入并集成了 Ray Flow Insight——一套面向分布式 Ray 应用的可视化分析工具。它采用零侵入式设计，无需修改任何用户代码，即可基于 Ray 内部机制自动捕获 Actor（有状态组件）、Task（无状态函数）、Object（跨组件数据流）三大核心原语的运行时数据，并将其可视化，从而把复杂的分布式作业变得透明可观测。

Flow Insight 从宏观到微观、从静态到动态，提供四个互补视图：

• 逻辑视图（Logical View）：展示组件间的调用关系与数据依赖，帮助开发者快速理解整个作业的拓扑结构；

• 物理视图（Physical View）：展示 Actor/Task 在集群节点上的分布及 CPU、内存、GPU 资源占用，为部署与资源编排优化提供数据支撑；

• 分布式调用栈（Distributed Stack）：提供跨节点的调用链路追踪，快速定位执行卡点与潜在死锁，替代单机时代逐节点手动排查的低效方式；

• 分布式火焰图（Distributed Flame Graph）：聚合整个作业的执行耗时，直观呈现性能热点分布，指导精准优化。

Xpark多模态数据处理引擎

传统多模态处理要靠 FFmpeg（视频）、PaddleOCR（OCR）、SentenceTransformers（向量化）等一堆工具拼接脚本，环境割裂、无法横向扩展；迁到 Spark/Flink 又撞上 PyUDF 性能瓶颈与 API 不兼容。Xpark 是腾讯云基于 Ray Data 自研的分布式多模态计算引擎，它将 FFmpeg、PaddleOCR 等分散工具收敛为一套原生分布式、开箱即用的算子库。

• 丰富多模态算子：内置 40+ 文本 / 图片 / 音频 / 视频处理算子，支持用户上传自定义算子，不同模态数据可联合处理；

• 业界领先的去重性能：文本 Minhash 去重算子性能是 Data-Juicer(v1.4.3) 的 8 倍，独家分布式 Exact Substring 去重较开源版快 50 倍——这对大模型语料清洗这类"去重即降本"的场景意义重大；

• 完善的错误容忍：算子级重试、任务重分配、跳过策略与血缘重建，保障单点故障及数据异常场景下的可靠性；

• 任务级 Checkpoint：轻量级快照 + 异步持久化 + 增量快照，避免 Ray 故障下的全量重执行——PB 级作业跑到一半挂了，可从 Checkpoint 续跑而非从头再来；

• 原生分布式：基于 Ray Data 实现，天然横向扩展至 PB 级吞吐。

用户通过 Spark SQL 等工具在统一元数据（Gravitino）下建表，算子读取元数据，AI算子（如 TextTranslate）直连 TBDS 推理服务在 CPU/GPU 节点执行，结果直接回写平台表。建表、元数据、处理、回写四环节全程在 TBDS 内闭环，中间数据经 Object Store 零拷贝流转、免落盘，无需上传第三方 API 或中转外部存储。AI数据不出域，从机制上规避外泄风险，满足金融、政务等强监管行业的合规要求。

企业级产品能力

TBDS 为企业级 AI 场景提供从环境、运维到治理的全栈标准化能力，让算法团队无需关心底层基础设施、专注多模态数据处理本身。

监控告警与资源大盘

异构集群的可观测性难点在于"维度多、粒度细"——既要看全局资源水位，又要能下钻到单张 GPU、单个 Task。TBDS 构建了从集群到算子的四层可观测体系：

• 资源大盘（集群级）：平台提供统一的资源大盘，实时展示集群的 GPU 卡总量、已用量与剩余量，并支持按 Namespace/Project 维度查看各团队的配额与实际用量，资源分布情况清晰可查，协助运维及时发现并回收这部分碎片资源。

• 节点级监控：每张 GPU 的显存占用、温度、功耗实时采集和展示。

• 作业级监控：借助Flow Insight和Histroy Server，TBDS作业全生命周期追踪（提交时间、排队时间、执行时间、资源使用量），并提供任务级 Profiling——每个 Actor/Task 的 CPU / 内存 / 显存时间线，便于事后复盘与调优。

• 告警：对资源水位、作业健康度、节点异常设置阈值告警，异常自动通知，支撑运维快速响应。

操作审计

面向金融、券商和政务等高合规行业，TBDS 构建了覆盖全链路的企业级安全审计体系，确保算力平台上每一笔操作均可追溯、可举证、可审计：

• 全链路操作审计：对多源 Ray 任务实施全量操作轨迹记录，完整留存"何人、何时、何种操作"等关键审计要素，涵盖作业提交、资源申请、集群操作等全部交互行为。审计日志支持全文检索与批量导出，严格满足信息安全等级保护及行业监管的审计合规要求。

• 细粒度鉴权管控：实现用户级与租户级的双重权限管控。作业提交、资源申请、集群管理等关键操作均纳入统一鉴权框架，确保最小权限原则贯穿始终，从机制上杜绝越权操作风险。

• 国密算法全栈合规：TLS 传输层全面支持 SM2 / SM3 / SM4 国密算法套件，覆盖身份认证、数据加密与完整性校验等环节，在传输层面满足金融、政务等行业对商用密码应用的强制性合规要求。

自动扩缩容，集群挂起与资源调配

GPU/CPU 是最昂贵的资源，TBDS 从两个时间尺度上做资源降本，拒绝资源限制：

• 自动扩缩容（应对波动）：Ray 集群与推理服务均内置自动扩缩容——预设资源使用阈值（如队列积压、GPU 利用率、请求 QPS），触达阈值后自动扩容 Worker/推理副本，负载回落后自动缩容回收。让算力"随业务波动而伸缩"，避免为峰值长期预留冗余。

• 一键挂起 / 重建：对于阶段性使用的集群（如夜间空闲、项目间歇），可一键挂起释放底层全部机器资源、需要时一键原规格重建，规格、镜像、配置无损还原。相比"删除重建"，挂起/重建等操作，把集群恢复时间从小时级压缩到分钟级。

• 在线资源调配（应对规格变更）：当任务运行中需调整 Ray Worker 的计算规格（如增减 GPU、变更实例类型）时，TBDS 支持在线资源调配——修改目标规格后，系统自动触发 Worker 滚动重启并以新规格拉起，省去了"停服-重建-恢复"的冗长流程，在规格变更场景下保障业务连续性。

Python依赖包安装与管理系统

多模态 AI 的运行环境涉及 CUDA、cuDNN、ffmpeg、OpenCV、PyTorch 及各类模型 runtime，版本依赖关系复杂，环境搭建与维护成本较高。TBDS 通过一套分层的镜像与依赖管理体系，简化环境治理、提升构建效率：

• 双架构基础镜像：内置 x86 架构下的 GPU / CPU 双基础镜像，预装常用机器学习库，并将 CUDA、驱动等底层环境沉淀为标准基座，为上层应用提供稳定一致的运行底座。

• 在线 / 离线依赖部署：业务 Python 依赖同时支持在线安装（联网 pip）与离线部署（内网隔离环境下的私有源或包上传），适配不同网络条件下的环境构建需求。

• 免重打包动态调整：用户既可直接使用开箱即用的标准镜像，也可按需叠加自定义依赖，无需重新打包镜像即可调整运行环境。相较于传统"修改依赖需重新构建、推送、拉取整个镜像"的流程，该方式将环境调整简化为轻量的增量操作，有效缩短迭代周期。

Cache加速

在多模态大数据场景下，数据的"读"往往比"算"更容易成为瓶颈——PB 级数据反复从远端对象存储回源，带宽与时延双双成为瓶颈。TBDS 智算集群支持作业运行中，一键开启Cache加速，通过多级 cache 与零拷贝把数据尽量留在"离计算最近的地方"，提高GPU约15%的使用率：

• tbdsfs:// 直读 + 本地 cache：统一存储层 TBDSFS 支持直读，并在计算节点本地缓存热数据，命中后无需回源对象存储，显著降低 IO 时延；

• Object Store 共享内存零拷贝：同一节点内跨算子传递张量时"传引用不传数据"（passing by reference），避免了序列化/反序列化与内存拷贝开销，让 GPU 等待数据的时间趋近于零；

• 只有极少量数据需要落盘：配合高度优化 Object Memory Store Spill 算法，整条链路的落盘量被压到最低。

Spark SQL打通结构化数据与Lance多模态数据

TBDS 现已实现对开源湖仓格式 Lance 的产品化全链路支持。通过 Apache Gravitino 统一元数据服务注册 Lance Catalog，并结合 Lance SDK 完成底层数据读写，TBDS 让 Lance 表与平台内已有的 Hive、Iceberg 表处于同一元数据视图之下——用户只需一条标准 Spark SQL，即可在结构化业务数据与 Lance 多模态数据之间自由 JOIN、检索与聚合。

Lance 是面向多模态 AI 的新一代开源湖仓格式，专为图像、视频、文本、向量等数据设计，随机访问性能较 Parquet 提升百倍，并原生支持向量索引，全文索引等功能。传统架构上，结构化数据在数仓、多模态数据在 AI 存储，二者割裂、需反复搬运；如今在 TBDS 上，二者共享一份存储、共用一套元数据，一条 SQL 即可完成关联分析。

从元数据打通（Gravitino Lance Catalog）到数据读写（Lance SDK）再到计算执行（Kyuubi + Spark），TBDS 实现了 Lance 多模态数据分析的产品化全链路串通，让数据分析师与 AI 工程师在同一平台高效协作，加速企业级 AI 应用落地。

落地场景

TBDS 智算平台已在金融、券商等多个强监管、高算力需求行业落地。基于 TBDS 完成从多模态数据处理到 AI 落地的全流程。

适用客户与业务

• 银行 / 保险：合同、财报、尽调材料、影像件的批量解析与关键指标提取，支撑授信尽调、合同审核、智能风控

• 证券 / 基金：研报、招股书、公告的自动解析与摘要，支撑投研与合规审查

• 传媒 / 视频平台：每日数百万条 UGC/PGC 视频的抽帧、字幕识别、内容打标与安全审核

这类业务的共同特征是：数据形态多样（视频、PDF、PPT、扫描件、音频），处理链路天然异构——文档解析、抽帧、格式转换是 CPU 密集，OCR 与大模型理解是 GPU 密集，二者交替出现。

传统方案的困境

CPU 环节与 GPU 环节分属两套集群，中间靠对象存储接力：抽帧结果落盘、预处理结果再落盘、跨集群拉取到 GPU 侧、推理结果又落盘再入库。数据在集群间反复搬运，GPU 大量时间空等上游 CPU 出数据，两套集群利用率长期不足 40%，端到端时延被中间落盘环节拖成"小时级"甚至"天级"。若自建 OCR + NLP + 规则引擎链路，还需组建专门的 AI 工程团队，门槛高、周期长。

TBDS实施方案

针对多模态数据处理和RAG检索，TBDS 提供四种由浅入深的实现方案，客户可根据团队技术能力与业务复杂度自由选择：

方案一：Xpark 算子 (推荐，适合简单链路）

整条链路用 Xpark 函数+TBDS统一推理服务，可以快速构建多模态数据处理PipeLine，跑在同一个 CPU/GPU 混合集群内，利用GPU加速计算，利用推理服务提升多模态数据处理效果。

• 统一调度：CPU 算子（解码、抽帧、预处理、结果聚合）调度到 CPU 节点，推理算子调度到 GPU 节点，并对 GPU 做细粒度切分，让多路数据共享同一张卡；

• 流水并行 + 背压：各阶段以流水线方式并行推进，抽帧刚出一批、预处理与推理即跟进，GPU 不再空等；推理成为瓶颈时上游 CPU 自动降速；

• 零拷贝 + Spill：阶段间的解码帧、张量在内存中以引用流转、免去落盘，Spill 算法保障大对象在内存吃紧时不 OOM。

适用场景：多阶段、CPU/GPU 交替的复杂流水线（如视频理解全链路），追求极致资源利用率与吞吐性能的规模化生产场景。

方案二：自建 Ray 集群 + Python 作业（适合业务已有算法代码、需灵活定制）

对于已有成熟处理逻辑、希望保留代码控制权的团队，可在 TBDS 上一键创建 Ray 集群，按需安装多模态处理库（ffmpeg、OpenCV、PyTorch、各类模型 runtime 等），直接提交 Python 作业运行：

• 基于双架构基础镜像快速拉起集群，依赖支持在线 / 离线部署，免重打包动态叠加；

• 算法同学沿用熟悉的 Python / Ray API 编写分布式作业，平台负责调度与弹性扩缩容。

适用场景：已有存量算法代码需迁移上云、处理逻辑高度定制、或需要精细控制模型加载与推理细节的团队。

方案三：内置 SQL AI Function（适合业务人员零门槛自助）

借助自研 SQL AI Function，业务人员用一句 SQL 即可完成文档智能解析，无需任何 AI 工程能力：

• ai_parse_document 将非结构化文档解析为结构化 JSON；

• ai_query 按 prompt 模板抽取关键条款、判断风险点；

• ai_summarize 生成材料摘要；

• ai_mask 对敏感信息脱敏。

方案四：Ray + Lance 构建 RAG 检索底座（适合知识库问答与检索增强）

对于需要将企业私有文档沉淀为可检索知识库、支撑大模型检索增强生成（RAG）的场景，TBDS 基于 Ray + Lance 提供一体化方案，把"文档入库 → 向量化 → 检索"整条链路收敛到同一异构集群内：

• 分布式向量化入库：用 Ray 并行完成文档解析、切分（Chunking）与 Embedding 计算，CPU 侧做解析切分、GPU 侧跑 Embedding 模型，处理结果直接写入 Lance 列式向量存储，PB 级语料也能高吞吐灌库；

• Lance 湖仓一体检索：Lance 原生支持向量索引与标量过滤混合检索，向量、原文、元数据同表存储，无需再维护独立的向量数据库，检索时"一次查询"即可完成召回与过滤；

• 增量更新与零拷贝：新增文档以增量方式追加入库，无需全量重建索引；检索结果经 Object Store 零拷贝流转给下游大模型，直接拼接 prompt 完成生成。

适用场景：企业知识库问答、智能客服、研报/合规文档检索、投研资料库等需要检索增强的场景，尤其适合语料规模大、需频繁增量更新、且要求检索与生成低时延闭环的业务。

结语

TBDS 多模智算平台的异构计算能力，本质上是围绕 Ray 内核做深、做稳，再向上生长出面向异构与多模态的统一底座：

• 内核层，Head 高可用、自动故障转移、滚动升级，以及自研 Object Store Spill 算法，让大规模作业稳定长跑；

• 调度层，CPU + GPU + 信创芯片统一纳管，单 DAG 算子级绑核绑卡，把异构资源边界彻底抹平；

• 框架层，HyperFrame 把多模态 Pipeline 收敛为一张 DAG，CPU/GPU 一条流水线打通；

• 产品层，完善的监控告警、审计、弹性扩缩容、Python 依赖管理、cache 加速，以及自研 Xpark 多模态数据引擎与 SQL AI Function（一句 SQL 调用大模型），共同构成生产级、可信创的完备底座。