1、数据摄取概述：什么是数据摄取、ETL vs ELT、实时 vs 批量、数据管道的基本架构

数据摄取，说白了就是把数据从源头搬到目的地。听起来简单？我刚开始做数据工程时也这么想。直到有一次，生产环境的 Kafka 集群突然积压了上亿条消息，我才意识到——搬数据这件事，远没想象中那么轻松。

你想想看，一个大型电商平台每天产生多少数据？用户点击、订单、支付、物流、评论……这些数据来自不同的系统，格式五花八门。怎么把它们统一收集起来，送到数据仓库或数据湖里？这就是数据摄取要解决的问题。

什么是数据摄取

数据摄取（Data Ingestion）是从各种数据源获取数据，并将其传输到存储或处理系统的过程。它通常包含三个环节：

• 采集：从源系统读取数据，比如数据库、日志文件、API、消息队列
• 传输：通过网络将数据从源端送到目标端
• 写入：将数据持久化到目标存储，比如 HDFS、S3、ClickHouse

嗯，这里要注意：数据摄取不等于数据集成。集成通常还包含数据清洗和转换，而摄取更关注数据的可用性和时效性。我见过不少团队把两者混为一谈，结果管道设计得又重又慢。

ETL vs ELT：两种哲学

ETL 和 ELT 的区别，本质上就是「什么时候做转换」的问题。

维度	ETL	ELT
转换时机	加载之前	加载之后
存储成本	较低（只存转换后数据）	较高（存原始数据）
灵活性	低（转换逻辑固定）	高（可按需转换）
适用场景	传统数仓、存储昂贵	数据湖、云原生架构
典型工具	Informatica、DataStage	dbt、Spark、Flink

我个人习惯在高吞吐场景下优先选 ELT。为什么？因为 ETL 的转换环节会成为瓶颈。我曾经维护过一个 ETL 管道，每天凌晨跑 4 小时转换任务，数据量一涨就超时。后来改成 ELT，先把原始数据怼进 S3，再用 Spark 按需处理——问题迎刃而解。

当然，ETL 也有它的位置。比如在数据脱敏场景，你必须在加载前把敏感字段去掉。还有数据质量要求极高的场景，ETL 可以在源头就把脏数据过滤掉。

实时 vs 批量：两种节奏

批量处理是「定时拉取」，实时处理是「持续推送」。两者没有的好坏，关键看业务需求。

• 批量摄取：按固定时间间隔（如每小时、每天）拉取数据。适合报表、离线分析、历史数据归档
• 实时摄取：数据产生后立即传输，延迟通常在秒级甚至毫秒级。适合监控、推荐、风控

我记得有一次帮一个金融客户设计风控系统。他们原本用 T+1 的批量管道，结果欺诈交易发生后 24 小时才能发现。后来我们改成基于 Kafka 的实时摄取，延迟降到 5 秒以内——嗯，效果立竿见影。

但实时不是银弹。它带来的复杂度包括：

1. 状态管理：实时流需要维护 offset、watermark 等状态
2. 容错机制：网络抖动、节点宕机怎么恢复？
3. 背压处理：生产速度 > 消费速度时怎么办？
4. 运维成本：实时系统通常需要 7×24 值守

数据管道的基本架构

一个典型的数据管道，通常包含以下几个层次：

这个架构看起来简单，但每个层次都有不少坑。我挑几个重点说说：

采集层

采集层负责从数据源拉取数据。这里的关键是增量采集——全量采集在数据量大的时候根本跑不动。我常用的方案是：

• MySQL 用 Canal 监听 binlog
• PostgreSQL 用 Debezium 捕获变更
• 日志文件用 Filebeat 或 Flume

传输层

传输层是管道的「血管」。我个人最推荐 Kafka，原因有三：

1. 高吞吐：单机可以支撑百万级消息/秒
2. 持久化：消息落盘，不怕丢数据
3. 解耦：生产者和消费者互不依赖

存储层

存储层的选择取决于你的查询模式：

• OLAP 分析：ClickHouse、Doris
• 全文搜索：Elasticsearch
• 数据湖：HDFS、S3 + Parquet
• 时序数据：InfluxDB、TimescaleDB

嗯，这里有个常见的误区：很多人想把所有数据都塞进一个存储系统。我建议按场景拆分——热数据放 ClickHouse，冷数据放 S3，搜索走 ES。各司其职，性能才能上去。

本章小结

数据摄取是整个数据工程的起点。选 ETL 还是 ELT，走实时还是批量，没有标准答案。关键是要理解业务需求，评估成本和复杂度。

我个人总结了几条原则：

• 能不转就不转：原始数据先落地，转换后面再说
• 能不实时就不实时：批量能解决的问题，别上流式
• 能解耦就解耦：消息队列是管道的灵魂