📚 课程目录第2章数据采集基础

数据采集基础：数据源分类与采集工具选型

数据治理这件事，第一步就是「把数据拿进来」。听起来简单，但我在项目中见过太多团队栽在这一步——要么选错了采集工具，要么没搞清楚数据源的脾气，最后搞得整个链路鸡飞狗跳。

今天咱们就把数据采集的底牌翻个底朝天。我会从数据源分类、采集方式、工具选型三个角度，把实战中那些坑和经验一并倒出来。

一、数据源分类：先搞清楚你的数据长什么样

数据源分三类：结构化、半结构化、非结构化。说白了，就是看数据有没有固定的「骨架」。

类型	典型代表	特点	我踩过的坑
结构化	MySQL、Oracle、PostgreSQL	行和列固定，Schema 严格	表结构变更没通知，采集脚本直接崩
半结构化	JSON、XML、日志文件	有自描述结构，但字段不固定	日志里突然多了一层嵌套，解析器报错
非结构化	图片、视频、PDF、音频	没有固定格式，靠元数据管理	存了一堆图片，结果检索时发现没打标签

结构化数据，比如关系型数据库里的订单表。字段名、类型、长度都是定死的。这类数据采集最省心，但有个致命问题——Schema 变更。我曾经接手一个项目，业务方半夜加了个字段，第二天采集任务全挂。从那以后，我要求所有采集任务必须带 Schema 版本校验。

半结构化数据，比如 Nginx 访问日志、API 返回的 JSON。它有自己的「骨架」，但骨架会变。举个例子，用户行为日志今天还只有 5 个字段，明天产品经理一拍脑袋加了「来源渠道」，你的解析逻辑就得跟着改。嗯，这里要注意：半结构化数据采集，一定要预留字段扩展能力。

非结构化数据，图片、视频、PDF 这些。它们本身没有结构，但元数据可以结构化。比如一张图片，文件名、拍摄时间、GPS 位置这些元数据，才是采集时真正要抓的东西。我个人习惯是：非结构化数据走对象存储（OSS/S3），元数据走消息队列，分开处理。

核心原则：数据源分类不是学术游戏，它直接决定你用什么工具、怎么解析、怎么存储。搞错了分类，后面全是坑。

二、采集方式：批量还是实时？这是个战略问题

采集方式就两种：批量（Batch）和实时（Stream）。选哪个，取决于你的业务容忍度。

批量采集

定时跑任务，比如每天凌晨把昨天的订单数据从 MySQL 抽到 Hive。优点是简单、稳定、成本低。缺点是延迟高——你今天看到的报表，其实是昨天的数据。

我做过一个电商项目，运营要求「实时看销量」。结果一查，底层数据源是 Oracle 老库，批量采集 T+1 都跑不稳。最后折中方案：核心指标走实时，明细报表走批量。别一上来就全量实时，那是烧钱。

实时采集

数据一产生就抓走，延迟在秒级甚至毫秒级。典型场景：风控、实时大屏、监控告警。实时采集的代价是：系统复杂度飙升。你要处理数据乱序、重复、丢失、背压……每一个问题都能让你加班到怀疑人生。

维度	批量采集	实时采集
延迟	分钟~天级	秒~毫秒级
实现难度	低	高
资源消耗	集中式高负载	持续低负载
适用场景	报表、离线分析	风控、监控、推荐
数据一致性	容易保证	需要额外机制

我的建议：能用批量就别用实时。实时采集的成本是批量的 3-5 倍，除非业务真的等不了那几分钟。

三、采集工具选型：Flume、Logstash、DataX 怎么选？

工具选型这件事，我见过太多人「拿着锤子看什么都像钉子」。Flume 好，就所有场景都用 Flume；Logstash 流行，就无脑上 ELK。其实每个工具都有自己的「舒适区」。

Flume：日志采集的老炮

Flume 是 Hadoop 生态的老牌日志采集工具。它的核心模型是 Source-Channel-Sink，说白了就是：从哪读、暂存哪、写到哪。

我当年做第一个大数据项目时，Flume 还是 1.4 版本。那时候用它采集几百台服务器的 Nginx 日志，稳定跑了两年没出过大问题。Flume 的优势是：和 Hadoop 生态无缝集成，写 HDFS、Kafka 都是原生支持。

但 Flume 也有短板：配置繁琐。一个简单的日志采集，要写一堆配置文件。而且它的 Channel 用内存容易丢数据，用文件又影响性能。嗯，这里要注意：生产环境一定要用 File Channel，别图省事用 Memory Channel。

# Flume 配置示例：采集日志写入 HDFS
agent.sources = tailSource
agent.channels = fileChannel
agent.sinks = hdfsSink

