委托订单还原引擎使用最佳实践

深交所的逐笔委托数据能够完整记录进入撮合系统的委托。无论委托最终是否成交，逐笔委托表都会记录对应的原始委托信息。

因此，基于逐笔委托数据即可直接统计委托量、订单流等特征，无需额外关联逐笔成交数据来补全委托信息。

上交所对能够立即撮合的委托做了精简，具体分为以下两种情形。

情形一：委托提交后立即全部成交。此时上交所不会再发送原始委托记录，只保留对应的成交记录。

• 如图 1-1 所示，一笔委托量为 3,700 的买单（委托号 218,629）提交后，立即与市场上的 4 笔卖单（委托号分别为 204,322、34,204、137,957、210,374）完全成交。逐笔数据中会出现连续的 4 条成交记录（1300 + 1500 + 500 + 400 = 3700），但找不到委托量为 3,700 的原始委托记录。

情形二：委托提交后立即部分成交。此时逐笔数据中会先出现成交记录，再出现一条委托记录，且委托记录中的委托量是剩余未成交量，而非原始委托量；原始委托量等于成交量与剩余委托量之和。

• 如图 1-2 所示，一笔委托量为 2,000 的卖单（委托号 218,630）提交后，其中 531 股立即与市场上一笔买单（委托号 214,265）成交，剩余 1,469 股作为一条新的委托记录发送（该委托后续在 09:30:17 被撤单）。逐笔数据中同样找不到委托量为 2,000（531 + 1469）的原始委托记录。

很多高频指标需要统计过去一段时间市场新增的委托数量，例如：

• 最近 60 秒新增买单数量

• 最近 60 秒新增卖单数量

• 最近 5 分钟委托量波动率

这些指标关注的是订单到达情况，而不是最终是否成交。

如果逐笔委托数据中缺少立即成交的委托记录，基于原始数据直接统计就会低估实际的委托流入量。

因此，对于上交所数据，需要首先恢复这些缺失的委托，再进行统计分析。

输出表在输入表的基础上新增两个字段。具体示例见图 2-1，新增字段位于表格的最后两列。

表 2-1 新增字段说明表

其中，orderMark 用于区分不同来源的数据。

表 2-2 orderMark来源表

情形一：对于立刻且全部成交的委托单，会补上一条原始委托信息。

如图 2-1 所示，相比于原始数据，还原后的数据新增了一条委托量为 3,700（3700 = 1300 + 1500 + 500 + 400）的原始委托数据。

注：

• 最后一列 orderIndex 用于替代原来的数据中的 ApplSeqNum，作为通道内的单增序号列。ApplSeqNum 从 1 开始递增，而 orderIndex 从 0 开始递增，如图 2-2 所示。

• 还原具体步骤：

  • 引擎读到第一笔成交单（图 2-1 第二行 ApplSeqNum = 243,059），发现它是由一笔没有记录的委托单触发的。引擎通过 BuyNo 找到该委托对应的所有成交单，用这些成交单的成交量汇总还原出原始委托量。

  • 引擎还原一条委托量为 3,700 的原始委托，并将其插入当前 orderIndex 所对应的位置（即 243,058）。为了尽可能保留溯源信息，它的 ApplSeqNum 继承了触发它的第一笔成交单的值（243,059）。

  • 第一笔成交单的 orderIndex 顺延为 243,059，后续记录的 orderIndex 依次顺延。

• 由于是即时全部成交，还原的委托和原始的成交数据 orderMark 都为 1。

情形二：对于立刻部分成交的委托单，会补上一条原始委托信息，原来的剩余委托记录不再保留，因为它已经包含在恢复后的原始委托之中。

如图 2-3 所示，相比于原始数据，增加了一条委托量为 2,000（2000 = 531 + 1469）的原始委托数据，并减少了一条委托量为 1469 的部分委托数据。

注：

