数据源分析与评估：摸清家底才能动手
数据仓库建模，说白了就是个「数据搬运工」的活儿。但搬运之前，你得先搞清楚——搬的是什么？从哪搬？搬来的东西能不能用？
我个人习惯，在开始任何建模工作之前，先花一周时间做数据源调研。这一步省了，后面全是坑。我记得有个项目，业务方信誓旦旦说CRM数据很干净，结果一接入发现客户ID居然有三种编码规则……嗯，那感觉就像你打开冰箱发现鸡蛋全是坏的。
内部数据源：你的核心资产
内部数据源，就是公司自己产生的数据。通常我们关注三大类：CRM、ERP、日志。这三兄弟各有脾气，得分开伺候。
CRM系统：客户数据的源头
CRM存的是客户信息、销售线索、合同、服务记录。这东西看起来简单，但坑最多。
- 客户主数据：姓名、电话、邮箱、公司。我遇到过同一个客户在CRM里出现三次，因为销售录入时手抖多打了个空格。
- 销售流程数据：线索状态、商机阶段、成交金额。注意状态字段，很多CRM用中文枚举值，比如「已成交」「已关闭」，但不同团队可能写「成交」「关闭」——这就是不一致。
- 时间戳：创建时间、更新时间、最后联系时间。时区问题要小心，尤其是跨国业务。
ERP系统：业务运营的骨架
ERP管的是订单、库存、财务、供应链。这玩意儿数据量大，关系复杂，但质量通常比CRM好——毕竟跟钱挂钩，没人敢乱填。
| 数据域 | 典型表 | 常见质量问题 |
|---|---|---|
| 订单 | 订单头、订单行 | 订单状态缺失、金额精度不一致 |
| 库存 | 库存快照、出入库记录 | 库存数量为负数（超卖） |
| 财务 | 凭证、科目余额 | 借贷不平、科目编码变更 |
| 供应链 | 采购单、供应商 | 供应商编码重复、采购单价为空 |
ERP的数据模型通常很规范，但要注意——ERP的数据库表结构可能跟业务语义对不上。比如「订单状态」在数据库里存的是数字代码，你得找业务方要映射表。
日志数据：行为轨迹的宝藏
日志包括服务器日志、应用日志、用户行为日志。这东西量最大，价值也最高——但也是最脏的。
- Web日志：IP、URL、User-Agent、响应时间。注意IP可能是代理IP，User-Agent可能被伪造。
- 应用日志：接口调用、错误堆栈、业务事件。我见过一个系统把敏感信息（比如密码）直接打日志里——这不仅是质量问题，还是安全问题。
- 用户行为日志：点击、浏览、搜索、下单。埋点不规范的话，事件名称可能五花八门，比如「click_buy」和「buy_click」其实是同一个动作。
外部数据源：借力打力
光靠内部数据，很多时候不够用。比如你要做客户画像，得补充征信数据；要做竞品分析，得爬取公开信息。外部数据源主要分两类：第三方API和爬虫。
第三方API：稳定但有限
调用第三方API获取数据，比如天气、地理位置、企业工商信息、社交媒体数据。好处是数据质量有保障，坏处是——贵，而且有调用限制。
- 认证方式：、OAuth、。注意密钥管理，别硬编码在代码里。
- 限流策略：每秒多少次、每天多少万次。超限会被封，我有个项目就因为没做限流，一天把一个月配额用完了。
- 数据格式：JSON、XML、Protobuf。JSON最常见，但嵌套层级可能很深，解析时要小心。
- 响应延迟：API调用通常几十到几百毫秒。批量拉取时，建议用异步或并发，但别把对方服务器打挂了。
爬虫数据：灵活但麻烦
爬虫适合抓取公开网页数据，比如竞品价格、行业报告、招聘信息。但这事儿有法律风险，得先确认目标网站是否允许爬取。
- 反爬机制：IP封禁、验证码、动态渲染。我建议用代理池+随机User-Agent，但别太暴力。
- 数据解析：HTML解析（BeautifulSoup、XPath）、JSON解析。网页结构经常变，爬虫代码得定期维护。
- 数据去重：爬虫可能重复抓取同一页面，需要做URL去重或内容哈希去重。
- 增量更新：全量爬取太慢，建议只爬新增或变更的内容。可以用时间戳或ETag判断。
数据质量评估：别让垃圾数据毁了你的模型
数据源找好了，接下来就是评估质量。我一般从三个维度入手：完整性、一致性、准确性。这三个词听起来很学术，但说白了就是——数据全不全？格式统一不统一？值对不对？
完整性：有没有缺胳膊少腿
完整性检查的是数据有没有缺失。比如客户表里，手机号字段有20%是空的——这就不完整。
- 字段级完整性：每个字段的空值率。我一般设定阈值，比如手机号空值率超过5%就要预警。
- 记录级完整性：一条记录的关键字段是否都非空。比如订单记录，订单ID、客户ID、金额这三个字段必须都有值。
- 表级完整性：表与表之间的外键关系是否完整。比如订单表的客户ID，在客户表里找不到对应记录——这就是引用完整性缺失。
一致性：别搞「一个客户多个名字」
一致性指的是同一数据在不同地方是否保持一致。这是数据仓库建模最头疼的问题之一。
| 一致性类型 | 问题示例 | 解决方案 |
|---|---|---|
| 命名一致性 | CRM叫「客户」，ERP叫「顾客」 | 建立数据字典，统一术语 |
| 编码一致性 | CRM用「M/F」，ERP用「1/0」表示性别 | 做编码映射表 |
| 单位一致性 | 订单金额有的用元，有的用分 | 统一单位，或加单位字段 |
| 时间一致性 | 有的用UTC，有的用北京时间 | 统一转成UTC+0存储 |
你想想看，如果客户ID在CRM和ERP里对不上，你做的客户360视图就是笑话。我建议在数据接入阶段就做一致性校验，别等到建模了才发现。
准确性：数据到底对不对
准确性是最难评估的，因为你需要一个「标准答案」来对比。比如订单金额，你从ERP拿到的数据，跟财务系统对一下，看是否一致。
- 业务规则校验：比如订单金额不能为负数，库存数量不能超过仓库容量。
- 统计分布校验：看数据的均值、中位数、标准差是否在合理范围内。比如某天订单量突然暴涨100倍——可能是数据重复，也可能是双十一。
- 交叉验证：用不同数据源的数据互相验证。比如CRM的客户数跟ERP的客户数对比，差异超过5%就要查原因。
数据源评估框架：一张图说清楚
说了这么多，我画个图帮你理清思路。数据源分析与评估，核心就是三个步骤：识别数据源、评估质量、记录元数据。
这张图展示了我做数据源评估的完整流程。从左到右，先识别数据源类型，再深入每个数据源的具体内容，最后做质量评估，输出评估报告和元数据。每一步都不能跳过。