3. PSI 数据采集与预处理：数据源接入、清洗、归一化、时间窗口对齐

PSI（Page Speed Index）漂移告警的准确性，高度依赖底层数据的质量。原始 PSI 数据通常来自多个异构数据源（Lighthouse CI、CrUX API、RUM 探针），存在格式不一致、缺失值、时间戳抖动、量纲差异等问题。本章聚焦数据接入后的四个核心预处理环节，确保告警规则引擎的输入是干净、对齐、可计算的时序指标。

3.1 数据源接入与格式统一

不同数据源的 PSI 指标字段命名、单位、上报周期各不相同。接入层必须完成字段映射与类型转换，形成统一的内部指标模型。

3.2 数据清洗：缺失值、异常点与重复数据

原始 PSI 数据流中常见三类污染：缺失值（网络抖动导致上报丢失）、异常点（浏览器插件或缓存策略导致指标突变）、重复数据（重试机制导致同一时间戳多条记录）。清洗策略如下：

• 缺失值处理： 对于单点缺失，使用前向填充（forward fill）或线性插值；连续缺失超过 3 个窗口则标记为数据空洞，不参与漂移计算。
• 异常点检测： 基于 3σ 或 IQR 规则剔除离群值。例如 LCP 超过 10 秒或 CLS 大于 1.0 的数据点直接丢弃。
• 去重策略： 按 (metric_name, timestamp, source) 组合键去重，保留最新到达的一条记录。

3.3 数据归一化：消除量纲与分布差异

PSI 告警规则引擎通常需要将多个指标（LCP、FID、CLS、TBT）合并计算综合漂移分数。不同指标的量纲和数值范围差异巨大，必须进行归一化处理。

3.4 时间窗口对齐：固定窗口与滑动窗口

告警规则引擎要求所有 PSI 指标在相同的时间基准上进行比较。数据到达时间存在延迟（CrUX 数据通常滞后 24 小时），必须通过时间窗口对齐策略统一时间轴。

• 固定窗口（Tumbling Window）： 按 5 分钟、15 分钟或 1 小时切分，每个窗口内聚合均值或 P75 值。适用于实时 RUM 数据。
• 滑动窗口（Sliding Window）： 窗口长度 1 小时，滑动步长 5 分钟，保证每个数据点参与多个窗口计算，提升漂移检测的平滑度。
• 滞后对齐： 对于 CrUX 等延迟数据源，设置最大等待时间（如 36 小时），超时未到的数据标记为缺失，不阻塞当前窗口计算。

3.5 预处理质量监控与校验

预处理环节本身也需要可观测性。建议在管道中埋入以下监控指标：

• 数据到达率： 每个窗口实际到达数据量 / 期望数据量，低于 90% 触发告警。
• 清洗丢弃率： 被清洗的数据行数 / 总行数，超过 5% 说明上游数据源异常。
• 归一化边界溢出率： 归一化后值超出 [0,1] 或 [-3,3] 的比例，超过 1% 需重新校准缩放器。
• 窗口对齐延迟： 数据从采集到完成对齐的平均耗时，超过 2 分钟需排查管道瓶颈。