02 · 一份数据集是怎么来的

⏱ 46 分钟 ｜ ⭐ 五种来源，五套坑

🎯 一句话

你手里那张表不是「数据」，是某个人为了另一个目的、在某个时刻、按某一版口径写下来的东西。 把它当成「客观记录」，是数据工作里最贵的一个误解 —— 尤其是埋点：它是产品团队写的，口径随时会变，而没人会通知你。

🧭 一、五种来源，一眼看清

🔑 一条贯穿全章的判断法： 拿到任何一列，先问 「这一列是为谁的 KPI 服务的？」 答案几乎从来不是「为你的模型」。 它服务谁，就会在谁需要的时候被改。

📜 二、业务日志：为对账写的，不是为你写的

业务日志通常是最"可信"的一类 —— 因为钱要对得上。但它的设计目标决定了三个坑。

怎么发现：

📡 三、埋点：本章的重点

埋点不是数据工程产的，是产品经理提需求、客户端开发写的。 它的生命周期完全由产品迭代驱动，而你的模型，不在任何人的考虑范围内。

3.1 埋点要穿过三层，每层都能改

3.2 埋点漂移的四种，按恶心程度排序

💀 「上报时机变化」是所有数据事故里最难查的一类： 字段名没变、类型没变、非空率没变、行数只是「少了一些」—— 所有自动校验全部通过， 而这一列的含义已经换了一个。

3.3 采样率：一个安静的乘数

🧪 四、口径指纹：抓「schema 没变但语义变了」

既然 schema 校验拦不住时机变化和采样变化，就需要另一套东西： 每天给每个关键字段拍一张「指纹」，然后比昨天。

import numpy as np
import pandas as pd

def fingerprint(df: pd.DataFrame, cols, day_col="dt"):
    """给每个 (日期, 字段) 算一组分布指纹。schema 不变但语义变了，会在这里露出来。"""
    out = []
    for day, g in df.groupby(day_col):
        for c in cols:
            s = g[c]
            rec = {"dt": day, "col": c, "n": len(s), "null_rate": s.isna().mean()}
            if pd.api.types.is_numeric_dtype(s):
                q = s.quantile([0.05, 0.5, 0.95]).values
                rec.update({"p05": q[0], "p50": q[1], "p95": q[2],
                            "zero_rate": (s == 0).mean()})
            else:
                vc = s.value_counts(normalize=True)
                rec.update({"n_uniq": s.nunique(),
                            "top1": vc.index[0] if len(vc) else None,
                            "top1_share": vc.iloc[0] if len(vc) else np.nan})
            out.append(rec)
    return pd.DataFrame(out)

def diff_fingerprint(fp: pd.DataFrame, ref_day, cur_day, tol=0.15):
    """比较两天的指纹，列出可疑变化。tol 是相对变化阈值。"""
    a = fp[fp.dt == ref_day].set_index("col")
    b = fp[fp.dt == cur_day].set_index("col")
    alerts = []
    for c in a.index.intersection(b.index):
        # ⭐ 绝对量的变化最能暴露"上报时机变了"——比率类指标会互相抵消，看不出来
        if abs(b.loc[c, "n"] - a.loc[c, "n"]) / max(a.loc[c, "n"], 1) > tol:
            alerts.append((c, "行数突变", a.loc[c, "n"], b.loc[c, "n"]))
        for k in ("null_rate", "p50", "p95", "zero_rate", "top1_share", "n_uniq"):
            if k in a.columns and pd.notna(a.loc[c, k]) and pd.notna(b.loc[c, k]):
                base = abs(a.loc[c, k]) + 1e-9
                if abs(b.loc[c, k] - a.loc[c, k]) / base > tol:
                    alerts.append((c, k, a.loc[c, k], b.loc[c, k]))
        # ⭐ 众数换人 = 枚举漂移或口径重定义，几乎从不是正常波动
        if "top1" in a.columns and a.loc[c, "top1"] != b.loc[c, "top1"]:
            alerts.append((c, "众数变了", a.loc[c, "top1"], b.loc[c, "top1"]))
    return pd.DataFrame(alerts, columns=["col", "signal", "ref", "cur"])

# 用法：fp = fingerprint(df, ["impression", "price", "channel"]); diff_fingerprint(fp, "2026-03-11", "2026-03-12")

