2. 行情数据基础

行情数据是金融市场在交易过程中产生的、描述价格与成交状态的时间序列信息。它既是量化策略的输入原料,也是风控、监控、清算等系统的判断依据。理解行情数据的分类与传输方式,是设计Schema与兼容方案的前提——因为不同数据类型的字段结构、更新频率、语义约束差异极大,Schema演进策略也必须随之分化。

一、行情数据的定义与核心属性

从工程视角看,一条行情记录至少包含四个维度:标的标识(如股票代码、合约代码)、时间戳(交易所时间与本地接收时间)、价格与数量(最新价、成交量、买卖盘)、状态标记(是否集合竞价、是否停牌、是否涨停)。这四个维度构成了行情Schema的最小骨架,后续任何字段扩展都应视为对骨架的补充而非替代。

关键认知:行情数据不是“一张大表”,而是按更新频率和语义分层的数据流。逐笔、快照、K线、盘口分别对应不同的时间粒度和消费方式,混用会导致Schema设计失焦。

二、常见行情数据类型

按时间粒度与用途,行情数据可分为四类,它们在生产、传输和存储环节各有侧重:

类型时间粒度典型字段主要用途
逐笔成交每笔成交成交价、成交量、买卖方向、成交编号微观结构分析、滑点建模
快照固定间隔(如3秒)最新价、买卖五档、累计成交量行情展示、中频策略
K线1分钟/日线等开高低收、成交量、持仓量技术指标、趋势策略
盘口实时或快照附带买卖各档价格与挂单量流动性评估、订单簿重建

逐笔数据强调“事件驱动”,每条记录代表一次不可变的市场行为;快照强调“状态切片”,同一标的在相邻快照间可能丢失中间变化;K线是聚合结果,天然带有降采样误差;盘口则常作为快照的嵌套结构出现,其档位数量是Schema兼容中的高频变更点。

行情数据类型与数据流关系 逐笔成交 事件驱动 · 不可变 快照 状态切片 · 固定间隔 K线 聚合结果 · 降采样 盘口 嵌套结构 · 档位可变 传输协议层 TCP 组播 WebSocket FIX/FAST HTTP 轮询 典型应用场景 行情展示 量化策略 风控监控 订单簿重建

三、数据源与传输协议

行情数据源可分为交易所直连、第三方数据商和聚合平台三类。交易所直连延迟最低但接入成本高;第三方数据商(如Wind、聚宽)提供标准化接口但存在二次封装;聚合平台则常用于跨市场对比。传输协议的选择直接影响Schema的序列化方式:

  • TCP组播:交易所主流方式,吞吐高、延迟低,但需处理丢包与乱序,Schema通常为二进制定长或TLV格式。
  • WebSocket:互联网行情常用,文本或二进制帧,Schema多为JSON,字段名即键名,兼容性依赖字段可选性设计。
  • FIX/FAST:机构间标准协议,字段以标签号标识,Schema演进需维护标签字典版本。
  • HTTP轮询:简单但延迟高,适合非实时场景,Schema通常为JSON数组。

实战建议:在Schema设计初期就明确“字段是必选还是可选”。必选字段变更需版本升级,可选字段可平滑扩展。这一决策比具体序列化格式更影响长期兼容成本。

四、典型应用场景与Schema影响

不同应用场景对行情Schema的诉求差异显著。行情展示系统关注字段可读性与前端渲染效率,常要求快照中包含完整的盘口档位;量化策略关注逐笔数据的完整性与时间戳精度,对字段缺失零容忍;风控监控关注状态标记的实时性,如停牌、涨跌停标志必须第一时间更新;订单簿重建则要求盘口档位数量可动态扩展,且买卖方向不能混淆。

以订单簿重建为例,若交易所将盘口从五档扩展为十档,Schema必须支持档位数组长度变化。若采用固定字段bid1~bid5,则需新增bid6~bid10并保证旧消费者忽略新字段;若采用数组bids: [{price, volume}],则只需扩展数组长度,兼容性更好。这正是Schema演进中“结构选择决定兼容成本”的典型体现。

// 固定字段方案(兼容性差)
{
  "symbol": "600519",
  "bid1": 1800.0, "bid1_vol": 100,
  "bid2": 1799.5, "bid2_vol": 200,
  ...
}

// 数组方案(兼容性好)
{
  "symbol": "600519",
  "bids": [
    {"price": 1800.0, "volume": 100},
    {"price": 1799.5, "volume": 200}
  ]
}

五、常见误区与复盘

误区一:认为“快照就是逐笔的聚合”。实际上快照是交易所按固定间隔推送的状态切片,可能丢失间隔内的多笔成交,二者不可互相推导。

误区二:忽视时间戳的时区与精度。交易所时间、本地接收时间、业务处理时间三者混用,会导致回测与实盘信号错位。

误区三:盘口档位写死。档位数量是交易所规则变更的高频点,Schema应预留扩展能力。

复盘上述误区,核心结论是:行情Schema的设计必须建立在对数据类型的正确认知之上。逐笔、快照、K线、盘口各自承载不同的语义,传输协议决定了序列化边界,应用场景则反向约束字段的必选性与扩展性。只有先厘清这些基础,后续的Schema演进与兼容处理才有稳固的出发点。