1. 课程导入
在金融交易、数字货币、券商行情、风控监控等场景中，行情数据具有典型的“高频写入、海量存储、低延迟查询、多维分析”特征。一个可用的实时行情平台，既要能承接每秒数十万甚至百万级的逐笔与盘口更新，又要支持按标的、时间窗口、交易所、品种等维度做秒级聚合与历史回溯。本课程将以 ClickHouse 为核心存储与分析引擎，带你从零构建一套可落地的实时行情平台。
一、核心需求：行情平台到底在解决什么问题
行情平台的第一性需求不是“存下来”，而是“在正确的时间以正确的粒度被正确的人查到”。我们可以把需求拆成四层：
- 接入层：对接交易所 WebSocket、TCP 组播、FIX 或第三方数据源，处理断线重连、乱序、重复与心跳。
- 写入层：将逐笔成交、盘口快照、K 线等数据以高吞吐方式落库，保证不丢、少重、可追溯。
- 查询层：支持最新行情点查、时间范围扫描、多标的聚合、分钟/小时 K 线生成。
- 服务层：通过 API、WebSocket 推送或 BI 看板对外提供稳定、低延迟的数据服务。
这些需求共同决定了技术选型：传统关系型数据库在写入吞吐和聚合扫描上容易成为瓶颈；而 ClickHouse 的列式存储、向量化执行、MergeTree 系列引擎与物化视图，恰好匹配行情数据的写入与聚合模式。
二、ClickHouse 的定位：为什么是它，而不是别的
ClickHouse 在本项目中承担“实时写入 + 历史分析 + 聚合加速”三位一体的角色。它不负责消息缓冲，也不负责复杂事务，而是作为分析型存储底座，与 Kafka、Flink 或自研采集程序配合使用。
| 能力维度 | 行情平台要求 | ClickHouse 对应机制 |
|---|---|---|
| 写入吞吐 | 每秒数十万行以上 | 批量插入、MergeTree 顺序写、分区裁剪 |
| 查询延迟 | 点查毫秒级，聚合秒级 | 主键索引、跳数索引、向量化执行 |
| 数据保留 | 热数据近实时，冷数据可归档 | TTL、分区、冷热分层存储 |
| 聚合加速 | 分钟 K 线、成交量统计 | 物化视图、AggregatingMergeTree |
| 扩展性 | 水平扩容、副本高可用 | 分片、副本、Distributed 表 |
ClickHouse 不是“万能数据库”。它擅长高吞吐写入与大规模聚合，不擅长高频单行更新和强事务。行情平台中“最新价”这类状态，通常用 Redis 或内存表辅助，而不是反复 UPDATE ClickHouse。
三、整体项目架构：从数据源到查询服务
本项目采用“采集 → 缓冲 → 入仓 → 聚合 → 服务”的分层架构。采集程序负责对接交易所并做初步清洗；Kafka 作为削峰缓冲；ClickHouse 承担明细存储与物化视图聚合；上层通过查询服务与推送网关对外输出。
图中可以看到，Kafka 同时向 ClickHouse 明细表和查询服务供数：明细表用于历史回溯与聚合，查询服务用于实时推送与最新值缓存。这种“双通道”设计避免了所有查询都压到 ClickHouse 上。
四、学习路线：30 章如何一步步走完
本课程按“认知 → 建模 → 写入 → 查询 → 优化 → 实战”推进，建议按顺序学习，每章都配有可运行的 SQL 或配置片段。
- 认知与架构（第 1–4 章）：需求分析、ClickHouse 定位、环境搭建、表引擎选型。
- 数据建模（第 5–10 章）：行情表结构设计、分区与排序键、物化视图、K 线聚合模型。
- 写入链路（第 11–16 章）：Kafka 接入、批量写入、去重、监控与背压。
- 查询与服务（第 17–22 章）：点查、范围扫描、聚合查询、API 封装与推送。
- 优化与运维（第 23–27 章）：索引、TTL、冷热分层、副本与分片、故障排查。
- 综合实战（第 28–30 章）：完整平台部署、压测、复盘与扩展。
建议在学习每章时同步搭建本地 ClickHouse 与 Kafka 环境，边写 SQL 边观察执行计划。行情平台的问题往往不是“写不出来”，而是“写出来跑不动”。
五、常见误区与复盘
初学者在行情平台建设中容易踩三类坑：
- 误区一：把 ClickHouse 当 OLTP 用。频繁单行 UPDATE 最新价会导致 part 过多、合并压力大。正确做法是用 ReplacingMergeTree 或外部缓存。
- 误区二：忽略排序键与分区键。行情查询几乎都带时间范围和标的过滤，若排序键设计不当，扫描量会成倍放大。
- 误区三：所有聚合都实时算。分钟 K 线若每次查询都从 tick 聚合，延迟和资源都不可控，应使用物化视图预聚合。
行情数据的时间字段务必统一时区与精度。交易所时间、采集时间、入库时间三者混淆，是后续对账和回测中最难排查的问题之一。