• 当一笔 2,000 股的卖单下达，并立刻与盘口的 531 股成交时，上交所原始数据流顺序是先推成交，再推剩余的委托，如图 2-4 所示：

  

  1. 先收到（ApplSeqNum = 243,063）：一笔 531 股的逐笔成交。

  2. 后收到 （ApplSeqNum = 243,064）：一笔 1,469 股的逐笔委托（这是扣除成交后的剩余委托）。

• 还原具体步骤：

  • 引擎将后收到的 1,469 股剩余委托，加上已知的 531 股成交，反推出了一笔 2,000 股的原始委托单。这条还原出的数据，保留了它原本作为剩余委托时的身份标识，即 ApplSeqNum = 243,064。

  • 引擎把较小的逻辑序号 orderIndex = 243,063 分配给还原的 2,000 股委托记录，使该委托记录在成交记录之前。

  • 引擎把较大的逻辑序号 orderIndex = 243,064 分配给 531 股成交记录。该成交记录原始的 ApplSeqNum 为 243,063，通过调整 orderIndex，确保还原的委托记录先于该成交记录。

• 输入数据：成交和委托的合并表

委托订单还原引擎的输入为一张同时包含逐笔成交和逐笔委托的数据表。

将逐笔成交、逐笔委托处理成相同的表结构可以存储到同一张输入表中。合并时新增 SourceType 字段区分消息来源：0 表示逐笔委托，1 表示逐笔成交。后续引擎会根据成交与委托之间的委托号关系，识别全部即时成交、部分即时成交等场景，并输出补全后的委托流。

• 完整的输入字段【必填】

输入数据至少需要包含以下 8 个字段。输入表中字段名可以自定义，只需要在创建委托还原引擎时需要通过 inputColMap 参数将引擎所需的逻辑字段映射到实际列名。

表 3-1 必选输入字段表

• 推荐保留字段【选填】

除了上述必须包含的 8 个字段外，输入表中可以冗余其他字段，并在输出表中一同输出。

比如 DolphinDB 中已有快照合成引擎，且快照合成引擎也是基于逐笔合并数据进行处理。上交所还原引擎的输出可以作为快照合成引擎的输入。

表 3-2 推荐保留字段表

• 规范的枚举值

上交所委托还原引擎对相关字段的枚举值有明确约定。输入表中的枚举值必须符合约定才能得到正确结果。比如 BSFlag 字段，约定 1 代表买方向， 2 代表卖方向。

• 单个引擎处理范围：对于同一个引擎，至多只能输入一天一个通道的全部标的

委托订单还原依赖成交与委托之间的委托号关系、通道内逐笔消息顺序，以及引擎维护的通道内状态。因此，输入同一个引擎的数据应来自同一交易日、同一通道号，并按通道内消息顺序写入。

时间范围：单个引擎实例只能处理一天的数据，不能跨交易日处理。如果需要处理多天数据，则需要每天重新创建引擎实例。

标的范围：单个引擎实例只能处理一个通道的数据。如果需要处理多个通道，则需要为每个通道分别创建引擎实例。

输入数据顺序：单通道内按 ApplSeqNum 按升序排序。

本节提供批量合并上交所逐笔成交和逐笔委托至同一张表中的示例。

输入数据

本节提供测试数据压缩包：SH20260429_db.zip，其中包含 2026.04.29 当天 2 支上交所股票的完整逐笔委托数据（SHorder）和逐笔成交数据（SHtrans）。

将数据压缩包上传至 DolphinDB 部署服务器并解压缩：

• 如果将数据文件夹放置在 DolphinDB 节点主目录下，可以直接运行示例脚本。可在 DolphinDB 客户端执行 getHomeDir() 查询节点主目录。例如 /home/user/DolphinDB/server/SH20260429_db 。

• 如果将数据放置在其他自定义目录，则需要修改示例脚本中的 sh_db 变量，将其设置为实际的数据目录后再运行脚本。

示例脚本

