ETL 与 ELT 是什么

ETL（Extract-Transform-Load）先抽取、在独立计算引擎里转换、再把结果加载进目标库；ELT（Extract-Load-Transform）先把原始数据原样装进目标库，再用目标库自身的算力做转换。两者处理的是同一件事——把源系统的数据加工成可用数据，差别只在转换发生在哪里。

为什么转向 ELT

云数仓与湖仓把存储与计算解耦、扩容按需，目标库算力不再是瓶颈，于是把转换下推成 SQL 更省事：数据不必为适配某个引擎反复搬运，原始数据保留下来还能随时改口径重算。这是 ELT 在云上成为默认形态的直接原因。

基本信息

对比维度

典型使用场景

• 自建数仓、目标库算力紧张：先在 Spark 侧把大表关联与聚合算完再入库，选 ETL
• 云数仓上做 ODS/DWD/DWS 分层加工：用 ELT 让转换贴着数据走，省掉中间搬运
• 半结构化数据（日志、JSON）入库前要解析与规范化：ETL 阶段完成结构对齐
• 合规要求保留原始数据、口径需随时重算：ELT 先落后算，重算不依赖源系统
• 团队以 SQL 为主、没有 Java/Scala 开发资源：ELT 的落地成本明显更低
• 源库压力敏感：抽取阶段只做轻量过滤与脱敏，重加工放到数仓

两条路径示意

# ETL：转换在独立引擎完成，目标库只接结果
源库 → 抽取 → Spark 清洗/关联/聚合 → 写入数仓结果表

# ELT：原件先入仓，转换下推到数仓
源库 → 原样入 ODS（保留全部字段）→ 数仓内 SQL 逐层加工 DWD/DWS → ADS

# 关键差别：ELT 链路里 ODS 是可回溯的事实来源，ETL 链路里中间态通常在引擎侧就没落了

ELT 的转换长什么样

-- ODS 原样落地，不改字段
INSERT OVERWRITE TABLE ods_order PARTITION (dt = '2026-10-11')
SELECT id, user_id, total_amount, status, update_time FROM src_order WHERE update_time >= '2026-10-11 00:00:00';

-- 口径在数仓内用 SQL 实现，改口径只改这一段
INSERT OVERWRITE TABLE dwd_trade_order_di PARTITION (dt = '2026-10-11')
SELECT order_id, user_id, CAST(total_amount AS DECIMAL(18,2)) AS pay_amount, status
FROM ods_order WHERE dt = '2026-10-11';

怎么选

判断顺序建议是：先看目标库能否承担加工（云数仓通常可以），再看转换是否需要非 SQL 能力（复杂文本解析、特征计算、外部接口调用），最后看团队技能栈。多数场景的答案是「抽取阶段做轻 ETL，库内做 ELT」——源库压力与改口径成本同时被照顾到。