⭐ diff_fingerprint 里最关键的设计是「看绝对量，不看比率」： 如果只监控 CTR，曝光口径收紧会让 CTR 变好看，你还以为模型进步了。 只有同时盯分子和分母的绝对值，才能看见分母被换掉。 （这条和 模型上线之后 11 的「分母变了」是同一件事的两端。）

✍️ 五、人工标注：唯一为你而生的数据，也是最贵的

💰 六、外购数据：三个必问，一个必查

一个必查：

🧬 七、合成数据：边缘像，联合不像

⚠️ SMOTE 有个几乎人人都踩的坑： 必须在训练集内部做，且在交叉验证的每一折内部做。 先 SMOTE 再切分 = 合成样本的"父样本"在训练集、"子样本"在验证集 → 指标虚高（第 6 章、第 14 章会详细说这个机制）。

（合成数据的完整讨论在 第 16 章。）

💀 八、事故复盘：曝光口径改了一行，模型偏了 19 天

发生了什么

为什么没被发现

怎么发现的

不是监控发现的。 是 3 月 31 日一个运营在群里问： 「为什么最近推荐的东西越来越水？」

代价

该补什么

⭐ 这个事故最该记住的一句话： 「指标变好了」从来不是「不用查」的理由。 在数据这一关，向上的跳变和向下的跳变同样危险 —— 而绝大多数监控体系只对向下的那一半设了告警。

🗺️ 九、一张来源溯源表（建议每个项目都建一份）

先沿一行追踪一个字段的来源，再看「最近变更」是否有待确认项。

⭐ 「最近变更」那一列如果写着“未知”，就是一个待办事项。

⭐ 这张表本身就是第 3 章数据契约的雏形，也是第 17 章血缘的人工版。

🔗 这一章连到哪里

✅ 检查点

1. 五种数据来源分别是什么？各自「为谁的 KPI 服务」？
2. 业务日志的三个坑是什么？为什么「状态表」不能直接当特征？
3. 埋点要穿过哪三层？每层分别能改什么、会不会通知你？
4. 埋点漂移的四种形态里，哪一种 schema 校验完全拦不住？为什么它最难查？
5. 采样率变化为什么危险？为什么「按 user_id 哈希采样」会让用户级特征看起来正常？
6. 口径指纹为什么要看绝对量而不是比率？diff_fingerprint 里哪两个信号最强？
7. 拿到一份人工标注要问哪六件事？哪两件决定天花板？
8. 外购数据的「一个必查」是什么？怎么查？
9. 合成数据的「真假判别器」检验怎么做？AUC 接近 1 说明什么？SMOTE 必须在哪里做？
10. 曝光口径那个事故：改了什么、连锁反应是什么、为什么六项校验全过、发现延迟多久、代价多少？最该记住的一句话是什么？

🛑 可以停在这里

⚡ 走神救援

⭐ 你手里那张表不是「数据」，是某个人为了另一个目的、在某个时刻、按某一版口径写下来的东西。

⭐ 判断法：问「这一列是为谁的 KPI 服务的」——它服务谁，就会在谁需要的时候被改，而那个人从来不是你。

业务日志三坑里最贵的一条：⚠️ 状态表存的是最终态不是当时态——直接拿「已退款」当特征就是用了未来。

⭐ 埋点是本章重点：它穿过客户端 SDK、采集层、数仓三层，而你看到的表是三层叠加的产物——⚠️ 表结构没变，不代表前两层没变。 漂移四形态里，改名和类型 schema 能拦，💀 而「上报时机变化」完全拦不住：字段名没变、类型没变、非空率没变，所有自动校验全过，含义却换了一个。

⚠️ 采样率是安静的乘数：按用户哈希采样会让用户级特征分布正常、全站聚合特征全错。

⭐ 对策是口径指纹：每天给每个字段拍一组分布数字然后 diff——关键是看绝对量不看比率（只看点击率的话，曝光口径收紧反而会让它变好看）。最强的两个信号是行数突变和众数换人。

⚠️ 外购数据必查一条：单独拿它训一个模型，如果单它一个就到很高的 AUC，⭐ 几乎一定是你的目标混进去了。

💀 那个事故：产品把曝光口径从「进入视口」改成「停留一秒」，字段名和类型全没改，而算法团队不在通知群里。

下一节 👉 03-数据契约.md