// 读取指定的磁盘目录下的数据，使用 getHomeDir() 拼接得到绝对路径
sh_db = getHomeDir() + "/SH20260429_db"

// 加载逐笔委托和逐笔成交表
SHorder = loadTable(sh_db, "SHorder")
SHtrans = loadTable(sh_db, "SHtrans")

// 创建合并表 SHOrderTrans
name = ["TradeDate","SecurityID","Time","SourceType","Type","Price","Qty",
        "BSFlag","BuyNo","SellNo","ApplSeqNum","ChannelNo","Market","ReceiveTime"]
type = ["DATE","SYMBOL","TIME","INT","INT","LONG","LONG",
        "INT","LONG","LONG","LONG","INT","SYMBOL","TIMESTAMP"]
SHOrderTrans = table(1:0, name, type)

// 指定枚举值的映射关系
orderTypeMap = dict(["S", "A", "D"], [-1, 2, 10])
BSFlagMap = dict(["B", "S"], [1, 2])

// 逐笔委托数据格式处理: 加载order表并处理为特定的表结构	
orderTemp = 
    select trade_date as TradeDate, 
        security_id as SecurityID, 
        trade_time as Time,
        iif(order_type=="S", -1, 0) as SourceType,  
        orderTypeMap[order_type] as Type,
        long(order_price * 10000) as Price,
        order_qty as Qty,
        BSFlagMap[side] as BSFlag,
        order_no as BuyNo,
        order_no as SellNo,
        appl_seq as ApplSeqNum,
        channel_no as ChannelNo,
        exchange as Market,
        update_time as ReceiveTime
        from SHorder
SHOrderTrans.append!(orderTemp)

// 逐笔成交数据格式处理: 加载transaction表并处理为特定的表结构
tradeTemp = 
    select 
        trade_date as TradeDate, 
        security_id as SecurityID, 
        trade_time as Time,
        1 as SourceType,
        0 as Type,
        long(trade_price * 10000) as Price,
        trade_qty as Qty,
        BSFlagMap[side].nullFill(iif(sell_no > buy_no, 2, 1)) as BSFlag, // side缺失时用买卖单号大小关系推断方向
        buy_no as BuyNo,
        sell_no as SellNo,
        appl_seq as ApplSeqNum,
        channel_no as ChannelNo,
        exchange as Market,
        update_time as ReceiveTime
    from SHtrans
SHOrderTrans.append!(tradeTemp)


// 处理逐笔数据的顺序: 按照 ApplSeqNum 进行排序
SHOrderTrans = select * from SHOrderTrans order by ApplSeqNum

• 逐笔委托数据处理说明：

  • 逐笔委托数据中包含产品状态信息，所以需要处理数据源字段。当 order_type="S" 时，表示该记录为产品状态，对应的 SourceType 设置为 -1，示例脚本中通过 iif(order_type=="S", -1, 0) 完成该处理。

  • 上交所委托类型通过 orderTypeMap 映射为统一编码：S 表示产品状态，映射为 -1；A 表示新增委托，映射为 2；D 表示撤单，映射为 10。

  • 上交所还原引擎要求输入价格列为整型。所以示例脚本中通过 long(Price*10000) 对价格做保留 4 位小数的处理。

  • 上交所逐笔委托数据中的 order_no 用于标识委托单的唯一编号，逐笔成交数据中的 buy_no 和 sell_no 分别对应买方和卖方委托单编号。原始委托数据中没有 buy_no 和 sell_no 字段，所以处理时使用委托数据中的 order_no 进行填充。

• 逐笔成交数据处理说明：

  • 上交所逐笔成交数据没有单独的成交类型字段，示例中将成交记录的 Type 统一填充为 0。

  • 上交所还原引擎要求输入价格列为整型。所以示例脚本中通过 long(Price*10000) 对价格做保留 4 位小数的处理。

  • 当成交记录中的 side 缺失时，示例使用 iif(sell_no > buy_no, 2, 1) 根据买卖委托号大小关系推断买卖方向，并通过 nullFill 补齐 BSFlag。

