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

一、業(yè)務(wù)概況

首先來介紹一下 B 站的業(yè)務(wù)概況。B 站是一個(gè)視頻社區(qū)，其中很多內(nèi)容是與 AI 相關(guān)的，比如生成式 AI、高光時(shí)刻、數(shù)字人、音色克隆、視頻剪輯等場景。下面分享三個(gè)典型場景，介紹其面臨的一些痛點(diǎn)。

場景 1 - 視頻剪輯

在視頻剪輯場景中，需要對(duì)視頻的內(nèi)容進(jìn)行多維度的提取和篩選過濾，當(dāng)中包括高光片段、畫面美學(xué)評(píng)分、彈幕信息等，具體會(huì)包括離線和在線兩條鏈路：

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

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

在這一鏈路中主要面對(duì)的痛點(diǎn)包括：

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

場景 2 - 多模態(tài)訓(xùn)練

多模態(tài)訓(xùn)練場景中的主要工作包括：

• 預(yù)處理
  預(yù)處理階段主要涵蓋視頻切片、抽幀等操作，在此基礎(chǔ)上還需進(jìn)行優(yōu)質(zhì)數(shù)據(jù)篩選，而篩選的依據(jù)包括光流分析以及美學(xué)評(píng)分等，通過這些步驟完成對(duì)原始數(shù)據(jù)的預(yù)處理，為后續(xù)工作奠定基礎(chǔ)。
• 多模態(tài)特征抽取
  抽取文本、Embedding、VAE 等特征。
• 模型訓(xùn)練
  多維度特征+原始物料數(shù)據(jù)，大規(guī)模數(shù)據(jù)訓(xùn)練。

工程方案如下圖所示。

其中的主要痛點(diǎn)為：

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

場景 3 - 多媒體業(yè)務(wù)

多媒體業(yè)務(wù)場景具有一些顯著特點(diǎn)。一方面，任務(wù)量極為龐大，像直播和點(diǎn)播這類業(yè)務(wù)均呈現(xiàn)無狀態(tài)特性。另一方面，存在異構(gòu)資源訴求，涵蓋 GPU、CPU、內(nèi)存、磁盤以及網(wǎng)絡(luò)等多種資源。此外，實(shí)時(shí)性需求具有差異化，其中直播業(yè)務(wù)要求達(dá)到毫秒級(jí)的實(shí)時(shí)響應(yīng)，普通轉(zhuǎn)碼業(yè)務(wù)需滿足秒級(jí)的實(shí)時(shí)性，而優(yōu)化轉(zhuǎn)碼業(yè)務(wù)則為分鐘級(jí)的時(shí)效性要求。

下圖展示了工程鏈路的設(shè)計(jì)，分為兩部分，第一部分是通過轉(zhuǎn)碼調(diào)度器驅(qū)動(dòng)切片、轉(zhuǎn)碼和合并三個(gè)階段的計(jì)算處理；第二部分是提供給業(yè)務(wù)的一些微服務(wù)。

這一鏈路面臨的痛點(diǎn)包括：

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

綜合上述三種業(yè)務(wù)場景，我們對(duì)核心需求進(jìn)行了抽象：

• 分布式數(shù)據(jù)管道：多態(tài)數(shù)據(jù)的分布式處理；通用算子（OCR 等）和業(yè)務(wù)定制。
• 內(nèi)容理解：圍繞多模態(tài)大模型，抽取特征；各垂域場景微調(diào)大模型的推理供給業(yè)務(wù)。
• 技術(shù)底座：資源（C/GPU）、存儲(chǔ)（靈活、多時(shí)效）、計(jì)算（Python/異構(gòu)/性能效率）。

二、架構(gòu)升級(jí)

根據(jù)上述三個(gè)場景的分析和痛點(diǎn)的概括，我們提出了針對(duì)性的解決方案。

1. 問題洞察和方案實(shí)施

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

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

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

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

2. Ray 概述

Ray 主要包含 Core 和 AI Runtime 兩大部分。在 Core 層面，它具備異構(gòu)計(jì)算能力，能夠?qū)崿F(xiàn) GPU 與 CPU 的協(xié)同工作，同時(shí)支持細(xì)粒度并行計(jì)算，將并行粒度細(xì)化到函數(shù)級(jí)。而 AI Runtime 則是面向 AI 鏈路，提供從一端到另一端的整套生態(tài)解決方案，為 AI 相關(guān)任務(wù)提供全面支持。

3. Ray 計(jì)算原語

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

4. Iceberg 概述

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

5. PyIceberg

Iceberg 針對(duì) AI，做 PyIceberg 擴(kuò)展，包含 DuckDB、pandas、daft、Ray 等等。

6. 整體架構(gòu)

