2024 年 12 月 6 日，由 Ray 中文社區、螞蟻開源聯合主辦的 Ray Forward 2024 年度盛會在北京螞蟻 T 空間成功舉辦。其中，Bilibili 基礎架構部技術專家鄭志升分享了《Ray 在 Bilibili 的場景探索與落地實踐》。Ray 作為新興分布式計算框架，為 B 站業務發展提供了強大助力。本文將詳細解讀 B 站如何借助 Ray 實現技術突破與業務升級。文章開篇將介紹 B 站業務概況，包括業務場景、訴求以及面臨的痛點，揭示 B 站尋求變革的背景。接著深入架構升級部分，分享問題洞察與方案實施過程，展現如何借助 Ray 優化架構。核心挑戰環節聚焦 Ray 的能力增強和優化，揭秘 B 站工程師們如何突破技術瓶頸。最后，未來展望從場景擴展、底層能力提升和平臺化等維度，勾勒出基于 Ray 的業務發展藍圖。無論是技術愛好者，還是渴望了解行業前沿的人士，都能從本文收獲關于 B 站與 Ray 深度融合的寶貴經驗與前瞻性視角。

一、業務概況

首先來介紹一下 B 站的業務概況。B 站是一個視頻社區，其中很多內容是與 AI 相關的，比如生成式 AI、高光時刻、數字人、音色克隆、視頻剪輯等場景。下面分享三個典型場景，介紹其面臨的一些痛點。

場景 1 - 視頻剪輯

在視頻剪輯場景中，需要對視頻的內容進行多維度的提取和篩選過濾，當中包括高光片段、畫面美學評分、彈幕信息等，具體會包括離線和在線兩條鏈路：

• 離線鏈路：主要工作是對視頻數據進行處理，從中提取多維度特征。處理完成后，會將得到的 embedding 向量存儲于 ES（Elasticsearch），以便后續在線上實現高效的檢索功能。
• 在線鏈路：首先通過 Query 對用戶意圖展開分析，并借助標簽過濾初步篩選信息。隨后，基于多維度特征進行匹配召回，從眾多數據中找出相關內容，再經過多路重排進行精細篩選，為用戶提供精準的結果。

下圖展示了視頻智能剪輯的工程鏈路。

在這一鏈路中主要面對的痛點包括：

• 多業務訴求
  在多業務場景下，存在著如字幕提取、抽幀以及片段處理等工作，這些工作的最終目的是通過提取特征實現檢索。然而，各業務之間存在差異，主要體現在抽取邏輯和分析邏輯不一致。例如，字幕提取業務可能側重于文本信息的抽取與分析，抽幀業務則更關注圖像畫面的特征獲取，片段處理或許又有其獨特的邏輯思路，這些不同的邏輯共同構成了多業務在實現特征提取與檢索過程中的復雜訴求。
• 資源接入割裂
  業務資源池，公司混部資源池，需要多種技術適配。
• 復雜異構計算
  對于業務研發，需要搭建復雜的計算工程來完成整個鏈路。

場景 2 - 多模態訓練

多模態訓練場景中的主要工作包括：

• 預處理
  預處理階段主要涵蓋視頻切片、抽幀等操作，在此基礎上還需進行優質數據篩選，而篩選的依據包括光流分析以及美學評分等，通過這些步驟完成對原始數據的預處理，為后續工作奠定基礎。
• 多模態特征抽取
  抽取文本、Embedding、VAE 等特征。
• 模型訓練
  多維度特征+原始物料數據，大規模數據訓練。

工程方案如下圖所示。

其中的主要痛點為：

• Hadoop 存儲和計算
  當前采用綁定 Spark，通過 RDD 串聯鏈路結合 Hive 讀寫的方式。其中，特征數據存儲于 Hive，視頻則存于 HDFS，但 HDFS 存儲視頻時存在小文件問題，這不僅影響存儲效率，還可能增加計算資源消耗，給多模態訓練工作帶來阻礙。
• GPU 計算效率
  目前采用下發任務到 K8s 的方式，針對不同計算匹配不同資源類型。然而，這一過程中資源利用率較低，主要原因在于 Pod 調度、資源加載以及模型初始化等環節，這些環節消耗了大量時間與資源，影響了整體的 GPU 計算效率。

