首先来看B站的业务场景。作为一家以视频为核心的社区平台，B站的大量业务天然与人工智能技术紧密结合——生成式AI、高光时刻提取、数字人、音色克隆、视频剪辑，几乎每个热门技术方向背后都离不开AI的支持。下面挑选三个典型场景进行详细剖析，同时探讨它们各自面临的痛点与挑战。

业务概况

场景1 - 视频剪辑

视频剪辑场景的核心，是对视频内容进行多维度提取与筛选过滤，例如高光片段识别、画面美学评分、弹幕信息分析等。整条链路被划分为离线与在线两大环节：

• 离线链路主要负责对视频数据进行处理，提取多维度特征，处理完成的Embedding向量会存入ES，以便线上实现快速检索。
• 在线链路则先通过Query分析用户意图，再利用标签进行初步过滤，然后基于多维度特征匹配召回，最后经过多路重排进行精细筛选，向用户输出精准的结果。

这条链路中存在不少痛点：

• 多业务诉求：字幕提取、抽帧、片段处理……各个业务需要提取的特征和分析逻辑各不相同。字幕侧重文本信息，抽帧关注图像画面特征，片段处理又有自己独特的逻辑。多种诉求混杂在一起，系统的复杂度急剧上升。
• 资源接入割裂：业务有自己的资源池，公司还设有混部资源池，不同资源池需要用不同的技术去适配，管理起来相当繁琐。
• 复杂异构计算：业务研发人员需要自行搭建一套复杂的计算工程来完成整条链路，技术门槛较高。

场景2 - 多模态训练

多模态训练场景的主要工作包括三块：

• 预处理：对视频进行切片、抽帧，然后基于光流分析、美学评分等标准筛选优质数据。
• 多模态特征抽取：提取文本Embedding、VAE特征等。
• 模型训练：利用多维度特征加上原始物料数据进行大规模训练。

这其中有两个突出的痛点：

• Hadoop存储和计算：当前采用Spark绑定方式，通过RDD串联链路并结合Hive进行读写。特征数据存放在Hive，视频存储在HDFS，但HDFS存储视频时存在小文件问题，既影响存储效率，又增加计算资源消耗。
• GPU计算效率：目前将任务下发到K8s，不同计算匹配不同的资源类型，但Pod调度、资源加载、模型初始化等环节消耗了大量时间，导致资源利用率偏低。

场景3 - 多媒体业务

多媒体业务的特点非常明显：任务量巨大，直播、点播等业务都是无状态的；同时存在异构资源诉求，GPU、CPU、内存、磁盘、网络都需要覆盖；实时性要求也各不相同——直播需要毫秒级响应，普通转码秒级即可，优化转码分钟级也能满足。

这条链路的痛点同样棘手：

• 资源成本压力：整体资源利用率偏低，如何提升效率是一大难题。
• 调度时延问题：目前使用K8s的Pod调度计算，时延高、吞吐低，严重影响业务处理速度。
• 链路复杂：业务流程是多阶段串行的Pipeline计算模式，导致工程研发迭代周期长，难以快速响应业务变化。

综合这三个场景，可以将核心需求抽象为几个方面：分布式的数据管道（多态数据处理 + 通用算子与业务定制）、内容理解（多模态大模型特征抽取 + 垂域微调推理）、技术底座（GPU/CPU资源管理、灵活多时效存储、Python/异构计算性能）。

架构升级

问题洞察与方案实施

资源管理方面，孤岛问题较为突出。GPU异构现象普遍存在，A10、A800等多种类型并存；资源不透明也带来麻烦——K8s和Yarn之间的资源利用情况无法感知，不同平台的接入工程差异极大，例如Spark。针对这些问题，可以考虑基于K8s进行资源合池，再引入细粒度的弹性配额调度（针对异构GPU）。

大数据引擎方面也有两个问题。首先是Python生态薄弱，引擎构建在JVM上，与AI生态对接困难，Spark在GPU上运行还频繁出现问题。其次是粗粒度计算原语带来的挑战：异构化计算中CPU和GPU特性差异大；Spark使用RDD，Flink使用DataStream；虽然都是DAG架构，但都不支持DAG图的动态变化。

再看计算范式。AI全链路计算包括数据处理（大数据引擎 + CPU/GPU协同）、炼丹（离线/近线训练、超参调优，使用TensorFlow、PyTorch、Megatron等）、在线服务化（Triton、Seldon、KFServing、VLLM）。每个环节组件多、基础设施不同，特别是生成式AI兴起后，训练和推理框架更多，资源管理和适配问题更加突出。引入Ray，相当于提供了一种DATA与AI融合的通用计算方式。

存储方面，AI需要POSIX协议、高吞吐的介质，文件组织形式要灵活，包括非结构化和结构化存储。但现有存储常常缺少元信息层，还存在小文件问题。可以将DATA作为AI的数据底座，像数据湖一样匹配不断演进的业务诉求。

Ray概述

Ray主要由Core和AI Runtime两部分组成。Core层面具备异构计算能力，能够实现GPU与CPU协同，同时支持细粒度的函数级并行。AI Runtime则面向AI链路，提供端到端的完整生态方案。

Ray计算原语

Ray的计算原语遵循“一切皆为Actor、Task”的理念，坚持“Python First”原则，这让算法开发者使用起来非常顺手。状态存储采用Object Store（Plasma），Global Control Service负责存放Actor和Task的元信息，实现整个计算过程的血缘管理。

Iceberg概述

