数据模型设计：订单簿数据结构的核心要素

做量化交易，订单簿就是你的战场地图。我见过太多人一上来就写代码，结果数据结构设计得一塌糊涂，后面回测跑起来全是坑。今天咱们就把订单簿的数据模型聊透。

订单簿到底长什么样？

说白了，订单簿就是一个实时更新的价格-数量映射表。买方挂单和卖方挂单分别排成两列，价格从高到低（买盘）和从低到高（卖盘）排列。每个价格档位上，都有对应的挂单数量。

举个例子，比特币的订单簿可能是这样的：

买盘（Bid）	价格	卖盘（Ask）
12.5 BTC	30,100
8.3 BTC	30,050
	30,000	5.2 BTC
	29,950	10.1 BTC

嗯，这里要注意：买盘和卖盘的价格是错开的，中间那个价差就是spread。我刚开始做的时候，以为订单簿就是个简单的字典，后来发现完全不是那么回事。

核心三要素：价格、数量、时间戳

一个订单簿条目，最少需要三个字段：

• 价格：挂单的价格，浮点数。但要注意精度问题，我建议用整数存储（比如乘以10000），避免浮点误差。
• 数量：该价格上的挂单总量。可以是整数（股票）或浮点数（加密货币）。
• 时间戳：这条数据生成的时间。微秒级精度最好，因为高频场景下，同一毫秒可能有多笔更新。

你想想看，如果没有时间戳，你怎么判断哪条数据是最新的？我在项目中遇到过，某交易所的WebSocket推送偶尔会乱序，没有时间戳根本没法做数据对齐。

用Python的dataclass建模

Python的dataclass是建模利器。简洁、可读性强、自带类型提示。我个人习惯用它来定义所有数据模型。

from dataclasses import dataclass, field
from typing import List, Optional
from decimal import Decimal
from datetime import datetime

@dataclass
class OrderBookLevel:
    """订单簿单个档位的数据"""
    price: Decimal        # 价格，用Decimal避免浮点误差
    quantity: Decimal     # 数量
    timestamp: datetime   # 时间戳，微秒级
    
    def __post_init__(self):
        """初始化后校验数据"""
        if self.price <= 0:
            raise ValueError(f"价格必须大于0: {self.price}")
        if self.quantity < 0:
            raise ValueError(f"数量不能为负: {self.quantity}")

@dataclass
class OrderBookSnapshot:
    """订单簿快照，包含所有档位"""
    symbol: str                    # 交易对，如 "BTC-USDT"
    bids: List[OrderBookLevel]     # 买盘，按价格降序
    asks: List[OrderBookLevel]     # 卖盘，按价格升序
    timestamp: datetime            # 快照生成时间
    exchange: str = ""             # 交易所名称，可选
    
    def __len__(self):
        """返回总档位数"""
        return len(self.bids) + len(self.asks)
    
    @property
    def spread(self) -> Decimal:
        """计算买卖价差"""
        if not self.bids or not self.asks:
            return Decimal('0')
        return self.asks[0].price - self.bids[0].price

数据结构的演进：从简单到复杂

实际项目中，订单簿的数据结构会经历几个阶段：

1. 初级阶段：用两个字典分别存买盘和卖盘，key是价格，value是数量。简单粗暴，但更新效率低。
2. 进阶阶段：用有序字典（OrderedDict）或SortedDict，保证价格排序。我建议用sortedcontainers库的SortedDict，插入和删除都是O(log n)。
3. 高级阶段：用红黑树或跳表实现。Python标准库没有，但可以用bisect模块配合列表模拟。不过说实话，大部分场景用SortedDict就够了。

增量更新 vs 全量快照

订单簿有两种更新方式：

• 增量更新：只推送变化的部分。比如"价格30,000的买盘数量从5变成8"。优点是数据量小，但需要维护本地状态。
• 全量快照：每次推送整个订单簿。优点是简单，但数据量大，不适合高频场景。

我建议的做法是：用全量快照做初始化，然后用增量更新维护本地状态。每过一段时间（比如10秒）再拉一次全量快照做校验，防止数据漂移。

@dataclass
class OrderBookUpdate:
    """订单簿增量更新"""
    symbol: str
    bids: List[OrderBookLevel]     # 变化的买盘
    asks: List[OrderBookLevel]     # 变化的卖盘
    timestamp: datetime
    is_snapshot: bool = False      # 是否为全量快照
    
    def apply_to(self, book: 'OrderBook') -> None:
        """将更新应用到本地订单簿"""
        if self.is_snapshot:
            book.reset(self.bids, self.asks)
        else:
            for level in self.bids:
                book.update_bid(level.price, level.quantity)
            for level in self.asks:
                book.update_ask(level.price, level.quantity)

可视化：订单簿的核心逻辑

下面这张图展示了订单簿数据模型的核心关系：

这张图把整个数据模型串起来了。从快照到买卖盘，再到单个档位，层次非常清晰。我每次设计新系统时，都会先画这样一张图，确保数据结构没有遗漏。

实战中的几个坑

最后分享几个我踩过的坑：

• 价格精度：不同交易所的价格精度不一样。有的支持小数点后2位，有的支持8位。我建议统一用Decimal，并在初始化时指定精度。
• 数量为0的处理：有些交易所推送数量为0的更新表示删除该档位。有些则直接不推送。我建议统一处理：数量为0时删除该档位。
• 时间戳的时区：交易所返回的时间戳可能是UTC，也可能是本地时间。我建议全部转成UTC存储，展示时再转成本地时间。

好了，订单簿的数据模型就聊到这儿。记住：好的数据结构设计，能让后面的代码写起来行云流水。别急着写业务逻辑，先把数据模型想清楚。