場景 3 - 多媒體業務

多媒體業務場景具有一些顯著特點。一方面，任務量極為龐大，像直播和點播這類業務均呈現無狀態特性。另一方面，存在異構資源訴求，涵蓋 GPU、CPU、內存、磁盤以及網絡等多種資源。此外，實時性需求具有差異化，其中直播業務要求達到毫秒級的實時響應，普通轉碼業務需滿足秒級的實時性，而優化轉碼業務則為分鐘級的時效性要求。

下圖展示了工程鏈路的設計，分為兩部分，第一部分是通過轉碼調度器驅動切片、轉碼和合并三個階段的計算處理；第二部分是提供給業務的一些微服務。

這一鏈路面臨的痛點包括：

• 資源成本壓力，整體的資源利用率偏低，如何提升資源高效利用。
• 調度時延問題突出，當前圍繞 K8s 的 Pod 調度計算方式，存在高時延、低吞吐的情況，嚴重影響業務處理速度。
• 鏈路復雜且缺乏有效編排，業務流程呈現多階段串行的 Pipeline 計算模式，使得工程研發迭代周期變長，難以快速響應業務需求變化。

綜合上述三種業務場景，我們對核心需求進行了抽象：

• 分布式數據管道：多態數據的分布式處理；通用算子（OCR 等）和業務定制。
• 內容理解：圍繞多模態大模型，抽取特征；各垂域場景微調大模型的推理供給業務。
• 技術底座：資源（C/GPU）、存儲（靈活、多時效）、計算（Python/異構/性能效率）。

二、架構升級

根據上述三個場景的分析和痛點的概括，我們提出了針對性的解決方案。

1. 問題洞察和方案實施

在資源管理領域，孤島資源問題較為突出。其中，GPU 異構現象普遍，存在如 A10、A800 等各種不同類型的 GPU。同時，資源不透明問題嚴重，一方面無法感知多平臺（如 K8s 和 Yarn）之間的資源利用情況，另一方面，不同平臺在資源接入時工程差異極大，以 Spark 為例，這種差異給資源整合帶來諸多困難。針對這些問題，可采取基于 K8s 資源合池的措施，并引入細粒度（針對異構 GPU）資源彈性的配額調度，以優化資源管理。而這一系列舉措，與大數據引擎的高效運行息息相關。

大數據引擎存在兩方面顯著問題。首先是 Python 生態薄弱，由于大數據計算引擎構建于 JVM 之上，這使得它與 AI 生態難以實現無縫對接，同時，Spark 在 GPU 上運行時問題頻發，適配過程困難重重。其次，粗粒度計算原語也帶來挑戰：異構化計算中，CPU 與 GPU 特性差異明顯；計算模型方面，Spark 采用 RDD，Flink 使用 DataStream；而且，盡管 Flink 和 Spark 都采用 DAG 架構，卻均無法支持 DAG 圖的動態變化。

在計算范式中，AI 全鏈路計算過程涵蓋多個關鍵環節。數據處理環節借助大數據計算引擎，針對多模態數據進行 CPU 與 GPU 協同計算；“煉丹” 環節包括離線和近線訓練、超參調優，會用到 TensorFlow、PyTorch、Megatron 等工具；在線服務化環節涉及在線推理以及大規模在線推理，常采用 Triton、Seldon、KFServing、VLLM 等。實施方案方面，每個計算環節都涉及眾多組件或工具，且不同環節的基礎設施存在差異。尤其是生成式 AI 的興起，帶來更多訓練和推理框架，使得資源管理和適配問題愈發突出。在此背景下，引入 Ray 可提供一種 DATA 與 AI 融合的通用計算方式，有望解決上述難題。

在存儲介質方面，AI 對存儲有著特定要求。一方面，需要 AI 友好的介質，即遵循 POSIX 協議且具備高吞吐能力（如緩存）的存儲介質，以滿足 AI 運算對數據讀取速度的需求。另一方面，文件組織形式需足夠靈活，涵蓋非結構化與結構化存儲。然而，現有存儲常缺乏元信息層，且存在小文件問題。針對這些情況，可采取的措施是，將 DATA 作為 AI 的數據底座，使其能像數據湖一樣，匹配不斷演進的業務訴求，更好地服務于 AI 應用場景。

