4. 回放数据源准备：离线日志清洗、事件时间与处理时间对齐、数据分区策略
离线特征回放的第一步也是最关键的一步，是准备高质量的回放数据源。生产环境中的原始日志通常包含脏数据、延迟到达、时间戳错乱等问题，直接用于回放会导致特征计算结果与线上不一致。本节围绕日志清洗、时间对齐与分区策略三个核心环节展开，确保回放数据源具备完整性、时序一致性和可回溯性。
4.1 离线日志清洗：从原始日志到可回放记录
原始日志在采集、传输和落盘过程中会引入多种噪声。离线清洗的目标是过滤无效记录、修复可纠正字段、统一格式，最终输出结构化的回放事件表。
| 清洗类型 | 常见问题 | 处理策略 |
|---|---|---|
| 格式清洗 | JSON 解析失败、字段缺失、类型不匹配 | 丢弃解析失败行；对缺失字段填充默认值或 Null；强制类型转换并记录异常 |
| 去重清洗 | 同一条日志被重复写入（如重试机制导致） | 基于事件 ID + 时间戳做精确去重；保留最早到达的一条 |
| 范围清洗 | 时间戳超出合理范围（未来时间或过于久远） | 设定上下界阈值（如当前时间 ±7 天），超范围记录标记为异常并隔离 |
| 业务清洗 | 关键业务字段为空（如 user_id、item_id） | 根据业务规则填充或丢弃；无法填充的直接过滤 |
实践建议：清洗阶段应保留原始日志的完整副本，清洗后的数据写入新分区。不要原地覆盖，以便后续排查清洗逻辑是否正确。
4.2 事件时间与处理时间对齐
回放的核心要求是模拟线上特征计算时的数据视图。线上特征服务在收到请求时，只能看到该时刻之前已到达的事件。离线回放必须严格区分事件时间（Event Time）和处理时间（Processing Time），并按照处理时间对齐数据。
- 事件时间（Event Time）：业务发生的时间，通常由客户端或服务端在事件产生时记录，例如用户点击行为的发生时刻。
- 处理时间（Processing Time）：日志到达离线存储系统的时间，即数据被写入 HDFS 或 Hive 表的时间戳。
对齐策略：回放时以处理时间作为数据可见性的依据，即只使用处理时间 ≤ 回放时刻的事件。事件时间仅用于特征计算中的时间窗口聚合（如近 7 天点击次数），不用于决定数据是否可见。
关键原则：离线回放的数据可见性由处理时间决定，特征计算的时间窗口由事件时间决定。两者不可混淆。
下面展示事件时间与处理时间在回放流程中的对齐关系：
4.3 数据分区策略：支撑高效回放查询
离线回放通常需要按天或按小时回溯大量历史数据。合理的数据分区策略能大幅减少扫描量，提升回放效率。分区设计需兼顾查询模式和存储成本。
4.3.1 分区键选择
| 分区键 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| 处理时间（天） | 大多数离线回放场景 | 与数据可见性一致；回放时按天裁剪 | 跨天事件需扫描多个分区 |
| 事件时间（天） | 需要按业务时间回溯的场景 | 便于按事件时间聚合统计 | 与处理时间不一致，可能导致数据不完整 |
| 事件类型 | 多事件类型混合存储 | 快速过滤特定事件 | 分区数过多，小文件问题严重 |
| 复合分区（天 + 事件类型） | 大规模多类型事件回放 | 兼顾时间裁剪与事件过滤 | 分区数量膨胀，需控制粒度 |
4.3.2 推荐分区方案
对于大多数离线特征回放场景，推荐使用处理时间天级分区作为主分区键，配合事件类型作为二级分区（可选）。示例如下：
-- Hive 表分区示例
CREATE TABLE offline_replay_events (
event_id STRING,
user_id STRING,
item_id STRING,
event_type STRING,
event_time TIMESTAMP,
process_time TIMESTAMP,
extra_data MAP<STRING,STRING>
)
PARTITIONED BY (
dt STRING, -- 处理时间天级分区，格式 yyyy-MM-dd
event_type STRING -- 事件类型二级分区，如 click、expose、purchase
)
STORED AS PARQUET
TBLPROPERTIES ('parquet.compression'='SNAPPY');
注意：分区粒度不宜过细。小时级分区在数据量不大时会导致大量小文件，降低查询性能。建议日分区数据量超过 500GB 时再考虑小时级分区。
4.4 回放数据源准备流程总览
将上述三个环节串联起来，形成完整的回放数据源准备流程：
流程要点：清洗阶段输出干净事件 → 时间对齐阶段标记处理时间与事件时间 → 分区阶段按处理时间组织存储。每一步的输出都是下一步的输入，环环相扣。
4.5 常见问题与避坑指南
- 延迟数据处理：部分事件可能延迟数小时甚至数天才到达。建议在清洗阶段将延迟超过阈值（如 24 小时）的事件单独存储，不参与常规回放，仅在专项分析中使用。
- 时间戳时区问题：确保所有时间戳统一转换为 UTC 存储，避免因时区混用导致回放结果偏差。分区字段也建议使用 UTC 日期。
- 小文件合并：分区策略执行后，定期对小于 128MB 的文件进行合并，避免 HDFS 小文件过多影响读取性能。
- 数据校验：每次清洗和分区完成后，运行数据量校验（如行数、时间范围、关键字段非空率），确保数据质量符合预期。