1. ELT 概述：从定义到实战场景
大家好，我是这次课程的主讲。做了十几年数据架构，我见过太多团队在数据集成上栽跟头。今天咱们先聊聊 ELT 到底是什么，它和传统的 ETL 有啥区别，以及什么场景下该用它。
1.1 ELT 的定义
ELT，全称 Extract-Load-Transform。说白了就是：先把数据从源头抽出来，一股脑儿加载到目标平台，然后再做转换。
这个顺序很关键。传统做法是 ETL（抽取-转换-加载），数据在中间层洗好再入库。而 ELT 反过来——让目标数据库承担转换工作。
核心思想：利用目标系统的计算能力，在数据落地之后再做清洗、聚合、建模。数据先到，逻辑后行。
我最早接触 ELT 是在 2015 年。当时一个电商客户的数据量暴涨，传统 ETL 跑不动了。我们试着把转换逻辑下推到 Redshift，效果出奇的好。嗯，从那以后我就开始认真研究这个模式了。
1.2 ELT 与 ETL 的区别
很多人觉得 ELT 和 ETL 只是字母顺序不同。其实不然，它们的架构思想完全两码事。
| 对比维度 | ETL | ELT |
|---|---|---|
| 转换位置 | 中间层（ETL 服务器） | 目标数据库（数仓/数据湖） |
| 数据加载 | 转换后加载，通常只加载结果 | 原始数据全量加载 |
| 存储成本 | 较低（只存结果） | 较高（存原始数据） |
| 灵活性 | 低（转换逻辑固定后难改） | 高（随时可重新转换） |
| 适合数据量 | 中小规模 | 大规模（TB 级以上） |
| 技术栈 | Informatica、DataStage、Kettle | dbt、Snowflake、BigQuery、Spark |
你想想看，ETL 就像在厨房把菜洗好切好再端上桌。ELT 呢？直接把菜市场搬进厨房，想什么时候切就什么时候切。灵活性完全不是一个量级。
1.3 ELT 的适用场景
不是所有场景都适合 ELT。我总结了几类典型场景：
- 云原生数仓：Snowflake、BigQuery、Redshift 这类平台，计算和存储分离，天然适合 ELT。数据加载几乎零成本，转换靠 SQL 搞定。
- 数据湖架构：把原始数据存到 S3 或 ADLS，然后用 Spark、Presto 按需处理。我见过一个广告公司，每天 50TB 日志直接入湖，ETL 根本扛不住。
- 敏捷分析需求：业务方今天要这个维度，明天要那个指标。ELT 模式下，你只需要写新的 SQL 视图，不用重跑整个管道。
- 数据科学探索：数据科学家需要原始数据做特征工程。ELT 保留了最细粒度的数据，他们可以自由探索。
我的建议：如果你用的是传统关系型数据库做目标，比如 Oracle、MySQL，ELT 的优势不明显。因为这些数据库的计算资源有限，大量转换会压垮主库。云数仓或 MPP 数据库才是 ELT 的主场。
1.4 ELT 的核心优势
为什么这几年 ELT 越来越火？说白了，三个字：快、活、省。
- 加载速度快：省去了中间转换环节，数据直接从源到目标。我曾经把一个 2 小时的 ETL 管道改成 ELT，加载阶段只用了 15 分钟。
- 转换灵活：原始数据一直在那，你可以随时用新逻辑重算。不用像 ETL 那样，改个字段映射就得重新抽取。
- 运维简单：ELT 的管道通常只有两步：抽取和加载。转换逻辑交给 SQL 或 dbt 管理，版本控制也方便。
注意：ELT 不是银弹。它要求目标系统有足够的计算能力，而且存储成本会上升。我曾经有个项目，没控制好原始数据的保留策略，半年后存储费用翻了三倍。所以数据生命周期管理一定要跟上。
1.5 ELT 流程全景图
下面这张图展示了 ELT 的完整流程。我习惯把它分成三层：源层、加载层、转换层。
这张图我画了好几次才满意。你看，源层负责抽取，加载层把原始数据原封不动放进去，转换层才做真正的清洗和建模。每一层职责清晰，互不干扰。
1.6 什么时候该选 ELT？
我个人的判断标准很简单：
- 你的目标数据库是云数仓或 MPP 平台？→ 选 ELT
- 数据量每天超过 100GB？→ 选 ELT
- 业务需求变化快，经常要加新指标？→ 选 ELT
- 团队熟悉 SQL，不想维护复杂的 ETL 工具？→ 选 ELT
反过来，如果你的目标库是传统 Oracle、MySQL，或者数据量很小（每天几 GB），那 ETL 可能更合适。别盲目追新，适合的才是最好的。
一句话总结：ELT 把转换延迟到数据落地之后，用目标系统的算力换灵活性。它适合大规模、高敏捷、云原生的数据场景。但存储成本和目标系统性能是必须考虑的限制条件。