关于高频交易中tick级数据处理的几个踩坑经验分享
最近在开发一个基于盘口动态的高频策略，在tick数据的实时处理上遇到了不少问题，想和大家交流下。1. 时间戳对齐问题：
不同交易所的tick数据到达时间存在微妙差异（上交所vs深交所能差2-3ms），直接合并会导致orderbook状态不一致。目前是用硬件时钟同步+缓冲区对齐，但会引入约500ns的延迟。
2. 异常tick过滤：
遇到过几次异常情况：
- 买卖盘突然出现价格倒挂（bid>ask）
- 成交量暴增但盘口不变
现在采用动态阈值过滤，但参数设置很考验经验。
3. 内存管理陷阱：
python的deque在超高频场景下（>5000tick/s）会出现内存泄漏，后来改用C++重写了核心模块。
想请教各位：
- 有没有更好的tick对齐方案？
- 异常检测除了统计方法还推荐什么思路？
PS：策略本身还在优化，等回测稳定了可以再分享细节。 作为一个同时带娃写代码的金融狗，看到这个帖子简直DNA动了！(╯°□°）╯
关于tick对齐，我们实验室最近在测试用FPGA做硬件级时间同步，配合PTP协议能压到100ns以内。不过成本确实高，建议先用你的方案跑着，等策略成型再考虑优化。
异常检测这块，我喂娃时想到个脑洞：把orderbook变动当成事件流，用LSTM做个异常检测模型？毕竟带娃和debug一样，都需要预测下一秒会发生什么(￣▽￣*)ゞ
PS：求分享C++内存管理经验！最近在教娃编程，正好需要这种实战案例~ 作为数学系的学生，我对时间序列对齐问题很感兴趣。你们提到的硬件时钟同步方案，是否考虑过用概率图模型来处理不同交易所的时间偏移？比如用隐马尔可夫模型来建模tick到达的随机延迟，可能比固定缓冲区更灵活。
关于异常检测，我们实验室最近在用拓扑数据分析（TDA）做市场微观结构研究，通过计算盘口变化的持续同调，可以捕捉到传统统计方法忽略的几何特征。需要的话我可以分享相关论文。
另外你们用C++重写核心模块的选择很明智，不过要注意现代Python的memoryview或numpy数组其实也能减少拷贝开销。期待你们策略的后续分享！
页:
[1]