1. 特征工程概述
1.1 特征工程的定义
特征工程（Feature Engineering）是将原始数据转化为能够更有效表示问题本质、提升机器学习模型性能的特征表示的过程。在实时计算场景下，特征工程不仅涉及数据变换，还包含对无界数据流的窗口聚合、状态维护与时效性管理。
核心观点：数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限。特征工程正是决定这个“上限”高度的关键环节。
1.2 特征工程在机器学习中的重要性
特征工程直接影响模型的预测能力、泛化能力和训练效率。以下是特征工程在机器学习全流程中的关键作用：
| 维度 | 影响说明 | 典型问题（无特征工程） |
|---|---|---|
| 模型精度 | 高质量特征能显著提升 AUC、准确率等指标 | 原始数据噪声大、信息冗余，模型难以学习有效模式 |
| 训练效率 | 降维、离散化等操作减少特征维度，加速收敛 | 高维稀疏特征导致训练时间呈指数级增长 |
| 可解释性 | 构造的统计特征、交叉特征具有明确业务含义 | 原始高维特征难以解释模型决策逻辑 |
| 鲁棒性 | 归一化、异常值处理提升模型对数据波动的容忍度 | 量纲不一致导致模型偏向数值大的特征 |
| 实时性 | 实时特征工程保证模型在毫秒级响应最新数据 | 离线特征无法捕捉用户行为的瞬时变化 |
业界经验：在推荐系统和广告点击率（CTR）预估场景中，特征工程带来的效果提升往往超过模型结构优化带来的提升。Google、Meta 等公司的实践表明，特征工程投入占模型开发总工作量的 60% 以上。
1.3 实时特征与离线特征的区别
实时特征与离线特征在数据来源、计算模式、时效性要求和存储方式上存在本质差异。理解这些区别是构建实时特征生产链路的基础。
下表从多个关键维度详细对比实时特征与离线特征的差异：
| 对比维度 | 离线特征 | 实时特征 |
|---|---|---|
| 数据形态 | 有界、静态数据集（全量历史数据） | 无界、持续到达的数据流 |
| 计算模式 | 批处理（Batch），一次性扫描全量数据 | 流处理（Streaming），逐条或微批处理 |
| 延迟要求 | 分钟级到天级，无严格延迟约束 | 毫秒级到秒级，严格低延迟 |
| 状态管理 | 无需维护中间状态，每次全量计算 | 需要维护窗口状态、Keyed State 等 |
| 特征更新 | 周期性全量刷新，覆盖旧特征 | 增量更新，实时追加或替换 |
| 数据一致性 | 强一致性，可重跑保证精确结果 | 最终一致性，需处理乱序、迟到数据 |
| 存储选型 | HDFS、Hive、HBase | Redis、内存表、RocksDB |
| 典型框架 | MapReduce、Spark SQL、Hive | Flink、Spark Streaming、Kafka Streams |
常见误区：不要试图用离线特征工程的方法直接套用到实时场景。离线特征可以容忍全量扫描和复杂 Join，而实时特征必须考虑状态大小、背压控制和 Exactly-Once 语义。例如，离线中常用的“用户过去 30 天点击次数”在实时中需要维护滑动窗口状态，并处理窗口过期和状态清理。
1.4 实时特征生产面临的挑战
实时特征生产在工程落地时面临以下核心挑战：
- 状态爆炸：高基数 Key（如用户 ID、商品 ID）导致 Flink 状态后端存储压力巨大，需要合理设计状态 TTL 和 RocksDB 配置。
- 数据乱序与迟到：网络延迟、客户端时间偏差导致事件时间乱序，需要 watermark 机制和 allowed lateness 策略。
- 特征一致性保障：实时特征与离线特征在训练和推理阶段必须保持计算逻辑一致，否则会导致训练-推理偏差（Training-Serving Skew）。
- 端到端延迟：从数据进入 Kafka 到特征写入 Redis 的端到端延迟需要控制在 200ms 以内，对序列化、网络 IO 和状态访问提出极高要求。
- 容错与恢复：Flink 作业故障后，需要从 Checkpoint 快速恢复，同时保证特征状态不丢失、不重复。