元数据卡
- 前置知识：编程基础（Vol 1）
- 预计时间：40 分钟
- 核心难度：入门
- 阅读模式：轻松漫游
- 完成标志：能够描述数据从产生到销毁的完整链路，并判断每个阶段的关键工程决策
从战报数据中提炼真金。我看到数据中藏着整个旅程的答案。
你的进度
你从咒术高塔出来，穿过一条长长的地下通道，走进了一座巨大的厅堂——数据预言厅。
大厅四壁挂满了发光的水晶屏幕，每块屏幕上都在显示不同的数字：战场各处的传感器读数、魔法驿道的通信流量、数据堡垒的查询日志、工匠之都的构建状态——整个系统的每一个角落都在持续不断地产生数据。
你看着这些流动的信息，意识到一个问题：数据来了，但然后呢？
你的任务
你手头有一批原始数据——来自系统日志、传感器读数、用户操作记录。它们散落在各处，格式不一，有些甚至已经损坏。你想从中提取洞察，但不知道从哪里开始。这一章帮你建立全局视角：数据要经过哪些阶段，每个阶段你该做什么、不该做什么。
数据的旅程
数据不是凭空出现的，也不会自己变干净。从产生到最终服务于决策，它经历一条明确的链路。理解这条链路，你才能在遇到具体问题时定位到正确的阶段。
一条数据生命周期的典型阶段：
- 采集（Acquisition）—— 数据从哪里来，怎么进来
- 传输（Transfer）—— 从源头到存储系统
- 存储（Storage）—— 怎么存、存多久
- 处理（Processing）—— 清洗、转换、聚合
- 分析（Analysis）—— 探索、建模、可视化
- 归档（Archive）—— 冷存储、长期保留
- 销毁（Destruction）—— 合规删除、安全擦除
你不需要每一步都线性执行。实际项目中，数据可能在采集后直接被分析，也可能在存储后被反复处理。但这张地图帮你回答一个关键问题：我现在在哪个阶段，下一步做什么？
阶段一：采集
这是数据的原点。采集的方式决定了你能拿到什么质量的数据。
最常见的采集模式有三种：
- 批量导入（Batch）：定期从外部系统拉取数据，比如每天凌晨从 MySQL 导出前一天的任务数据到 CSV，再用 Python 加载到分析环境。延迟高，但吞吐量大。
- 流式采集（Streaming）：数据一条一条地进来，比如用户点击行为通过 Kafka 实时发送。延迟低，但需要额外的基础设施。
- 日志采集（Log Ingestion）：通过 tail 文件、syslog、Fluentd 等工具收集服务器日志。这是最常见的"被动"采集方式。
# 批量采集——从 CSV 加载
import pandas as pd
# 你从外部系统拿到一批每日快照
df = pd.read_csv("missions_snapshot_2026-06-24.csv")
print(df.info())输出会显示列名、非空数量、数据类型。这是你第一次接触这批数据，也是你判断"脏不脏"的起点。
阶段二：传输
数据从源头到目标系统的路径。关键约束是：
- 带宽限制——网络不是无限快的
- 丢包和重试——传输过程中数据可能损坏
- 顺序保证——消息到达的顺序可能和发送时不一致
传输阶段最常见的问题是"数据丢了"。你在采集端发了 100 万条，到目标系统收到了 99 万条，剩下 1 万条去哪了？这种问题排查起来极其痛苦。一个经验规则：在传输的两个端点都做计数校验。
阶段三：存储
数据到了之后放在哪。你根据使用场景选择不同的存储系统：
| 存储类型 | 适合场景 | 典型工具 |
|---|---|---|
| 关系型数据库 | 结构化、需事务 | PostgreSQL |
| 数据仓库 | 分析查询、大表聚合 | ClickHouse, Snowflake |
| 对象存储 | 文件、备份、原始数据 | S3, MinIO |
| 列式存储 | 列式扫描、聚合 | Parquet |
| 缓存 | 高频读取 | Redis |
你的选择原则很简单：查询模式决定存储格式。如果你要经常按天聚合，就不要用行式存储；如果你要随机查单条记录，就不要用列式存储。
阶段四：处理
这是你花最多时间的阶段。处理包括：
- 清洗——补缺失值、去重、修格式
- 转换——字段拆分、类型转换、衍生字段
- 聚合——按时间/类别汇总
- 特征提取——为建模准备输入
这个过程通常要反复迭代。你发现一个清洗规则不够，加一条；你发现某个字段藏着异常值，再修一次。不是一次就能做好的。
阶段五：分析
数据已经被处理到可用状态。你现在可以问问题了：
- "数据量最大的任务类型是什么？"
- "成功率有没有周期性波动？"
- "某个指标在过去 30 天的趋势是什么？"
分析可以是探索性的（EDA），也可以是验证性的（假设检验、建模）。这个阶段你用 Jupyter Notebook、SQL 查询、可视化工具反复追问数据。
阶段六：归档
不是所有数据都需要随时能查。几个月前的历史数据，访问频率急剧下降。把它们移到更便宜的存储上，释放热存储空间。
归档的决策：
- 保留策略：原始数据保留 30 天，聚合数据保留 1 年
- 存储迁移：从 SSD 搬到 HDD 或 S3 Glacier
- 压缩：gzip / zstd 压缩后可减少 80% 空间
阶段七：销毁
数据不是永远保留的。合规要求（如 GDPR）规定某些数据必须在特定时间后删除。销毁不只是"删文件"——文件系统删除只是标记位，数据仍然可恢复。真正的销毁需要：
- 覆写（overwrite with random data）
- 加密删除（delete the key, data becomes unrecoverable）
- 物理销毁（粉碎硬盘）
并非每次都走完全流程
在实际项目中，你会遇到各种简化路径：
- 一次性的分析任务，从采集直接跳到分析，不需要归档
- 持续监控的数据管道，处理完就丢弃原始数据
- Debug 场景，你只从存储中拿出来看几行
这个生命周期模型是地图，不是强制路线。知道每条路的走向，你才能在岔路口做选择。
常见陷阱
- 跳过传输校验。源头 1000 行，目标 999 行——你觉得无所谓，但那个缺失的行可能是关键异常数据。
- 存储格式选错。把需要按列扫描的数据存成 JSON，查询慢 10 倍。
- 太早归档。你刚归档了一批数据，第二天就要查它——等解压的 20 分钟会让你后悔。
- 从不考虑销毁。数据存了五年，违规了，你才发现没有安全删除的工具。
通关挑战
- 热身：列出你过去一周接触过的数据，它们经过了生命周期的哪些阶段？
- 挑战：拿一个真实数据集，跟踪它从原始 CSV 到分析报告的全过程。记录每个阶段花了多长时间。
- 观察：在一个已有的数据处理管道中，找出缺失的传输校验点。
验收标准
- 能画出一条数据从采集到销毁的完整链路
- 能为一个给定场景选择正确的存储介质
- 知道数据销毁为什么不能只用
rm
旅人笔记
数据生命周期是地图。它不告诉你每一步怎么走，但它告诉你现在在哪、前面有什么。
下一站预告
有了全局地图，下一章我们弯下腰，面对实际数据中最棘手的环节——清洗。