数据管道中的模式漂移与语义漂移

在本文的后续部分，我们将使用两个术语：数据形态和数据含义。数据形态指的是数据集中的字段、这些字段的路径以及它们所包含的值类型。模式检测器通过检查每个字段及其对应的值类型来获取这些信息。

def walk(obj, prefix, schema):
    for key, value in obj.items():
        field = f"{prefix}{key}"
        if isinstance(value, dict):
            walk(value, field + ".", schema)
        else:
            schema.setdefault(field, set()).add(type(value).__name__)

对于基线情况，这种检测方法会返回如下形式的结果：acquired_at: {'str'}、equipped_slot: {'NoneType', 'str'}以及attributes.durability: {'int'}。

然而，数据含义还包括字典中未包含的所有信息，例如数值的单位、时区、预期取值范围、有效的字符串集合，以及空值的代表意义。由此可见，任何仅关注数据形态的检测工具都存在局限性。由于模式检测器是根据字段路径和数据类型的字典来生成结果的，因此它无法区分那些虽然生成了相同的字典，但实际包含的意义不同的数据集。

在九种变化情况中，有三种并没有改变这个字典的结构：时区调整、新的枚举值以及耐用性的变化。因此，模式检测器并没有对这些变化作出任何标记。

检测工具可以在不同层面上对数据进行分析：

1. 形态层面：检查哪些字段存在，以及它们所包含的值类型。
2. 值约束层面：检查单个数值是否遵循特定的规则，例如是否需要提供时区信息，或者某个字段的取值范围是否被限定在特定范围内。
3. 分布层面：将各种统计指标（如平均值、各类别所占的比例、空值的出现频率）与基线数据进行比较，从而发现数据中的变化。这种方法无需明确规定每个数值的具体含义，就能揭示数据的变化趋势。
4. 语义层面：检查数据实际代表的意义，包括单位、时区规则以及空值的含义。这些规则的确定需要基于对数据的深入理解，而且必须由生成和使用这些数据的人员或系统来制定。

前四种检测工具涵盖了前三种分析层次。然而，第四种分析层次超出了这些工具的能力范围——因为一个数据集可能在结构、单个数值以及统计分布方面都符合检测要求，但其实际含义却发生了变化。要真正理解数据的意义，我们需要一些仅凭数据本身无法获得的上下文信息。

结果矩阵

结果矩阵总结了四种检测工具对九种变化情况的反应情况。

for drift in ALL_DRIFTS:
    dst = ROOT / "data" / "drifted" / f"{drift.name}.jsonl"
    drifted_db = DB_DIR / f"{drift.name}.db"

    apply_drift(drift, BASELINE, dst)
    result = run_pipeline(dst, db_path=str(drifted_db))
    outcome = classify(result, baseline_db, drifted_db, drift.fields)

    detected = {
        det.name: det.check(str(BASELINE), str(dst))["detected"]
        for det in DETECTORS
    }

    rows.append((drift, outcome, detected, result.get("error")))

它显示了这些变更中哪些被检测到了，哪些被遗漏了，以及处理流程是失败了还是继续使用了错误的数据。

“是（仅此一项出现错误）”表示只有该检测工具发现了这一变更；“n/a”表示处理流程崩溃，因此没有数据被加载。

处理流程错误

严格检查模式的检测结果最好（9项变更中有7项被检测到），其次是模式差异检测（6项），宽松检查模式排在第三位（4项），统计分析模式的检测效果最差（2项）。

但是，每个检测工具都遗漏了一些变化。有三种变化仅被其中一个检测工具发现：严格模式的检测工具发现了时区变更，模式差异检测工具发现了level字段的变化，而统计分析工具则察觉到了数据持久性的调整。

检测数据结构的变化

在九种变化中，有五种改变了数据的结构。这些变化包括将rarity字段的名称更改、删除equipped_slot字段、添加guild字段、用数组替换stats对象，以及将level字段的类型从整数改为字符串。

模式差异检测工具发现了这五种变化中的全部五种；严格模式的检测工具发现了四种，而宽松模式的检测工具只发现了三种。这一事实表明，模式差异检测工具在检测结构变化方面最为有效。

