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

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

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

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

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

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

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

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

数据类型

关键辨析：

• 结构化/半结构化/非结构化​ 是 从数据格式的规范性​ 角度划分。

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

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

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

1. 业务系统（如ERP、CRM）：

   • **为什么是结构化数据？**​因为这些系统基于关系型数据库构建，必须遵循严格的表结构来保证事务的ACID特性。一条“订单”数据，必须包含订单ID、用户ID、金额、时间等固定字段。

   • 设计原因：保证数据的一致性、完整性和准确性，这是业务运转的基石。

2. 应用日志与埋点：

   • **为什么是半结构化数据（如JSON）？**​ 因为日志需要灵活地记录各种事件，不同事件的参数差异很大。JSON的键值对形式既能保持一定的可读性，又能灵活扩展。

   • 示例：一个“点击事件”的JSON日志可能包含 {“event”: “click”, “user_id”: “123”, “page”: “home”, “timestamp”: “2023-05-12 10:00:00”}，而一个“支付事件”的日志会增加 “amount”: 100, “order_id”: “456”等字段。

   • 设计原因：灵活性和可扩展性。业务快速迭代时，可以随时增加新的日志字段，而无需修改数据库表结构。

3. 物联网与传感器：

   • **为什么是流式数据？**​ 因为物理世界是连续变化的，传感器以固定的频率（如每秒100次）持续产生读数。

   • 设计原因：实时监控与即时响应。例如，监控电网频率，必须在毫秒级发现异常并触发保护。

4. 图片、音视频：

   • **为什么是非结构化数据？**​ 其信息蕴含在像素、声波、帧序列中，计算机无法直接理解其“含义”。

   • 设计原因：承载人类可感知的丰富信息。一张产品图片所包含的信息，远非“颜色：红，尺寸：大”这几个结构化字段所能概括。

存储方式与设计原因

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

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

1. 视频文件（非结构化） -> 存入 对象存储（OSS），获得一个URL。

2. 视频元信息（结构化）：标题、作者、时长、OSS URL -> 存入 关系数据库（MySQL）。

3. 用户播放行为日志（半结构化JSON） -> 实时写入 消息队列（Kafka）。

4. Kafka中的日志​ -> 被 流处理引擎Flink实时消费，计算热度指标。

5. **计算结果（结构化）**​ -> 写回 数据库​ 或 数据仓库，用于推荐。

大数据中的易混淆概念

数据流动方向

如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

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

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

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

假设你有一个电商平台：

• 数据湖​ 里存了什么？

  • MySQL 里订单表的 全量二进制日志。

  • 用户在前端的所有 点击流JSON日志。

  • 商品页的 详情图片。

  • 客服与用户的 聊天录音。

  • 这些数据可能几年都不会被用到，但一旦需要训练一个“以图搜图”的模型，商品图片就派上用场了。

• ODS层​ 里存了什么？

  • 从MySQL同步过来的 ods_order表，已经将时间字段统一为UTC，将用户状态编码（如0/1）统一为中文（‘有效’/‘无效’）。

  • 从日志服务器同步过来的 ods_user_click表，已经将JSON日志解析成了结构化的字段（user_id, page_url, click_time）。

  • 它的目的非常明确：快速、稳定地为下游的DWD（明细层）、DWS（汇总层）提供高质量的、结构化的数据源。

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

1. 数据湖（Data Lake）

   • 定义：一个集中存储所有原始数据（结构化、半结构化、非结构化）的存储库，就像一个大湖，无论河水、雨水都先汇集于此。

   • 核心特征：“先存后用”，存储成本低，格式不限，支持灵活的数据探索与高级分析（如AI训练）。

2. 数据仓库（Data Warehouse）

   • 定义：一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

   • 核心特征：“先用后存”，数据经过清洗、转换、建模（如维度建模），形成易于理解的、高质量的数据模型（如分层模型：ODS→DWD→DWS→ADS）。

3. 大数据平台（Big Data Platform）

   • 定义：提供数据全生命周期管理能力的技术底座与工具集合。它是承载数据湖、数据仓库、数据中台运行的“操作系统”和“工具箱”。

   • 核心特征：技术导向，包含存储（HDFS / S3）、计算（Spark、Flink、MapReduce）、工具（Hive、Kafka、HBase）、调度系统、元数据管理等一整套技术组件。

4. 数据中台（Data Middle Platform）

   • 定义：一种组织战略与架构理念，通过将数据资产、数据能力、数据服务进行平台化、组件化、标准化，以API服务的形式快速响应前台业务需求。

   • 核心特征：业务与组织导向，核心目标是“降本增效”和“数据业务化”。它不是一个具体软件，而是基于大数据平台构建的“数据产品工厂”和“服务超市”。

   • 数据治理（标准、质量、血缘）、数据资产（标签 / 指标）、数据服务（API / 数据接口）、数据复用（跨部门使用）

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

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

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

电商场景的实例

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

1. 数据湖：存储用户所有的原始点击流日志、商品图片、搜索词、甚至客服语音。

2. 数据仓库：将点击流日志清洗成结构化表 dwd_user_click，并与商品表dim_product关联，生成用户行为宽表 dws_user_behavior。

3. 大数据平台：用 Flink​ 实时处理点击流写入数据湖，用 Spark​ 每天定时计算 dws_user_behavior表，用 Airflow​ 调度整个任务。

4. 数据中台：数据中台团队将 dws_user_behavior表中的核心逻辑（如“用户近期偏好类目”）封装成一个名为 **“用户实时偏好服务”**​ 的API。推荐系统的开发团队直接调用这个API，而无需关心数据在哪里、如何计算。

现代趋势：湖仓一体

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

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

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

为什么会出现 Lakehouse

1）数据仓库的问题

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

2）数据湖的问题

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

湖仓一体 vs. 其他概念

Lakehouse 核心能力

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

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

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

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

1. 统一的元数据层：在HDFS或对象存储（S3/OSS）之上，增加一个统一的元数据管理层，像“智能目录”一样管理所有数据。

2. 开放的表格式：采用 Apache Iceberg、Apache Hudi、Delta Lake​ 等“事务化表格式”层。这是湖仓一体的技术核心。

   • 它们为存储在湖上的文件提供了类似数据库表的抽象，支持ACID事务、时间旅行、模式演进、高效upsert/delete。

3. 计算引擎分离：计算引擎（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）          │
└─────────────────────────────────────┘