3. 时间戳与数据生命周期
在另类数据工程中，“数据是什么时候的”往往比“数据是什么”更关键。同一笔电商订单、同一条招聘信息、同一份卫星影像，如果时间戳口径不同，回测结果可能从盈利变为亏损。Point-in-Time（PIT）对齐的本质，就是让每个数据点在“当时真实可被使用”的时间点上进入模型，而不是在事后被追溯修正的时间点上进入。要做到这一点，必须先厘清数据从产生到可用的完整链路中，五个核心时间戳的语义边界。
一、五个时间戳的核心定义
数据生命周期中，时间戳并非一个，而是一组。它们分别回答不同的问题：
- 事件时间（Event Time）：业务事实在现实世界中真正发生的时刻。例如用户下单的瞬间、职位发布的瞬间、卫星过境的瞬间。它是数据的“物理出生证”，通常由业务系统或传感器记录。
- 采集时间（Collection Time）：数据被采集方抓取、接收或感知到的时刻。例如爬虫请求返回的时间、API 回调到达的时间、Kafka 生产者发送的时间。它可能晚于事件时间数秒到数天。
- 处理时间（Processing Time）：数据进入计算引擎后被解析、清洗、转换、聚合的时刻。例如 Spark 作业开始处理该条记录的时间、Flink 算子处理该事件的系统时间。
- 入库时间（Ingestion Time）：数据被写入持久化存储（数据仓库、数据湖、特征库）的时刻。它标志着数据在物理上“落盘”，但未必可被查询。
- 可用时间（Available Time）：数据经过质量校验、权限控制、索引构建后，真正对下游用户或模型可查询、可读取的时刻。这是 PIT 对齐中最严格的约束点。
关键原则：在 PIT 特征工程中，任何特征在时间 t 的取值，只能使用“可用时间 ≤ t”的数据。事件时间、采集时间、处理时间、入库时间都不能直接作为可用性依据，只有可用时间才是最终裁判。
二、从产生到可用的完整链路
以一条电商评论数据为例，完整链路如下：
- 用户在 2024-06-01 10:00:00 提交评论（事件时间）。
- 爬虫在 2024-06-01 10:03:12 抓取到该评论（采集时间）。
- 数据进入 Kafka，Flink 作业在 2024-06-01 10:03:45 开始解析（处理时间）。
- 解析后的结构化记录在 2024-06-01 10:04:10 写入 Hive 表（入库时间）。
- 经过分区注册、质量校验、权限同步，该分区在 2024-06-01 10:15:00 对特征平台可见（可用时间）。
如果模型在 2024-06-01 10:10:00 做预测，那么这条评论不可用，因为可用时间晚于预测时间。若错误地使用入库时间或采集时间，就会造成前视偏差（Look-ahead Bias）。
三、时间戳错位的典型场景与后果
不同数据源的时间戳质量差异巨大，以下是三类高频问题：
| 场景 | 常见错误做法 | 后果 | 正确做法 |
|---|---|---|---|
| 财报数据 | 用报告期结束日作为可用时间 | 提前数月使用未公开数据 | 使用实际公告日或入库日 |
| 电商价格 | 用采集时间代替可用时间 | 忽略清洗延迟，引入未来信息 | 记录分区就绪时间作为可用时间 |
| 卫星影像 | 用事件时间（过境）直接对齐 | 忽略下载、预处理耗时 | 使用影像产品发布或入库时间 |
误区警示：很多团队认为“入库时间”就是“可用时间”，这是 PIT 泄漏最常见的根源。入库只代表数据写入了存储，但分区可能尚未注册、质量校验可能尚未通过、权限可能尚未同步。在特征平台中，必须显式维护一张“数据可用性元数据表”，记录每个分区真正可被查询的时间。
四、工程落地：可用时间元数据管理
要实现严格的 PIT 对齐，建议在数据链路中增加可用时间登记环节。以下是一个简化的元数据配置示例：
{
"dataset": "ecommerce_reviews",
"partition": "dt=2024-06-01/hour=10",
"event_time_range": ["2024-06-01T10:00:00Z", "2024-06-01T10:59:59Z"],
"collection_time": "2024-06-01T10:03:12Z",
"processing_time": "2024-06-01T10:03:45Z",
"ingestion_time": "2024-06-01T10:04:10Z",
"available_time": "2024-06-01T10:15:00Z",
"quality_status": "passed",
"pit_policy": "available_time_only"
}特征计算引擎在读取该分区时，必须校验 available_time <= prediction_time。若不满足，则跳过该分区或回退到更早的可用分区。这一条规则看似简单，却是防止前视偏差的最后一道闸门。
实践建议：对于高频另类数据（如舆情、招聘、App 排名），建议将可用时间粒度细化到小时甚至分钟，并在特征回填（Backfill）时严格按可用时间重放。任何“先入库后补时间戳”的操作，都必须在元数据中留下审计痕迹。
总结来看，事件时间回答“何时发生”，采集时间回答“何时被看到”，处理时间回答“何时被计算”，入库时间回答“何时被存储”，可用时间回答“何时能被用”。PIT 对齐只认最后一个。理解这五者的区别与链路关系，是构建无泄漏另类数据特征体系的第一块基石。