• 逐笔数据顺序处理说明：

  • 合并结果写入内存表 SHOrderTrans。由于委托还原引擎需要依赖同一通道内的逐笔顺序，后续输入引擎前应按交易日和 ChannelNo 过滤，并按 ApplSeqNum 升序排序。

如图 3-1 所示，逐笔委托与逐笔成交合并后生成 SHOrderTrans 表。

注：深交所逐笔委托数据已经完整披露，不需要、也不应写入上交所委托订单还原引擎。该引擎的处理逻辑针对上交所“立即全部成交不发送原始委托、立即部分成交只发送剩余委托”的发布规则设计；如果将深交所数据写入引擎，引擎会按照上交所规则尝试识别和改写委托流，导致输出数据与深交所原始逐笔数据不一致。因此，深交所数据只需按照统一字段口径完成标准化处理，后续可直接接入快照合成或因子计算流程。

在实时数据接入委托还原引擎时，必须保证逐笔成交和逐笔委托以交易所发送的真实顺序有序写入。

因此，实时输入数据处理可以概括为以下流程：

1. 在 DolphinDB 中创建共享流数据表，用于接收处理好的逐笔数据。表结构要求参考 3.1 章节。

2. 订阅共享流数据表，将合并后的逐笔数据实时写入委托还原引擎中。

3. 通过行情 SDK 同时订阅逐笔成交和逐笔委托数据，并将同一个通道的逐笔成交和逐笔委托数据写入同一张共享流数据表。即，在行情 SDK 的回调函数中解析收到的逐笔成交和逐笔委托数据，并完成类型转换、枚举值映射以及字段填充等数据处理工作。数据处理示例参考 3.2 章节。

一般推荐以下方式将实时数据源接入 DolphinDB server 中：

• 方案一：使用 DolphinDB 行情数据源插件。

  • DolphinDB 的行情数据源插件已经支持将委托和成交接收到同一张表中，并且内置实现了枚举值转换，可以直接接收到委托还原引擎期望的输入数据。

    • amdQuote 插件：amdQuote 订阅时选择 dataType="orderExecution"

    • NSQ 插件：订阅时选择dataType="orderTrade"

    • MDL 插件：订阅时选择 svrID="SHL2_ORDER_AND_TRANSACTION"

    • WindTDF 插件：订阅时选择 dataType="orderTrade"

    • EFH 插件：订阅时选择 dataType="orderExecution"

    • CSM 插件：订阅时选择 dataType="SSEL2_Tick"

    • INSIGHT 插件：订阅时选择 marketDataTypes="MD_ORDER_TRANSACTION"

    • XTP 插件：订阅时在 tableDict 参数里选择接收逐笔合并表（TickByTickTable）

• 方案二：使用 DolphinDB API 编写外部程序。

  • 自行开发数据接收程序，比如 C++ 程序。

  • 推荐使用 MultithreadedTableWriter 接口往 DolphinDB 的共享流表内实时写入数据。

  • 接收程序内的处理逻辑可以参考上述流程和插件源码。

引擎的输入表为标准化后的逐笔委托与逐笔成交合并表，输出表在原始字段基础上增加 orderMark 和 orderIndex 两列，用于标识还原结果来源以及还原后的通道内顺序。

示例脚本

use ops
// 定义输入表：创建逐笔合并数据输入表
colNames = ["TradeDate","SecurityID","Time","SourceType","Type","Price","Qty",
        "BSFlag","BuyNo","SellNo","ApplSeqNum","ChannelNo","Market","ReceiveTime"]
colTypes = ["DATE","SYMBOL","TIME","INT","INT","LONG","LONG","INT",
        "LONG","LONG","LONG","INT","SYMBOL","TIMESTAMP"]
dummyTable = table(1:0, colNames, colTypes)

