第二章：数据源架构——搭建实时宏观经济数据库

做外汇交易，尤其是宏观事件驱动型策略，最怕什么？

怕数据不准，怕时间对不上，怕凌晨两点非农数据出来，你的系统还在用昨天的旧值做判断。

这一章，我们就来聊聊怎么搭建一个靠谱的实时宏观经济数据库。说白了，就是给交易系统装上一双「实时眼」。

2.1 核心数据源：哪些数据必须接？

我个人习惯把宏观数据分成三类：

• 高频数据：每天甚至每小时更新的，比如PMI初值、周度失业金申请人数
• 中频数据：每月发布的，比如非农就业、CPI、利率决议
• 低频数据：每季度或每年，比如GDP修正值、长期通胀预期

你想想看，如果系统里只有月频数据，那周内交易信号基本就是瞎蒙。所以我的建议是：至少覆盖以下五大类：

数据类别	典型指标	发布频率	影响货币对
经济增长	GDP（初值/修正值）	季度	所有主要货币
通胀	CPI、核心PCE	月度	美元、欧元、英镑
制造业/服务业	PMI（Markit/ISM）	月度	商品货币、美元
就业	非农、失业率、平均时薪	月度	美元、加元
货币政策	利率决议、会议纪要	按会议周期	所有货币

2.2 数据清洗：别让脏数据毁了你的策略

我在项目中遇到过最坑的一次——某数据源把日本GDP的季度环比年化率直接当成了同比数据推送。要不是回测时发现策略在日元上疯狂亏损，根本不会注意到这个细节。

数据清洗，我总结了三步走：

1. 格式统一：所有数值统一为浮点数，日期统一为UTC时间戳。别问我为什么强调UTC——你想想看，美国东部时间晚上8:30发布的非农，和北京时间早上8:30发布的PMI，如果不转成统一时区，时间对齐就是噩梦。
2. 异常值检测：用Z-score或IQR方法。比如CPI月率突然跳了5个标准差，大概率是数据源抽风，不是真通胀。
3. 缺失值处理：宏观数据很少随机缺失，通常是节假日或数据源故障。我的做法是：如果是短期缺失（1-2个周期），用前值填充；如果是长期缺失，直接标记为「不可用」，不让策略使用。

2.3 时间戳对齐：这是最容易被忽视的坑

为什么时间戳对齐这么重要？

举个例子：美国非农数据通常在当月第一个周五的北京时间20:30发布。但如果你用的是数据商的「收盘价」时间戳，它可能把数据标记为当天的00:00:00。这样一来，你的策略在20:30:01收到数据，但系统里记录的时间却是00:00:00——时间轴完全错位。

我建议的做法是：

• 原始时间戳：保留数据源提供的原始时间，不做任何修改
• 对齐时间戳：统一转换为「数据实际发布时间」的UTC时间
• 交易时间戳：策略实际接收到数据的时间，用于回测时模拟延迟

嗯，这里要注意：不同数据源的发布时间可能有几秒到几分钟的差异。比如非农数据，有的数据商通过直连美联储服务器能快0.5秒，有的则慢3秒。对于高频策略来说，这3秒可能就是盈亏的分水岭。

2.4 数据存储架构：选对工具省一半力气

宏观数据的特点是：写入少、读取多、查询范围固定（按时间范围）。

我个人推荐用时序数据库，比如InfluxDB或TimescaleDB。原因很简单：

• 写入速度快，适合批量导入历史数据
• 查询效率高，尤其是按时间范围聚合
• 自带数据保留策略，可以自动清理过期数据

如果你团队里DBA资源有限，也可以用PostgreSQL + 时间分区表。我在早期项目里就这么干过，效果也不错。

下面是一个简单的表结构示例：

CREATE TABLE macro_data (
    id BIGSERIAL PRIMARY KEY,
    indicator_name VARCHAR(50) NOT NULL,  -- 比如 'US_NFP', 'US_CPI'
    release_time TIMESTAMPTZ NOT NULL,    -- 数据发布时间（UTC）
    actual_value DOUBLE PRECISION,
    forecast_value DOUBLE PRECISION,
    previous_value DOUBLE PRECISION,
    source VARCHAR(20),                   -- 数据源标识
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 按月份分区
CREATE TABLE macro_data_2025_01 PARTITION OF macro_data
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

2.5 实时数据管道：从发布到入库，延迟控制在1秒内

对于宏观事件驱动型策略，数据延迟就是真金白银。我一般用这样的架构：

数据源（Bloomberg/路透/官方API）
    ↓
消息队列（Kafka / RabbitMQ）
    ↓
数据清洗服务（Python / Go）
    ↓
时序数据库（InfluxDB / TimescaleDB）
    ↓
策略引擎（C++ / Python）

为什么中间要加一层消息队列？

因为数据发布是突发性的。非农数据发布的那一秒，可能有几十个指标同时推送。如果直接写入数据库，很容易造成写冲突。消息队列可以缓冲流量，保证数据不丢失。

2.6 数据质量监控：别等亏钱了才发现数据有问题

我见过最惨的案例——某团队用了三个月错误的数据做回测，策略表现「完美」，一上线就亏了20%。

所以，数据质量监控必须自动化：

• 延迟监控：如果某个指标超过预定时间30分钟还没更新，自动报警
• 值域校验：比如CPI月率正常范围在-2%到+5%之间，超出就标记异常
• 一致性检查：同一指标不同数据源的值差异超过阈值时，触发人工审核

嗯，这里还要提一句：历史数据的质量同样重要。我建议在入库时对历史数据做一次全量校验，用官方发布的数据做基准。别偷懒，这一步省不了。

2.7 本章知识体系总览

下面这张图，是我做这个系统时的核心架构思路。你可以把它当成一张「地图」，后面每个模块都会对应到这张图上的某个节点。

这张图里，从上到下依次是数据源层、消息队列层、清洗对齐层、存储层。每一层都有明确的职责，层与层之间通过消息传递解耦。这样做的好处是：任何一层出了问题，都不会影响其他层的正常运行。

---