高频回测技术架构

[anyongjin]

https://github.com/EthanShang8989/banbot/tree/feature/TradeBT
上面是一个可参考的高频回测实现。

当前的问题有：

多个方法不应该添加V2后缀，在原函数修改即可：RunHistFeedersV2、SortFeedersV2

Batch数据：

高频数据直接按毫秒排序触发即可，不应该按时间粒度分批触发：1ms, 10ms, 100ms, 1000ms, 5000ms；按ms触发可基本和实盘一致，降低用户使用和配置负担。
因上面要求，Batch接口中的多个数据必定毫秒时间戳一样，所以只需一个TimeMS() int64函数即可。
对于K线的Batch接口，可修改banexg.Kline增加TimeMS方法
对于高频数据，每种数据定义结构体支持TimeMS即可（TradeBatch应只保留必要逻辑，不应有额外计算：TotalVolume、TotalValue、VWAPPrice这些应由用户自行计算）

配置方面：

能复用现有配置的尽量不添加新配置
use_file_trade_data：没必要，用户策略中要求使用高频数据，就直接走相关逻辑
trade_timeframe：似乎没必要
trade_precision_ms：没必要，毫秒级触发，无需指定精度
trade_cache_hours： 没必要，每个品种只预加载下1个小时数据即可

高频数据加载器：WsDataLoader

统一处理多种数据：aggTrade、trade、depth等。（也可BaseLoader处理通用部分，派生Loader处理各自逻辑）
应统一处理的任务：下载、解压分片保存、加载；可分别使用3组并发，比如5:2:3；可参考orm/kdata.go:downOHLCV2DBRange
提交任务：symbol，data_type，start_tme, end_time, callback
当前TradeCache使用自定义二进制存储，需对比相比zip/csv和gob两种格式的压缩率、读取速度、压缩速度；

高频Feeder：TradeFeeder为例

参考：data/feeder.go:TfKlineLoader
caches是当前小时的逐笔交易，rowIdx是当前读取的数据索引。
nextCaches是下个小时的逐笔交易，当开始读取caches，应发出加载请求到WsDataLoader，提供回调函数，得到数据后存入nextCaches
当caches读取完成时，将nextCaches赋值到caches并清空nextCaches，判断未读取到endMS继续发加载请求

	type TradeFeeeder struct {
		caches []*banexg.Trade
		nextCaches []*banexg.Trade
		rowIdx int
		EndMS int64
	}

SortFeedersV2实现不佳：

1. 当地排序每次重新开始，效率较低。应继续使用原有的排序判断：已有序时使用插入排序，无序时才sort.Slice
2. 直接使用IHistFeeder的getSymbol和getNextMS即可排序，不应给Batch增加额外Symbol() string方法，也不应调用GetBatch再排序
3. 排序规则可改为：时间优先、其次symbol、再次数据类型；任意一个相等时判断下一个

接口变动：

IHistFeeder新增Type() BatchType用于SortFeeders排序
IHistWSFeeder 的getSymbol() string移动到IHistFeeder用于SortFeeders排序
IHistWSFeeder 删除Warmup，因实盘无法预热高频数据，回测预热似乎也没必要
IHistWSFeeder删除，因与IHistFeeder一样

type IHistFeeder interface {
	getNextMS() int64
	SetSeek(since int64)
	SetEndMS(ms int64)
	GetBatch() Batch
	RunBatch(bar Batch) *errs.Error
	CallNext()
	Type() BatchType
	getSymbol() string
}

type Batch interface {
    TimeMS() int64
}

type IHistKlineFeeder interface {
	IKlineFeeder
	IHistFeeder
	DownIfNeed(sess *orm.Queries, exchange banexg.BanExchange, pBar *utils.PrgBar) *errs.Error
}

其他讨论

直接文件存储高频数据，不通过TimeScaledb，从https://data.binance.vision/ 下载，因为TimeScaledb的压缩比太低，高频数据不适合。如果后续支持dolphindb倒是可以存高频数据，不需要解压更快，压缩比也高

测试内存中列式存储是否更省内存
比如[]Trade这是常规行存储。下面是列式存储：
BatchTrade{ price []float64, quantity: []float64, timestamp []int64, index: int }

然后在HistProvider里，每种数据一个map(aggTrade/depth/trade)

小时为单位存储读取高频数据

[anyongjin]

几种不同高频数据格式：

aggTrade
agg_trade_id,price,quantity,first_trade_id,last_trade_id,transact_time,is_buyer_maker
11663913,0.05812,4943.0,30887806,30887807,1754092803060,true

bookDepth
timestamp,percentage,depth,notional
2025-08-05 00:00:07,-5,3475739.00000000,251917.67091000

bookTicker
update_id,best_bid_price,best_bid_qty,best_ask_price,best_ask_qty,transaction_time,event_time
3540021753883,0.00441100,100000.00000000,0E-8,0E-8,1700661601009,1700661601013

indexPriceKlines
open_time,open,high,low,close,volume,close_time,quote_volume,count,taker_buy_volume,taker_buy_quote_volume,ignore
1754352000000,0.07465260,0.07465692,0.07448785,0.07449499,0,1754352059999,0,60,0,0,0

metrics
create_time,symbol,sum_open_interest,sum_open_interest_value,count_toptrader_long_short_ratio,sum_toptrader_long_short_ratio,count_long_short_ratio,sum_taker_long_short_vol_ratio
2025-08-05 00:05:00,1000000BOBUSDT,38932843.0000000000000000,2894327.1158697900000000,1.34516129,1.60761300,1.92481203,0.73624200

trade
id,price,qty,quote_qty,time,is_buyer_maker
31268059,0.07467,132.0,9.85644,1754352003040,true

[anyongjin]

逐笔交易回测支持已完成。还需支持：未完成K线，订单簿深度