1.2 数据分析生命周期

上一节建立了从决策、问题、证据到发现和行动的推理链。现在需要一套工作过程，在数据发生变化、缺陷逐渐显现、假设需要修改时仍能保住这条链。

数据分析常被画成一条直线流水线，实际却更像生命周期（lifecycle）：各阶段有先后关系，也有明确的回退路径。发现问题并回到前一阶段不是浪费工作，而是阻止缺陷最终变成自信结论的质量控制。

六个阶段及其产物

每个阶段都应产生一种产物（artifact），也就是不依赖分析者记忆、可以被他人检查的记录。

配送公司的原始导出文件可能叫 deliveries_2026-08-01.csv。应原样保留它，清洗时产生新的处理后数据，而不是默默覆盖证据。来源说明记录源系统、提取时间、筛选条件和负责人。这就是数据溯源（data provenance）：对数据来源及其历史的记录。

为什么生命周期会回退

假设探索时发现南区大量缺少配送时间。这不只是画图不方便，还可能让关键指标失效，因此分析必须回到理解、清洗与验证阶段。

不同发现会指向不同回退路径：

• 如果读者真正需要支持的是另一个决策，就回到问题定义。

• 如果某个重要群体从未被采集，就回到数据获取。

• 如果单位、时区、缺失或重复有误，就回到理解、清洗与验证。

• 如果两个输出对同一指标给出不同答案，就先检查转换和计算，再进行沟通。

• 如果结论会随合理定义发生剧烈变化，就缩小结论范围或收集更好的证据。

迭代过程应有明确记录：是什么发现触发了回退、修改了什么、哪些旧输出已经失效。否则，输入或指标改变后，旧图表可能仍混在报告中。

保留从原始输入到结果的链路

数据血缘（data lineage）是从来源经过各项转换直到输出的可追踪路径。一个小项目可以采用这样的结构：

delivery-analysis/
├── data/
│   ├── raw/          # 未修改的来源快照
│   └── processed/    # 可以重新生成的清洗数据
├── notebooks/        # 探索与解释
├── src/              # 可复用的读取与验证代码
├── reports/          # 生成的图表与摘要
└── README.md         # 问题、来源、环境和运行步骤

raw 目录不是“我当前正在使用的文件”，而是尽量接近来源原貌的保留副本。处理后文件应当是可丢弃的输出：即使删除，也能由代码根据原始输入重建。

面对每个关键结果，都可以问一个追踪问题：“这个数字由哪些来源记录、排除条件、转换步骤和指标定义产生？”如果无法重建这条路径，结果即使外观精美，也不具备可审计性。

区分探索与确认

探索阶段允许分析者了解数据内容、发现意外群体、尝试摘要并形成假设。这种自由很有价值，但也会带来风险：尝试许多定义后，偶然也可能出现一个醒目的模式。

有纪律的流程会记录探索选择，并将探索与验证性检查（confirmatory check）区分开来。验证性检查通常是在看到结果前预先指定，或者在新数据上重复。不是每张图都需要正式实验，但必须诚实说明某个发现是事先预期，还是尝试许多方案后才看到。

同样要记录没有明显结果的尝试。如果三个合理比较都没有差异，却只留下第四张戏剧性的图，工作历史就会误导读者。

下一节会放大观察多数分析的核心产物——数据集。使用 NumPy 或 pandas 之前，必须准确知道一行代表什么、每列是什么意思，以及一个数字究竟是可计算的数量，还是看起来像数字的标签。