// 定义输出表：创建委托还原输出表
newColNames = colNames <- ["orderMark", "orderIndex"]
newColTypes = colTypes <-["INT", "LONG"]
try{unsubscribeAll("newOrderTrans")}catch(ex){}
share(streamTable(1:0, newColNames, newColTypes), "newOrderTrans")

// 定义委托还原引擎
inputColMap = 
      { "codeColumn":"SecurityID",    // 证券代码
        "typeColumn":"Type",          // 交易类型
        "priceColumn":"Price",        // 价格
        "qtyColumn":"Qty",            // 数量（股数）
        "buyOrderColumn":"BuyNo",     // 买方订单号
        "sellOrderColumn":"SellNo",   // 卖方订单号
        "sideColumn":"BSFlag",        // 买卖方向
        "msgTypeColumn":"SourceType"  // 数据类型
      }
inputColMap = dict(inputColMap.keys(), inputColMap.values().flatten())
try{dropStreamEngine("OrderReconstitute")}catch(ex){}
engine = createOrderReconstituteEngine(
						name="OrderReconstitute", 
						dummyTable=dummyTable, 
						outputTable=objByName("newOrderTrans"), 
						inputColMap=inputColMap)

• 定义输入表：

  • colNames 和 colTypes 定义了输入表字段结构，需要与 3.2 节生成的合并表保持一致。

• 定义输出表：

  • 输出表在输入字段基础上新增 orderMark 和 orderIndex 两列，字段含义见 2.1 小节。

• 定义委托还原引擎：

  • name：引擎名字。创建引擎前先调用 dropStreamEngine 清理同名引擎，避免重复创建时报错。

  • dummyTable： 指定输入表结构。

  • outputTable：指定引擎输出表。

  • inputColMap：用于指定输入表中各字段在引擎中的语义。详情参考 3.1 节。

创建完成后，后续只需要向引擎追加符合字段结构的上交所合并数据，即可得到还原后的逐笔数据。

进行历史批计算时，可以从 3.2 节保存的上交所合并表 SHOrderTrans 中读取一天一个通道的数据，按 ApplSeqNum 排序后写入委托还原引擎。

示例脚本

// 选取一天一个通道的数据计算
testData = select * from SHOrderTrans
           where TradeDate=2026.04.29 and ChannelNo=1
           order by ApplSeqNum

// 将历史数据追加到委托还原引擎
getStreamEngine("OrderReconstitute").append!(testData)

• 委托还原引擎会维护每个通道内的订单状态，因此历史批计算时一次只输入同一交易日、同一通道的数据。

  • SHOrderTrans 是 3.2 节中提供的示例数据。

  • ApplSeqNum 是交易所在同一个 ChannelNo 内为逐笔委托、逐笔成交等消息分配的连续递增序号，通常从 1 开始递增，用于表示该通道内原始行情消息的发布先后顺序。引擎需要按照这个顺序逐条更新订单簿状态、关联成交与委托号，并识别立即全部成交或立即部分成交等需要还原的场景；如果不同交易日或不同通道的数据混在一起输入，或者同一通道内的 ApplSeqNum 顺序被打乱，就可能导致状态串扰、成交无法正确匹配到对应委托，进而影响还原结果。

  • 后续在快照合成或因子计算中使用上交所数据时，在需要连续顺序列的场景中，要将 ApplSeqNum 字段换成 orderIndex 字段。

• 调用 getStreamEngine("OrderReconstitute").append!(testData) 后，引擎会将还原后的逐笔数据写入输出表 newOrderTrans。

还原后得到的逐笔数据表如图 4-1 所示。

实时流计算时，可以按照 4.3 节的流程进行前序行情接入和标准化处理，并将逐笔委托、逐笔成交统一写入流表。

1. 在 DolphinDB 中创建共享流数据表，用于接收处理好的逐笔数据。表结构要求参考 3.1 章节。

2. 订阅共享流数据表，将合并后的逐笔数据实时写入委托还原引擎中。

