小红书 Data+AI 数据平台实践
等你加入的约 14 分钟Dataverse 是小红书打造的数据开发和管理平台，平台周活跃用户达到上千人，其中算法和 DS 占近一半。原先算法和DS 在 Dataverse 上开发还存在诸多低效卡点，例如缺乏像 Notebook 交互式开发环境，算法链路涉及在线、近线和离线链路，链路长，涉及技术栈多，因为缺少端到端的血缘，当出现效果类故障时无法快速归因。同时大模型时代的到来，为 AI-Coding带来了新的机遇。2025 年 Dataverse 升级为 Data+AI 数据平台，通过推出 Notebook，构建 Data+AI 全链路血缘，打造 Copilot 代码助手，极大提高了算法和 DS 的迭代效率。
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 端的代码助手工具
2.1 Notebook 加速算法和 DS 迭代效率，提效100%
2.1.1 什么是 Dataverse notebook ?
Dataverse Notebook 是一种支持代码、文本、可视化图表混合编辑的交互式计算环境，核心特点是“可执行文档”——用户可以在一个文件中同时编写代码、记录分析思路、展示结果（如图表、表格），并实时运行代码查看输出。它的设计目标是让“探索-分析-记录-分享”流程更高效，尤其适合数据科学、机器学习等需要“边思考边验证”的场景。
2.1.2 相比原生Jupter 我们有哪些不一样？
互联互通：和公司内部系统互联互通
和 Dataverse 一体化集成，支持探索分析 -> 发布周期性调度。作为 Dataverse 的一种新的任务类型，算法可以直接将一个探索分析后的报告 Notebook 发布成一个周期性任务。
和 RedBI 集成打通，SQL 的执行结果可以直接用 RedBI 做图表的二次分析。Notebook SQL Cells 会将执行结果自动保存成一个临时表，同时调用 RedBI 接口创建一个临时数据集，用户可以直接用 RedBI 的自助分析，对 SQL 的执行结果进行二次分析和制作图表，同时也可以分享和保存给其他的人，其他人可以继续打开自助分析的图表进行拖拽分析。
Data+AI 协同开发：能够同时支持 Python 和 SQL 的 Notebook
SQL -> Python：算法可以在一个 Notebook里面，先用 SQL Cells 取数，平台会自动将 SQL 的执行结果保存成 DataFrame 变量，然后算法可以在下面的 Python Cells 中写代码直接对 DataFrame 进行处理。
Python -> SQL：Python 处理完的数据，通过平台内置的命令行工具，可以直接将文件上传到 oss 临时表目录下， 通过 hive 创建临时表，即可在后续的 SQL Cells 中对 Python 处理的数据进行读写。
Python 动态生成SQL：在 Python 代码中，可以动态生成 SQL，保存成变量，然后在 SQL Cells中直接执行该 SQL。
对于纯写SQL的开发者，以SQL + Python的方式，也可以提效。原先需要通过UDF的模式，而现在只需要通过SQL读数据，然后用Python 处理数据， 在一个Notebook 里面就可以完成整个操作，避免原先先开发UDF，然后调试打包，上传到资源文件，再在SQL中引用的低效。
SQL -> Python
Python -> SQL
Python 动态生成 SQL
SaaS 平台产品化：
专属个人容器：平台会为每个用户构建一个专属容器，用于开发和调试 Notebook 任务。如果任务需要发布上线，必须白盒化，平台每次调度实例都会新拉一个容器，从基础镜像开始构建容器和环境，确保稳定可靠。
专属云盘管理：平台会为每个容器挂载一个云盘，用户可以直接上传一个本地文件，用 Python 读取数据，然后和线上的 Hive表进行对比，这个场景属于算法和分析师的高频场景。
镜像环境：如果平台提供的默认 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 算法链路的数据血缘建设
数据入湖段：
Agentsmiht：埋点日志采集服务，主要负责构建应用服务->Kafka 血缘链路
DTS：CDC 数据库日志实时同步服务，主要负责构建 MySQL -> Kafka/Hive/iceberg/OSS 血缘链路
数据同步：批量数据同步服务，主要负责数据源-> Hive/Iceberg 血缘链路
数据湖处理阶段：
离线开发平台/实时开发平台：算法直接在离线开发平台和实时开发平台上开发的 Sparl/Flink 任务，包括SQL、Jar类。
算法工程框架生成的任务：算法工程框架生成的Spark/Flink 任务，包括SQL、Jar类。
在线和离近线交接处：
Redis/Redkv
kafka
索引类：LDS、LSE、LVE、LRE、Omega
特征
样本
模型
词表
在线服务：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 的任务，构建业务线、项目空间、个人的健康分看板，如果健康分低于阈值，会限制开发者使用高优先级和高保障等级的任务权限。
3.1 AI For Data
3.1.1 应用场景
代码续写和补全：同时支持 SQL 和 Python 代码的续写和补全
代码纠错：支持对代码进行纠错，对比原代码和纠错后代码的 diff，分行采纳
代码补全
代码续写
代码纠错
3.1.2 工程链路建设
核心关键技术：
非完整SQL的解析：由于在代码补全和续写场景中，SQL 往往存在语法错误和不完整等特点，使用传统的 calcite 没办法完整的解析出SQL的语法结构，需要通过正则的方式，解析SQL，提取光标所在位置上下文的语法结构信息。
相关表召回：只有在光标前后上下文中提取到相关表，且能够与元数据库中的表信息 match ，才会进入下一步续写流程。Copilot 会自动从元数据中心提取数据字典信息。针对表中的字段，会按照光标上下文是否出现过，预先计算的字段访问热度排序，然后截取 top 20 个字段。表最多 3 个。
相似代码召回：基于向量数据库，对光标上下文中的代码进行 embeding。针对 xhs 历史代码，提前 embeding 到 millvus 中，进行向量检索召回。
评测模型：针对大模型续写和补全代码存在的语法错误，代码不符合规范等，利用大模型进行拦截，从染色数据看，拦截对采纳率有 6%～8% 提升。
3.1.3 模型训练
模型基本信息：
模型：Qwen Coder 7B 模型 + SFT
部署：H800 12实例 * 2卡 = 24卡
模型训练SOP：
标注阶段：利用人工标注的方式，对线上真实的采纳和未采纳的Case 进行人工打标，标注的依据主要是根据用户最终输入的内容和github 推荐的内容，经过人工确认后，产生GroudTruth，进入样本，用于后续的模型评测和SFT流程。
训练样本准备：针对线上未采纳的样本，分析和提取问题点，例如 ）<光标> as 这种，模型就推荐为空。然后对样本利用LLM进行增广，利用xhs 的元数据，让LLM按照规则生成SQL，作为训练数据集。原先，我们采用的训练方式，是使用xhs 全量的SQL 随机挖洞的方式进行SFT，但是天花板较低，后来就采用了针对问题进行定向精准训练的模式，推荐采纳率有明显的提升。
模型SFT：利用准备的训练数据集，对模型采用 LORA 的方式进行多轮训练。
模型评测：针对问题，准备评测训练样本集合，验证模型是否已经掌握我们需要它学会的能力。
3.1.4 应用成果
SQL Copilot 代码推荐采纳率27%，Python 代码推荐采纳率25.53%
代码纠错推荐采纳率 60%
4.1 DataAgent
在我们的规划中，我们希望通过 2～3 年，打造能够大规模落地应用的 DataAgent，能够取代目前 DataEngineer 和 DataScience 的低难度工作。在我们的技术规划路线上，DataAgent 会包括3层，第一层是分析助手，主要是完成数据洞察到业务价值的闭环；第二层是取数助手，核心是从已有的数据资产中提取用户需要的关键数据；第三层，代码助手，当已有的数据资产无法满足用户的需求时，需要通过建模 + 代码生成 ，完成数据集的自动化生成 。未来，我们成功时的样子，应该是3个Agent 合成一个DataAgent，能够实现需求直出。
DataAgent 的出现未来会对我们的工作带来深刻的变化，一个是交付内容的变化，过往我们交付给业务的是指标、看板、数据集，未来我们交付的是一个具备自主思考，能够直接给出建议和洞察的Agent。 另外一个更重要的是生产关系的变化，原先我们做一个数据产品，需要产品、技术、数仓、DS等多角色的参与迭代，成本极高，而有个DataAgent，数仓只需要在一个分析Agent 开发平台上， 通过调试和配置，即可完成交付，不仅交付速度大幅提高，试错成本也大幅度降低，数据到业务价值的落地将更加敏捷！
DataAgent 大门已经打开，未来星辰大海，欢迎有志向的小伙伴加入小红书数据平台团队，一起探索AI 时代数据驱动业务的新范式！
羽田（郭忆）
小红书数据平台平台技术研发负责人，负责分析平台RedBI、离线生产平台Dataverse、实时计算平台百川、用户行为分析平台UBA、实验平台Racing，《极客时间》数据中台实战课作者，订阅量超过 3W+，拥有 13 年数据平台的架构设计和团队管理实践经验。
招聘岗位
作为小红书统一数据平台团队，既涵盖了前台属性的所有业务线数据 BP 和内容产品，又包括了平台属性的平台工具类产品，形成了“既是平台，又是前台”的组织特色，为 AI+ 时代提供了组织层先发优势
基本信息
工作地点： 杭州、上海
工作经验： 3-5年
学历要求： 本科及以上
工作职责
负责生产平台 Dataverse 的核心模块的功能开发，具体包括数据同步、任务开发、数据测试、数据发布、任务运维及调度系统。
负责生产平台 Dataverse 日常的问题排查和疑难问题解决。
负责生产平台 Dataverse 的稳定性保障，通过设计高可用、可扩展的系统架构，确保平台的日常稳定运行。
任职资格
本科及以上学历，计算机相关专业，有生产平台开发经验者优先。
熟练掌握 Java 编程语言，熟悉 SQL 及 Hive 优化。
有高可用系统的设计经验和能力，具备高并发、海量数据的处理能力。
深入理解 Hadoop 生态组件（HDFS/YARN/Hive/Spark/Flink 等），有实际项目落地经验。
对大模型有强烈的兴趣和好奇心，积极拥抱 AI，有大模型的使用和调优经验优先。
熟悉 Linux 环境及 Shell 脚本，具备任务调度系统开发经验。