利用美股行情接口的实时盘口深度，搭建动态订单簿失衡 OBI 指标
展开
平时研究美股的时候，我过去大多惯看 K 线、看成交量，等价格涨完跌完之后，再回头去复盘行情发生了什么。相信不少做美股的朋友也是这套思路。
后面接触了实时盘口深度数据之后才意识到，很多短期行情异动，在 K 线价格还没体现出来的时候，盘口挂单的结构已经发生变化。买卖盘挂单的多寡、盘口深度的倾斜程度，往往可以反映短时间场内多空力量的博弈情况。
这也是我会去研究美股 API 实时深度数据的缘由。单纯看价格，只能看到博弈的结果；而订单簿，可以看到博弈的全过程。订单簿失衡指标（OBI），就是盘口分析里面很实用的一个工具。
一、订单簿失衡 OBI 到底怎么算OBI 的逻辑并不复杂，本质就是对比买盘、卖盘挂单的体量差异。
基础计算公式：OBI =（买方挂单总量 − 卖方挂单总量）÷（买方挂单总量 + 卖方挂单总量）
举个简单例子，如果买盘深度 8000 股，卖盘深度 4000 股，算出来结果偏向正数，代表当下买盘力量更强。反过来卖盘挂单更大，数值就偏向负数。
OBI 接近 1：买方盘口深度占上风OBI 接近‑1：卖方抛压比较重OBI 接近 0：买卖双方力量相对均衡但实盘跑起来之后就会发现一个问题：直接固定取前几档盘口去计算，并不能适配所有行情。行情震荡平稳的时候，靠前几档的挂单基本可以反映盘面变化；可一旦行情波动加剧，更深档位的挂单，同样会左右短期资金情绪。所以实操中，要根据市场活跃度动态调整参与计算的盘口档位，指标才更贴合当下真实盘面。
二、实时盘口深度该怎么拿OBI 这个指标，对数据更新速度要求很高。
最开始我尝试过普通 HTTP 接口定时拉取盘口快照。这种方式拿来跑日线、低频回测没什么问题。但如果要观察秒级的盘口变动，提高请求频率之后，延迟高、数据断断续续的问题就全部暴露出来，经常丢快照。
后面就改用 WebSocket 长连接来接收实时数据流。建立连接之后就持续接收行情推送，不用反复发请求，更适合做盘口的实时监控。我自己做测试的时候，使用 AllTick API 获取美股的 Tick 与深度数据，以此来演算订单簿指标。
这里提醒一句：不同行情 API 返回的字段不一样，拿到之后要根据返回结构修改解析逻辑。而且做 7×24 小时挂机的时候，不能只写订阅接收逻辑，还要处理连接异常、本地数据缓存、断线自动重连，不然跑久了很容易出现数据空洞。
三、做动态 OBI，不能只看挂单数量
最刚开始写 OBI 脚本，我只简单拿买卖盘挂单的数字直接计算。实盘跑出来发现误判特别多。
美股盘口经常会出现一闪而过的大额挂单，也就是大家常说的虚单，挂出来并不是真想成交，用来干扰盘面。如果单纯只统计挂单量，指标很容易被这种临时大单带偏。
现在处理盘口数据，我一般会结合四个维度交叉验证：
挂单的持续时间：一闪就消失的大单，参考价值很低；真实成交量变化：挂单出现的同时有没有对应的成交放大；买卖盘价差：价差大小代表当下市场流动性好坏；主动成交方向：看主动吃买、主动砸卖的订单流向。比方说一笔大买单能够在盘口持续停留，同时成交量不断放大，这种信号可信度就会高很多。
另外一个工程上的坑：实时深度的数据量非常庞大。每收到一条盘口快照就直接写入数据库，读写压力会暴涨，脚本很容易变卡。
实际写代码，更推荐先把行情丢进内存队列做缓冲，先完成 OBI 指标运算，再按需持久化历史数据。既保障实时计算，回测需要的历史样本也可以保留下来。
四、个人实战感悟
折腾订单簿这一段时间，我对行情分析有了不一样的体会。K 线记录的是已经尘埃落定的结果，订单簿展示的却是当下多空正在博弈的过程。
但也要客观看待，OBI 只是一个辅助信号，不能单凭这一个指标去判定后市涨跌。实操一定要结合价格走势、真实成交、整体市场环境综合去看。
对于自己写脚本做美股量化的朋友来说，能够稳定拿到实时深度数据，仅仅只是第一步。真正考验人的，是如何利用这些原始盘口数据，打磨出适配自己交易模式的分析逻辑，让数据服务于自己的策略。
后面接触了实时盘口深度数据之后才意识到，很多短期行情异动，在 K 线价格还没体现出来的时候，盘口挂单的结构已经发生变化。买卖盘挂单的多寡、盘口深度的倾斜程度，往往可以反映短时间场内多空力量的博弈情况。
这也是我会去研究美股 API 实时深度数据的缘由。单纯看价格，只能看到博弈的结果；而订单簿，可以看到博弈的全过程。订单簿失衡指标（OBI），就是盘口分析里面很实用的一个工具。
一、订单簿失衡 OBI 到底怎么算OBI 的逻辑并不复杂，本质就是对比买盘、卖盘挂单的体量差异。
基础计算公式：OBI =（买方挂单总量 − 卖方挂单总量）÷（买方挂单总量 + 卖方挂单总量）
举个简单例子，如果买盘深度 8000 股，卖盘深度 4000 股，算出来结果偏向正数，代表当下买盘力量更强。反过来卖盘挂单更大，数值就偏向负数。
OBI 接近 1：买方盘口深度占上风OBI 接近‑1：卖方抛压比较重OBI 接近 0：买卖双方力量相对均衡但实盘跑起来之后就会发现一个问题：直接固定取前几档盘口去计算，并不能适配所有行情。行情震荡平稳的时候，靠前几档的挂单基本可以反映盘面变化；可一旦行情波动加剧，更深档位的挂单，同样会左右短期资金情绪。所以实操中，要根据市场活跃度动态调整参与计算的盘口档位，指标才更贴合当下真实盘面。
二、实时盘口深度该怎么拿OBI 这个指标，对数据更新速度要求很高。
最开始我尝试过普通 HTTP 接口定时拉取盘口快照。这种方式拿来跑日线、低频回测没什么问题。但如果要观察秒级的盘口变动，提高请求频率之后，延迟高、数据断断续续的问题就全部暴露出来，经常丢快照。
后面就改用 WebSocket 长连接来接收实时数据流。建立连接之后就持续接收行情推送，不用反复发请求，更适合做盘口的实时监控。我自己做测试的时候，使用 AllTick API 获取美股的 Tick 与深度数据，以此来演算订单簿指标。
这里提醒一句：不同行情 API 返回的字段不一样，拿到之后要根据返回结构修改解析逻辑。而且做 7×24 小时挂机的时候，不能只写订阅接收逻辑，还要处理连接异常、本地数据缓存、断线自动重连，不然跑久了很容易出现数据空洞。
三、做动态 OBI，不能只看挂单数量
最刚开始写 OBI 脚本，我只简单拿买卖盘挂单的数字直接计算。实盘跑出来发现误判特别多。
美股盘口经常会出现一闪而过的大额挂单，也就是大家常说的虚单，挂出来并不是真想成交，用来干扰盘面。如果单纯只统计挂单量，指标很容易被这种临时大单带偏。
现在处理盘口数据，我一般会结合四个维度交叉验证：
挂单的持续时间：一闪就消失的大单，参考价值很低；真实成交量变化：挂单出现的同时有没有对应的成交放大；买卖盘价差：价差大小代表当下市场流动性好坏；主动成交方向：看主动吃买、主动砸卖的订单流向。比方说一笔大买单能够在盘口持续停留，同时成交量不断放大，这种信号可信度就会高很多。
另外一个工程上的坑：实时深度的数据量非常庞大。每收到一条盘口快照就直接写入数据库，读写压力会暴涨，脚本很容易变卡。
实际写代码，更推荐先把行情丢进内存队列做缓冲，先完成 OBI 指标运算，再按需持久化历史数据。既保障实时计算，回测需要的历史样本也可以保留下来。
四、个人实战感悟
折腾订单簿这一段时间，我对行情分析有了不一样的体会。K 线记录的是已经尘埃落定的结果，订单簿展示的却是当下多空正在博弈的过程。
但也要客观看待，OBI 只是一个辅助信号，不能单凭这一个指标去判定后市涨跌。实操一定要结合价格走势、真实成交、整体市场环境综合去看。
对于自己写脚本做美股量化的朋友来说，能够稳定拿到实时深度数据，仅仅只是第一步。真正考验人的，是如何利用这些原始盘口数据，打磨出适配自己交易模式的分析逻辑，让数据服务于自己的策略。
主题股票：
主题概念：
声明：遵守相关法律法规，所发内容承担法律责任，倡导理性交流，远离非法证券活动，共建和谐交流环境！