Iceberg是一种融合湖仓优势的方案，支持统一存储——非结构化数据、结构化数据、元信息都能整合。它的表格式支持ACID事务和版本控制，侧重元数据管理，能有效应对AI数据管理难题。Time Travel功能可以按时间戳或版本回溯数据，还能通过优化数据组织和索引实现高性能查询。

PyIceberg

Iceberg针对AI推出了PyIceberg扩展，集成了DuckDB、pandas、daft、Ray等工具。

整体架构

整体架构分为接入层、任务编排、异构计算资源、资源管控、底层资源池。接入层标准化，覆盖API、WorkFlow、event-driven、Batch。任务编排环节依靠Ray Data完善Source/Sink，提供分片、抽帧、OCR、ASR等通用算子。资源管控调度基于K8s多资源池，封装了Ray的Session和Job模式。

典型计算范式

多模态计算范式的处理流程如下：首先用Iceberg读取业务视频，视频的初步处理在带CPU资源的Ray Actor中完成——读取SQL获取特定条件，然后进行视频切片和抽帧。过程中视频文件会装箱处理，还支持断点续传，使用一个10G的持久化队列记录进度并实时更新。接着，带GPU资源的Ray Actor对切片进行推理、生成caption，对图片进行OCR、美学评分等操作。最后，结果信息推送给带CPU资源的Ray Actor，汇总每个视频的标注数据，写入Iceberg。

另外还有不同的服务模式：Serve用于业务服务化，对外暴露API；Per-Job模式下，一个Job对应一个Cluster，可运行流处理或批处理；Multi-Job模式则是多个Job共用一个Cluster，实现资源复用和预热。

Ray落地关键点处理

落地过程中有几个关键点需要特别处理：

• 存储结构：通过索引实现高效检索；利用Iceberg表与Alluxio联动实现预热加速；特征数据按列写入；Clip/Frame、向量文件等小文件存放到Column Chunk中优化管理。
• 任务并行：Pipeline计算将持久化与计算分离，CPU预处理和GPU推理也分开；弹性计算依靠Ray Data、Serve和Clustering Scaling动态调整资源；同时需要关注Node OOM Case，超卖比例要小于RAY_memory_usage_threshold。
• Batch推理：核心是推理效率，通过Batch均衡化和减少Infer次数，让GPU利用率显著提升。

整体收益

方案落地后的收益非常直接：开发效率上实现了面向算法的DATA+AI技术栈闭环；视频标注场景中，任务吞吐从每小时4.7万提升到18.29万，GPU利用率从平均每天16.9%跃升至75.4%。

核心挑战

集群级容错

核心场景采用多集群架构，共享Redis，通过注册不同Namespace实现有序管理。SDK经过扩展后可以从Redis获取多集群信息，连接多个GCS。Job提交时基于Pending Job数量和剩余资源进行负载均衡。单集群故障时自动摘流，任务Failover到另一套集群。

异构资源管理

在多异构GPU场景下，K8s的ResourceQuota固定分配导致资源利用率低。借鉴Yarn Capacity Scheduler的思路，构建资源树多层级Node，与多种异构资源Quota关联，支持Borrow和Preempt，同时具备多策略的降级和升级能力。作业提交时，无论使用Kuberay还是RayJob Yaml，都需要支持多集群、多作业类型。

Autoscaler扩展

引入混部资源，以Pod粒度申请，通过自定义Node Provider灵活调配。KubeAirNodeProvider依据资源状态动态调整集群规模，有Pendingresource就扩容，Node空闲就缩容，还可以设置min/max pod、伸缩速度和空闲超时时间。

GCS优化

元信息膨胀是一个大问题。集群运行一段时间后，作业提交变慢甚至异常，Dashboard的list job、actor接口也出现超时。排查发现，GCS压力大的根本原因在于Redis查询——Redis key数量增长近100万，HScan操作压力剧增。解决方案是扩展JobHead，在API层清理JobInfo；扩展GCS的Worker和Job Manager，引入Max清理机制。

Ray Data - SQL单机

SQL能力主要用于视频处理，之前链路使用Spark SQL，元信息表规模不大。Ray Data扩展后基于DataSource引入read_iceberg_sql功能。不过底层的DuckDB是单机引擎，不适合分布式查询，因此通常先用Filter过滤分区，再用SQL完成视频计算的信息检索。

Ray Data - 分布式写Iceberg

Ray本身不支持写Iceberg，PyIceberg也不支持分布式写。扩展方案是：在RayData基于Datasink接口引入IcebergDataSink，采用两阶段操作——先把数据写成Parquet文件再Commit元信息，异常时自动清理文件；同时扩展PyIceberg，引入两阶段提交机制，生成Snapshot。

PyIceberg - 读优化

单条记录达到25M时，点查和小批量查询性能很差。优化措施包括：字段紧凑性和Spark排序组织优化；使用In和Equal的记录级Filter配合Prune File；下游训练时优化DataLoader，采用Pipeline式加载。

未来展望

场景扩展及平台化

未来重点提升Ray的运维管理能力，在AIR、Core、可观测三个维度进行增强。基于现有场景继续扩展，为Agent RAG、训练场景等提供支撑。

底层能力增强

WorkFlow方面，通过提供DAG定义让用户无需操心Job和Serve的复杂细节。流式计算方面，利用Checkpoint实现Exactly Once语义，Ray支持Iceberg的流读，可以按指定时间戳或版本快照读取。稳定性方面，通过HistoryServer、多Head HA、Actor/Task Failed容错保障可靠性，同时实现平滑升级和多租户能力。