2. 特征服务基础架构：分层架构、核心组件与数据流转
在归因稳定性巡检场景中，特征服务需要同时支撑高吞吐的在线推理、低延迟的近线补数据和海量的离线回溯。单一架构无法满足这三类需求，因此业界普遍采用在线 / 近线 / 离线三层分离的架构模式。每一层独立部署、独立扩缩，通过统一的元数据中心和存储层实现数据协同。
2.1 分层架构总览
三层架构的核心设计思想是：在线层追求毫秒级响应，近线层处理分钟级延迟的流式更新，离线层负责小时级或天级的批量回溯与训练样本生成。三层共享同一份特征定义（Feature Spec），但数据存储和计算引擎各自独立。
2.2 核心组件详解
每一层都由若干核心组件构成，这些组件协同完成特征的定义、生产、存储、服务、监控全生命周期。下表列出各层的关键组件及其职责：
| 层级 | 组件名称 | 核心职责 | 归因场景中的关键作用 |
|---|---|---|---|
| 在线层 | Feature Server | 接收推理请求，组装特征向量 | 实时查询归因特征，拼接用户/物料画像 |
| 缓存层 (Redis/Local) | 热数据缓存，降低存储压力 | 缓存高频归因特征，减少重复计算 | |
| 路由网关 | 请求分发、限流、降级 | 保障归因巡检高峰期服务稳定性 | |
| 近线层 | Stream Processor | 消费实时事件流，计算窗口特征 | 实时归因：点击→转化窗口内的特征聚合 |
| 消息队列 (Kafka) | 事件缓冲、解耦、重放 | 归因事件的有序传递与回溯 | |
| 近线存储 (HBase) | 存储分钟级更新的特征快照 | 提供近线归因查询，平衡延迟与一致性 | |
| 离线层 | Batch Processor | 批量计算历史特征 | 归因回溯：重新计算历史归因链路 |
| ETL 调度器 | 编排离线任务依赖 | 确保归因特征与标签对齐时间窗口 | |
| 特征仓库 (Hive/Iceberg) | 存储全量历史特征 | 归因稳定性巡检的基准数据集 |
2.3 数据流转路径
归因稳定性巡检的数据流转涉及三条主要路径，分别对应不同的时效性要求。理解这些路径是排查归因偏差的基础。
关键路径速览：
- 路径 A（在线实时）： 事件 → Kafka → Stream Processor → Feature Server → 在线推理 → 归因结果
- 路径 B（近线准实时）： 事件 → Kafka → Stream Processor → 近线存储 → 近线查询 → 归因结果
- 路径 C（离线回溯）： 历史事件 → Batch Processor → 特征仓库 → 离线查询 → 归因基准
2.4 分层架构的巡检意义
理解分层架构后，归因稳定性巡检的切入点就变得清晰：
- 在线层巡检： 重点检查缓存一致性、Feature Server 的请求成功率、特征版本是否与近线/离线对齐。归因偏差往往源于在线使用了过期特征。
- 近线层巡检： 重点检查流处理任务的延迟、Kafka 堆积量、窗口聚合的准确性。近线层是归因实时性的核心保障。
- 离线层巡检： 重点检查批量任务的数据完整性、特征仓库与在线/近线的数据一致性。离线层是归因回溯的基准。
实践建议： 在巡检系统中为每一层建立独立的监控仪表盘，并设置跨层数据对比任务。例如，每天对比在线层与离线层对同一时间窗口的归因特征分布，差异超过阈值即触发告警。这是发现归因稳定性问题的第一道防线。