1. 流水线基础概念：什么是数据流水线、ETL vs ELT、批处理与流处理

大家好，我是老张。做数据流水线这行快十年了，踩过的坑比写过的代码还多。今天咱们先聊聊最基础的东西——到底什么是数据流水线？

说白了，数据流水线就是一套自动化的流程。它把原始数据从源头搬出来，经过清洗、转换、加工，最后送到目标系统里。你想想看，就像工厂里的流水线一样，原料进去，成品出来。只不过咱们处理的是数据，不是零件。

1.1 数据流水线的三个核心环节

不管流水线多复杂，拆开来看就三个环节：

• 抽取（Extract）——从数据库、API、日志文件、消息队列等源头把数据读出来
• 转换（Transform）——清洗脏数据、做格式统一、聚合计算、打业务标签
• 加载（Load）——把处理好的数据写入数据仓库、数据湖、或者下游系统

嗯，这里要注意。很多新手以为流水线就是写几个SQL跑一跑。其实不然。我在项目中遇到过，一个看似简单的抽取环节，因为源库表结构变更没通知，导致整个流水线挂了三天。所以每个环节都要考虑异常处理。

1.2 ETL vs ELT：两种主流架构

这两个概念经常被搞混。我刚开始带团队的时候，也跟架构师争论过到底用哪个。咱们直接看对比：

维度	ETL	ELT
执行顺序	先转换，再加载	先加载，再转换
计算位置	在中间层（ETL服务器）完成	在目标系统（数据仓库/数据湖）内完成
适用场景	传统数仓、数据质量要求极高	大数据平台、云原生架构、数据湖
存储成本	较低（只存转换后的数据）	较高（原始数据和转换后数据都存）
灵活性	低（转换逻辑固定后难改）	高（原始数据保留，随时重新转换）
典型工具	Informatica、DataStage、Kettle	dbt、Spark、BigQuery、Snowflake

为什么会这样？我解释一下。

ETL 是传统架构。数据先拉到中间层，做完清洗转换，再加载到目标库。好处是目标库里的数据直接能用，质量有保障。坏处是中间层容易成为瓶颈。我记得2016年做一个金融项目，ETL服务器每天凌晨跑4个小时，后来数据量翻倍，直接跑不完。最后只能拆流水线。

ELT 是云原生时代的玩法。先把原始数据一股脑加载到数据湖或者云数仓里，然后在里面用SQL或者Spark做转换。好处是灵活，原始数据随时可以重新加工。坏处是存储成本高，而且对目标系统的计算能力要求高。

1.3 批处理与流处理

这两个概念决定了流水线的运行模式。咱们还是先看对比：

维度	批处理	流处理
数据范围	处理一段时间内的全部数据（如一天）	处理实时到达的每条数据
延迟	分钟级到小时级	毫秒级到秒级
触发方式	定时调度（如每天凌晨2点）	数据到达即触发
典型场景	日报、月报、历史数据回溯	实时监控、风控、推荐系统
工具	Hive、Spark SQL、Airflow	Flink、Kafka Streams、Storm

批处理，说白了就是「攒一波，一起干」。每天凌晨跑一次，把昨天的数据全处理完。优点是逻辑简单、容易调试、资源利用率高。缺点是延迟高，你今天早上看到的报表，其实是昨天的数据。

流处理，就是「来一条，干一条」。数据到了立刻处理，延迟极低。但代价是系统复杂度飙升。我曾经在一个实时风控项目里，用Flink做流处理，光是处理数据乱序和迟到数据就花了两周时间。

1.4 四种模式的组合

实际项目中，ETL/ELT 和 批处理/流处理 是交叉组合的。我画了一张图，帮你理清这四种模式：

你看这张图就清楚了。左上角是传统ETL批处理，最经典的模式。右上角是ELT批处理，现在云数仓的主流。左下角是ETL流处理，适合对数据质量要求高的实时场景。右下角是ELT流处理，架构最复杂，但灵活性最高。

1.5 我的一点经验

说了这么多，最后分享几个实际经验：

• 别追求纯流处理。大部分场景，批处理+短周期调度（比如每5分钟跑一次）就能满足需求。纯流处理的运维成本是批处理的3-5倍。
• ETL和ELT可以混用。我在一个项目中，核心业务数据用ETL保证质量，日志类数据用ELT保留原始信息。没必要二选一。
• 先画图再写代码。每次设计流水线之前，我都会先画一张类似上面的架构图。把数据流向、处理模式、工具选型都标清楚。画清楚了，写代码就是体力活。