一、课程导学与系统全景：Tick数据是什么？为什么需要自建系统？课程目标与整体架构概览

1.1 Tick数据到底是什么？

先问大家一个问题：你平时看股票行情，看到的价格是真实的吗？

其实，你看到的K线图，是「加工过的数据」。每一根K线，背后都藏着无数笔真实的成交。

Tick数据，就是最原始的那一笔。每一笔成交，都对应一条Tick记录。它包含：

• 成交时间：精确到毫秒甚至微秒
• 成交价格：实际成交价
• 成交量：这一笔成交了多少手
• 买卖方向：主动买还是主动卖

举个例子。你在交易软件上看到「茅台在10:00:00以1800元成交了100手」——这就是一条Tick数据。

但如果你看的是1分钟K线，这100手已经被揉进了那一分钟的汇总里。你再也看不到「是谁在什么时间点以什么价格成交的」。

说白了，Tick数据就是市场的「原始录音」，而K线是「剪辑后的新闻稿」。

1.2 为什么需要自建Tick采集系统？

你可能会问：券商、行情软件不都提供数据吗？我直接买不就行了？

嗯，这里有几个坑，我一个个说。

第一，数据质量不可控。

我在项目中遇到过，某知名行情供应商的Tick数据，竟然有5%的时间戳是错的。你想想看，5%的错数据，回测出来的策略你敢用吗？

第二，延迟太高。

做高频交易的人都知道，1毫秒的延迟可能就是几百万的盈亏。第三方数据到你手里，中间经过了至少3-5层转发。等你拿到数据，黄花菜都凉了。

第三，成本问题。

一套全市场Tick数据，一年几十万甚至上百万。自己搭系统，硬件成本可能就几万块。我算过一笔账，自建系统第二年就开始回本了。

第四，定制化需求。

你可能只需要某个板块、某个时间段的Tick数据。第三方不会为你定制。自己搭系统，想怎么切就怎么切。

1.3 课程目标：你能学到什么？

这门课的目标很明确：从零开始，搭建一个生产级的Tick数据采集系统。

具体来说，学完这门课，你能做到：

• 理解Tick数据的完整生命周期：从交易所到数据库
• 掌握行情网关的搭建：如何低延迟接收Tick数据
• 学会数据清洗与校验：剔除脏数据、修复时间戳
• 设计高性能存储方案：每天几亿条数据，怎么存、怎么查
• 实现实时监控与告警：系统挂了怎么办？数据丢了怎么办？

说白了，这门课不是讲理论，是讲「怎么干」。每一章都有可运行的代码，每一章都有我踩过的坑。

1.4 整体架构概览

先给大家画一张全景图。整个Tick采集系统，我把它分成5层：

这张图，就是整个课程的地图。每一章都会对应其中一层。

我个人习惯，做系统架构时先画这张图。有了全景，你才知道每一块拼图该放哪里。

1.5 技术栈选型

选技术栈这件事，我踩过不少坑。这里直接给结论：

层级	技术选型	为什么选它
行情网关	C++ / Rust	低延迟、零GC停顿
数据清洗	Python + Pandas	开发效率高、生态丰富
消息队列	Kafka / Redis Stream	高吞吐、持久化
存储	ClickHouse / InfluxDB	列式存储、压缩率高、查询快
监控	Prometheus + Grafana	开源、可视化好

1.6 一个真实的Tick数据长什么样？

说了这么多，不如直接看一条真实的Tick数据。这是我从上交所采集的某只股票的原始记录：

{
  "symbol": "600519",
  "timestamp": 1704067200123456,  // 微秒级时间戳
  "price": 1800.50,
  "volume": 100,
  "turnover": 180050.00,
  "direction": "buy",             // 主动买
  "exchange": "SSE"
}

你看，就这么简单。但就是这条数据，背后涉及了网络传输、协议解析、时间同步、数据校验等一系列问题。

我曾经因为时间戳精度不够，导致回测结果和实盘差了3个点。后来才发现，是网关层的时间戳精度只到了毫秒级，而交易所实际是微秒级。

嗯，这种坑，后面会专门讲怎么避。

1.7 课程适合谁？

这门课不是入门课。我希望你有以下基础：

• 熟悉至少一门编程语言（Python或C++最好）
• 了解基本的网络协议（TCP/IP、UDP）
• 用过数据库（MySQL或PostgreSQL都行）

如果你没有这些基础，建议先补一补。不然跟着做可能会吃力。

但如果你有基础，这门课会让你少走至少两年的弯路。为什么？因为这里面的每一个方案，都是我在生产环境里验证过的。

---