2. 特征工程基础回顾：特征存储、特征计算模式与特征生命周期管理
在深入离线与实时特征一致性校验之前，必须夯实特征工程的核心基础。特征工程不仅仅是特征提取与变换，更涉及特征在生产系统中的存储、计算模式选择以及全生命周期的治理。本章将围绕这三个关键维度展开，为后续的一致性校验方法建立统一的认知框架。
2.1 特征存储：在线与离线存储体系
特征存储是特征工程的基础设施，决定了特征的访问速度、一致性和可用性。根据使用场景，特征存储主要分为离线存储与在线存储两大类。
| 存储类型 | 典型技术 | 核心用途 | 访问模式 | 一致性要求 |
|---|---|---|---|---|
| 离线特征存储 | HDFS、Parquet、ORC、Hive、Iceberg | 训练数据准备、批量回溯、历史分析 | 批量读取、全量扫描 | 最终一致性、高吞吐 |
| 在线特征存储 | Redis、HBase、Cassandra、DynamoDB | 实时推理、低延迟特征查询 | 点查、小批量读取 | 强一致性或读己之写 |
| 混合特征存储 | Feast、Tecton、自研特征平台 | 统一特征视图、离线在线一致性 | 双模式（批+流） | 可配置一致性级别 |
实践要点： 离线存储通常采用列式格式（如 Parquet）以压缩和加速分析查询；在线存储则优先考虑低延迟与高并发，Redis 的哈希结构是特征点查的常见选择。混合存储层（如 Feast）通过统一的特征视图（Feature View）抽象底层存储差异，是解决离线/在线一致性问题的关键基础设施。
2.2 特征计算模式：批处理 vs 流处理
特征计算模式直接决定了特征的时效性、计算成本与一致性难度。批处理与流处理并非互斥，现代特征平台通常采用 Lambda 架构或 Kappa 架构来融合两者。
2.2.1 批处理模式
- 计算窗口： 通常以小时、天或周为周期，对历史全量数据进行计算。
- 典型场景： 用户画像特征、统计聚合特征（如近7天点击率）、跨实体关联特征。
- 优势： 数据完整、易于回溯、计算成本可控、支持复杂逻辑（如多表 Join、窗口函数）。
- 劣势： 时效性差（分钟级到天级延迟），无法满足实时推理需求。
2.2.2 流处理模式
- 计算窗口： 基于事件时间或处理时间，以秒或毫秒级粒度持续计算。
- 典型场景： 实时点击率、实时交易风控、动态定价特征。
- 优势： 低延迟（秒级）、可感知最新数据变化、支持滑动窗口与计数。
- 劣势： 状态管理复杂、回溯困难、计算资源消耗高、数据乱序与迟到问题突出。
一致性挑战： 批处理与流处理使用不同的计算引擎（如 Spark Batch vs Flink Streaming），对同一特征（如“近1小时用户点击次数”）的计算逻辑、时间窗口边界、数据源状态可能存在差异，这是离线与实时特征不一致的主要根源。
2.3 特征生命周期管理
特征从定义到退役的全生命周期管理，是保障特征质量与一致性的核心治理活动。一个完整的特征生命周期包含以下阶段：
- 特征定义与注册： 在特征仓库（Feature Registry）中声明特征名称、类型、来源、计算逻辑、时间窗口等元数据。
- 特征开发与验证： 编写特征计算代码，在离线环境进行单元测试与数据质量验证。
- 特征部署与发布： 将特征计算任务部署到批处理或流处理流水线，并同步更新在线存储。
- 特征监控与告警： 持续监控特征值分布、延迟、缺失率、一致性指标（如离线 vs 实时差异）。
- 特征退役与清理： 当特征不再使用时，从在线存储中删除，并归档离线数据。
常见陷阱： 许多团队只关注特征开发与部署，忽略了特征监控与退役环节。未退役的“僵尸特征”会持续占用在线存储资源，并可能在模型推理时引入过时或不一致的特征值，导致模型效果下降。
2.4 特征存储与计算模式对一致性的影响
特征存储与计算模式的选择，直接决定了离线与实时特征一致性校验的难度与策略：
- 存储分离导致的数据漂移： 离线存储与在线存储使用不同的数据写入路径和时间点，容易产生数据版本不一致。例如，离线特征基于 T-1 的全量数据，而实时特征基于最近 5 分钟的增量数据。
- 计算引擎差异： 批处理引擎（如 Spark SQL）与流处理引擎（如 Flink SQL）对窗口函数、时间语义、状态管理的实现细节不同，即使逻辑相同，计算结果也可能存在微小偏差。
- 生命周期管理缺失： 缺乏特征版本管理与监控，导致特征变更后离线与实时未同步更新，产生系统性不一致。