3. 数据采集与存储：实时采集架构设计、历史数据回补策略、分布式存储方案选型
好，咱们进入第三章。这一章聊的是Tick数据的“入口”和“仓库”。说白了，就是数据怎么进来，进来之后放哪儿，以及万一漏了怎么补回来。
我做了这么多年量化，见过太多团队在数据采集上栽跟头。有的是采集架构扛不住行情爆发，直接崩了；有的是存储选型不对，查询慢得像蜗牛。嗯，咱们今天就把这些坑一个个填上。
3.1 实时采集架构设计
实时采集，核心就一个字：快。Tick数据每秒成千上万笔，延迟稍微高一点，策略就吃不到肉了。
我个人习惯用生产者-消费者模式。生产者负责从交易所接收行情，消费者负责处理、清洗、存储。中间用消息队列解耦。
核心架构图：Tick数据实时采集流水线
这里有几个关键点：
- 采集网关：直接对接交易所API。我建议用C++或Rust写，性能好。Python做网关？嗯，除非你不在乎延迟。
- 消息队列：Kafka是首选。吞吐量高，持久化好。我在项目中遇到过RabbitMQ在行情爆发时丢消息的情况，后来全换成了Kafka。
- 消费者集群：负责清洗、去重、落库。可以水平扩展，扛得住。
小技巧：采集网关要加本地缓存。万一网络抖动，数据不会丢。我曾经因为没加缓存，一次网络闪断丢了3秒的Tick数据，复盘时差点没把大腿拍肿。
3.2 历史数据回补策略
实时采集再稳，也难免有漏网之鱼。网络断了、交易所维护、程序bug……这时候就需要历史数据回补。
回补策略，我总结了三板斧：
- 定时回补：每天凌晨跑一次，检查前一天的数据完整性。缺了就补。
- 事件触发回补：检测到数据断层，立即触发回补。适合对实时性要求高的场景。
- 全量回补：换数据源或重建数据库时用。从原始数据源重新拉取全部历史数据。
你想想看，回补最怕什么？怕重复数据。所以回补逻辑里一定要加去重。我一般用时间戳+交易对+交易所作为唯一键，写入时做upsert。
避坑指南：我曾经在回补时没控制好并发，直接把数据库写崩了。后来加了限流和分批写入，才稳住。记住，回补不是越快越好，稳定第一。
3.3 分布式存储方案选型
Tick数据量有多大？一天几亿条很正常。单机肯定扛不住，得上分布式。
我这些年试过不少方案，挑几个典型的说说：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| InfluxDB | 时序数据库，写入快，压缩率高 | 复杂查询弱，集群版贵 | 纯时序数据，简单聚合查询 |
| ClickHouse | 列式存储，查询极快，支持SQL | 写入延迟稍高，不适合高频更新 | 大规模分析，历史数据查询 |
| HBase | 水平扩展强，支持实时写入 | 运维复杂，查询延迟不稳定 | 超大规模实时写入 |
| Parquet + S3 | 成本低，存储无限，适合批处理 | 实时性差，查询需计算引擎 | 冷数据归档，离线分析 |
我个人习惯用分层存储：
- 热层：最近7天的数据，放ClickHouse。查询快，策略回测直接读。
- 温层：7天到3个月的数据，放Parquet文件，存S3。用Spark或Presto查。
- 冷层：3个月以上的数据，压缩后归档。几乎不查，但得留着。
核心逻辑图：分层存储架构
数据怎么在层之间流动？我写了个调度任务，每天凌晨把7天前的数据从ClickHouse导出到Parquet，上传S3，然后删掉ClickHouse里的旧数据。自动化，省心。
提示：选型时别光看性能，也得看团队技术栈。如果你们全栈Python，硬上HBase就是给自己挖坑。我见过一个团队，选了HBase但没人会运维，最后数据全丢了。嗯，血的教训。
好了，这一章就到这里。数据采集和存储是Tick数据的根基，根基不稳，后面全白搭。下一章咱们聊聊数据清洗的具体细节，到时候见。