核心概念：离线特征与在线特征、特征组、特征视图、特征服务

在金融 Feature Store 的架构中，理解核心概念是构建高效、可靠特征工程流水线的基础。本章将深入剖析四个关键概念：离线特征与在线特征、特征组（Feature Group）、特征视图（Feature View）以及特征服务（Feature Service）。这些概念共同构成了特征存储的逻辑骨架，决定了特征从生产到消费的全生命周期管理方式。

1. 离线特征与在线特征

特征根据其计算与存储的时效性，分为离线特征与在线特征。两者在计算引擎、存储介质、延迟要求和使用场景上存在显著差异。

2. 特征组（Feature Group）

特征组是特征的逻辑集合，通常对应一个业务实体（如用户、设备、交易）或一个数据源表。它将一组在逻辑上紧密相关的特征聚合在一起，便于管理和复用。

• 实体绑定：每个特征组必须关联一个主键（Primary Key），例如 user_id、device_id、transaction_id。
• 时间戳：特征组通常包含事件时间戳（Event Timestamp），用于支持时间旅行（Time Travel）和点查询（Point-in-Time Query）。
• 版本控制：特征组支持 Schema 演进和版本管理，确保特征定义的变更可追溯。

# 特征组定义示例（Python DSL 风格）
feature_group = FeatureGroup(
    name="user_transaction_aggregates",
    entity="user_id",
    primary_key=["user_id", "event_date"],
    features=[
        Feature(name="total_transaction_amount_7d", dtype=Float64),
        Feature(name="transaction_count_7d", dtype=Int64),
        Feature(name="max_transaction_amount_7d", dtype=Float64),
    ],
    event_timestamp_column="event_date",
    online_enabled=True,  # 支持在线服务
)

3. 特征视图（Feature View）

特征视图是面向模型的特征抽象层。它从一个或多个特征组中选取特征，并定义特征的时间窗口、聚合逻辑以及特征与模型之间的映射关系。特征视图是模型训练和推理的直接数据源。

• 特征选择：从特征组中挑选模型所需的特征子集。
• 时间窗口：定义特征的时间范围（如近 7 天、近 30 天），确保训练和推理使用相同的时间逻辑。
• 特征变换：支持在视图层进行简单的特征变换（如归一化、分箱），但复杂变换建议在特征组层完成。

# 特征视图定义示例
feature_view = FeatureView(
    name="user_risk_features_v1",
    feature_groups=["user_transaction_aggregates", "user_profile_features"],
    features=[
        "user_transaction_aggregates.total_transaction_amount_7d",
        "user_transaction_aggregates.transaction_count_7d",
        "user_profile_features.credit_score",
        "user_profile_features.income_level",
    ],
    ttl=timedelta(days=30),  # 特征有效时间
    online_serving=True,
)

4. 特征服务（Feature Service）

特征服务是特征存储对外提供在线特征读取的接口层。它封装了特征视图的在线存储细节，提供低延迟、高并发的特征检索能力。特征服务通常暴露 gRPC 或 HTTP API，供在线推理服务调用。

• 批量获取：支持一次请求获取多个实体的多个特征，减少网络开销。
• 特征缓存：内置本地缓存（如 LRU Cache）和分布式缓存（如 Redis Cluster），降低后端存储压力。
• 降级策略：当在线存储不可用时，可降级到离线存储或返回默认值，保证服务可用性。

# 特征服务调用示例（gRPC 风格）
request = GetOnlineFeaturesRequest(
    feature_view="user_risk_features_v1",
    entity_keys=[
        EntityKey(entity_id="user_123"),
        EntityKey(entity_id="user_456"),
    ],
    features=[
        "total_transaction_amount_7d",
        "transaction_count_7d",
        "credit_score",
    ]
)
response = feature_service.get_online_features(request)
# 返回：{ "user_123": { "total_transaction_amount_7d": 15000.0, ... }, ... }

5. 概念关系与架构总览

以下 SVG 图展示了四个核心概念之间的层级关系与数据流向，帮助理解它们在 Feature Store 中的定位。

6. 金融场景中的概念映射

以“实时交易反欺诈”场景为例，展示上述概念如何落地：

7. 离线与在线特征的一致性保障

为了确保离线训练与在线推理的特征一致，Feature Store 通常采用以下机制：

• 同一份特征定义：特征组和特征视图的 Schema 在离线与在线之间共享，避免手工复制逻辑。
• 特征计算管道复用：使用同一套特征计算代码（如 Spark 作业）生成离线训练数据，同时将结果写入在线 KV 存储。
• 点查询验证：在模型上线前，对同一实体的离线特征与在线特征进行逐字段比对，确保数值一致。

# 离线-在线一致性校验示例（伪代码）
def validate_offline_online_consistency(entity_id, feature_view):
    offline_features = get_offline_features(entity_id, feature_view, timestamp="2025-01-15")
    online_features = get_online_features(entity_id, feature_view)
    for feature_name in offline_features.keys():
        if abs(offline_features[feature_name] - online_features[feature_name]) > 1e-6:
            raise ValueError(f"Feature {feature_name} mismatch: offline={offline_features[feature_name]}, online={online_features[feature_name]}")
    print("Consistency check passed.")

通过上述四个核心概念的清晰划分与协作，金融 Feature Store 能够同时支撑离线模型训练的高吞吐需求与在线推理的低延迟要求，成为金融科技中台的关键基础设施。