经典批 ETL（基线方案）
使用场景: 构建首个分析管道的团队
定时按小时或夜间运行
从源抽取到 staging 区
在管道中转换（Spark、Pandas、加载前 dbt 模型）
仅把干净、建模过的数据加载进仓库
仓库保持小而干净
这样组织的原因: 经典批 ETL 在加载前转换——图表把转换作为独立阶段，让仓库保持精简，但把复杂度推给管道工具。
真实案例
ELT（现代云仓库模式）
使用场景: 使用 Snowflake / BigQuery / Redshift 的团队
先抽取并加载原始数据进仓库
在仓库内用 SQL（dbt）转换
仓库内 raw 层 + staging 层 + marts 层
更易调试——原始数据可查询
用仓库计算，不需外部 Spark 集群
这样组织的原因: ELT 颠倒顺序——图表把 Load 放在 Transform 之前，转换阶段住在仓库里。这能工作是因为现代云仓库在规模上让转换变得便宜。
流式管道
使用场景: 需要近实时数据的团队
源通过 Kafka / Kinesis 流式发送事件
通过 Flink / Spark Streaming / ksqlDB 转换
持续加载进仓库或实时存储
延迟在秒级而非小时级
无调度器——管道持续运行
这样组织的原因: 流式用持续运行的管道取代批调度器——图表去掉调度器框、加入流处理引擎，因为新鲜度要求把架构从定期批处理推向常开式流动。
变更数据捕获（CDC）
使用场景: 把业务库同步进仓库的团队
读源库的变更日志（binlog、WAL）
通过 Debezium → Kafka 流式发送变更
增量应用变更到仓库表
对源库影响小（无重查询）
近实时且无需完整抽取
这样组织的原因: CDC 消除定期完整抽取——图表用变更日志读取器替代 Extract 阶段，让仓库保持同步而无需扫描源表。
使用技巧
- 始终把调度器作为管道之上的独立组件——编排是一个可部署系统，不是 Transform 阶段的属性。
- 把监控作为独立节点；没有阶段成功 / 新鲜度告警，管道失败是静默的。
- 明确标注转换位置（管道内 vs 仓库内）——这个单一选择就是 ETL vs ELT 的区别。
- 对于流式管道，去掉调度器并加入流处理引擎；两者并存会让读者困惑。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=etl-pipeline-architecture
编辑此 ETL 模板