叠加:流 × 量化

面向量化研究的期权流 API

在实时 WebSocket 上设计流特征,再在历史 SQL 的同一字段语义上验证——减少研究与生产之间的训练/在线偏差。

适合谁:既需要实时期权成交流(日均约 1000 万),又需要 SQL 数仓(自 2025 年 2 月起 20 亿+ 成交),并要求 Greeks/IV/权利金语义一致的量化研究员。

在线特征 → 历史证明 → 生产

在流与 SQL 上保持权利金、delta 区间与剩余天数过滤的同一套定义。

在流上原型

用服务端过滤抽样大额权利金或短期限流,避免笔记本被全量成交淹没。

记录特征向量

按将要上线的同一公式持久化分钟线或事件特征(权利金、|delta|、IV)。

在 ClickHouse 回测

通过历史 SQL 回放多周窗口,并使用适合研究任务的行数/超时防护。

阈值原样上线

把过滤提升为生产 WebSocket 参数,并对照 SQL 基线监控漂移。

量化对流的特殊关切

  • SQL 与 WebSocket 字段的训练/在线一致性
  • AGGREGATED vs RAW 会影响扫单统计
  • 试用 SQL 有行数上限——认真回测请用正式套餐
  • 事件时刻用期权链快照提供曲面上下文
  • 在套餐条款下用于专业研究的 OPRA 授权成交
  • 另见:面向量化的期权数据 API 总览
示例:在 SQL 中验证实时权利金/情绪特征
-- Promote a live flow feature to historical validation
SELECT
  toStartOfMinute(timestamp) AS minute,
  sumIf(size * price * 100, sentiment = 'BULLISH') AS bull_prem,
  sumIf(size * price * 100, sentiment = 'BEARISH') AS bear_prem,
  avg(abs(delta)) AS avg_abs_delta
FROM RawOptionTrades
WHERE date = today() AND symbol = 'SPY' AND premium >= 50000
GROUP BY minute
ORDER BY minute;

面向量化的期权流常见问题

可以只用历史 SQL、不用实时流做研究吗?

可以。许多研究从 SQL 开始。叠加价值在于把同一特征提升到 WebSocket 而无需重定义字段。

AGGREGATED 模式会改变研究结果吗?

会。AGGREGATED 合并同时段同合约成交;RAW 保留每条交易所打印。从回测到生产请固定一种模式。

历史有多长?

OptionData 自 2025 年 2 月起保存期权成交——撰写时 20 亿+ 行——可通过 REST 上的 ClickHouse SQL 查询。

Greeks 是模型估计吗?

Greeks 与 IV 是在模型假设下的分析估计。应作为特征使用,而非对盈亏的保证。