数据中台、数据仓库、大数据平台、数据湖概念区分

Tue, 05 May 2026 21:23:00 +0800

数据源、数据特点、存储方式

“数据源”是一个泛指，它包含企业内外部所有可能产生数据的系统。关系型数据库（如MySQL、Oracle）只是其中最重要、最结构化的一类。

根据行业实践，数据源主要分为以下几类：

数据源类型	典型示例	数据特点	常用采集技术
企业内部业务数据	ERP、CRM、OA、财务系统	高度结构化，质量高，价值密度大	数据库同步（Sqoop、CDC）、API
应用日志与埋点	服务器日志、APP/Web用户行为埋点	半结构化/非结构化，数据量大，实时性强	Flume、Logstash、Kafka
物联网与传感器	智能设备、工业传感器、GPS	流式数据，频率高，实时性要求极高	MQTT、边缘计算、Flink
互联网与社交媒体	网页、电商评论、社交媒体内容	非结构化为主，格式多样，更新快	网络爬虫、公开API
第三方数据	数据服务商、政府公开数据	标准化程度不一，有合规要求	API下载、文件导入

结论：数据源是多源异构的。大数据平台的首要任务就是将这些不同来源、不同格式、不同时效的数据统一接入。

数据源：远不止关系型数据库

你图中的“数据源”是一个泛指，它包含企业内外部所有可能产生数据的系统。关系型数据库（如MySQL、Oracle）只是其中最重要、最结构化的一类。

根据行业实践，数据源主要分为以下几类：

数据源类型	典型示例	数据特点	常用采集技术
企业内部业务数据	ERP、CRM、OA、财务系统	高度结构化，质量高，价值密度大	数据库同步（Sqoop、CDC）、API
应用日志与埋点	服务器日志、APP/Web用户行为埋点	半结构化/非结构化，数据量大，实时性强	Flume、Logstash、Kafka
物联网与传感器	智能设备、工业传感器、GPS	流式数据，频率高，实时性要求极高	MQTT、边缘计算、Flink
互联网与社交媒体	网页、电商评论、社交媒体内容	非结构化为主，格式多样，更新快	网络爬虫、公开API
第三方数据	数据服务商、政府公开数据	标准化程度不一，有合规要求	API下载、文件导入

结论：数据源是多源异构的。大数据平台的首要任务就是将这些不同来源、不同格式、不同时效的数据统一接入。

数据类型

数据类型	定义	典型示例	类比
结构化数据	具有严格固定模式的数据，可以用二维表结构（行和列）逻辑表达。	关系型数据库表（MySQL订单表）、Excel表格、CSV文件。	乐高积木：每个零件都有固定的形状和接口，可以精确拼接。
半结构化数据	具有一定结构，但模式不固定，常以自描述的形式存在（如标签、标记）。	JSON、XML、日志文件、HTML页面。	一封信：有固定的开头（称呼）、正文、结尾（署名）结构，但正文内容自由。
非结构化数据	没有预定义数据模型，格式多样，无法用简单的二维表表示。	文本（文章、邮件）、图片、音频、视频、PDF文档。	一团黏土：没有固定形状，可以塑造成任何样子。
流式数据	按时间顺序持续不断、无限生成的数据序列，强调数据的时效性和顺序性。	传感器实时读数、股票交易流水、APP点击流、直播弹幕。	自来水管中的水：持续流动，必须用容器（如桶）接住并实时处理，否则就流走了。

关键辨析：

结构化/半结构化/非结构化 是 从数据格式的规范性 角度划分。
流式数据 是 从数据产生的时序性和处理方式 角度划分，它可以是结构化的（如交易流水），也可以是半结构化的（如JSON格式的日志）。

为什么数据源对应不同的数据特点

这由数据产生的源头和方式决定。

业务系统（如ERP、CRM）：
- **为什么是结构化数据？**因为这些系统基于关系型数据库构建，必须遵循严格的表结构来保证事务的ACID特性。一条“订单”数据，必须包含订单ID、用户ID、金额、时间等固定字段。
- 设计原因：保证数据的一致性、完整性和准确性，这是业务运转的基石。
应用日志与埋点：
- **为什么是半结构化数据（如JSON）？** 因为日志需要灵活地记录各种事件，不同事件的参数差异很大。JSON的键值对形式既能保持一定的可读性，又能灵活扩展。
- 示例：一个“点击事件”的JSON日志可能包含 {“event”: “click”, “user_id”: “123”, “page”: “home”, “timestamp”: “2023-05-12 10:00:00”}，而一个“支付事件”的日志会增加 “amount”: 100, “order_id”: “456”等字段。
- 设计原因：灵活性和可扩展性。业务快速迭代时，可以随时增加新的日志字段，而无需修改数据库表结构。
物联网与传感器：
- **为什么是流式数据？** 因为物理世界是连续变化的，传感器以固定的频率（如每秒100次）持续产生读数。
- 设计原因：实时监控与即时响应。例如，监控电网频率，必须在毫秒级发现异常并触发保护。
图片、音视频：
- **为什么是非结构化数据？** 其信息蕴含在像素、声波、帧序列中，计算机无法直接理解其“含义”。
- 设计原因：承载人类可感知的丰富信息。一张产品图片所包含的信息，远非“颜色：红，尺寸：大”这几个结构化字段所能概括。

