Dataverse 是小紅書打造的數據開發和管理平臺，平臺周活躍用戶達到上千人，其中算法和 DS 占近一半。原先算法和DS 在 Dataverse 上開發還存在諸多低效卡點，例如缺乏像 Notebook 交互式開發環境，算法鏈路涉及在線、近線和離線鏈路，鏈路長，涉及技術棧多，因為缺少端到端的血緣，當出現效果類故障時無法快速歸因。同時大模型時代的到來，為 AI-Coding帶來了新的機遇。2025 年 Dataverse 升級為 Data+AI 數據平臺，通過推出 Notebook，構建 Data+AI 全鏈路血緣，打造 Copilot 代碼助手，極大提高了算法和 DS 的迭代效率。

01、背景

Dataverse 是小紅書打造的數據開發和管理平臺，具備跨云多集群管理、與小紅書內部系統互通互通等優勢，經過 2 年的建設實踐，已經具備了完整的 DataOps 數據開發流水線能力，比較好地支撐了Data For BI方向，目前平臺任務總量 9.3 萬，日調度實例 40 萬，周活躍用戶上千人，內部NPS 滿意度調研達到 69% 。

2025 年，Dataverse 的目標是從 Data For BI 數據平臺升級為 Data For AI+BI 數據平臺，主要目標是為平臺上活躍的 530 個算法和數據科學 DS 角色提效。

1.1 算法和 DS 研發鏈路存在低效卡點

• Python/Scala 代碼類任務無法使用生產環境的數據進行開發和調試。代碼類任務多是算法和 DS 相較于數倉的一個顯著特點。原先，在 Dataverse 上開發一個 PySpark 任務，用戶需要在本地 Coding ，然后打包成一個 Jar 文件，上傳到 Dataverse ，在平臺上執行，如果發現結果不符合預期，就需要重新回到線下開發，然后再重新打包上傳到線上，反復的線上、線下的穿梭，導致開發和調試效率極低。Dataverse 平臺代碼類任務約占平臺任務總量的 10% 。
  
• 缺少 Notebook 類交互式的開發環境。算法在用 Spark 訓練完一個機器學習的模型以后，需要測試模型的效果，首先需要load 模型到內存中，這個過程耗時比較久，如果要調試的代碼在模型加載程序之后，則需要每次都完整的運行模型加載程序，非常耗時（每次都需要等待幾個小時）。交互式開發環境，意味著算法可以分段執行代碼，只需要加載一次模型，即可反復的調試程序，環境中會保存上下文的會話狀態，非常高效。
• 缺少穩定可靠的 Python 開發環境。目前公司缺乏對 Python 開發環境的平臺工程化解決方案，目前一些算法團隊內部私下搭建的 jupter 服務，經常因為資源競爭問題，任務排隊較長，跑不起來。
• Jupter 對 Python 友好，但是不支持 SQL 。SQL在一些簡單的數據處理和分析的場景中，有獨特的優勢，而Python 在復雜的數據結構處理以及建模領域有獨特優勢，目前缺乏一個工具，同時支持 Python 和 SQL 的混合開發和調試。
• 跨平臺連通性不足。目前 Dataverse 平臺上面執行的 SQL 無法直接使用圖表進行分析，需要將其導入到一個表中，或者下載成一個 csv ，再到分析平臺 RedBI 去利用自助分析或者看板做圖表分析。

1.2 算法鏈路的穩定性風險向效果類故障轉移

25 年以來，算法效果類 RCA 占比超過 50% ，其中以數據鏈路為核心帶來的 RCA ，占比 27% ，P 級故障占比超過 50% 。穩定性風險向效果類故障轉移趨勢明顯，其中算法數據鏈路帶來的故障顯著。

這里的核心問題：

