第2章数据源与数据特征

第2章：数据源与数据特征

大家好，我是老张。今天咱们聊聊数据融合里最基础、也最绕不开的一个话题——数据源长什么样，以及它们各自有什么脾气。

说实话，我刚开始做数据融合那几年，踩过最大的坑就是「拿到数据就开干」。结果呢？结构化数据字段对不上，半结构化数据解析到一半崩了，非结构化数据更是直接把我内存撑爆。嗯，后来我学乖了——先摸清数据的「性格」，再动手。

2.1 结构化数据：最听话，但规矩多

结构化数据，说白了就是那种规规矩矩待在表格里的数据。行是记录，列是字段，每个字段有明确的类型和约束。关系数据库里的表、Excel 表格，都是典型代表。

我个人习惯把结构化数据比作「军训队列」——每个人站得笔直，位置固定，一眼就能看出谁是谁。

特点

模式固定：字段名、数据类型、长度都是提前定义好的
查询高效：支持 SQL 这种标准化的查询语言
一致性高：数据完整性约束（主键、外键、唯一性）保证了质量

处理难点

模式冲突：不同系统的字段名可能不同。比如 A 系统叫「user_id」，B 系统叫「uid」。我在项目中遇到过两家公司合并，光对齐用户字段就花了三周。
数据漂移：上游系统改了字段类型，下游没同步。你想想看，一个「金额」字段突然从 decimal 变成了 string，你的聚合查询直接报错。
脏数据：空值、异常值、重复记录。我曾经处理过一张表，里面「年龄」字段居然有 999 岁的记录——明显是默认值没处理好。

我的避坑指南：拿到结构化数据后，第一件事不是写融合逻辑，而是跑一遍数据质量检查。我曾经因为没检查，直接把两个系统的「客户编号」字段做 join，结果发现一个系统用「CUST_001」，另一个用「001」——对不上，全白干。

2.2 半结构化数据：灵活，但解析起来头疼

半结构化数据，就是那种「有结构，但结构不固定」的数据。JSON、XML、YAML 都是典型。它不像结构化数据那么死板，也不像非结构化数据那么「野」。说白了，它有自己的 schema，但这个 schema 可以变。

我经常跟团队说：半结构化数据就像「变形金刚」——看起来有模有样，但随时可能换个形态。

特点

自描述：数据本身包含了元信息（比如 JSON 的 key 名）
层次嵌套：可以表达复杂的父子关系、数组结构
模式灵活：同一个集合里，不同文档的字段可以不一样

处理难点

嵌套深度：JSON 嵌套个七八层是常事。我记得有一次处理电商订单数据，一个订单里嵌套了商品列表、优惠信息、物流轨迹——展开后字段数直接翻了三倍。
字段缺失：有的记录有「phone」字段，有的没有。你写解析逻辑时，必须处理这种「可选字段」。
类型推断：同一个字段，这条记录是字符串，那条记录是数字。比如「price」字段，有的写 "19.99"，有的写 19.99。解析器一不小心就报错。

  实战经验：处理半结构化数据时，我建议先做一次「schema 探测」——把数据样本跑一遍，看看字段的完整度、类型分布、嵌套深度。别上来就写死解析逻辑，否则数据一变，代码就废。

2.3 非结构化数据：最「野」，但价值最高

非结构化数据，就是那些没有预定义模型的数据。文本、图片、音频、视频、日志文件……都属于这一类。这类数据占企业数据总量的 80% 以上，但处理难度也最大。

你想想看，一张图片里有没有「猫」，结构化数据能告诉你吗？不能。你得靠深度学习模型去识别。这就是非结构化数据的「野」——它不跟你讲规矩。

特点

无固定模式：没有字段、没有表结构，数据就是内容本身
体积巨大：一张高清图片几十 MB，一段视频几个 GB
语义复杂：同样的文字，不同语境下意思完全不同

处理难点

特征提取难：你得把非结构化数据「翻译」成结构化特征。比如从文本里提取关键词、从图片里识别物体。这需要 NLP、CV 等专业模型。
存储与计算成本高：非结构化数据通常要存到对象存储（如 S3、OSS）里，处理时还要上 GPU。我曾经处理过一批监控视频，光转码就跑了三天。
质量参差不齐：用户上传的图片可能模糊、倾斜、带水印。文本可能包含拼写错误、emoji、多语言混写。这些「噪声」会直接影响下游模型的效果。

注意：非结构化数据融合时，千万别想着「一步到位」。我建议先做「结构化映射」——把非结构化数据的关键信息提取出来，存成结构化或半结构化格式，再去做融合。否则，你就是在拿大炮打蚊子。

2.4 三种数据类型的对比

为了让你看得更清楚，我整理了一张对比表。嗯，这张表我用了很多年，每次给新团队培训都会拿出来讲。

维度	结构化数据	半结构化数据	非结构化数据
典型代表	关系表、CSV	JSON、XML	文本、图片、视频
模式	固定、预定义	灵活、自描述	无模式
查询方式	SQL	JSONPath、XPath	全文检索、模型推理
存储	关系数据库	NoSQL 数据库	对象存储、文件系统
处理难点	模式冲突、脏数据	嵌套解析、字段缺失	特征提取、计算成本
融合难度	低	中	高

2.5 核心知识体系图

下面这张图，是我自己梳理的「数据源与数据特征」知识框架。你可以把它当作本章的「地图」——先看整体，再深入细节。

2.6 一个小例子：三种数据融合的代码片段

光说不练假把式。我写个简单的 Python 示例，展示一下三种数据怎么「碰面」。

import json
import pandas as pd

# 1. 结构化数据：从 CSV 读入
df_structured = pd.read_csv('orders.csv')
# 假设字段：order_id, user_id, amount

# 2. 半结构化数据：从 JSON 解析
with open('user_info.json', 'r') as f:
    semi_structured = json.load(f)
# 假设结构：{"user_id": "U001", "name": "张三", "tags": ["vip", "new"]}

# 3. 非结构化数据：文本评论（模拟）
unstructured_text = "这个商品质量不错，物流也快，但包装有点简陋。"

# 融合思路：把非结构化文本提取成结构化特征
# 这里用简单的关键词匹配做演示
positive_words = ['不错', '快', '好']
negative_words = ['简陋', '差', '慢']

sentiment_score = sum(1 for w in positive_words if w in unstructured_text) - \
                 sum(1 for w in negative_words if w in unstructured_text)

# 构建融合后的记录
fusion_record = {
    'order_id': df_structured.iloc[0]['order_id'],
    'user_id': df_structured.iloc[0]['user_id'],
    'amount': df_structured.iloc[0]['amount'],
    'user_name': semi_structured['name'],
    'user_tags': ','.join(semi_structured['tags']),
    'sentiment_score': sentiment_score
}

print("融合后的数据：", fusion_record)

你看，这个例子虽然简单，但把三种数据的处理思路都串起来了。结构化数据直接读表，半结构化数据解析嵌套结构，非结构化数据先做特征提取再融合。嗯，这就是实战中的基本套路。

  核心总结：数据融合不是「一把抓」，而是「分类施策」。结构化数据重对齐，半结构化数据重解析，非结构化数据重提取。摸清每种数据的脾气，融合起来才能得心应手。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录