为什么要”tick 数据 × 高规格 VPS” #

tick 是”每次成交”的最小单位记录。点差内部到底在发生什么、急变时成交偏向哪一侧——这类微观结构，一旦聚合成 K 线就消失了。正因如此，验证短线策略需要 tick。然而 tick 的数据量级别不同，采集、保存、计算的每一环都在考验机器的真实底力。本文会坦诚地分享 tick 数据采集中人人都会踩的坑，直到 “以为采到了、实则缺失 8 成”的失败及其修复。

做了什么（成果） #

全流程耗时（实测） #

从零到”可分析的完整 2 年 tick 底座 ＋ 优化结果”，实际只需 3 小时多一点。

STEP 1：数据采集 ― 免费 feed 与”两个坑” #

历史 tick 可从 Dukascopy 的免费数据源获取（.bi5 = LZMA 压缩 + 20 字节定长记录）。1 小时 = 1 文件，可用纯 Python 解码。

# .bi5（LZMA + 20B 定长: ms_offset, ask, bid, ask_vol, bid_vol）以小时为单位并行获取
import lzma, urllib.request, numpy as np, concurrent.futures as cf
REC = np.dtype([("t",">u4"),("ask",">u4"),("bid",">u4"),("av",">f4"),("bv",">f4")])
def fetch_hour(sym, y, m, d, h):
    url = f"https://datafeed.dukascopy.com/datafeed/{sym}/{y:04d}/{m-1:02d}/{d:02d}/{h:02d}h_ticks.bi5"
    raw = urllib.request.urlopen(url, timeout=30).read()
    return np.frombuffer(lzma.decompress(raw), dtype=REC)  # 价格 = points/(JPY 为 1000, 其他为 100000)

坑①：HTTP 503（限速）由”爆发”触发，而非”总量” #

为了提速，我们把任务分散到多台机器，反复停止→立即重启，结果 IP 被 Dukascopy 临时以 503 → 无响应 封锁。验证的结论：

• 503 的触发因素不是”请求总量”，而是”短时间内的连接爆发”（＝连续停止、重启，过多的并发连接）。
• 即使被封，只要完全停止请求，5～10 分钟即可自然恢复。
• 铁律是 “只跑一次 · 用克制的并发 · 不停顿地一气流完”。这次 每对 24 线程 × 2 对并行（=48 连接） 是稳定区间。

坑②（最重要）：”静默丢弃” ― 以为采到了，实则缺失 8 成 #

第一次采集看似”跑完”了，但 之后测覆盖率却只有约 22%。原因是下载器 把 HTTP 503 当作”无数据(404)”一样静默丢弃。即便没被封，拥堵时也会零星出现软性 503，那些小时就这样悄悄缺失。“数据在流 ＝ 完整”是不成立的。

🛠 如何发现、如何修复（可复现的清单）

1. 完整性要用”覆盖率/缺失率”来验证，而非”是否在流”。若”nonempty 率”大幅低于交易时段的预期（≈80%），就要怀疑缺失。这次是下游分析中对齐极度变瘦（5 分钟面板本应 15 万根，却只有 200 根上下）才暴露出来。
2. 区分 404 与 503。404＝正当休市（不重取），503/超时＝需重取。一旦把两者等同，缺失就被隐形化。
3. 多趟 · 缺口填补。记录每个 (日, 时) 的取得结果，仅对失败的小时以指数退避重取 → 反复直至失败为 0。
4. 以覆盖报告收尾。务必输出”total / data / 休市(404) / 未取得”，确认未取得 ≈0 且 ticks/年 符合预期后再去信任。

结果覆盖率从 22% → ≈100%（每对未取得 ≤6 小时 / 15,048）。完整 2 年可靠取得 4.06 亿 tick。

STEP 2：坑③内存 ― tick 处理是”RAM 受限” #