存储方式与设计原因

不同的数据类型，因其使用方式不同，采用了截然不同的存储方案。

数据类型	典型存储方案	为什么这么设计？
结构化数据	关系型数据库（MySQL/Oracle）、数据仓库（Hive/ClickHouse）	为了高效的关联查询和事务处理。二维表结构和SQL语言是为关联查询而生的最优解。数据仓库则针对海量数据的分析查询做了列式存储等优化。
半结构化数据	NoSQL数据库（MongoDB/ES）、分布式文件系统（HDFS）、消息队列（Kafka）	为了灵活的模式和快速的读写。MongoDB的文档模型直接存储JSON，便于扩展。HDFS和Kafka则提供了高吞吐的廉价存储，适合海量日志的批量或流式处理。
非结构化数据	对象存储（AWS S3/阿里云OSS）、分布式文件系统（HDFS）	为了存储海量、低访问频率的“大文件”。对象存储提供近乎无限的容量、极高的持久性和低廉的成本，并通过HTTP接口访问，非常适合存储图片、视频。
流式数据	消息队列（Kafka/Pulsar）、流处理引擎内存	为了缓冲和削峰填谷。流数据产生速度不稳定，需要消息队列作为“缓冲区”来承接，再让下游的流处理引擎（如Flink）以可控的速度消费处理。Kafka的持久化机制也允许数据重播。

一个综合案例：用户上传短视频

视频文件（非结构化） -> 存入 对象存储（OSS），获得一个URL。
视频元信息（结构化）：标题、作者、时长、OSS URL -> 存入 关系数据库（MySQL）。
用户播放行为日志（半结构化JSON） -> 实时写入 消息队列（Kafka）。
Kafka中的日志 -> 被 流处理引擎Flink实时消费，计算热度指标。
**计算结果（结构化）** -> 写回 数据库或数据仓库，用于推荐。

大数据中的易混淆概念

数据流动方向

如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 数据源（业务系统 / 日志 / IoT）
 ↓
 数据湖（原始数据池）
 ↓
 数据仓库（结构化分析层）
 ↓
 数据中台（数据服务层）
 ↓
 业务应用 / BI / AI

 大数据平台 = 整体技术底座（承载以上所有）

数据湖 vs. 数据仓库ODS层：核心区别

这是一个经典问题。两者虽然都可能存储“原始数据”，但定位、设计和用途有本质区别。

对比维度	数据湖	数据仓库ODS层
核心定位	企业级原始数据“蓄水池”	面向分析的数据“预处理区”
设计哲学	“先存储，后定义” (Schema-on-Read)	“先定义，后存储” (Schema-on-Write)
数据范围	全量原始数据：结构化、半结构化、非结构化（文本、图片、视频、日志）	业务系统结构化数据的镜像：主要来自关系型数据库、日志文件等
数据状态	绝对原始，基本不做清洗转换，保留所有细节和可能的“脏数据”。	轻度清洗整合：会进行字段标准化、编码统一、简单去重等，保证数据一致性。
存储目标	长期存储，用于数据探索、机器学习、回溯分析等未知场景。	短期或周期存储，作为数据仓库ETL流程的缓冲区和数据来源。
主要用户	数据科学家、算法工程师，进行数据挖掘和模型训练。	数据开发工程师、数据分析师，进行ETL加工和即席查询。
技术实现	基于 HDFS、对象存储（如S3、OSS），搭配 Hive、Spark、Presto 进行查询。	通常是 Hive 或 MPP数据库中的一个逻辑层，有明确的表结构。

假设你有一个电商平台：

数据湖 里存了什么？
- MySQL 里订单表的 全量二进制日志。
- 用户在前端的所有 点击流JSON日志。
- 商品页的 详情图片。
- 客服与用户的 聊天录音。
- 这些数据可能几年都不会被用到，但一旦需要训练一个“以图搜图”的模型，商品图片就派上用场了。
ODS层 里存了什么？
- 从MySQL同步过来的 ods_order表，已经将时间字段统一为UTC，将用户状态编码（如0/1）统一为中文（‘有效’/‘无效’）。
- 从日志服务器同步过来的 ods_user_click表，已经将JSON日志解析成了结构化的字段（user_id, page_url, click_time）。
- 它的目的非常明确：快速、稳定地为下游的DWD（明细层）、DWS（汇总层）提供高质量的、结构化的数据源。