• 「根本」數據鏈路及任務重要性看不清：背后的根本原因是數據血緣無法覆蓋離線、近線和在線的完整鏈路，傳統的數據血緣主要是 Hive 表的血緣關系，但是在算法鏈路中遠遠不夠，從在線服務，到索引/特征/推理服務，再到上游的 Spark/Flink、模型訓練任務甚至實驗，涉及技術棧多，平臺多，組織多，無法根據下游在線消費的強依賴的數據上推上游鏈路的生產任務的重要性。核心需要把每個平臺自己維護的血緣片段，通過統一的標準，拼接起來，構建公司級數據血緣視圖，才能看清任務重要性，這也是一切的基礎！
• 「事前」任務變更過程中數據質量前置管控和代碼掃描攔截能力不足：算法數據鏈路除了 Hive 表以外，還涉及到Redis/Redkv、Kafka、模型、索引、特征、詞表、對象存儲等算法特性明顯的數據源，除了 SQL 以外，還有大量的 Jar 任務，數據測試、數據比對、數據稽核需要覆蓋算法的完整鏈路。另外，大水漫灌，影響迭代實驗效率，一個樣本上游可能有幾百個特征生產任務，需要根據字段級別的血緣，甄別出真正影響下游關鍵特征的數據鏈路進行前置管控，必須經過數據測試、比對，添加數據質量稽核規則，才能發布上線；
• 「事中」故障過程中監控響應能力、可觀測性能力及全鏈路時效保障能力不足：高優先級任務和保障等級不對齊，高優先級任務的響應機制沒有完全落到產品工具中，例如，高優先級任務，如果出現異常，需要 call 任務的 owner，如果 owner 不接，再轉接到值班。快速定位難，效果類指標異常，故障時間長（特征 MTTR:66.9，索引 MTTR：327.8）。另外，故障診斷能力不足，無法快速定位上游數據鏈路的異常，需要有工具能力，能夠根據數據血緣，數據質量稽核規則的成功率，數據任務執行狀態，數據任務的代碼變更快速定位到異常任務，減少故障定位和修復時間；
• 「長效治理」算法任務穩定性治理：需要構建適用算法組織架構下的長效數據治理的機制，需要從業務線（搜廣推）、團隊（ L1 ）、個人不同視角的問題通曬和監管能力，解決任務歸屬不對，任務日常健康狀態缺乏管理的問題，一些高危害問題，高消耗的任務、參數配置不合理的任務需要及時抓出來處理。

1.3 AI-Coding 提效

代碼生成是大模型經過行業實踐最成熟的應用領域，在業界，代碼推薦采納率能夠做到25%的水平，對于開發者提效明顯。但是聚焦到算法和 DS 在數據領域，面臨如下問題：

• 從公司代碼安全合規的角度，目前算法和 DS 都在被禁止使用外部商業化代碼助手工具的范圍內
• 業界公開的 SQL 訓練數據集本身比較少，大模型在SQL語言的代碼續寫、補全和自然語言生成的推薦采納普遍低于Java 等
• 目前代碼助手工具都是以編輯器客戶端插件的形式存在，缺少能夠直接集成到 Web 端的代碼助手工具

02、Data For AI實踐

2.1 Notebook 加速算法和 DS 迭代效率，提效100%

2.1.1 什么是 Dataverse notebook ?

Dataverse Notebook 是一種支持代碼、文本、可視化圖表混合編輯的交互式計算環境，核心特點是“可執行文檔”——用戶可以在一個文件中同時編寫代碼、記錄分析思路、展示結果（如圖表、表格），并實時運行代碼查看輸出。它的設計目標是讓“探索-分析-記錄-分享”流程更高效，尤其適合數據科學、機器學習等需要“邊思考邊驗證”的場景。

2.1.2 相比原生Jupter 我們有哪些不一樣？

• 互聯互通：和公司內部系統互聯互通

     a.和 Dataverse 一體化集成，支持探索分析 -> 發布周期性調度。作為 Dataverse 的一種新的任務類型，算法可以直接將一個探索分析后的報告 Notebook 發布成一個周期性任務。

     b.和 RedBI 集成打通，SQL 的執行結果可以直接用 RedBI 做圖表的二次分析。Notebook SQL Cells 會將執行結果自動保存成一個臨時表，同時調用 RedBI 接口創建一個臨時數據集，用戶可以直接用 RedBI 的自助分析，對 SQL 的執行結果進行二次分析和制作圖表，同時也可以分享和保存給其他的人，其他人可以繼續打開自助分析的圖表進行拖拽分析。

