📚 课程目录第4章金融数据源与特征类型

4. 金融数据源与特征类型

在金融 Feature Store 的落地过程中，数据源与特征类型的划分决定了后续特征注册、血缘追踪、离线回填与在线服务的整体架构。金融场景的数据天然具有多源、异构、时序性强、噪声大、合规要求高等特点，如果一开始不把数据源和特征类型梳理清楚，后续很容易出现特征口径不一致、线上线下不一致、重复计算等问题。本节将围绕行情数据、交易数据、用户行为数据、基本面数据以及衍生特征五大类，建立一套可落地的分类框架。

一、核心原理：为什么金融特征要按数据源分类

特征的本质是“从原始数据中提取出的、可供模型直接使用的数值或向量”。在 Feature Store 中，特征不是孤立存在的，它必须绑定到具体的数据源、计算逻辑、更新频率和实体主键。金融领域的数据源差异极大：行情数据是高频时间序列，交易数据是事件流，用户行为数据是埋点日志，基本面数据是低频结构化报表。它们的采集方式、更新节奏、存储介质、质量约束完全不同。

因此，按数据源分类的核心原理有三点：

口径一致性：同一特征在不同数据源下计算逻辑可能不同，例如“用户活跃度”在交易数据中体现为下单频次，在行为数据中体现为登录次数，必须明确来源。
时效性匹配：行情数据要求毫秒级或秒级更新，基本面数据按季度更新，特征存储的 TTL 和物化策略必须与数据源节奏对齐。
血缘可追溯：当模型效果下降时，需要快速定位是哪个数据源、哪段计算逻辑出了问题，分类是血缘追踪的前提。

  在 Feature Store 中，建议为每个特征打上“数据源类型”标签，例如 source_type=market、source_type=trade、source_type=behavior、source_type=fundamental，衍生特征则记录其依赖的父特征列表。

二、五类数据源与特征映射

下面用一张表梳理五类数据源的核心对象、典型特征、更新频率与存储建议。这张表可以作为团队内部的特征分类基线。

数据源类型	核心对象	典型特征示例	更新频率	存储建议
行情数据	股票、期货、外汇、加密货币	收盘价、涨跌幅、成交量、波动率、买卖价差	毫秒～日级	时序数据库 / Parquet + 分区
交易数据	用户、账户、订单	下单金额、持仓集中度、换手率、盈亏比	秒～日级	数仓事实表 + 增量物化
用户行为数据	用户、设备、会话	登录频次、页面停留、点击率、搜索关键词	分钟～小时级	日志湖 + 流式聚合
基本面数据	上市公司、行业、宏观	市盈率、ROE、营收增速、资产负债率	季度 / 年度	关系型数据库 + 快照表
衍生特征	由上述特征组合计算	动量因子、波动率因子、用户价值分层、交叉特征	随父特征	特征视图 + 物化表

需要强调的是，衍生特征不是独立数据源，而是对前四类特征的再加工。在 Feature Store 中，衍生特征必须显式声明依赖关系，否则无法做正确的回填和一致性校验。

三、方法流程：从原始数据到特征注册

一个标准的金融特征工程流程可以拆解为以下步骤：

数据源接入：行情通过行情网关或交易所直连，交易数据来自订单系统，行为数据来自埋点 SDK，基本面数据来自财报接口或第三方数据商。
实体对齐：统一实体主键，例如 user_id、account_id、symbol、trade_date，确保跨源特征可以 join。
特征计算：离线用 Spark / Flink 批流一体计算，在线用 Redis / 特征服务做低延迟读取。
特征注册：在 Feature Store 中登记特征名称、数据类型、实体、数据源类型、更新频率、TTL、负责人。
一致性校验：对比离线与在线特征值，设置偏差阈值，例如 abs(offline - online) / offline < 1e-6。

# 特征注册示例（伪 YAML）
feature:
  name: user_30d_trade_amount
  entity: user_id
  source_type: trade
  dtype: float
  ttl: 30d
  owner: risk_team
  dependencies:
    - trade_order_fact
  online_store: redis
  offline_store: hive

建议在特征命名中体现数据源与时间窗口，例如 market_1d_return、trade_7d_order_cnt、behavior_30d_login_cnt，这样在排查问题时可以快速定位来源。

四、案例场景：用户价值分层特征

假设我们要构建一个“高价值用户”识别模型，需要融合多类数据源：

交易数据：近 30 天累计交易金额、交易笔数、平均持仓市值。
行为数据：近 7 天登录次数、行情页停留时长、自选股添加次数。
行情数据：用户持仓组合的 30 天波动率、最大回撤。
基本面数据：用户持仓股票的行业分布、平均市盈率。
衍生特征：用户价值分 = 交易金额分位 × 0.5 + 活跃度分位 × 0.3 + 持仓稳定性分位 × 0.2。

在 Feature Store 中，这些特征分别注册到不同数据源类型下，衍生特征通过依赖关系自动串联。当模型上线后，如果发现“用户价值分”分布异常，可以沿着依赖链逐层排查，快速定位是交易数据延迟、行为埋点缺失，还是行情波动率计算窗口错误。

五、误区与复盘

常见误区一：把衍生特征当作独立数据源。衍生特征必须声明依赖，否则回填时无法确定计算顺序，容易产生空值或错误值。

常见误区二：忽略数据源的时间语义。行情数据的“最新价”和基本面数据的“最新财报”时间粒度完全不同，混用会导致特征穿越（look-ahead bias）。

常见误区三：线上线下特征口径不一致。离线用 SQL 计算，在线用 Java 重写，逻辑稍有差异就会导致模型线上效果下降。建议用同一套特征定义 DSL，由 Feature Store 统一生成离线和在线计算逻辑。

复盘时，建议定期做特征血缘审计：随机抽取若干衍生特征，检查其父特征是否仍然有效、数据源是否仍在更新、TTL 是否合理。对于金融场景，还要特别关注合规要求，例如用户行为数据是否脱敏、交易数据是否满足审计留痕。只有把数据源分类和特征类型管理做扎实，Feature Store 才能真正成为金融模型迭代的基础设施。