数据中台、数据仓库、大数据平台、数据湖

数据湖（Data Lake）
- 定义：一个集中存储所有原始数据（结构化、半结构化、非结构化）的存储库，就像一个大湖，无论河水、雨水都先汇集于此。
- 核心特征：“先存后用”，存储成本低，格式不限，支持灵活的数据探索与高级分析（如AI训练）。
数据仓库（Data Warehouse）
- 定义：一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
- 核心特征：“先用后存”，数据经过清洗、转换、建模（如维度建模），形成易于理解的、高质量的数据模型（如分层模型：ODS→DWD→DWS→ADS）。
大数据平台（Big Data Platform）
- 定义：提供数据全生命周期管理能力的技术底座与工具集合。它是承载数据湖、数据仓库、数据中台运行的“操作系统”和“工具箱”。
- 核心特征：技术导向，包含存储（HDFS / S3）、计算（Spark、Flink、MapReduce）、工具（Hive、Kafka、HBase）、调度系统、元数据管理等一整套技术组件。
数据中台（Data Middle Platform）
- 定义：一种组织战略与架构理念，通过将数据资产、数据能力、数据服务进行平台化、组件化、标准化，以API服务的形式快速响应前台业务需求。
- 核心特征：业务与组织导向，核心目标是“降本增效”和“数据业务化”。它不是一个具体软件，而是基于大数据平台构建的“数据产品工厂”和“服务超市”。
- 数据治理（标准、质量、血缘）、数据资产（标签 / 指标）、数据服务（API / 数据接口）、数据复用（跨部门使用）

核心区别与联系（一张图看懂）

维度	数据湖	数据仓库	大数据平台	数据中台
核心定位	原始数据 “仓库”	分析数据“超市”	技术“工具箱”与“地基”	数据能力“服务商”
主要目的	存储一切，探索未知	支撑已知的、稳定的分析报表	提供稳定可靠的数据处理技术能力	快速响应业务变化，赋能创新
数据状态	原始、未加工、格式多样	清洗、整合、建模后的高质量数据	承载上述所有数据状态	不直接存储数据，提供数据的服务化封装
典型用户	数据科学家、算法工程师	数据分析师、业务决策者	数据开发工程师、平台运维	前端业务开发、产品经理、运营
技术栈	HDFS/S3 + Spark/Presto	Hive/Spark + 维度建模 + BI工具	Hadoop生态全家桶 + 调度/监控	基于大数据平台，增加服务化、资产化管理组件
产出物	原始数据集、AI模型	报表、指标、分析结论	稳定运行的集群、任务、管道	统一数据服务API（如“用户画像API”、“实时风控API”）
通俗比喻	毛坯房仓库（什么都能放，但找东西难）	精装陈列馆（分门别类，方便参观）	建筑工地与工具（水泥、钢筋、起重机）	物业管理公司+精品店（提供标准化服务，快速满足住户需求）

它们的关系链可以概括为：

大数据平台 提供了从“数据源”抽取数据到 **“数据湖” 的能力，并对湖中数据进行加工后存入 “数据仓库”。“数据中台”** 则将数据仓库（及数据湖）中的核心数据资产，封装成易用的服务，通过 大数据平台 的能力，高效地提供给“业务应用”。

电商场景的实例

假设“淘宝”要做一个“猜你喜欢”功能：

数据湖：存储用户所有的原始点击流日志、商品图片、搜索词、甚至客服语音。
数据仓库：将点击流日志清洗成结构化表 dwd_user_click，并与商品表dim_product关联，生成用户行为宽表 dws_user_behavior。
大数据平台：用 Flink 实时处理点击流写入数据湖，用 Spark 每天定时计算 dws_user_behavior表，用 Airflow 调度整个任务。
数据中台：数据中台团队将 dws_user_behavior表中的核心逻辑（如“用户近期偏好类目”）封装成一个名为 **“用户实时偏好服务”** 的API。推荐系统的开发团队直接调用这个API，而无需关心数据在哪里、如何计算。

现代趋势：湖仓一体

湖仓一体 是一种融合性数据架构，它试图在一个统一的平台上，同时提供数据湖的灵活性、低成本存储和数据仓库的高性能、强管理性。

核心思想：不再将“湖”和“仓”物理分离成两套系统，而是构建一个统一的数据管理层，让数据“一份存储”，却能同时支持数据科学探索（像用湖）和高性能BI分析（像用仓）。

👉 不再分湖和仓，而是直接在“湖”里建“仓能力”

为什么会出现 Lakehouse

1）数据仓库的问题

✅ 查询快 ❌ 只能结构化数据 ❌ 成本高 ❌ 不适合 AI / ML

2）数据湖的问题