• Data+AI 協同開發：能夠同時支持 Python 和 SQL 的 Notebook

     a.SQL -> Python：算法可以在一個 Notebook里面，先用 SQL Cells 取數，平臺會自動將 SQL 的執行結果保存成 DataFrame 變量，然后算法可以在下面的 Python Cells 中寫代碼直接對 DataFrame 進行處理。

     b.Python -> SQL：Python 處理完的數據，通過平臺內置的命令行工具，可以直接將文件上傳到 oss 臨時表目錄下， 通過 hive 創建臨時表，即可在后續的 SQL Cells 中對 Python 處理的數據進行讀寫。

     c.Python 動態生成SQL：在 Python 代碼中，可以動態生成 SQL，保存成變量，然后在 SQL Cells中直接執行該 SQL。

對于純寫SQL的開發者，以SQL + Python的方式，也可以提效。原先需要通過UDF的模式，而現在只需要通過SQL讀數據，然后用Python 處理數據， 在一個Notebook 里面就可以完成整個操作，避免原先先開發UDF，然后調試打包，上傳到資源文件，再在SQL中引用的低效。

SQL -> Python

Python -> SQL

Python 動態生成 SQL

• SaaS 平臺產品化：

    a.專屬個人容器：平臺會為每個用戶構建一個專屬容器，用于開發和調試 Notebook 任務。如果任務需要發布上線，必須白盒化，平臺每次調度實例都會新拉一個容器，從基礎鏡像開始構建容器和環境，確保穩定可靠。

     b.專屬云盤管理：平臺會為每個容器掛載一個云盤，用戶可以直接上傳一個本地文件，用 Python 讀取數據，然后和線上的 Hive表進行對比，這個場景屬于算法和分析師的高頻場景。

     c.鏡像環境：如果平臺提供的默認 Python 環境無法滿足開發者要求，開發者可以自己打包 Python環境，選擇要引入的 Python包，apt 安裝包，以及 docker 參數配置。

容器管理

云盤管理

鏡像環境

2.1.3 Notebook 應用成果

• 月活躍用戶：650，Spark 用戶滲透率（周）：99%
  
• Notebook 任務：4388，其中發布調度任務：264
  
• 用通過對算法用戶的調研，中等復雜度的Python 任務從開發、調試到發布的時間從1周縮短到2天～3天
  
• Dataverse NPS 在算法和數據分析角色中有明顯提升，算法61 -> 67，DS 37-> 63，從用戶留言中，Notebook 被高頻提及

2.2 【星鏈】以Data+AI數據血緣為核心的算法鏈路穩定性建設

2.2.1 算法鏈路的數據血緣建設

• 數據入湖段：

     a.Agentsmiht：埋點日志采集服務，主要負責構建應用服務->Kafka 血緣鏈路

     b.DTS：CDC 數據庫日志實時同步服務，主要負責構建 MySQL -> Kafka/Hive/iceberg/OSS 血緣鏈路

     c.數據同步：批量數據同步服務，主要負責數據源-> Hive/Iceberg 血緣鏈路

• 數據湖處理階段：

     a.離線開發平臺/實時開發平臺：算法直接在離線開發平臺和實時開發平臺上開發的 Sparl/Flink 任務，包括SQL、Jar類。

     b.算法工程框架生成的任務：算法工程框架生成的Spark/Flink 任務，包括SQL、Jar類。

• 在線和離近線交接處：

     a.Redis/Redkv

     b.kafka

     c.索引類：LDS、LSE、LVE、LRE、Omega

     d.特征

     e.樣本

     f.模型

     g.詞表

• 在線服務：X-ray
  
