一、数据底座概述：MLOps 数据底座的定义、核心价值、与传统数据仓库的区别、典型应用场景

1.1 到底什么是 MLOps 数据底座？

先说说我个人的理解。MLOps 数据底座，不是某个具体产品，也不是一套开源组件的简单拼凑。它是一套面向机器学习全生命周期的数据基础设施。

说白了，它要解决三个核心问题：

• 数据怎么来？—— 采集、接入、校验
• 数据怎么管？—— 存储、版本、血缘、质量
• 数据怎么用？—— 特征工程、训练、推理、反馈闭环

你想想看，传统的数据仓库或者数据湖，更多是面向 BI 报表和分析师的。但 ML 场景不一样。模型训练需要历史数据、实时数据、特征数据，还要能回溯、能复现、能自动化。这些东西，传统数仓很难搞定。

1.2 核心价值：为什么我建议你认真搞数据底座？

我在项目中遇到过不少团队，算法模型做得不错，但一到上线就卡住。为什么？数据环节全是坑。

数据底座的核心价值，我归纳为四点：

1. 可复现性 —— 训练时的数据快照、特征版本、代码版本，三者必须能精确对齐。没有数据底座，你根本说不清三个月前的模型是用哪份数据训的。
2. 自动化 —— 从数据接入到特征生成，再到训练数据准备，全流程可编排、可调度。人工操作越少，出错的概率越低。
3. 一致性 —— 训练环境和推理环境用同一套特征计算逻辑。我曾经见过训练时用 A 逻辑算特征，上线时用 B 逻辑，结果模型效果直接腰斩。数据底座能强制统一。
4. 可观测性 —— 数据质量谁在盯？特征分布漂移了没有？数据延迟了多少？这些都需要内置的监控和告警。

1.3 与传统数据仓库的区别

很多朋友问我：「我直接用数仓不行吗？非得搞个数据底座？」

嗯，这里要注意。数仓和 ML 数据底座，设计哲学完全不同。我整理了一张对比表：

对比维度	传统数据仓库	MLOps 数据底座
核心用户	数据分析师、BI 团队	数据科学家、ML 工程师
数据模型	星型/雪花型，面向主题	特征视图、时间序列切片、事件序列
数据版本	通常不支持细粒度版本	必须支持数据快照和特征版本
实时性要求	T+1 为主，实时为辅	批流一体，实时特征常见
数据消费方式	SQL 查询、报表	API 获取特征、DataFrame 加载、在线推理
回滚能力	有限（基于快照）	强要求（时间旅行查询）
典型工具	Snowflake, Redshift, BigQuery	Feast, Tecton, Hopsworks, Delta Lake

看到区别了吗？数仓是为「查询」设计的，数据底座是为「训练和推理」设计的。两者可以共存，但不能互相替代。

1.4 典型应用场景

光说概念太虚，我举几个真实场景，你就明白数据底座在干什么了。

场景一：推荐系统的特征管理

推荐模型通常有几百个特征，包括用户画像、物品属性、实时行为。这些特征需要统一管理，训练时用历史数据，在线推理时用实时数据。数据底座提供特征存储，保证训练和推理的特征计算逻辑完全一致。

场景二：风控模型的训练数据回溯

风控模型上线后，如果效果下降，需要快速回滚到某个历史版本重新训练。数据底座支持时间旅行查询，你可以直接读取某个时间点的数据快照，配合当时的代码版本，精确复现模型。

场景三：实时特征计算

在广告竞价场景中，用户点击后几毫秒内就要完成特征计算和模型打分。数据底座提供流批一体的能力，离线训练和在线推理共用一套特征逻辑，避免线上线下不一致。

1.5 数据底座的核心架构

下面这张图，是我个人习惯用的数据底座逻辑架构。它把数据底座拆成了四个核心层：

这四层从上到下，数据是流动的。但注意，不是简单的单向流动。实际项目中，反馈数据会从消费层回流到接入层，形成闭环。这也是 ML 数据底座和传统数仓最大的区别之一——数据是活的，会不断被模型消费，又不断产生新数据。

1.6 什么时候该开始搭数据底座？

我经常被问到这个问题。我的判断标准很简单：

• 模型数量超过 3 个，且特征有复用 —— 该搭了
• 训练数据和线上数据不一致，已经出过事故 —— 必须搭
• 团队超过 5 个人，数据各自为政 —— 立刻搭
• 模型需要定期更新，但每次都要手动准备数据 —— 别犹豫了