2. Ray 概述

Ray 主要包含 Core 和 AI Runtime 兩大部分。在 Core 層面，它具備異構計算能力，能夠實現 GPU 與 CPU 的協同工作，同時支持細粒度并行計算，將并行粒度細化到函數級。而 AI Runtime 則是面向 AI 鏈路，提供從一端到另一端的整套生態解決方案，為 AI 相關任務提供全面支持。

3. Ray 計算原語

在 Ray 的計算體系中，計算原語遵循“一切皆為 Actor、Task” 的理念，并且秉持“Python First” 原則，這使得其在開發過程中能緊密貼近算法開發，極大地方便了算法開發者。與之配套的狀態存儲，采用 Object Store（Plasma）來實現。此外，Global Control Service 扮演著重要角色，它負責存放 Actor、Task 的元信息，進而實現對整個計算過程的血緣管理，確保計算過程的可追溯性與有序性。

4. Iceberg 概述

Iceberg 是一種融合湖倉優勢的解決方案。它具備湖倉一體特性，可實現統一存儲，無論是非結構化數據、結構化數據還是元信息，都能整合存儲。Iceberg 表格式更是功能強大，不僅支持 ACID 事務及版本控制，確保數據操作的一致性與可追溯性，還著重于元數據管理，有效應對 AI 數據管理難題。同時，它提供 TimeTravel 功能，憑借時間戳或版本號回溯數據，滿足不同場景下的數據追溯需求。此外，通過優化數據組織與布局、增強索引等方式，實現高性能查詢，為數據處理和分析提供有力支持。

5. PyIceberg

Iceberg 針對 AI，做 PyIceberg 擴展，包含 DuckDB、pandas、daft、Ray 等等。

6. 整體架構

整體架構由接入層、任務編排、異構計算資源、資源管控、底層資源池構成。在接入層，采用標準化接入方式，涵蓋 API、WorkFlow、event - driven 以及 Batch，確保各類數據與任務能順利接入。任務編排環節，依托 Ray Data 完善 Source/Sink，并提供如分片、抽幀、OCR、ASR 等通用領域算子，實現任務的合理編排與處理。資源管控調度基于 K8s 多資源池，通過封裝 Ray 的 Session 和 Job 模式，對異構計算資源和底層資源池進行有效管理與調度，保障系統的高效穩定運行。

7. 典型計算范式

在典型計算范式中，針對多模態計算范式有著特定的處理流程。首先，借助 Iceberg 讀取業務相關視頻，這些視頻的初步處理運行在配備 CPU 資源的 Ray Actor 中，通過讀取 SQL 獲取特定條件，進而對視頻進行視頻切片與抽幀操作。在此過程中，目錄下的視頻文件會進行裝箱處理，并且支持斷點處理，利用一個大小為 10G 的持久化隊列來記錄處理進度并保持實時更新。隨后，配備 GPU 資源的 Ray Actor 進一步對相關信息（message）進行處理，具體包括對視頻切片開展推理、生成 caption，對圖片執行 OCR、進行美學評分等操作。之后，執行結果信息會被推送給配備 CPU 資源的 Ray Actor，由其匯總每個視頻的標注數據，這些數據涵蓋  OCR、評分、caption 等內容，最后將其持久化寫入 Iceberg。

此外，該計算范式還包含不同的服務模式。其中，Serve 用于業務服務化，通過對外暴露 API 實現接入；Per - Job 模式下，一個 Job 對應一個 Cluster，既可以運行流處理任務，也能運行批處理任務；而 Multi - Job 模式則是多個 Job 共用一個 Cluster，以此實現資源的復用與預熱（warmup）。

8. 針對 Ray 落地關鍵點問題處理

下面介紹 Ray 落地過程中，對存儲結構、任務并行、Batch 推理關鍵點的處理。

• 存儲結構

在存儲結構方面，包含多個重要部分。首先是查詢檢索，通過基于索引的方式實現對數據集的高效檢索。同時，借助 Iceberg 表與 Alluxio 的聯動，達成預熱加速效果，進一步提升檢索效率。其次是特征列，依據不同場景，會產出不同維度的特征數據，這些數據將按列寫入存儲系統。再者是小文件處理，諸如 Clip/Frame、向量文件等小文件，會被存儲到 Column Chunk 中，以此優化小文件的存儲管理。