• 實驗平臺：可以追蹤到模型和實驗之間的血緣關系，哪個模型在實驗上分配了多少流量，來確認模型的重要性

2.2.2 Data+AI 數據血緣架構

建設方案：項目（場景）驅動 + 各方注冊 + 統一底座（Unified Catalog + 元數據中心 + 元數據倉庫)

元數據應用可以分為在線元數據訪問和離線元數據應用。

• 在線元數據訪問由數據引擎團隊負責，核心工作是構建unified catalog，對標gravitino，可以認為是Data+AI時代的HMS(Hive MetaStore)，它除了包括大數據生態的庫表列，更重要的是把AI 生態的DataSet和Model的Schema信息也能夠管理起來，構建公司統一的Catalog，各個引擎可以直接通過這些Schema訪問數據，需要開發各個引擎SDK。
• 在離線元數據應用部分，首先是有一個for 離線元數據應用場景的元數據中心， 它包括數據字典、數據血緣和數據標簽。數據字典，直接跟下面的Unified Catalog 對齊，確保全局庫/表/列的一致。而這些也是數據血緣的頂點，全局Catalog的一致，可以確保各方注冊的數據血緣能夠拼接在一起。數據血緣部分，元數據中心需要提供一套數據血緣注冊的接口，各個血緣生產方通過接口將血緣注冊到元數據中心，同時元數據中心會標記血緣注冊的來源方。元數據中心提供API 接口，可以供給各個業務方，進行數據字典、數據血緣和數據標簽的查詢。
• 元數據中心的數據會被抽取到元數據倉庫，主要是For 數據治理場景使用。 數據地圖負責展示元數據的端到端的血緣可視化，數據治理主要基于血緣進行成本治理。

2.2.3 Data+AI 數據血緣應用

• 【看清重要性】基于數據血緣，根據下游消費的在線服務的 S0～S2 等級，自動上推上游的生產鏈路的數據任務保障等級，設定為 P0~P2，通過血緣上推，我們發現有 2600 個任務，實際重要性跟任務當前的保障等級不一致（原先的保障等級是靠人維護的）
• 【事前變更管控】對于 P0/P1的任務，任務變更強制數據測試，數據測試會讓 Spark/Flink 任務，讀取生產的數據，寫入一個影子鏈路，對影子鏈路進行測試，沒問題后再發布到生產環境。對 P0/P1 的任務，強制要求 SQL Scan 全部通過。
• 【事中監控和問題診斷】對于 P0/P1 的任務，在項目空間粒度，默認配置數據跌零 DQC 監控， 任務失敗監控、任務超時監控。對于 P0/P1 的任務，未在規定時間內認領，執行告警升級策略。通過 Radar系統，基于數據血緣，可以快速進行問題根音診斷，選擇診斷的在線服務，Radar可根據數據血緣，自動抓取上游鏈路的相關任務，對任務的執行狀態，任務是否做過變更，任務的 DQC 是否異常進行快速的掃描，抓出可疑問題點。

• 【事后治理】對于 P0/P1 的任務，構建業務線、項目空間、個人的健康分看板，如果健康分低于閾值，會限制開發者使用高優先級和高保障等級的任務權限。

03、AI For Data

3.1 AI For Data

3.1.1 應用場景

• 代碼續寫和補全：同時支持 SQL 和 Python 代碼的續寫和補全
• 代碼糾錯：支持對代碼進行糾錯，對比原代碼和糾錯后代碼的 diff，分行采納

代碼補全

代碼續寫

代碼糾錯

3.1.2 工程鏈路建設

