ADB-06 智能数据处理与大数据
ADB-06 智能数据处理与大数据
📅 预计 65 分钟 | ⭐ = 重要知识点 | 📌 中英术语见文末
📖 概念为主，ECA 规则等给可运行 SQLite 触发器示例
6.1 数据、信息与知识
从"堆在地上的零件"到"能造车的图纸"
想象一个快递仓库：纸箱上的条形码只是一串数字——数据；快递员扫一下，知道"这是发给张三的书"——有了含义，成了信息；主管看了几百单，总结出"周五下午单量是平时两倍，得多安排两个人"——能指导决策的规律，就是知识。三者递进，是理解"数据库为何走向智能"的总开关。
| 层次 | 一句话定义 | 例子 |
|---|---|---|
| 数据 data | 对客观事物的原始记录，是符号、是素材，本身不携带含义 | 温度计读出的 25；时间戳 2026-08-03 10:23:45 |
| 信息 information | 经过组织、加工、赋予语义的数据，回答"是什么" | 25 变成"今天贵阳 25 度，比昨天低 3 度" |
| 知识 knowledge | 可用于决策和预测的规律，回答"怎么办" | "连续 3 天降温后，感冒就诊量明显上升" |
从数据库角度看更直观：SELECT 温度 ... 查出的 25 是数据；配上日期与"比昨天低 3 度"才是信息；要得到"降温 → 就诊量上升"这类知识，还要在大量信息上统计归纳——这一步已进入后面要讲的数据挖掘范畴。
三个易错点：数据量大 ≠ 信息丰富（一万条没整理的日志不如一句精准摘要）；信息多 ≠ 知识正确（提炼会引入噪音，规律也会过时）；三者不是静态标签，同一内容在不同上下文可能处于不同层次。
💡 记忆口诀：数据是"原料"，信息是"加工品"，知识是"配方"——有了配方才能稳定做出一桌菜。
⚠️ 常见错误
- 把"数据"当"信息"：以为存进数据库的值就是信息。未加工的值只是数据，赋予语义之后才是信息。
- 以为数据只能是数字：文本、图像、声音、日志都是数据——数据是"任何可记录、可处理的符号"。
- 以为知识一定永远正确：知识是"由经验提炼的规律"，可能过时、可能误判，数据库里存的也不等于真相。
6.2 知识表示与推理 ⭐
把知识"装进盒子"，机器才拿得到
人的知识靠联想调用，机器只会处理结构化内容。要让机器"拥有"知识，第一步是把它表示（representation）成能存、能算的形式——像把散装知识装进四种盒子，各记一句话定义加一个例子即可。
① 产生式规则（production rule） ⭐：以"如果满足某条件，就推出某结论或执行某动作"的形式描述知识，写作 IF 条件 THEN 结论/动作。例子：IF 气温 < 5℃ THEN 提醒用户防寒；医疗里 IF 发烧 AND 咳嗽 AND 肺部阴影 THEN 疑似肺炎。优点是贴近人思维、模块化、易增删；缺点是规则多了可能冲突，需冲突消解。
② 语义网络（semantic network） ⭐：用节点表示概念、带标签的弧线表示关系的图结构。例子：
[麻雀] --属于--> [鸟] --会飞--> [飞行]
沿弧线遍历即可推理：麻雀属于鸟、鸟会飞 → 麻雀会飞。
③ 框架表示（frame） ⭐：用一个含若干**槽（slot）与槽值（value）**的结构描述一类对象，像"填表"。例子："学生"框架有姓名、学号、专业、成绩等槽；王五 这个实例就把槽一一填上值。框架还允许"继承"（研究生框架继承学生框架再添"导师"槽）和默认值，比普通二维表表达力强。
④ 本体（ontology） ⭐：对一个领域的概念、概念间关系、公理做形式化、可共享的规范描述，相当于"大家都认同的领域词典 + 关系图"。例子：电商领域统一定义"商品""订单""优惠券"及"订单包含商品"等关系，让不同系统对话用同一套词。它比语义网络更强调"规范、共享、可被机器互操作"。
💡 记忆口诀：产生式是"如果就"，语义网络是"一张图"，框架是"一张表"，本体是"共识词典"。
⚠️ 常见错误
- 混淆语义网络和本体：语义网络是"自己画出来"的图；本体强调"被共同认可、可共享的形式化规范"，更严格、更工程化。
- 以为框架就是数据表：框架还带继承、默认值和附加规则，比普通二维表表达的东西多。
- 把产生式规则当普通 if 语句：程序里的 if 是写死的判断；知识库里的规则是知识，可被推理引擎动态调用、组合、消解冲突。
6.3 知识库与知识库系统 ⭐
从"图书馆"到"导师办公室"
传统数据库像图书馆的书架：书摆得整齐，借什么给什么，只会"检索"。知识库更像有经验的导师办公室：他不光有资料，还能根据线索"推"出你没直接问的结论。图书馆只能查，导师会推理——这就是两者本质差异的写照。
知识库（knowledge base，KB）：以某种知识表示形式组织起来的知识集合，不只是事实，还包括规则、约束与推理所需的基础。
知识库与传统数据库的主要区别 ⭐：
| 维度 | 传统数据库 | 知识库 |
|---|---|---|
| 存储内容 | 结构化事实数据（表、记录） | 规则与知识（事实 + 规则） |
| 处理方式 | 检索：SQL 查询，结果就是存进去的 | 推理：能推出隐含结论，结果可能从未被显式存储 |
| 数据模式 | 表结构（模式）相对固定 | 表示形式多样（规则/网络/框架/本体） |
| 回答方式 | 精确匹配 | 既可精确匹配，也可逻辑推导 |
体会"检索 vs 推理"：数据库存了"张三是学生""学生是人"，问"张三是人吗"它查不到——表里没这一行；知识库沿"属于"链一推导就能答"是"。知识库的价值正是能回答没被显式存储的问题。
知识库管理系统（KBMS）的组成：类似 DBMS 是"管理数据的软件"，KBMS 是"管理知识的软件"，大致三部分：
- 知识库：存放事实与规则的存储主体。
- 推理机（inference engine）：按控制策略推导新结论。常见两种：正向推理从已知事实不断套规则往前推；反向推理从目标倒推需要哪些条件，医疗诊断多用后者。
- 知识获取与维护工具、解释与交互接口：帮专家录入、校验、更新知识，并向用户解释"结论怎么推出来的"——可解释性是知识库受信任的原因之一。
💡 记忆口诀：知识库系统 = 知识库（仓库）+ 推理机（大脑）+ 维护工具（管家）。
⚠️ 常见错误
- 把知识库当成大号数据库：核心差异在"推理"。没有推理机，一堆规则只是"规则表"。
- 以为知识库只存规则不存事实：知识库是"事实 + 规则"的组合，没有事实支撑，推理无从开始。
- 忽略知识的一致性维护：规则可能矛盾（一条说"发烧用 A 药"，另一条说"A 药对该患者过敏"），维护工具要能发现并处理冲突。
6.4 主动数据库与 ECA 规则 ⭐
让数据库从"被动挨问"变"主动办事"
普通数据库像只等人点单的餐厅：问一句答一句。主动数据库（active database）像盯着后厨的老店长：火候一到（事件）先检查菜熟没熟（条件），再自己上菜（动作）。所谓"主动"，就是数据库不只在收到查询时才干活，还会在特定时刻主动执行事先约定的逻辑。
ECA 规则是主动数据库的核心机制，三要素 ⭐：
- 事件（Event）：触发时机，回答"什么时候被唤起"。常见：某表被插入、更新、删除，也可以是定时事件。
- 条件（Condition）：事件发生后先检查的前提，成立才继续，回答"这事该不该管"。
- 动作（Action）：真正执行的操作——写另一张表、发告警、调外部程序，回答"怎么处理"。
三者串成链：事件 → 检查条件 → 条件成立则执行动作。
与传统触发器（trigger）的关系：数据库里的触发器就是 ECA 规则在 SQL 世界的直接实现——AFTER INSERT ON 表 是事件，WHEN 条件 是条件，BEGIN...END 里的语句是动作。理解 ECA 就理解了触发器为何这样设计；触发器是把 ECA 落地的具体工具。
下面是一个可直接运行的 SQLite 示例：员工工资被插入或更新后，若新工资低于下限，自动往告警日志写一条记录。
-- 建表：员工（含工资下限）
CREATE TABLE employee (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
salary REAL NOT NULL,
min_salary REAL NOT NULL DEFAULT 3000 -- 该员工的工资下限
);
-- 建表：告警日志
CREATE TABLE alert_log (
id INTEGER PRIMARY KEY AUTOINCREMENT,
emp_name TEXT,
message TEXT,
created_at TEXT DEFAULT (datetime('now'))
);
-- 触发器 1：新插入员工时，检查工资是否低于下限
CREATE TRIGGER trg_salary_alert_insert
AFTER INSERT ON employee -- E: 事件 = 插入新员工
WHEN NEW.salary < NEW.min_salary -- C: 条件 = 新工资 < 下限
BEGIN -- A: 动作 = 写一条告警日志
INSERT INTO alert_log(emp_name, message)
VALUES (NEW.name, '工资 ' || NEW.salary || ' 低于下限 ' || NEW.min_salary);
END;
-- 触发器 2：员工工资被更新时，同样检查并告警
CREATE TRIGGER trg_salary_alert_update
AFTER UPDATE OF salary ON employee -- E: 事件 = 修改工资列
WHEN NEW.salary < NEW.min_salary -- C: 条件
BEGIN -- A: 动作
INSERT INTO alert_log(emp_name, message)
VALUES (NEW.name, '工资 ' || NEW.salary || ' 低于下限 ' || NEW.min_salary);
END;
-- 正常插入：工资 8000 ≥ 下限 3000，条件不成立，不触发
INSERT INTO employee(name, salary, min_salary) VALUES ('张三', 8000, 3000);
-- 触发告警：工资 2500 < 下限 3000，条件成立，写入告警日志
INSERT INTO employee(name, salary, min_salary) VALUES ('李四', 2500, 3000);
-- 查询告警日志
SELECT id, emp_name, message FROM alert_log;
-- 输出:
-- 1|李四|工资 2500.0 低于下限 3000.0
（说明：SQLite 的一个触发器只对应一种事件，所以分别建 INSERT 和 UPDATE 两个，两者 ECA 结构相同。NEW 表示新插入或更新后的行；-- 输出: 后是预期结果。想动手试，可粘贴进 sqlite3 命令行或 Python 的 sqlite3 模块。）
本例与 ECA 的对应关系：
| ECA 要素 | 在本例中的位置 | 含义 |
|---|---|---|
| E 事件 | AFTER INSERT ON employee / AFTER UPDATE OF salary |
"有人插入新员工 / 修改了工资列" |
| C 条件 | WHEN NEW.salary < NEW.min_salary |
新工资低于下限才管，否则当没发生 |
| A 动作 | INSERT INTO alert_log ... |
自动记下"谁、多少"，供后续处理 |
⚠️ 常见错误
- 把"事件"当"条件"：事件是"操作发生了"（INSERT 执行了），条件是"发生后要不要管"（工资是否低于下限）。事件在前、条件在后。
- 忽略
AFTER与BEFORE的差别：AFTER在新值写入后触发，适合记录告警；BEFORE在写入前触发，适合校验拦截。选错时机行为就错。 - 触发器写成死循环：如果动作里又去修改触发它的同一张表，可能无限触发。让动作作用于另一张表（如本例的告警日志）就能绕开。
6.5 数据挖掘概述 ⭐
在矿山里"筛出金砂"
数据挖掘（data mining）是在海量数据中自动发现潜在、有用、先前未知的模式与规律——像淘金者从砂石里筛出金砂。它不回答"表里存了什么"（那是查询），而回答"数据背后藏着什么规律"。本模块介绍三种经典方法。
① 分类（classification） ⭐：事先给定若干已知类别，让模型从带标签的历史样本学规则，把新样本归入其中一个类别（有监督）。例子：银行用标好"按时还 / 违约"的历史记录训练模型，对每个新贷款客户判定"低风险 / 高风险"。关键是有"老师"——标签预先存在。
② 聚类（clustering） ⭐：事先不知道类别，只依据样本之间的相似度把数据自动分成若干组，做到"组内相似、组间相异"（无监督）。例子：电商按购买行为自动把顾客分成"高频回购型""价格敏感型""新品尝鲜型"——没人预先定义这三类，是算法自己分出来的。与分类的关键区别：分类有老师（标签），聚类没有。
③ 关联规则（association rule） ⭐：发现"买了 A 也常常买 B"这类共现规律，写成 A → B，常用支持度（A 和 B 同时出现的比例）与置信度（买了 A 的人中又买 B 的比例）衡量。例子：经典购物篮分析——超市发现"买啤酒的顾客中很多也买尿布"，于是把两者放相邻货架；再如"买手机"→"买手机壳"。注意它只说明"常一起出现"，不自动证明因果。
💡 记忆口诀：分类是"对号入座"，聚类是"物以类聚"，关联是"出双入对"。
⚠️ 常见错误
- 混淆分类与聚类：分类有预设标签（有监督），聚类没有（无监督）。看到"按已知类别归新样本"是分类，看到"自动分成几组"是聚类。
- 把关联当因果："啤酒与尿布"只是统计共现，不代表"啤酒导致买尿布"。挖掘结论必须结合业务验证。
- 以为挖掘结果一定正确：挖掘出的是统计规律，可能有噪音、可能过拟合（训练数据上好、换新数据失效），需要评估验证。
6.6 大数据技术应用 ⭐
当数据多到"一张表装不下"
前面谈的数据都还在"一张表"的范畴。当数据的量、速度、种类都超出现有工具的处理能力时，就进入大数据的地盘——好比家里书架换成了图书馆，单靠一本登记册管不过来，必须换成"分馆 + 编目系统 + 专门管理员"这套架构。
大数据 4V 特征 ⭐：
| 特征 | 英文 | 含义 | 例子 |
|---|---|---|---|
| 规模 | Volume | 数据量巨大，常以 TB/PB 计 | 一天新增数亿条用户访问日志 |
| 速度 | Velocity | 产生与处理速度快，要求实时或近实时 | 股票行情、监控告警每秒写入 |
| 多样 | Variety | 类型多样：结构化、半结构化、非结构化 | 文本、图片、视频、JSON 日志并存 |
| 价值 | Value | 总量大但单位价值密度低，需挖掘才体现价值 | 海量日志里只有极少数是故障信号 |
云计算与分布式存储：大数据靠"一个人扛不动，就一群人扛"。**云计算（cloud computing）**把计算与存储变成按需获取的服务（租虚拟机、租对象存储），好比"用电不用自己建发电厂"；**分布式存储（distributed storage）**把大文件切成数据块分散存储、保留多副本，防单机损坏丢数据。二者是承载大数据的地基。
Hadoop 生态简述 ⭐（记"三兄弟分工"）：
- HDFS（Hadoop Distributed File System，分布式文件系统）：管存。把大文件切成数据块、分散存储到集群并保存副本，解决"文件太大、怕单机损坏"。
- MapReduce（计算模型）：管算。"分而治之"的框架：Map（映射）把任务拆散并行处理，Reduce（归约）汇总中间结果。适合批量统计，如一天算完全站访问量。
- Hive（数据仓库工具）：管查。把 SQL 自动翻译成 MapReduce 作业，让写 SQL 的人也能处理大数据，是"SQL 翻译官 + 数据仓库"。
社交网络大数据应用举例：社交媒体上人与人的关系本身就是一张巨大的图，是大数据的典型舞台。常见应用：个性化推荐（据浏览与好友行为推内容）、热点话题发现（从海量转发识别突发词）、社群划分（按互动关系自动分组，对应 6.5 的聚类）、舆论与情感分析（从评论文本判别情绪）。前面的分布式存储、MapReduce、数据挖掘方法在此被组合成整体方案。
💡 记忆口诀：4V 记"量大、快、杂、值"；Hadoop 三兄弟记"HDFS 存、MapReduce 算、Hive 查"。
⚠️ 常见错误
- 漏记或替换 4V：4V 是 Volume / Velocity / Variety / Value。有扩展说法会加"真实性 Veracity"，但本模块以教材主线的 4V 为准。
- 以为大数据就是"数据量大"：量（Volume）只是四分之一，速度、多样、价值同属 4V，缺一不可。
- 混淆 HDFS 与 MapReduce 的职责：HDFS 管"存"、MapReduce 管"算"、Hive 是"SQL 查询入口"。分工不同，别张冠李戴。
🧠 记忆口诀
- 数据 → 信息 → 知识：原料 → 加工品 → 配方。
- 四种知识表示：产生式"如果就"、语义网络"一张图"、框架"一张表"、本体"共识词典"。
- 知识库系统 = 知识库（仓库）+ 推理机（大脑）+ 维护工具（管家）。
- ECA = 事件（啥时管）→ 条件（管不管）→ 动作（怎么管）。
- 数据挖掘三兄弟：分类"对号入座"、聚类"物以类聚"、关联"出双入对"。
- 大数据 4V：量大、快、杂、值。
- Hadoop 三兄弟：HDFS 存、MapReduce 算、Hive 查。
⭐ 考点清单
- 数据、信息、知识的定义与递进关系（能举例区分三者）
- 四种知识表示方法：产生式规则、语义网络、框架、本体——各一句话定义 + 例子
- 知识库 vs 传统数据库：存知识/规则 vs 存数据；检索 vs 推理
- 知识库管理系统组成：知识库 + 推理机 + 维护/交互工具
- ECA 规则三要素（事件 / 条件 / 动作）及其与触发器（trigger）的对应关系
- SQLite 触发器体现 ECA 的机制（
AFTER/WHEN/BEGIN...END分别对应什么） - 数据挖掘三种方法：分类、聚类、关联规则（定义 + 例子 + 分类与聚类的区别）
- 大数据 4V：Volume / Velocity / Variety / Value
- 云计算与分布式存储的基本思想
- Hadoop 生态：HDFS（存储）、MapReduce（计算）、Hive（SQL 查询入口）
- 社交网络大数据的典型应用场景
📌 中英术语表
| 中文 | English | 记忆点 |
|---|---|---|
| 数据 | data | 原始符号 |
| 信息 | information | 有语义的数据 |
| 知识 | knowledge | 可用于决策的规律 |
| 知识表示 | knowledge representation | 把知识结构化 |
| 产生式规则 | production rule | IF-THEN |
| 语义网络 | semantic network | 节点 + 带标签的弧 |
| 框架 | frame | 槽与槽值 |
| 本体 | ontology | 领域共识规范 |
| 知识库 | knowledge base（KB） | 事实 + 规则 |
| 推理机 | inference engine | 推导新结论 |
| 正向推理 / 反向推理 | forward / backward reasoning | 从事实推 / 从目标倒推 |
| 主动数据库 | active database | 主动响应事件 |
| ECA 规则 | Event-Condition-Action rule | 事件-条件-动作 |
| 触发器 | trigger | ECA 的 SQL 实现 |
| 数据挖掘 | data mining | 从数据中发现规律 |
| 分类 | classification | 有标签，对号入座 |
| 聚类 | clustering | 无标签，物以类聚 |
| 关联规则 | association rule | 买 A 常买 B |
| 购物篮分析 | market basket analysis | 啤酒与尿布 |
| 支持度 / 置信度 | support / confidence | 关联规则的度量 |
| 大数据 | big data | 4V |
| 云计算 | cloud computing | 按需获取计算资源 |
| 分布式存储 | distributed storage | 分块存储、多副本 |
| HDFS | Hadoop Distributed File System | 分布式文件系统 |
| MapReduce | MapReduce | Map 拆 / Reduce 合 |
| Hive | Hive | 把 SQL 翻译成 MapReduce |