数据底座核心组件：数据湖、数据仓库、数据湖仓、元数据管理、数据目录

聊到 MLOps 的数据底座，很多人第一反应就是「存数据嘛」。嗯，这话没错，但存法不一样，后面运维的坑就差得远了。我这些年见过太多团队，数据湖、数据仓库傻傻分不清，结果数据越存越乱，模型训练时找数据比写模型还费劲。

今天咱们就把这几个核心组件掰开揉碎。你想想看，数据底座说白了就干三件事：存得住、查得快、管得清。围绕这三件事，演化出了数据湖、数据仓库、数据湖仓、元数据管理和数据目录。下面我一个一个说。

2.1 数据湖：原始数据的「大澡堂」

数据湖的概念最早是 Hadoop 生态带起来的。它的核心思想很简单——把所有数据原封不动扔进去，不管结构化的、半结构化的、非结构化的，先存了再说。

我个人习惯把数据湖比作「大澡堂」：你往里倒什么都可以，但想从里面捞到干净的东西，得自己动手洗。数据湖存储的是原始格式（Parquet、Avro、ORC、JSON、CSV、甚至图片视频），schema 在读取时才定义，这叫 schema-on-read。

我在项目中遇到过最典型的问题：数据湖变成了「数据沼泽」。大家只管往里灌数据，没人管数据质量，结果湖里全是脏数据，模型训练时根本不敢用。所以运维数据湖，核心就两件事——权限管控和数据质量监控。

特性	数据湖	数据仓库
存储格式	原始格式（Parquet/JSON/CSV）	结构化表（行存/列存）
Schema 定义	读取时定义（schema-on-read）	写入时定义（schema-on-write）
数据质量	低（原始数据）	高（经过清洗转换）
典型场景	数据探索、机器学习、日志存储	BI 报表、业务分析、固定查询
常用技术	HDFS、S3、MinIO、Delta Lake	ClickHouse、Snowflake、Redshift

2.2 数据仓库：结构化数据的「精装房」

数据仓库跟数据湖正好相反。它要求数据先洗干净、定好 schema，再存进去。这叫 schema-on-write。说白了，数据仓库是给分析师和 BI 工具用的，查询性能必须快，数据必须准。

我建议你在 MLOps 场景里这样用：特征工程产出的特征数据、模型训练的标签数据、线上服务的日志聚合数据，这些适合放数据仓库。因为它们结构固定，查询模式也固定，用仓库存着，模型上线时直接拉取，延迟低、稳定性高。

但数据仓库有个硬伤——存不了非结构化数据。你想想看，模型训练经常要用到图片、文本、音频，这些数据仓库根本存不了。所以就有了数据湖仓。

2.3 数据湖仓：两全其美的「新物种」

数据湖仓（Lakehouse）是最近几年最火的概念。它把数据湖的灵活性和数据仓库的可靠性结合在了一起。底层还是用对象存储（S3、HDFS），但上层加了事务层、索引层和 schema 管理层。

Delta Lake、Apache Iceberg、Apache Hudi 是当前三大主流方案。我个人的选择标准很简单：

• Delta Lake：如果你深度绑定 Spark 和 Databricks，选它没错。事务能力强，但生态相对封闭。
• Apache Iceberg：如果你需要跨引擎（Spark、Flink、Trino、Hive），选它。开放程度最高，我目前主力用这个。
• Apache Hudi：如果你有大量实时写入场景（比如 CDC 入湖），选它。写入性能最优。

数据湖仓的核心价值在于：一份数据，既能跑机器学习，又能跑 SQL 分析。你不用再像以前那样，数据湖一份、数据仓库一份，中间还要 ETL 同步，数据延迟大、一致性差。

2.4 元数据管理：数据的「大脑」

元数据是什么？就是「关于数据的数据」。比如这张表叫什么、谁创建的、字段类型是什么、数据从哪里来的、血缘关系如何。没有元数据管理，数据底座就是一堆死数据。

我见过最惨的案例：一个团队做了半年特征工程，产出了 3000 多张特征表。结果模型上线时，没人知道哪张表是最新的、哪张表已经废弃了。最后只能全部重跑一遍，浪费了 2 周时间。

元数据管理要管三层：

1. 技术元数据：表结构、分区信息、文件路径、存储大小。这些自动采集就行。
2. 业务元数据：字段的业务含义、数据来源、更新频率。这些需要人工维护。
3. 操作元数据：谁在什么时候跑了什么查询、数据血缘关系。这些用于审计和排障。

常用的元数据管理工具有 Apache Atlas、DataHub、Amundsen。我个人偏好 DataHub，它的血缘解析能力很强，而且支持实时推送。

2.5 数据目录：数据的「黄页」

数据目录跟元数据管理是孪生兄弟。元数据管理是后台，数据目录是前台。数据目录解决的核心问题是：我怎么找到我想要的数据？

你想想看，一个 MLOps 平台可能有几千张表、几万个特征。数据科学家想找一个「用户近 7 天点击率」的特征，如果没有数据目录，他得去问运维、问同事、翻文档，效率极低。

数据目录应该提供这些能力：

• 搜索：支持按表名、字段名、标签、描述搜索
• 浏览：按数据域、项目、团队分类浏览
• 详情：展示表的 schema、样例数据、血缘关系、最近更新时间
• 认证：数据质量等级、是否经过审核、是否可用于训练

2.6 核心组件关系图

下面这张图展示了数据底座核心组件之间的关系。你可以看到数据湖和湖仓是存储层，数据仓库是分析层，元数据管理和数据目录是管理层，它们共同支撑 MLOps 的数据需求。

2.7 运维视角的选型建议

说了这么多，到底怎么选？我根据实际运维经验，给你一个快速决策表：

场景	推荐方案	理由
纯 ML 训练，数据量大、格式杂	数据湖（S3 + Delta Lake）	灵活存储，支持多种格式，成本低
BI 报表 + 固定查询	数据仓库（ClickHouse）	查询性能高，数据质量有保障
ML + BI 混合场景	数据湖仓（Iceberg + Trino）	一份数据跑所有负载，减少 ETL
团队数据治理能力弱	先上元数据管理（DataHub）	先把数据管起来，再考虑存储选型
数据发现效率低	数据目录（DataHub + 搜索）	让数据科学家自己找数据，减少沟通成本