• 核心關鍵技術：

     a.非完整SQL的解析：由于在代碼補全和續寫場景中，SQL 往往存在語法錯誤和不完整等特點，使用傳統的 calcite 沒辦法完整的解析出SQL的語法結構，需要通過正則的方式，解析SQL，提取光標所在位置上下文的語法結構信息。

     b.相關表召回：只有在光標前后上下文中提取到相關表，且能夠與元數據庫中的表信息 match ，才會進入下一步續寫流程。Copilot 會自動從元數據中心提取數據字典信息。針對表中的字段，會按照光標上下文是否出現過，預先計算的字段訪問熱度排序，然后截取 top 20 個字段。表最多 3 個。

     c.相似代碼召回：基于向量數據庫，對光標上下文中的代碼進行 embeding。針對 xhs 歷史代碼，提前 embeding 到 millvus 中，進行向量檢索召回。

     d.評測模型：針對大模型續寫和補全代碼存在的語法錯誤，代碼不符合規范等，利用大模型進行攔截，從染色數據看，攔截對采納率有 6%～8% 提升。

3.1.3 模型訓練

• 模型基本信息：

     a.模型：Qwen Coder 7B 模型 + SFT

     b.部署：H800 12實例 * 2卡 = 24卡

• 模型訓練SOP：
  

     a.標注階段：利用人工標注的方式，對線上真實的采納和未采納的Case 進行人工打標，標注的依據主要是根據用戶最終輸入的內容和github 推薦的內容，經過人工確認后，產生GroudTruth，進入樣本，用于后續的模型評測和SFT流程。

     b.訓練樣本準備：針對線上未采納的樣本，分析和提取問題點，例如 ）<光標> as 這種，模型就推薦為空。然后對樣本利用LLM進行增廣，利用xhs 的元數據，讓LLM按照規則生成SQL，作為訓練數據集。原先，我們采用的訓練方式，是使用xhs 全量的SQL 隨機挖洞的方式進行SFT，但是天花板較低，后來就采用了針對問題進行定向精準訓練的模式，推薦采納率有明顯的提升。

     c.模型SFT：利用準備的訓練數據集，對模型采用 LORA 的方式進行多輪訓練。

     d.模型評測：針對問題，準備評測訓練樣本集合，驗證模型是否已經掌握我們需要它學會的能力。

3.1.4 應用成果

• SQL Copilot 代碼推薦采納率27%，Python 代碼推薦采納率25.53%
• 代碼糾錯推薦采納率 60%

04、未來展望

4.1 DataAgent

在我們的規劃中，我們希望通過 2～3 年，打造能夠大規模落地應用的 DataAgent，能夠取代目前 DataEngineer 和 DataScience 的低難度工作。在我們的技術規劃路線上，DataAgent 會包括3層，第一層是分析助手，主要是完成數據洞察到業務價值的閉環；第二層是取數助手，核心是從已有的數據資產中提取用戶需要的關鍵數據；第三層，代碼助手，當已有的數據資產無法滿足用戶的需求時，需要通過建模 + 代碼生成 ，完成數據集的自動化生成 。未來，我們成功時的樣子，應該是3個Agent 合成一個DataAgent，能夠實現需求直出。

DataAgent 的出現未來會對我們的工作帶來深刻的變化，一個是交付內容的變化，過往我們交付給業務的是指標、看板、數據集，未來我們交付的是一個具備自主思考，能夠直接給出建議和洞察的Agent。 另外一個更重要的是生產關系的變化，原先我們做一個數據產品，需要產品、技術、數倉、DS等多角色的參與迭代，成本極高，而有個DataAgent，數倉只需要在一個分析Agent 開發平臺上， 通過調試和配置，即可完成交付，不僅交付速度大幅提高，試錯成本也大幅度降低，數據到業務價值的落地將更加敏捷！

DataAgent 大門已經打開，未來星辰大海，歡迎有志向的小伙伴加入小紅書數據平臺團隊，一起探索AI 時代數據驅動業務的新范式！

05、作者簡介

羽田（郭憶）

小紅書數據平臺平臺技術研發負責人，負責分析平臺RedBI、離線生產平臺Dataverse、實時計算平臺百川、用戶行為分析平臺UBA、實驗平臺Racing，《極客時間》數據中臺實戰課作者，訂閱量超過 3W+，擁有 13 年數據平臺的架構設計和團隊管理實踐經驗。