3. 通过行情 SDK 同时订阅逐笔成交和逐笔委托数据，并将同一个通道的逐笔成交和逐笔委托数据写入同一张共享流数据表。在行情 SDK 的回调函数中解析收到的逐笔成交和逐笔委托数据，并完成类型转换、枚举值映射以及字段填充等数据处理工作。数据处理示例参考 3.2 章节。

示例脚本

// 定义输入流表: 首先，创建共享流数据表，用于接收处理好的逐笔数据
colNames = ["TradeDate","SecurityID","Time","SourceType","Type","Price","Qty",
        "BSFlag","BuyNo","SellNo","ApplSeqNum","ChannelNo","Market","ReceiveTime"]
colTypes = ["DATE","SYMBOL","TIME","INT","INT","LONG","LONG","INT",
        "LONG","LONG","LONG","INT","SYMBOL","TIMESTAMP"]
try{unsubscribeAll("OrderTrans")}catch(ex){}
share(streamTable(1:0, colNames, colTypes), "OrderTrans")
  
// 创建订阅: 其次，订阅共享流数据表，将合并后的逐笔数据实时写入委托还原引擎中。
subscribeTable(
      tableName="OrderTrans", actionName="orderTrans_to_reconstitute", 
      offset=-1, batchSize=10000, throttle=0.01, msgAsTable=true,
      handler=getStreamEngine("OrderReconstitute"))
  
// 实时写入数据: 最后将实时数据写入共享流表
testData = select * from SHOrderTrans
           where TradeDate=2026.04.29 and ChannelNo=1
           order by ApplSeqNum
submitJob("replay", "replay", 
          replay{inputTables=testData, 
                        outputTables=objByName("OrderTrans"), 
                        dateColumn="TradeDate", 
                        timeColumn="Time", 
                        replayRate=1000})

• 定义输入流表：

  • colNames 和 colTypes 定义了输入表字段结构，需要与 3.2 节生成的合并表保持一致。

  • 表类型需要是流表 streamTable，用于后续发布订阅

• 创建订阅：

  • subscribeTable 会持续订阅 OrderTrans 中新增的数据，并通过 getStreamEngine("OrderReconstitute") 将消息直接追加到委托订单还原引擎。

• 实时写入数据：

  • SHOrderTrans 是 3.2 节中提供的示例数据。

  • 对示例数据，使用 replay 函数进行控速回放，以此模拟实时数据写入的效果。

  • 使用 submitJob 函数将回放任务作为后台任务执行。可以通过 getRecentJobs 查看后台任务情况。

• 引擎处理后的结果会持续写入输出表 newOrderTrans。

• 实时接入时仍需保证同一引擎只处理同一交易日、同一 ChannelNo 的数据，并确保同一通道内按 ApplSeqNum 顺序写入。若多通道并行接入，建议按 ChannelNo 拆分输入流或为每个通道创建独立任务。

委托订单还原引擎补全上交所缺失的原始委托后，输出表可以直接作为 createOrderBookSnapshotEngine 的输入，用于订单簿还原和自定义快照的生成。

与直接使用原始上交所逐笔数据相比，关键差异在于：快照合成引擎需要按照还原后的逻辑顺序处理逐笔数据，因此创建引擎时应将 inputColMap 中的 seqColumn 映射为还原输出表新增的 orderIndex 列，而不是原始 ApplSeqNum 列。

快照合成引擎的详细使用教程参考 基于逐笔数据合成高频 Orderbook：DolphinDB Orderbook 引擎。

在高频因子计算中，通常需要对委托表与成交表进行复杂的关联操作，且需要针对沪深两市编写不同的数据清洗逻辑。深交所可以直接在原始逐笔委托表上统计，而上交所必须先关联逐笔成交表、反查缺失的委托量，才能得到与深交所口径一致的统计结果。

基于委托还原引擎输出的标准化数据流可以将这一差异消除在数据层：同一个因子只需要维护一套计算逻辑，即可在沪深全市场范围内直接复用。