一、数据采集概述：从零到一的第一步
数据采集，说白了就是「把数据从源头拿过来」。听起来简单，但我在项目中踩过的坑，十有八九都出在这一步。
你想想看，后面所有的清洗、建模、可视化，都建立在采集到的数据之上。源头数据要是歪了，后面再怎么折腾也是白搭。我个人习惯把数据采集比作「打地基」——地基没打好，楼盖得再漂亮也得塌。
1.1 数据采集的定义与重要性
数据采集，就是从各种数据源中获取原始数据的过程。它不光是「拿数据」，还包括了数据格式的识别、传输协议的适配、采集频率的控制等等。
核心观点：数据采集的质量，直接决定了数据分析的天花板。
我记得有一次做电商平台的用户行为分析，采集端漏掉了「页面滚动深度」这个字段。结果模型训练出来，用户流失预测的准确率死活上不去。后来补上这个字段，准确率直接提升了12%。
数据采集的重要性体现在三个层面：
- 时效性：数据采集的延迟，决定了你能多快响应业务变化
- 完整性：漏采一个字段，可能就漏掉了关键的业务信号
- 准确性：采集过程中的数据失真，会污染整个分析链路
我曾经接手过一个项目，上游系统采集时把时间戳的时区搞错了。结果所有时序分析全部偏移了8小时，排查了整整两天才找到根因。嗯，从那以后我每次做采集都会先校验时间戳。
1.2 数据采集的完整流程
数据采集不是孤立的动作，它是一条完整的链路。我习惯把它拆成五个环节：
- 采集：从数据源获取原始数据
- 清洗：去除噪声、处理缺失值、统一格式
- 存储：把清洗后的数据写入目标系统
- 建模：构建数据模型，支撑业务分析
- 可视化：把数据变成可读的图表和报表
这五个环节环环相扣，任何一个环节出问题，都会传导到下游。我见过太多团队只关注「采集」和「可视化」，中间的清洗和建模草草了事，结果就是「垃圾进，垃圾出」。
1.3 常见数据源
数据源的类型很多，但归纳起来就四大类。我按项目中出现频率排个序：
| 数据源类型 | 典型场景 | 采集方式 | 我踩过的坑 |
|---|---|---|---|
| 数据库 | 业务系统、CRM、ERP | JDBC/ODBC、CDC、全量/增量同步 | 大表全量同步导致源库IO打满 |
| API | 第三方服务、开放平台 | RESTful、GraphQL、WebSocket | 接口限流没处理，采集任务被拉黑 |
| 日志文件 | 服务器日志、应用日志 | Filebeat、Flume、Tail | 日志轮转导致文件丢失 |
| 传感器 | IoT设备、工业监控 | MQTT、CoAP、Modbus | 数据包乱序，时间戳对齐困难 |
数据库采集
这是最常见的数据源。我建议优先考虑增量采集，别动不动就全量拉取。你想想看，一张上亿行的订单表，每次全量同步不仅慢，还会影响源库的正常业务。
我的经验：用CDC（Change Data Capture）方式做数据库采集，只同步变更的数据。MySQL用Binlog，PostgreSQL用WAL，这样对源库几乎无侵入。
API采集
调用第三方API时，一定要处理限流和重试。我曾经对接过一个支付接口，对方限流是每秒100次，我没做限流控制，结果直接触发了对方的熔断机制，整个采集链路断了两个小时。
# 一个简单的API采集重试逻辑
def fetch_with_retry(url, max_retries=3):
for attempt in range(max_retries):
try:
response = requests.get(url, timeout=10)
if response.status_code == 429:
# 被限流了，等一会再试
time.sleep(2 ** attempt)
continue
return response.json()
except Exception as e:
print(f"第{attempt+1}次尝试失败: {e}")
time.sleep(1)
raise Exception("采集失败，已重试3次")日志文件采集
日志采集的难点在于文件轮转。很多应用会按天或按大小切分日志文件，采集工具如果没处理好，就会丢数据。我习惯用Filebeat配合Logstash，Filebeat会记录读取位置，即使文件轮转也不会丢。
传感器采集
IoT场景下，传感器数据的特点是：频率高、数据量大、网络不稳定。我建议在采集端做轻量预处理，比如数据压缩、时间戳标准化，别把原始数据一股脑全传上来。
特别注意：传感器数据的时间戳一定要在设备端生成，不要在采集服务器上打时间戳。网络延迟会导致时间戳偏差，后续时序分析全乱套。我曾经因为这个原因，排查了整整一周的「数据异常」。
1.4 采集策略的选择
不同的业务场景，采集策略也不同。我一般按两个维度来选：
- 实时性要求：实时采集 vs 批量采集
- 数据量级：全量采集 vs 增量采集
举个例子：用户点击流日志，需要实时采集做推荐，那就用Kafka做消息队列；财务对账数据，每天跑一次批量采集就够了，没必要实时。
嗯，这里要注意：不要为了「实时」而实时。实时采集的成本比批量高一个数量级，如果业务不需要秒级响应，别给自己找麻烦。
1.5 本章小结
数据采集是整个数据工程的起点，也是最容易出问题的地方。记住三个原则：
- 源头校验：采集时就做数据质量检查，别等到下游才发现
- 增量优先：能增量就别全量，能批量就别实时
- 容错设计：网络会断、接口会限流、文件会轮转，做好重试和补偿
我个人习惯在采集层加一个「数据质量看板」，实时监控采集的条数、延迟、错误率。这样一旦出问题，能第一时间发现，而不是等到业务方投诉才知道。