整體架構(gòu)由接入層、任務(wù)編排、異構(gòu)計(jì)算資源、資源管控、底層資源池構(gòu)成。在接入層，采用標(biāo)準(zhǔn)化接入方式，涵蓋 API、WorkFlow、event - driven 以及 Batch，確保各類數(shù)據(jù)與任務(wù)能順利接入。任務(wù)編排環(huán)節(jié)，依托 Ray Data 完善 Source/Sink，并提供如分片、抽幀、OCR、ASR 等通用領(lǐng)域算子，實(shí)現(xiàn)任務(wù)的合理編排與處理。資源管控調(diào)度基于 K8s 多資源池，通過封裝 Ray 的 Session 和 Job 模式，對(duì)異構(gòu)計(jì)算資源和底層資源池進(jìn)行有效管理與調(diào)度，保障系統(tǒng)的高效穩(wěn)定運(yùn)行。

7. 典型計(jì)算范式

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

此外，該計(jì)算范式還包含不同的服務(wù)模式。其中，Serve 用于業(yè)務(wù)服務(wù)化，通過對(duì)外暴露 API 實(shí)現(xiàn)接入；Per - Job 模式下，一個(gè) Job 對(duì)應(yīng)一個(gè) Cluster，既可以運(yùn)行流處理任務(wù)，也能運(yùn)行批處理任務(wù)；而 Multi - Job 模式則是多個(gè) Job 共用一個(gè) Cluster，以此實(shí)現(xiàn)資源的復(fù)用與預(yù)熱（warmup）。

8. 針對(duì) Ray 落地關(guān)鍵點(diǎn)問題處理

下面介紹 Ray 落地過程中，對(duì)存儲(chǔ)結(jié)構(gòu)、任務(wù)并行、Batch 推理關(guān)鍵點(diǎn)的處理。

• 存儲(chǔ)結(jié)構(gòu)

在存儲(chǔ)結(jié)構(gòu)方面，包含多個(gè)重要部分。首先是查詢檢索，通過基于索引的方式實(shí)現(xiàn)對(duì)數(shù)據(jù)集的高效檢索。同時(shí)，借助 Iceberg 表與 Alluxio 的聯(lián)動(dòng)，達(dá)成預(yù)熱加速效果，進(jìn)一步提升檢索效率。其次是特征列，依據(jù)不同場景，會(huì)產(chǎn)出不同維度的特征數(shù)據(jù)，這些數(shù)據(jù)將按列寫入存儲(chǔ)系統(tǒng)。再者是小文件處理，諸如 Clip/Frame、向量文件等小文件，會(huì)被存儲(chǔ)到 Column Chunk 中，以此優(yōu)化小文件的存儲(chǔ)管理。

• 任務(wù)并行

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

• Batch 推理

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

9. 整體收益

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

三、核心挑戰(zhàn)

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

1. 集群級(jí)容錯(cuò)

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

2. 異構(gòu)資源管理

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

在作業(yè)提交環(huán)節(jié)，涉及到 Worker 的相關(guān)操作。目前 RayJob 的適配方式尚在探討中，例如是采用 Kuberay，還是 RayJob Yaml 方式。無論采用何種方式，都需支持多集群、多作業(yè)類型，并能將不同的 Job 描述進(jìn)行封裝，提交到 k8s 平臺(tái)，以實(shí)現(xiàn)異構(gòu)資源管理下作業(yè)的高效提交與執(zhí)行。

3. Autoscaler 擴(kuò)展

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

4. GCS 優(yōu)化

GCS（全局控制服務(wù)）優(yōu)化成為亟待解決的問題，主要源于元信息膨脹現(xiàn)象。當(dāng)集群運(yùn)行一段時(shí)間后，作業(yè)提交速度明顯變慢，甚至出現(xiàn)異常情況，同時(shí) Dashboard 下的 list job、actor 等接口也會(huì)響應(yīng)超時(shí)。

經(jīng)過深入的問題剖析，發(fā)現(xiàn) GCS 承受著巨大壓力，響應(yīng)耗時(shí)居高不下，問題根源定位在 Redis 查詢環(huán)節(jié)。進(jìn)一步深入挖掘得知，Redis key 數(shù)量增長近 100 萬，使得 HScan 操作壓力劇增。

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

5. Ray Data - SQL 單機(jī)

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

6. Ray Data - 分布式寫 Iceberg

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

7. PyIceberg - 讀優(yōu)化

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

四、未來展望

1. 場景擴(kuò)展及平臺(tái)化

未來會(huì)提升 Ray 的運(yùn)維管理能力，對(duì)內(nèi)部應(yīng)用的一些 AIR、Core、可觀測(cè)三個(gè)維度進(jìn)行增強(qiáng)。基于目前場景進(jìn)一步擴(kuò)展，基于 Ray 對(duì) Agent RAG、訓(xùn)練場景等提供支撐。

2. 底層能力增強(qiáng)

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