数据体系（Data Platform）
目标：让数据从“可采集”→“可信”→“可复用”→“可决策”
P0（数据基础）
├── 数据采集 / 埋点体系
├── 数据中台（数据湖 / 数据仓库）
├── ETL / ELT 平台（Airflow）
P1（数据可信）
├── 元数据平台（Data Catalog）
├── 指标平台
├── 数据质量平台（DQ）
P2（数据服务）
├── 数据 API 平台
├── 报表平台（BI）
├── 数据可视化平台
P3（数据资产化）
├── 数据资产管理
├── 数据权限与安全治理
├── 特征平台（Feature Store）
中间件体系的本质不是“技术选型”，而是“运行能力抽象”：
下面我把 数据中台（以数据湖 / 数据仓库为核心） 按企业级、可落地、可演进的方式完整展开。
不是“概念对比”，而是为什么要这样建、每一层解决什么问题、什么时候该用哪一类技术。
一、一句话先定性
数据中台 = 用统一的数据架构 + 数据治理能力，把“分散的数据”沉淀为“可复用的数据资产”。
而其中最核心的两大基础设施就是：
- 数据湖（Data Lake）：解决“数据怎么都能先放进来”
- 数据仓库（Data Warehouse）：解决“数据怎么被稳定、可信地使用”
二、数据中台整体技术架构全景
数据采集层
↓
ODS 原始层（数据湖）
↓
数据湖治理层（格式 / Schema / 版本）
↓
明细数据层（DWD）
↓
汇总数据层（DWS）
↓
应用数据层（ADS / Mart）
↓
数据服务 & BI & AI
数据湖和数据仓库不是“二选一”，而是“分工协作”。
三、数据湖（Data Lake）——“什么都先接住”
1. 数据湖解决的核心问题
传统数仓的问题：
- 必须先建表
- Schema 强约束
- 新数据接入慢
数据湖的目标：
| 能力 | 说明 |
|---|---|
| 接入灵活 | 结构化 / 半结构化 / 非结构化 |
| 成本低 | 对象存储 |
| 可回放 | 原始数据可重算 |
| 解耦 | 采集 ≠ 建模 |
2. 数据湖的核心组成
（1）底层存储
常见选择：
- HDFS（传统）
- S3 / OSS / COS
- MinIO（私有化首选）
特征：
- 大文件
- 顺序读
- 冷热分层
（2）表格式（极其关键）
如果只有“文件”，那只是“垃圾场”。
现代数据湖 = 对象存储 + 表格式
主流三大表格式：
| 格式 | 特点 |
|---|---|
| Iceberg | Schema 演进强、生态好 |
| Hudi | Upsert / CDC 强 |
| Delta Lake | 事务能力强 |
👉 推荐优先级（企业） Iceberg ≥ Hudi > Delta
（3）ODS（原始数据层）
原则：
- 不做复杂清洗
- 尽量接近源数据
- 保留原始字段
典型用途：
- 重放
- 问题追溯
- 血缘分析
3. 数据湖常见“坑”
- 只有存储，没有表格式
- ODS 被当成业务表用
- 没有元数据治理
- 数据无限增长无生命周期
四、数据仓库（Data Warehouse）——“让数据可用、可信”
1. 数仓的核心目标
让不同人、不同时间、不同系统，看到“同一口径的数据”。
关键词：
- 稳定
- 可复用
- 口径统一
2. 数仓的经典分层模型
（1）ODS（数仓语义）
注意：数仓 ODS ≠ 数据湖 ODS
- 数据湖 ODS：原始
- 数仓 ODS：轻度清洗后的“贴源数据”
（2）DWD（明细层）
- 一行 = 一条业务事实
- 维度打平
- 不做聚合
（3）DWS（汇总层）
- 按主题域
- 统一指标口径
- 跨业务复用
（4）ADS / Data Mart
- 面向应用
- 面向 BI / API
- 不可复用也没关系
3. 建模方法（决定成败）
1️⃣ 维度建模（Kimball）
- 事实表 + 维度表
- BI 友好
- 上手快
2️⃣ 主题域建模（Inmon / Data Vault）
- 面向全局
- 前期成本高
- 中台型企业更适合
👉 大厂实践： 主题域为主，局部维度建模。
五、湖仓一体（现代主流架构）
1. 为什么一定会走向湖仓一体
如果分裂：
- 湖里一套
- 仓里一套
- 数据重复、成本翻倍
湖仓一体的本质：
同一份数据，用不同的计算引擎消费。
2. 典型湖仓一体架构
MinIO / S3
+ Iceberg
├── Spark（离线）
├── Flink（流）
├── Trino / Presto（交互）
└── Doris / StarRocks（OLAP）
3. 实时数仓的接入方式
- CDC → Hudi / Iceberg
- Flink 实时写表
- 分钟级 / 秒级可见
六、数据治理：中台的“中枢神经”
没有治理，就不叫中台。
1. 元数据治理
- 表 / 字段
- 血缘
- 影响分析
2. 数据质量
- 完整率
- 准确率
- 延迟
3. 指标治理
- 指标字典
- 口径审批
- 指标复用率
4. 数据资产化
- 数据目录
- 热度
- 价值评分
七、成本 & 生命周期管理（非常现实）
1. 数据分层存储
| 层级 | 存储 |
|---|---|
| 热数据 | 高性能 |
| 温数据 | 普通 |
| 冷数据 | 归档 |
2. 生命周期策略
- ODS 保留 7–30 天
- 明细层 6–12 月
- 汇总长期
八、常见失败案例总结
- 先买工具，后想架构
- 只有湖，没有仓
- 只有仓，没有治理
- 指标口径长期打架
- 中台没人用
九、结合你背景的关键价值点
结合你关注的：
- 监控 / 日志 / Trace
- 告警 / 根因分析
- AI 智能分析
结论非常明确：
数据湖 = 可观测原始事实 数据仓库 = 可决策的结构化事实
AI 的“可信度”，100% 取决于这里。
十、给你一份“企业级推荐组合”
如果是 自建 / 私有化 / 技术中台：
- 存储：MinIO
- 表格式：Iceberg
- 批计算：Spark
- 流计算：Flink
- OLAP：Doris / StarRocks
- 查询：Trino
- 治理：自研 + OpenMetadata
合理路径
前端 / 后端埋点
↓
Kafka
↓
Flink
↓
MongoDB（短期缓存 / 实时查询）
↓
Iceberg on MinIO（长期数据湖）