✅ 什么都能存 ✅ 成本低 ❌ 数据乱（容易变“数据沼泽”） ❌ 无事务、无治理 ❌ 查询慢

湖仓一体 vs. 其他概念

概念	与湖仓一体的相同点	与湖仓一体的核心不同点
数据湖	存储原始数据：湖仓一体继承了数据湖存储原始、多格式数据的能力。	缺乏治理与性能：传统数据湖是“野蛮生长”的，缺乏ACID事务、数据版本管理、行级更新和查询优化，难以直接支撑高性能BI。湖仓一体补上了这些能力。
数据仓库	支撑BI分析：湖仓一体提供了可与传统数据仓库媲美的SQL性能和数据治理能力。	不够开放灵活：传统数据仓库对非结构化数据和AI场景支持弱，且常是封闭、昂贵的专用系统。湖仓一体基于开放的存储格式（如Parquet/ORC）和计算引擎（如Spark），更开放、成本更低。
大数据平台	技术底座：湖仓一体是构建在大数据平台（如HDFS、对象存储、Spark）之上的一种具体架构实现。	范围更聚焦：大数据平台是一个更宽泛的“工具箱”概念。湖仓一体是这个工具箱为解决“湖仓割裂”问题而组合出的一种特定“解决方案”或“产品形态”。
数据中台	共同目标：两者都致力于提升数据利用效率、降低数据使用成本。	层次不同：数据中台是业务和组织层面的战略与架构，强调数据服务化。湖仓一体是偏技术层面的存储与计算架构，是中台战略得以实现的重要技术支撑。一个强大的湖仓一体平台，能让数据中台的数据资产管理和服务封装更高效。

Lakehouse 核心能力

序号	核心能力	含义	解决的问题	关键技术 / 实现方式	你项目里的对应
1️⃣	统一存储	所有数据（结构化 / 半结构化 / 非结构化）都存在同一份存储中	消除“湖一份 + 仓一份”的数据冗余	对象存储（ADLS / S3 / OSS）	ADLS / ObjectStore 作为底座
2️⃣	支持所有数据类型	同时支持表、JSON、日志、图片、音视频等	数据仓库只能存结构化数据的局限	Parquet / ORC / Avro / 二进制文件	Cosmos 原始日志 + Kusto 结构化数据
3️⃣	ACID 事务支持 ⭐	提供原子性、一致性、隔离性、持久性	数据湖没有事务、数据混乱、无法 Update/Delete	Delta Lake / Apache Iceberg / Apache Hudi	类似 Kusto 的 ingestion 一致性，但更通用
4️⃣	统一计算（多工作负载）	一套系统支持 BI、SQL、流计算、ML/AI	传统架构需要 Hive + Spark + Kafka + DWH 多套系统	Spark SQL / Flink / Presto / Databricks SQL	Spark + ADF + Kusto 的统一替代方案
5️⃣	存算分离	存储与计算独立扩展，按需付费	传统数仓存算耦合，扩容成本高	存储：ADLS / S3；计算：Spark / Trino / StarRocks	你现在 Spark on ADLS 就是典型存算分离
6️⃣	批流一体	离线和实时数据用同一套链路处理	Lambda 架构（批+流双链路）维护复杂	Delta Streaming / Flink CDC / Structured Streaming	替代“ADF批 + Kafka流”双链路

🎯 一句话记忆口诀（建议背下来）

一存（统一存储）、多类（多数据类型）、强事务（ACID）、多算（统一计算）、分离（存算分离）、一体（批流一体）

湖仓一体是如何实现的？（技术关键）

它并非魔法，而是通过一系列技术创新实现的：

统一的元数据层：在HDFS或对象存储（S3/OSS）之上，增加一个统一的元数据管理层，像“智能目录”一样管理所有数据。
开放的表格式：采用 Apache Iceberg、Apache Hudi、Delta Lake 等“事务化表格式”层。这是湖仓一体的技术核心。
- 它们为存储在湖上的文件提供了类似数据库表的抽象，支持ACID事务、时间旅行、模式演进、高效upsert/delete。
计算引擎分离：计算引擎（Spark、Flink、Presto、BI工具）可以直接通过统一的表格式层访问数据，而无需移动数据。

Lakehouse的5层架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌─────────────────────────────────────┐
│ 5. 应用层（BI / ML / AI / 实时） │
├─────────────────────────────────────┤
│ 4. 计算引擎层（Spark/Flink/Trino） │
├─────────────────────────────────────┤
│ 3. 元数据 / 事务层（Delta Log）⭐⭐ │ ← 核心
├─────────────────────────────────────┤
│ 2. 表格式层（Parquet + 索引） │
├─────────────────────────────────────┤
│ 1. 存储层（ADLS / S3 / OSS） │
└─────────────────────────────────────┘

Lakehouse on My Learning Notes