1. 数据采集系统概述：架构演进、核心组件、常见数据源类型与采集模式
1.1 从单机到分布式：架构演进之路
数据采集系统，说白了就是帮我们把散落在各处的数据「搬」到统一平台的那套东西。我入行那会儿，大家还在用简单的脚本定时拉取日志，架构就是一台服务器加一个数据库。现在呢？早就不是那个玩法了。
我个人习惯把架构演进分成三个阶段：
- 单体架构阶段：采集、清洗、存储全在一台机器上。优点是简单，缺点是扛不住量。我记得2015年帮一家电商公司做日志采集，双十一当天单机直接被打挂，数据丢了整整两小时——那叫一个惨。
- 分层架构阶段：采集层、缓冲层、处理层、存储层分开部署。这时候开始引入消息队列（Kafka、RocketMQ）做解耦，采集端只管收，处理端只管算，互不干扰。
- 流式架构阶段：实时采集、实时处理、实时落盘。Flink、Spark Streaming 这些引擎开始登场。说白了，就是数据还没落地，你已经在处理它了。
核心观点：架构演进的核心驱动力就两个——数据量变大、实时性要求变高。没有银弹，只有取舍。
1.2 核心组件：每个环节都不能掉链子
一个完整的数据采集系统，至少包含以下组件。我按数据流向给你捋一遍：
| 组件 | 职责 | 常见选型 |
|---|---|---|
| 采集代理（Agent） | 部署在数据源端，负责抓取数据 | Filebeat、Logstash、Flume |
| 消息队列 | 缓冲数据，削峰填谷 | Kafka、RabbitMQ、Pulsar |
| 传输通道 | 保证数据可靠送达 | HTTP、gRPC、TCP长连接 |
| 数据转换 | 清洗、过滤、格式化 | Logstash filter、自定义UDF |
| 存储引擎 | 最终落盘 | HDFS、ClickHouse、Elasticsearch |
嗯，这里要注意：消息队列不是必须的。如果你数据量很小，实时性要求也不高，直接用采集代理写到存储里就行。但一旦日均数据量超过百万条，我建议你老老实实上Kafka。为什么？
我曾经在一个项目中跳过消息队列，采集端直接写数据库。结果业务高峰期数据库连接池被打满，采集任务大面积超时，数据全丢了。后来加了Kafka做缓冲，再也没出过类似问题。
1.3 常见数据源类型：你面对的不只是日志
很多人一提到数据采集，第一反应就是「收日志」。其实数据源类型远比你想的丰富。我按来源分类给你列一下：
- 应用日志：Java的log4j、Python的logging、Nginx的access log。这类数据最典型，也最好处理。
- 数据库变更：MySQL的binlog、PostgreSQL的WAL日志。用Canal、Debezium这类工具监听，实现实时同步。
- API接口数据：第三方服务的RESTful接口、Webhook回调。说白了就是定时轮询或者被动接收。
- 物联网设备：传感器、智能硬件的上报数据。协议五花八门，MQTT、CoAP、HTTP都有。
- 用户行为埋点：前端JS埋点、APP SDK上报。这类数据量最大，也最容易出问题。
避坑指南：我曾经接手过一个埋点采集项目，前端上报的数据里字段名大小写不统一，有的用「userId」，有的用「user_id」。清洗脚本写了三天才搞定。所以，数据源侧的规范比采集侧的代码更重要。
1.4 采集模式：推还是拉？这是个问题
采集模式就两种：推（Push）和拉（Pull）。你想想看，这其实跟你去餐厅吃饭一个道理——推模式是服务员把菜端到你桌上，拉模式是你自己去厨房窗口取。
- 推模式（Push）：数据源主动把数据发到采集端。优点是实时性好，缺点是采集端扛不住突发流量。适合日志采集、埋点上报。
- 拉模式（Pull）：采集端主动去数据源取数据。优点是可控性强，你可以自己控制节奏。缺点是实时性差，适合数据库同步、API轮询。
实际项目中，我建议混合使用。比如日志采集用推模式，数据库同步用拉模式。别死磕一种，灵活点。
1.5 知识体系总览
下面这张图是我自己画的，把本章的核心逻辑串起来了。你看一眼就能明白数据采集系统到底在干什么：
注意：这张图展示的是通用架构。实际项目中，每一层都可能根据业务场景做裁剪或增强。比如物联网场景，采集层前面可能还要加一层协议网关。别照搬，要理解背后的设计思想。
1.6 小结
数据采集系统，说白了就是一条数据管道。从数据源到存储，中间经过采集、缓冲、传输、处理四个环节。架构怎么选、组件怎么搭、模式怎么定，全看你的数据量和实时性要求。
我见过太多人一上来就上Kafka、上Flink，结果数据量一天才几万条，纯属杀鸡用牛刀。也见过有人用单机脚本扛百万级数据，最后系统天天崩。嗯，这里面的度，得靠经验去把握。
下一章，我会带你深入采集代理的选型与配置，聊聊Filebeat、Logstash、Flume到底该怎么选。到时候见。