tick 的解码会先把目标范围的记录在内存中展开，再写出。也就是说 所需 RAM 与 周期 × 货币对数 成正比。

验证中，用 1.9GB RAM 的小型 VPS 作辅助，多年 × 多对时立刻 OOM（内存不足被强制结束）。而 OptiMax（251GB RAM）即便把完整 2 年 × 6 对整体载入内存也游刃有余（分析峰值时仍大量空闲）。

tick 数据处理中，比 CPU 更先到来的是 RAM 这堵墙。OptiMax 的大容量内存正是为此用途而生。

STEP 3：设计要点 ―把”下载机”与”计算机”分开 #

• 下载由线路质量（到 Dukascopy 的路由）主导。
• 分析 · 优化由 RAM 和核数主导。

它们是不同机器的强项，所以分工。这次用 2 台干净 IP 的采集机收集数据（把每 IP 限速规避翻倍＝分担的真正功效），并让 OptiMax 充当”计算母舰”专注于传输、汇聚、优化。约 1GB 的传输仅 51 秒。不被任一瓶颈拖累。

STEP 4：用 64 核”对策略穷举优化” #

这正是 OptiMax 的本领。与 MT5 的策略测试器优化同样的思路，把 1 次试验=1 核 分配下去，把所有核用尽。

关键在 并行的单位。仅按”货币对”并行只能跑 6 核。把 (货币对 × 信号 × 持仓时间 × 入场阈值) 的全部组合 作为 1 次试验，试验数一下子暴增，64 核就能跑满。沉重的预处理（1 秒网格）只构建一次并共享。

# 沉重的预处理(1秒网格)只做1次 → 用 fork pool 共享(copy-on-write) → 穷举所有组合
import multiprocessing as mp
GRIDS = {p: build_grid(p) for p in PAIRS}            # 父进程只构建一次(用 COW 共享给子进程)
tasks = [(p,sig,H,thr) for p in PAIRS for sig in SIGNALS for H in HORIZONS for thr in THRESHOLDS]
with mp.Pool(64) as pool:
    results = pool.map(eval_combo, tasks)            # 每个 combo = walk-forward + 计入成本 + bootstrap CI

实测：在 1.41 亿根 1 秒线 上，2,430 种 以 约 60 核占用 · 581 秒（构建网格 111s ＋ 扫描 470s）跑完。每次试验都是包含 walk-forward（时序的训练→验证切分）＋ 扣除来回点差的计入成本盈亏 ＋ 块 bootstrap 置信区间的完整验证。

“因为是回测所以用不满所有核”是误解。把并行的单位取为”参数组合”，优化就会随核数线性提速。OptiMax 的 64 核在此真正满负荷运转。

结果（通用的收获） #

完整 2 年 · 4.06 亿 tick · 2,430 次优化试验的定量结果：

• 信号本身”存在”：忽略成本（GROSS）的夏普比率最高达 +429。短线价格波动确实有结构。
• 但以 taker（市价）拿不到：扣除来回点差后，2,430 种里没有一种为正（NET>0 仅 0/2,430）。而且每次试验的 95% 置信区间上限也是 0/2,430 为正＝从统计上看”可能为正”的组合也为零（把数据补全后，源自噪声的”侥幸阳性”也随之消失）。
• 这是在 大规模 · 完整数据上严谨地再次确认 了市场微观结构的教科书结论（短线优势收敛于 bid-ask 点差之内，支付点差的一方＝taker 无法回收）。

实务含义：短线优势的研究，只有”扣除成本之后”才有意义。而要在现实时间内跑完那种大规模验证，就需要 完整的数据 · RAM · 核数。

总结 #

tick 级别的大规模回测 · 优化，已不再需要独占一台特殊计算机。有了 OptiMax VPS，就能在需要时取用需要的 RAM 和核数，在现实时间内跑完这种规模的验证。数据采集的那些坑（503 爆发 · 静默丢弃 · RAM 上限），也都能用本文的清单规避。