一、数据源概述：到底什么是数据源？

说实话，我做了十几年数据工程，每次跟新人聊「数据源」这个词，大家第一反应都是：「不就是数据库吗？」

嗯，对，但不全对。

数据源，说白了就是数据的来源地。它可以是数据库、文件、API接口，甚至是你桌上那张皱巴巴的Excel表格。我个人习惯把数据源定义为：任何能够产生或存储数据，并且可以被我们程序读取的地方。

数据源在数据工程中的角色

数据工程说白了就三件事：拿数据、管数据、用数据。而数据源，就是「拿数据」这第一步。

我经常跟团队讲一个比喻：数据工程就像做饭。数据源就是菜市场。你菜买得不好，后面厨艺再好也白搭。我在项目中遇到过太多次了——数据源质量差，后面清洗、建模全白干。

数据源在数据工程中扮演这几个关键角色：

• 数据入口：所有数据管道的第一站，决定了你能拿到什么数据
• 质量源头：数据质量问题的80%都出在数据源端
• 性能瓶颈：数据源的读取速度往往决定了整个管道的吞吐量
• 安全边界：数据源的访问权限管理是数据安全的第一道防线

数据源的三大分类

数据源怎么分类？其实就三种：结构化、半结构化、非结构化。你想想看，这世界上所有的数据，跑不出这三个筐。

1. 结构化数据

结构化数据，就是那种规规矩矩、行是行列是列的数据。每一行代表一条记录，每一列代表一个字段，字段类型固定。

典型代表：

• 关系型数据库（MySQL、PostgreSQL、Oracle）
• Excel表格（严格意义上的）
• CSV文件

举个例子：

-- 这就是结构化数据
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    email VARCHAR(100)
);

INSERT INTO users VALUES 
(1, '张三', 28, 'zhangsan@example.com'),
(2, '李四', 32, 'lisi@example.com');

结构化数据的好处是什么？查询快、好分析、容易做关联。我在做电商数据平台的时候，订单表、用户表、商品表全是结构化数据，用SQL一把梭，效率极高。

2. 半结构化数据

半结构化数据，说白了就是有结构但结构不固定。它有标签、有层级，但同一类数据的字段可以不一样。

典型代表：

• JSON / XML
• YAML配置文件
• HTML文档
• 日志文件（部分）

看个例子就明白了：

{
  "user": {
    "id": 1,
    "name": "张三",
    "contacts": [
      {"type": "email", "value": "zhangsan@example.com"},
      {"type": "phone", "value": "13800138000"}
    ]
  }
}

注意看，contacts数组里每个对象的字段是一样的，但你可以随时加一个新字段，比如加个"wechat"。这在结构化数据里就得改表结构，但在半结构化数据里，直接写进去就行。

3. 非结构化数据

非结构化数据，就是没有固定格式、没法直接用行列表示的数据。这类数据占到了企业数据总量的80%以上。

典型代表：

• 文本文件（TXT、PDF、Word）
• 图片（JPEG、PNG）
• 音频（MP3、WAV）
• 视频（MP4、AVI）
• 二进制文件

非结构化数据怎么处理？一般靠特征提取。比如图片提取像素特征，文本提取关键词，音频提取频谱特征。处理起来比结构化数据麻烦得多，但价值也大。

我记得有个项目要做用户评论的情感分析。评论数据全是中文文本，非结构化。我们先用NLP提取情感特征，再转成结构化数据存到数据库里。这一步处理，占了整个项目60%的工作量。

三种数据源的对比

维度	结构化	半结构化	非结构化
格式	固定模式（Schema）	自描述（Self-describing）	无固定格式
存储	关系型数据库	NoSQL、文件	对象存储、文件系统
查询	SQL，高效	特定查询语言	需提取后查询
灵活性	低（改结构麻烦）	中	高
处理难度	低	中	高
典型场景	交易记录、用户信息	日志、配置文件	图片、视频、文档

知识体系总览

下面这张图，是我自己梳理的数据源知识体系。你看一眼，就能把这一章的内容串起来。

小结

这一章我们聊了数据源的定义、角色和分类。说白了就三句话：

• 数据源是数据工程的起点，选不好后面全白搭
• 结构化数据最规矩，适合做精确分析
• 半结构化和非结构化数据更灵活，但处理起来也麻烦

我个人建议，刚开始做数据工程的朋友，先从结构化数据入手。把MySQL、CSV这些玩熟了，再去碰JSON、日志、图片这些。一步一个脚印，稳着来。

---