1、课程导论与系统架构设计

大家好，我是这门课的主讲。今天咱们聊聊数据采集系统的整体架构。

说实话，我见过太多团队一上来就写代码，结果做到一半发现数据丢了、系统崩了、扩展不了。嗯，这就是典型的「先开枪后瞄准」。我个人习惯是，动手之前先把架构想清楚。

数据采集系统概述

数据采集系统，说白了就是把各种源头的数据捞过来，存好，供后续使用。你想想看，无论是用户行为日志、传感器数据、还是业务数据库的变更，都需要一个靠谱的管道把它们汇集起来。

我在项目中遇到过最典型的场景：一个电商平台，每天要采集几亿条用户点击流。如果架构设计不好，光数据丢失就能让老板血压飙升。

整体架构设计

我把系统拆成四层。每一层各司其职，互不干扰。

采集层

这一层负责从数据源拿数据。数据源五花八门：

• Web 服务器的访问日志
• 移动端埋点上报
• 数据库的 binlog 变更
• 物联网设备的传感器数据

采集层要解决的问题很简单：怎么把数据「拿过来」。但简单不代表容易。我曾经踩过一个坑——采集端没做限流，结果上游突发流量直接把 Kafka 打挂了。所以，采集层一定要有缓冲和限流机制。

传输层

数据拿到之后，怎么安全、高效地送到下游？这就是传输层的活。

我建议用消息队列做中间层。Kafka 是我的首选。为什么？因为它能扛住海量数据，而且支持多消费者。你想想看，同一份数据，实时计算要读、离线分析也要读，Kafka 正好能搞定。

存储层

数据到了，存哪儿？这得看数据类型和查询需求。

数据类型	推荐存储	原因
结构化业务数据	MySQL	事务支持好，查询灵活
时序数据	InfluxDB / ClickHouse	写入快，聚合查询强
日志/文本数据	Elasticsearch	全文检索，适合分析
缓存/临时数据	Redis	速度快，适合热数据

我个人习惯是：能放 MySQL 的放 MySQL，但别把所有鸡蛋放一个篮子里。冷热数据分离，能省不少钱。

应用层

最后，数据要变成价值。应用层就是干这个的：

• 实时大屏展示
• 离线报表生成
• 数据 API 对外提供
• 异常告警通知

这一层最容易被忽视的是「数据质量监控」。我曾经因为一个字段类型变了，导致整个报表跑偏了三天才发现。所以，应用层一定要有数据校验和告警。

技术选型原则

选技术栈，我遵循三个原则：

1. 成熟稳定优先——别追新。Kafka 用了十年，MySQL 用了二十年，它们经得起考验。
2. 社区活跃——遇到问题能搜到答案。冷门框架再牛也别碰，你想想看，出 bug 了连个问的人都没有。
3. 团队熟悉——再好的技术，没人会用也是白搭。我见过有人硬上 Flink，结果团队学了大半年还没跑通。

项目环境准备

好，理论说完了，咱们动手。先把环境搭起来。

Python 3.9+

我推荐用 Python 3.9 或更高版本。为什么？因为 3.9 引入了很多好用的语法糖，比如字典合并操作符 |。而且，很多数据采集库（比如 kafka-python、pymysql）对 3.9 支持最好。

# 检查 Python 版本
python --version
# 输出应为 Python 3.9.x 或更高

MySQL

MySQL 8.0 是首选。安装时注意：

• 字符集用 utf8mb4，支持 emoji
• 时区设为 +08:00（国内项目）
• 开启 binlog，方便后续做 CDC

Redis

Redis 6.x 以上版本。我主要用它做：

• 采集任务的分布式锁
• 数据去重（用 Set 或 HyperLogLog）
• 临时缓存

# 启动 Redis
redis-server --daemonize yes
# 测试连接
redis-cli ping
# 输出 PONG

Kafka

Kafka 2.8+ 版本。安装步骤：

1. 下载并解压 Kafka 包
2. 启动 Zookeeper（Kafka 依赖它做协调）
3. 启动 Kafka 服务

# 启动 Zookeeper
bin/zookeeper-server-start.sh config/zookeeper.properties &
# 启动 Kafka
bin/kafka-server-start.sh config/server.properties &

好了，环境准备就绪。下一章咱们开始写采集代码。记住，架构设计是地基，地基稳了，楼才能盖得高。