agent.sources.tailSource.type = spooldir
agent.sources.tailSource.spoolDir = /var/log/nginx

agent.channels.fileChannel.type = file
agent.channels.fileChannel.checkpointDir = /data/flume/checkpoint
agent.channels.fileChannel.dataDirs = /data/flume/data

agent.sinks.hdfsSink.type = hdfs
agent.sinks.hdfsSink.hdfs.path = /data/logs/%Y%m%d
agent.sinks.hdfsSink.hdfs.fileType = DataStream

Logstash：ELK 家族的瑞士军刀

Logstash 是 Elastic 生态的采集工具。它的强项是：丰富的插件生态。输入插件有 50+，过滤插件有 40+，输出插件也有 30+。你几乎能找到任何数据源的接入方式。

但 Logstash 有个硬伤：性能差。同样是采集日志，Flume 单节点能扛 10 万条/秒，Logstash 到 3 万条就开始喘了。为什么？因为 Logstash 用 JRuby 写的，而且它的过滤插件是串行执行的。

我曾经帮一个团队排查 Logstash 性能问题。他们用 Logstash 采集 200 台服务器的日志，结果 CPU 跑满，数据延迟越来越严重。最后方案：Logstash 只做轻量级过滤，复杂处理交给下游的 Kafka Streams。

避坑指南：Logstash 适合日志量不大（日均百 GB 以内）且需要复杂数据处理的场景。如果数据量上 TB 级，建议用 Flume 或自研采集器。

DataX：结构化数据的搬运工

DataX 是阿里巴巴开源的异构数据源同步工具。它的定位很明确：搞定结构化数据的批量同步。MySQL 到 Hive、Oracle 到 HBase、SQL Server 到 MaxCompute……DataX 都能干。

DataX 的设计理念是「插件化」。Reader 插件负责读，Writer 插件负责写，中间通过 Framework 做数据交换。我特别喜欢它的「脏数据管理」机制——同步过程中出错的记录会被单独记录下来，不会影响整体任务。

举个例子，有一次我从 MySQL 同步 5000 万条数据到 Hive，中间有几百条数据因为编码问题报错。DataX 自动把这些脏数据写到指定目录，任务继续跑。最后我只需要修复那几百条数据，重新跑一次增量同步就行。

# DataX 配置示例：MySQL 到 Hive
{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "connection": [
              {
                "jdbcUrl": ["jdbc:mysql://localhost:3306/order_db"],
                "table": ["order_info"]
              }
            ],
            "username": "root",
            "password": "123456",
            "column": ["id", "order_no", "amount", "create_time"]
          }
        },
        "writer": {
          "name": "hdfswriter",
          "parameter": {
            "defaultFS": "hdfs://namenode:8020",
            "path": "/data/ods/order_info",
            "fileType": "text",
            "writeMode": "append",
            "fieldDelimiter": "\t"
          }
        }
      }
    ],
    "setting": {
      "speed": {
        "channel": 8
      }
    }
  }
}

工具对比：一张表说清楚

维度	Flume	Logstash	DataX
数据源类型	日志、文件	日志、消息队列、API	结构化数据库
采集模式	实时为主	实时为主	批量为主
性能	高（10万+/秒）	中（3万/秒）	高（取决于通道数）
生态集成	Hadoop 生态	Elastic 生态	阿里云生态
配置复杂度	中	低	中
适用场景	海量日志采集	中小规模日志处理	数据库批量同步

四、一张图看懂数据采集全貌

下面这张图，是我做数据治理项目时常用的「采集全景图」。它把数据源、采集方式、工具选型串在了一起。

五、选型决策：别纠结，看场景

工具选型没有银弹。我总结了一个简单的决策树，帮你快速定位：

数据源是数据库？ → 批量同步用 DataX，实时 CDC 用 Canal + Kafka
数据源是日志文件？ → 日均百 GB 以上用 Flume，百 GB 以下用 Logstash
数据源是 API/消息队列？ → Logstash 插件最丰富，或者自研采集器
数据要进 Elasticsearch？ → 无脑 Logstash，生态最完整
数据要进 HDFS/Hive？ → Flume 或 DataX，看是实时还是批量

个人经验：我一般会同时部署 Flume 和 DataX。Flume 负责实时日志流，DataX 负责数据库批量同步。两个工具各司其职，互不干扰。Logstash 只在 ELK 架构里用，不混搭。

数据采集是整个数据治理的「入口」。入口没把好，后面清洗、建模、分析全是白费功夫。选对工具、分好场景、留好扩展，这三点做到了，数据采集这关就算过了。