数据类型与质量

分析结论是否可信，首先取决于 数据类型是否用对、质量是否过关。BI 分析师不必写 ETL，但必须能识别脏数据、缺失值与口径陷阱。

学习目标

• 区分结构化、半结构化与非结构化数据
• 识别常见数据质量问题及处理策略
• 了解 GDPR 与敏感数据在分析中的基本约束

核心概念

数据类型

类型	示例	BI 常见用法
结构化	MySQL 表、CSV	SQL 聚合、JOIN
半结构化	JSON 日志、API 响应	解析字段后入仓
非结构化	文本评论、图片	词频、标签、需 NLP 预处理

CodeRoadMap 的 cf_track、cf_lesson 是典型 结构化 OLTP 数据；用户行为日志往往是半结构化 JSON，需 ETL 展平后再分析。

数据质量维度

完整性 — 必填字段是否为空、时间范围是否断档
准确性 — 金额、计数是否与源系统对账一致
一致性 — 同一指标在不同报表口径是否相同
及时性 — 数据延迟是否影响决策（T+0 vs T+1）
唯一性 — 主键重复、一对多 JOIN 导致行膨胀

发现异常时：先查源表与 ETL 日志，再查 JOIN 条件与过滤逻辑，不要直接改数「凑结论」。

缺失值与异常值

• 缺失：区分「未采集」与「 genuinely 无值」；填 0、均值或留空会影响指标
• 异常：3σ 规则、IQR 法识别离群点；业务上确认是错误还是真实大单
• 重复：COUNT(*) vs COUNT(DISTINCT user_id) 差异即信号

合规与隐私

• 个人标识（邮箱、手机号）分析时需 脱敏或聚合
• GDPR：用户可请求删除；分析层需与删除策略同步
• 内部分享报表避免导出含 PII 的明细到公开渠道

练习

• 列举 3 种数据质量问题，并各写一种检测 SQL 思路
• 说明「LEFT JOIN 用户表后行数变多」可能的原因
• 设计 cf_lesson 表的完整性检查清单（至少 4 项）

小结

类型决定工具，质量决定可信度；BI 分析师是数据的第一道质检员。 下一课用描述统计与推断读懂分布与显著性。