在三种变化中，数据处理流程出现了故障，但其中一些错误信息比其他信息更有用。将rarity字段的名称更改时，会引发KeyError: 'rarity'错误，这个错误信息明确指出了哪个字段缺失了；而将stats对象替换为[attack, defense, speed]数组时，则会出现TypeError: list indices must be integers or slices, not str错误，这个错误信息虽然说明了错误的类型，但并没有指出具体是哪个字段出了问题。要想找出问题的根源，就需要仔细分析相关的处理代码。

分类器会特别突出显示第一种错误；而confusing.It工具则通过检查错误信息中是否提到了受到变化的字段来区分这两种错误。

if result["status"] == "error":
    error_text = result["error"].lower()
    names_cause = any(f.lower() in error_text for f in drift_fields)
    return {
        "label": "failed_loudly" if names_cause else "failed_confusingly",
        "rows_affected": None,
        "loss_cells": 0,
        "corrupt_cells": 0,
        "extra_rows": 0,
    }

Pydantic检测工具也在同一个文件上进行了检测，它们报告的错误信息是stats: Input should be a valid dictionary，这个错误信息直接指出了出问题的字段。

level字段类型的变更再次说明了为什么某些结构变化会无法被检测出来。两种Pydantic模型都接受了这种变化，因为Pydantic的默认设置会将字符串"42"自动转换为整数42；数据处理流程也接受了这种变化，因为SQLite在将数据插入INTEGER类型的列时，也会自动将看起来像数字的文本转换为整数。因此，数据库认为这些数据是符合要求的，分类器也就将这次处理结果标记为passed_clean。

只有模式差异检测工具发现了这种变化，因为它会在任何转换操作发生之前就检查原始数据的类型。这一事实再次说明了在数据被强制转换之后再进行检查的局限性：一旦数据类型发生了改变，原本的变化就无法再被察觉到了。在这个例子中，最简单的检测工具反而发现了一种两种Pydantic模型都忽略了的变化。

实验还表明，并非所有被检测到的变化都会引发问题。添加guild字段，或者将level的值从整数改为字符串，这两种操作都会触发警报。模式差异检测器能够识别出这两种变化，而严格模型则只能检测到添加guild这一变化。不过，这两种变化都没有损坏任何数据行，因为加载步骤只会读取它预期会存在的字段。

这凸显出了区分那些应该中断数据处理流程的变化与那些只需被记录下来的变化的必要性。如果检测器错误地标记了太多无害的变化，用户很可能会开始忽略这些警告信息。

语义变化：错误数据的具体表现形式

其余那些变化并没有改变字段的内容或数据类型，而是改变了这些数值所代表的含义。这类变化更难以被检测出来，但它们确实会对最终结果产生影响。下表展示了每种变化所带来的影响，以及这些变化是否会在数据处理流程的输出结果中体现出来。

我注意到的一点是，大多数数据的数值看起来仍然很正常。例如，将时间戳向前推进4小时，只会使某些物品的记录日期发生变化；由于4小时相当于1天的六分之一，因此大约有六分之一的物品会出现在不同的日期上。每一天都会有一些物品从当前日期转移到下一天，同时也会从前一天获得一些物品。

物品的总数仍然是1,000件，每日记录的数量变化也非常小。考虑到平均每天会有5.5件物品被记录下来，数量的变化幅度通常也就两三件而已。因此，从9件减少到6件，这种变化很容易被视为正常的波动，而不会被认为是数据问题。

由于没有物品丢失，数据处理流程的总行数检查仍然通过了。任何只比较总数的检查方法也都无法发现这个问题。虽然总数是正确的，但有些物品现在被记录在了错误的日期下。

我还研究了为什么数据处理流程没有报告这个问题。在发生这些变化之后，原始的时间戳2026-01-02T22:30:00+00:00变为了2026-01-03T02:30:00。新的时间戳没有时区偏移，因此datetime.fromisoformat会将其视为普通的日期时间格式进行处理。isoformat()方法在输出结果时也不会加上时区偏移。而SQLite的DATE()函数会将这种没有时区偏移的时间戳视为UTC时间，从而导致物品的记录日期变成了1月3日，而不是1月2日。

该处理流程在处理时间戳时没有出现任何错误，但将相关数据归入了错误的日期。如果生产者原本输入的是2026-01-03T02:30:00+04:00，那么这个时间戳所表示的时间其实与原始数据相同。SQLite会将其转换为UTC时间，但相关数据仍然会被计入1月2日这一天。