• 任務并行

在任務并行處理方面，主要涉及以下幾個關鍵特性。首先是 Pipeline 計算，它將持久化與計算進行分離，同時把 CPU 預處理和 GPU 推理也分離開來，這種方式有助于提高任務處理的效率與靈活性。其次是彈性計算，借助 Ray Data、Serve 以及 Clustering Scaling 等技術，系統能夠根據任務需求動態調整資源，實現高效的資源利用。此外，還需關注 Node OOM Case（節點內存超賣情況），當節點出現內存超賣時，會觸發系統 killer。這里存在一個超賣比例，該比例需小于 RAY_memory_usage_threshold，以此維持系統的穩定性與可靠性。

• Batch 推理

在 Batch 推理方面，推理效率至關重要。實現高效推理主要依賴幾個方面：一是 Batch 均衡化，確保數據批次的合理分配；二是減少 Infer 次數，避免不必要的推理操作；通過這兩項舉措，能夠使 GPU 利用率得到均衡且顯著的提升，從而整體上提高 Batch 推理的效率。

9. 整體收益

整體來看，該方案帶來了多方面收益。在開發效率層面，實現了面向算法的 DATA + AI 技術棧閉環，為算法開發提供了更完整、高效的環境，極大地提升了開發效率。在視頻標注場景中，成效更為顯著：任務吞吐從每小時 4.7 萬提升至 18.29 萬，提升幅度明顯；GPU 利用率也從平均每日 16.9% 躍升至 75.4% ，資源利用效率大幅提高，有力地證明了方案在實際應用中的卓越價值。

三、核心挑戰

接下來介紹面向 Ray 底層遇到的一些問題以及相關的思考和解決方案。

1. 集群級容錯

在集群級容錯方面，主要圍繞核心場景多集群展開工作。針對核心場景中的多個集群，采用共享 Redis 的方式，并在其中注冊不同的 Namespace，以此來實現各集群間的有序管理。同時，對 SDK 進行擴展，擴展后的 SDK 能夠從 Redis 獲取多集群信息，進而連接多個 GCS（Global Control Service，全局控制服務 ）。在 Job 提交過程中，實現基于 Pending Job（待處理任務）數量以及剩余資源情況的負載均衡，確保資源的合理分配與高效利用。此外，當單集群出現 Failed（故障）或者下線的情況時，系統能夠自動進行摘流，并將任務 Failover（故障轉移）到另一套集群，以此保障整個系統的穩定運行，提升容錯能力。

2. 異構資源管理

異構資源管理面臨諸多挑戰，尤其是在多異構 GPU 場景下。其中一大難點在于，K8s 的 ResourceQuota 采用固定資源分配方式，導致資源利用率較低。為解決此問題，可借鑒 Yarn Capacity Scheduler 的策略。通過構建資源樹多層級 Node，將其與多種異構資源 Quota 相關聯，不僅支持資源的 Borrow（借用）、Preempt（搶占），還具備多策略的降級和升級功能，從而提升資源的動態管理能力。

在作業提交環節，涉及到 Worker 的相關操作。目前 RayJob 的適配方式尚在探討中，例如是采用 Kuberay，還是 RayJob Yaml 方式。無論采用何種方式，都需支持多集群、多作業類型，并能將不同的 Job 描述進行封裝，提交到 k8s 平臺，以實現異構資源管理下作業的高效提交與執行。

3. Autoscaler 擴展

在 Autoscaler 擴展方面，主要采取了兩項關鍵舉措。其一為引入混部資源，這種方式以 Pod 粒度進行資源申請，并通過自定義 Node Provider 來實現對資源的靈活調配。其二是采用 KubeAirNodeProvider，它依據資源狀態來動態調整集群規模。當存在 Pending resource（待處理資源請求）時，觸發 Scale up（擴容）操作；而當 Node 處于 Idle（空閑）狀態時，則執行 Scale down（縮容）。同時，還可對 Scale min/max pod（最小 / 最大 Pod 數量）、scale speed（伸縮速度）以及 Idle timeout（空閑超時時間）等參數進行設置，從而精準地控制集群資源的動態調整，以滿足不同業務場景下的資源需求。

4. GCS 優化

GCS（全局控制服務）優化成為亟待解決的問題，主要源于元信息膨脹現象。當集群運行一段時間后，作業提交速度明顯變慢，甚至出現異常情況，同時 Dashboard 下的 list job、actor 等接口也會響應超時。

經過深入的問題剖析，發現 GCS 承受著巨大壓力，響應耗時居高不下，問題根源定位在 Redis 查詢環節。進一步深入挖掘得知，Redis key 數量增長近 100 萬，使得 HScan 操作壓力劇增。

為解決這一問題，制定了元信息清理機制。一方面，擴展 Job Head，在 API 層引入對 JobInfo 的清理功能；另一方面，對 GCS 的 Worker 和 Job Manager 進行擴展，引入 Max 清理機制，以此來緩解 GCS 壓力，提升系統整體性能。

5. Ray Data - SQL 單機

在 Ray Data - SQL 單機場景下，其具備獨特的能力與特點。就 SQL 能力而言，主要應用于視頻處理，此前該鏈路采用 Spark SQL。其中，元信息表規模通常不大，而核心處理任務聚焦在視頻數據上。為進一步優化，Ray Data 進行了擴展，基于 DataSource 引入了 read_iceberg_sql 功能。不過，該模式也有其適用場景限制，由于底層采用的 DuckDB 為單機計算引擎，并不適合分布式查詢。所以，通常會先利用 Filter 對分區進行過濾，之后再借助 SQL 完成針對視頻計算的信息檢索工作。

6. Ray Data - 分布式寫 Iceberg

在 Ray Data - 分布式寫 Iceberg 過程中，面臨著一些問題。一方面，Ray 本身不支持寫 Iceberg；另一方面，PyIceberg 也不支持分布式寫操作。為解決這些問題，進行了多方面的擴展。在 Ray Data 方面，基于 Datasink 接口，創新性地引入了 Iceberg Data Sink。其采用兩階段操作，首先將數據寫入 Parquet 文件，之后再 Commit 元信息，若操作過程中出現異常，則會自動清理文件。同時，對 PyIceberg 也進行了擴展，引入兩階段提交機制，使其支持元信息的 Commit 提交，并生成 Snapshot，以此實現 Ray Data - 分布式寫 Iceberg 的功能。

7. PyIceberg - 讀優化

在 PyIceberg 的讀操作中存在一些問題。當單條記錄大小達到 25M，且執行點查或小批量查詢時，查詢性能較差，而這些數據下游又常用于訓練和離線推理，對性能要求較高。針對這些問題，進行了一系列 Iceberg 優化措施。首先，在數據存儲結構上，通過字段緊湊性以及 Spark 排序組織優化，提升數據讀取的基礎效率；其次，在查詢過濾方面，采用 In 和 Equal 的記錄級 Filter，結合 Prune File 優化，減少不必要的數據讀取；此外，針對下游訓練，優化 DataLoader，采用 Pipeline 式加載數據，進一步提升數據讀取性能，以滿足訓練和離線推理對數據讀取性能的需求。

四、未來展望

1. 場景擴展及平臺化

未來會提升 Ray 的運維管理能力，對內部應用的一些 AIR、Core、可觀測三個維度進行增強。基于目前場景進一步擴展，基于 Ray 對 Agent RAG、訓練場景等提供支撐。

2. 底層能力增強

在底層能力方面，主要對以下幾個關鍵領域進行增強。首先是 WorkFlow，通過提供 DAG 定義，幫助用戶屏蔽開發 Job 和 Serve 的復雜細節，降低開發難度，提升工作效率。其次是流式計算，借助 Checkpoint 機制，實現 Exactly Once 語義，確保數據處理的準確性和一致性。同時，Ray 支持 Iceberg 的流讀操作，能夠依據指定的 Timestamp 或版本號進行快照讀，為數據讀取提供更多靈活性。此外，穩定性增強也是重點工作，通過采用 History Server、多 Head HA 機制，以及針對 Actor/Task Failed 的容錯處理，保障系統在運行過程中的可靠性，同時實現平滑升級，和多租戶能力，進一步提升系統的整體穩定性和適用性，以滿足不同場景下的多樣化需求。