在数据工程里，ETL 和 ELT 是两个很容易被讲“浅”的概念。
很多文章会这么解释：
ETL 是 Extract、Transform、Load。
ELT 是 Extract、Load、Transform。
区别就是 T 和 L 的顺序不同。
这句话没错，但基本等于没说。
真正做过数据平台的人都知道，ETL 和 ELT 的差异不只是流程顺序，而是背后一整套架构假设变了：算力放在哪里、数据以什么形态落地、业务逻辑由谁维护、数据资产能不能重放、成本怎么计量、团队怎么协作，以及最后这套体系能不能支撑 AI、实时分析和数据产品化。
本文我想从架构师视角，把 ETL 和 ELT 这件事讲透一点。
1. 先把概念说清楚：ETL 和 ELT 到底差在哪？
ETL 是：
Extract -> Transform -> Load
抽取 -> 转换 -> 加载
也就是说，数据从源系统抽出来之后，先在一个独立的转换层里清洗、加工、关联、校验、聚合，然后再把处理好的数据加载到目标系统，比如数据仓库、数据集市或者报表库。
ELT 是：
Extract -> Load -> Transform
抽取 -> 加载 -> 转换
也就是说，数据先从源系统抽出来，尽可能原样加载到目标平台，比如云数据仓库、湖仓或者大数据平台，然后再在目标平台内部做转换。
Snowflake 官方文档里对传统 ETL 的描述是：Extract 是从数据源导出数据，Transform 是用规则、合并、查找表或其他方式修改源数据，使其匹配目标，Load 是把转换后的结果导入目标数据库；同时它也明确提到，较新的 ELT 用法强调转换不一定要发生在加载之前，尤其是在 Snowflake 这类支持加载后转换的系统中。
Microsoft Azure 架构文档也讲得很直白：ETL 是把不同来源的数据整合进统一数据存储，转换阶段通常会使用专门的转换引擎；而 ELT 的关键区别在于转换发生在目标数据存储里，使用目标数据存储自身的处理能力来完成转换。
所以，ETL 和 ELT 的核心差异不是“先 T 还是先 L”，而是：
数据转换的计算责任，到底由外部管道承担，还是由目标数据平台承担。
这个判断，会直接影响整套数据架构。
2. 为什么早期大家更喜欢 ETL？
要理解 ETL，就得回到传统数据仓库时代。
早期企业的数据源主要是 ERP、CRM、财务系统、交易系统、日志文件、关系型数据库。数据仓库通常比较昂贵，存储贵，计算贵，网络也没今天这么方便。那个时候，把大量原始数据直接灌进仓库并不现实。
所以最自然的做法是：
这个阶段的代表工具包括 Informatica、DataStage、Microsoft SSIS、Oracle Data Integrator，以及后来很多企业自研的 Spark / SQL / Shell 调度系统。
Microsoft SSIS 官方文档把它定义为构建企业级数据集成和数据转换解决方案的平台，可以从 XML 文件、平面文件、关系型数据源等多种来源抽取和转换数据，然后加载到一个或多个目标。
从架构上看，ETL 有几个非常明显的优点。
第一，它能在入库前控制数据质量。比如脏数据、非法值、重复数据、格式不一致的数据，都可以在进入仓库之前处理掉。
第二，它能减少目标仓库压力。数据仓库只接收已经清洗好的结果，不必承担太多复杂转换。
第三，它适合强治理场景。比如金融、医疗、政务这类业务，某些敏感字段可能不能进入统一数据平台，那么在 ETL 阶段提前脱敏、裁剪、过滤，就是很自然的选择。
第四，它适合目标系统能力弱的情况。如果目标数据库只是一个传统报表库，查询和计算能力有限，那就必须在外部先把数据算好。
这就是 ETL 在很长时间里成为主流的原因。
它本质上是一个“先加工、再入库”的思路。
3. 那为什么后来 ELT 又火了？
ELT 的流行不是因为大家突然喜欢换缩写，而是底层基础设施变了。
过去数据仓库贵，今天云数据仓库和湖仓平台把存储、计算、弹性扩展、SQL 执行能力都做到了平台内部。BigQuery、Snowflake、Redshift、Databricks、Doris、ClickHouse、StarRocks 这些平台，让“先把原始数据放进去，再在里面加工”变得可行。
Google BigQuery 文档直接把 ETL 和 ELT 放在一起讨论，并且明确说，常见选择是要么在加载到 BigQuery 前转换数据，也就是 ETL；要么先把原始数据加载到 BigQuery，再用 BigQuery 做转换，也就是 ELT。Google 还提到，一般推荐大多数客户使用 ELT，因为它把复杂的数据集成拆成“抽取加载”和“转换”两个更可管理的部分，并且能充分利用 BigQuery 的能力在规模化场景下准备、转换和优化数据。
这段话很关键。
ELT 的本质不是偷懒，而是把目标数据平台变成了主要计算引擎。
传统 ETL 里，数据仓库更像“存结果”的地方。
现代 ELT 里，数据仓库或湖仓不只是存储层，而是：
存储层 + 计算层 + 建模层 + 质量控制层 + 血缘管理层 + 服务层
数据先进入 Raw / Bronze 层，再逐步加工成 Staging / Silver / Gold 层，最后服务 BI、指标平台、画像系统、推荐系统、AI 特征、运营系统。
Databricks 在湖仓架构里也采用类似分层思路：原始数据进入 Bronze 层，经过清洗和验证形成 Silver 层，再通过维度建模和聚合形成 Gold 层。
这也是为什么 ELT 和 Lakehouse、Modern Data Stack、Analytics Engineering 经常一起出现。
4. ETL 的技术原理：控制、裁剪、固化
我们先看 ETL 的典型架构。
ETL 的转换引擎可以是 SSIS、DataStage、Informatica、Spark、Flink、AWS Glue、Azure Data Factory，也可以是企业内部自研的数据管道。
AWS Glue 官方文档把它描述为 serverless 数据集成服务，可以帮助用户发现、准备、移动和整合来自多个来源的数据，并支持 ETL、ELT 和流式等多种工作负载。
ETL 的技术重点主要在几个地方。
4.1 数据抽取
抽取可能是全量，也可能是增量。
常见方式包括：
1. 全量抽取
2. 按时间戳增量抽取
3. 按自增 ID 增量抽取
4. 基于 CDC 的变更捕获
5. 基于消息队列的事件消费
6. 基于文件落地的批处理
成熟的 ETL 系统一定要考虑幂等性。也就是说，同一个任务失败后重跑，不应该导致重复写入、重复扣减、重复聚合。
4.2 数据转换
转换是 ETL 的核心。
典型转换包括：
字段类型转换
空值处理
枚举值标准化
时间格式统一
多源数据 Join
事实表和维表关联
去重
聚合
脱敏
数据质量校验
异常数据分流
Microsoft Azure 文档也提到，ETL 的转换通常包括过滤、排序、聚合、关联、清洗、去重和验证等操作。
这里要注意一点：ETL 的转换逻辑往往比较“固化”。
什么意思？
就是转换结果在入仓前就已经确定了。数据被清洗成什么样、哪些字段被保留、哪些字段被丢弃、哪些指标被提前算好，都由 ETL 管道决定。
这有好处，也有坏处。
好处是结果稳定，口径强控制。
坏处是灵活性差。后面业务说“我想看一下原始字段”“我想换一种口径重新算”“我想回溯三个月前的明细”，如果原始数据没留下，就很麻烦。
4.3 数据加载
加载通常要考虑：
批量写入
分区写入
覆盖写入
追加写入
Upsert
Merge
拉链表处理
错误重试
事务一致性
这也是 ETL 的难点之一：外部转换引擎和目标数据库之间的写入边界非常重要。边界没设计好，数据容易出现半成功、重复、错分区、脏分区、任务重跑失败等问题。
5. ELT 的技术原理：落原始数据，再做模型化
ELT 的典型架构大概是这样：
ELT 的第一步通常不是“把数据处理干净”，而是“尽可能可靠地把数据落下来”。
这就是 ELT 和 ETL 心态上的区别。
ETL 的心态是：
我先把数据处理成我现在需要的样子，再入库。
ELT 的心态是：
我先把数据保留下来，再根据不同场景逐步加工。
这带来了几个关键变化。
5.1 原始数据变成资产
在 ELT 里，Raw 层不是垃圾堆，而是可重放的数据资产。
只要 Raw 层保留得好，下游模型错了可以重算，指标口径变了可以重算，新业务需求来了也可以重新建模。
这对于复杂业务非常重要。
比如用户订单数据，今天你只做 GMV 报表，明天可能要做用户生命周期分析，后天可能要做风控画像，再后天可能要做推荐特征。如果早期 ETL 只保留了聚合后的结果，很多后续需求就会被数据形态限制住。
5.2 SQL 变成核心生产语言
ELT 的转换通常发生在数据仓库或湖仓内部，所以 SQL 重新成为核心语言。
dbt 官方文档里说得很清楚：dbt 把原始仓库数据转换成可信的数据产品，开发者写简单的 SQL select 语句，dbt 负责创建模块化、可维护的数据模型；同时它把版本控制、测试、模块化、CI/CD、文档等软件工程实践引入分析工作流。
dbt 的模型文档也提到，执行 dbt run 时，模型会在数据不离开仓库的情况下完成转换；模型通常是一个 SQL select 语句，也可以在部分场景下使用 Python。
这其实代表了一个很大的组织变化。
过去数据转换更多是数据工程师在 ETL 工具里写任务。
现在很多公司开始让数据分析师、分析工程师、数据产品经理也参与数据建模。只要他们懂 SQL，就可以在规范、测试、代码评审和版本控制保护下参与生产级数据模型建设。
这就是 Analytics Engineering 的核心价值。
5.3 转换逻辑从“任务”变成“模型图”
传统 ETL 很容易变成一堆任务：
job_001
job_002
job_003
job_order_stat
job_user_profile
job_daily_report
这些任务之间可能靠调度平台维护依赖，也可能靠人工命名维护依赖。
ELT 更强调模型图：
raw_orders
-> stg_orders
-> int_order_items
-> fct_orders
-> mart_sales_dashboard
每一层模型都表达一个清晰的语义边界。
dbt 的最佳实践也建议，项目应使用版本控制，开发新功能和修复问题时创建 Git 分支，代码变更进入生产分支前应经过 Pull Request 审查；同时建议将原始数据引用集中管理，第一层转换完成字段重命名和类型转换，后续模型都构建在这一层之上，以减少重复逻辑。
这就是 ELT 的一个核心工程价值：数据转换开始具备软件工程特征。
6. ETL vs ELT，不是“谁更先进”，而是谁适合什么场景
很多人喜欢问：
ETL 和 ELT 哪个更好？
这个问题本身就有点误导。
更准确的问题应该是：
在当前业务、数据量、团队能力、合规要求、成本模型和平台能力下，哪种转换策略更合适？
我们可以用一张表来判断。
| 维度 | ETL 更适合 | ELT 更适合 |
|---|---|---|
| 数据治理 | 入库前强清洗、强脱敏 | 入库后分层治理、模型治理 |
| 数据平台能力 | 目标系统计算能力一般 | 目标平台计算能力强 |
| 数据形态 | 需求稳定，口径固定 | 需求变化快，用例多 |
| 成本结构 | 目标存储/计算贵 | 云存储便宜，计算可弹性扩展 |
| 团队能力 | 数据工程团队主导 | 数据工程 + 分析工程协作 |
| 原始数据保留 | 不一定保留 | 强调保留 Raw 层 |
| 合规要求 | 敏感数据不能入中心平台 | 可通过权限、脱敏、分层治理控制 |
| 典型技术 | SSIS、Glue、Spark、Flink | BigQuery、Snowflake、Databricks、dbt、Dataform |
我的经验是，不要做宗教式选择。
真正成熟的数据架构，往往是混合型的。
比如：
1. 敏感数据在入湖前先脱敏，这是 ETL。
2. 原始业务数据尽量落 Raw 层，这是 ELT。
3. 实时风控链路用 Flink 做流式 ETL。
4. 离线指标和数据集市用 dbt / SQL 做 ELT。
5. 最终结果再通过 Reverse ETL 推回 CRM、营销系统、运营系统。
BigQuery 文档也提到，在数据处理和分析之后，可以把结果导出到其他系统中应用，这个过程通常被称为 Reverse ETL。
Microsoft 文档同样把 Reverse ETL 定义为把分析系统中已经转换、建模的数据移动到运营工具和应用里，比如 CRM、营销自动化、客服系统和业务数据库。
所以今天讨论 ETL vs ELT，已经不能只停留在“数据进仓”这一段。
数据真正有商业价值，是因为它还能被激活。
7. 架构师视角：ETL 和 ELT 的本质是计算位置选择
从架构上看，ETL 和 ELT 最核心的问题其实是：
Transform 这个动作，应该在哪里发生？
有三个选择。
7.1 在源系统附近转换
这通常是 ETL 或边缘处理。
适合场景：
敏感数据不能外传
源系统字段需要提前标准化
源系统输出能力有限
数据量太大，必须提前裁剪
比如医疗数据、金融交易数据、用户隐私数据，很多时候不能直接把明细原样落到中心平台，必须先脱敏、裁剪、聚合。
7.2 在独立计算引擎里转换
这也是传统 ETL 和大数据 ETL 的常见做法。
比如用 Spark、Flink、Glue、Dataflow 处理数据，再写入目标系统。
Apache Spark 官方文档把 Spark 定义为面向大规模数据处理的统一分析引擎，支持 Java、Scala、Python、R 等 API，并提供 Spark SQL、MLlib、GraphX、Structured Streaming 等能力。
Apache Flink 官方文档则把 Flink 定义为面向有界和无界数据流的有状态计算框架和分布式处理引擎。
这类引擎适合复杂计算、流式计算、机器学习特征处理、大规模 Join、窗口计算和强状态处理。
7.3 在目标数据平台里转换
这就是 ELT 的核心。
适合场景：
云数仓 / 湖仓能力强
团队 SQL 能力强
下游消费场景多
需要保留原始数据
需要快速迭代业务口径
需要通过 Git / CI / 测试管理模型
BigQuery 通过 Dataform 管理 ELT 转换时，Dataform 可以把 SQL 工作流代码存储在仓库中，并使用 Git 跟踪文件变化；执行时，Dataform 会按对象依赖顺序在 BigQuery 中执行 SQL 查询。
这就是现代 ELT 的典型做法。
不是在仓库里随便写 SQL，而是把 SQL 工程化。
8. ETL 的坑：流程稳定，但容易僵化
ETL 最大的优点是控制强，但它的问题也来自这个优点。
8.1 原始数据丢失
如果 ETL 只保留转换后的结果，那么很多历史细节会消失。
业务口径一变，你就会发现很难重算。
比如原来销售额定义是：
销售额 = 已支付订单金额
后来业务说要改成：
销售额 = 已支付订单金额 - 退款金额 - 优惠券成本
如果原始订单明细、退款明细、优惠券明细没保留，你就只能重新从源系统抽，甚至根本抽不到。
8.2 转换逻辑黑盒化
很多 ETL 工具是图形化配置，刚开始很方便，但时间长了容易变成黑盒。
字段怎么来的？
谁改过？
什么时候改的？
为什么这样 Join？
出问题怎么回滚？
如果没有代码化、版本化、文档化，这些问题都会变成团队债务。
8.3 任务耦合严重
传统 ETL 经常出现这样的情况：
一个任务里同时做抽取、清洗、关联、聚合、落库、通知
短期看很快，长期看很难维护。
一个业务字段变化，可能要改一堆任务。
一个任务失败，也不知道是抽取失败、转换失败，还是加载失败。
8.4 扩展成本高
当数据源越来越多，指标越来越多，业务线越来越多，ETL 管道会不断膨胀。
如果每个需求都新建一个任务，最后就会形成“任务森林”。
这也是很多老数据平台后期难以维护的原因。
9. ELT 的坑：灵活，但容易失控
ELT 听起来很美，但它也不是银弹。
9.1 Raw 层容易变成垃圾场
很多团队听到“先把原始数据落下来”，就真的什么都往里倒。
没有数据目录。
没有字段说明。
没有分层规范。
没有权限控制。
没有质量规则。
结果 Raw 层不是资产，而是数据垃圾场。
9.2 SQL 容易失控
ELT 鼓励用 SQL 建模，但 SQL 如果不工程化，也会变成灾难。
典型问题包括：
一个 SQL 几千行
CTE 套 CTE
重复计算同一个指标
字段命名不统一
时间口径不统一
Join 粒度不一致
没有测试
没有文档
没有血缘
最后每个分析师都有自己的口径，每个部门都有自己的 GMV，每个报表都有自己的用户数。
这不是 ELT 的问题，而是治理缺失的问题。
9.3 成本容易爆炸
ELT 把转换放到目标平台里，目标平台通常是按存储、计算、扫描量、任务运行时间计费。
这意味着：
SQL 写得差，会贵。
分区设计差，会贵。
全量刷新太多，会贵。
重复模型太多，会贵。
没有增量策略，会贵。
所以 ELT 的成本治理非常关键。
一个成熟的 ELT 平台，至少要有：
分区策略
聚簇 / 索引策略
增量模型
任务运行成本监控
慢查询分析
模型复用
数据生命周期管理
9.4 敏感数据风险更高
ELT 常常会把原始数据先落到中心平台。
如果权限控制、脱敏策略、字段分级、审计日志没做好，敏感数据泄露风险会更高。
所以在合规要求强的行业里，ELT 不等于“所有数据原样入仓”。
更合理的做法是：
敏感字段在入仓前脱敏
高风险字段单独加密
Raw 层做严格权限控制
下游只开放脱敏后的 Silver / Gold 层
10. 技术选型：什么时候选 ETL，什么时候选 ELT？
下面给一个比较实用的判断框架。
10.1 适合 ETL 的场景
如果你的情况是这样：
1. 目标数据库计算能力弱
2. 数据必须入库前脱敏或清洗
3. 下游需求非常稳定
4. 数据转换逻辑高度复杂，SQL 不好表达
5. 需要大量流式状态计算
6. 数据进入中心平台前必须裁剪
7. 已经有成熟 ETL 工具和团队
那 ETL 是合理选择。
比如金融反欺诈实时链路、IoT 实时告警、支付交易风控、日志预处理、隐私合规强约束的数据同步，都很适合在入仓前先做转换。
10.2 适合 ELT 的场景
如果你的情况是这样：
1. 使用云数仓或湖仓
2. 原始数据有长期复用价值
3. 业务需求变化快
4. 下游分析场景很多
5. 团队 SQL 能力强
6. 希望通过 Git、测试、文档管理数据模型
7. 希望让分析师参与数据建模
8. 希望模型可以回溯、重算、审计
那 ELT 更合适。
比如增长分析、用户画像、经营分析、财务分析、营销分析、产品行为分析、指标平台、数据集市，都非常适合 ELT。
10.3 最成熟的答案通常是 Hybrid
真正成熟的数据架构，往往不是 ETL 或 ELT 二选一，而是混合策略。
我比较推荐这种分层思路：
入口层：必要的 ETL
- CDC
- 脱敏
- 格式标准化
- 异常数据隔离
- 安全策略执行
Raw / Bronze 层：保留原始或准原始数据
- 可追溯
- 可重放
- 可审计
Silver 层：标准化建模
- 字段统一
- 类型统一
- 主数据关联
- 去重
- 数据质量检查
Gold 层：面向业务消费
- 指标宽表
- 数据集市
- 画像标签
- BI 数据集
- AI 特征
这个思路和湖仓里的 Medallion Architecture 很接近，区别只是每家公司命名不同。
11. ETL 到 ELT，对行业的影响很大
ETL 到 ELT 的变化，不只是技术变化，它改变了整个数据行业的分工。
11.1 数据工程师的角色变了
过去数据工程师的核心工作是：
抽数据
写任务
调度任务
修任务
做报表宽表
保证跑批成功
现在数据工程师越来越像平台工程师：
建设数据底座
设计分层架构
定义数据标准
控制成本
做权限和治理
保障质量
提供自助建模能力
换句话说，数据工程师从“搬运工”变成了“平台建设者”。
11.2 分析工程师出现了
ELT 推动了 Analytics Engineer 这个角色的流行。
这个角色介于数据工程师和数据分析师之间。
他既懂 SQL 和业务，也懂建模、测试、版本控制、数据质量和指标口径。
dbt 之所以能流行，本质上就是因为它把软件工程实践带进了分析建模流程。dbt 官方文档明确提到，它支持版本控制、测试、模块化、CI/CD 和文档等实践，让熟悉 SQL 的数据团队成员可以安全地参与生产级数据管道建设。
这对组织效率影响很大。
以前一个分析需求可能是：
业务 -> 分析师 -> 数据工程师 -> 排期 -> 开发 -> 测试 -> 上线 -> 改口径 -> 再排期
现在可能变成：
业务 + 分析工程师 -> SQL 模型 -> PR Review -> 测试 -> 发布
周期会短很多。
11.3 数据平台厂商的价值上移了
ETL 时代，核心价值在 ETL 工具。
ELT 时代，核心价值逐渐向数据平台本身迁移。
云数仓、湖仓、查询引擎、数据目录、语义层、数据质量、血缘、指标平台、Reverse ETL、特征平台，都开始围绕目标数据平台展开。
BigQuery 在文档中推荐 ELT，并提供 Dataform、BigQuery pipelines、AI-augmented data preparation 等能力来支持加载后转换和数据准备。
这说明一个趋势：
数据平台不再只是存储和查询，它正在变成数据开发、治理、协作和 AI 准备的中心。
11.4 数据从“报表资产”变成“业务操作资产”
传统数仓的终点往往是 BI 报表。
现代数据平台的终点不只是报表，而是业务动作。
比如：
把高价值客户标签推到 CRM
把流失风险用户推到营销系统
把风控特征推到实时决策系统
把商品热度推到推荐系统
把企业知识库推到 RAG 系统
这就是 Reverse ETL、数据产品和 AI 数据底座的价值。
数据不只是被人看，而是被系统使用。
12. 商业价值：ETL / ELT 不是技术洁癖，而是钱的问题
从商业角度看，ETL 和 ELT 的选择会影响四件事。
12.1 上线速度
ELT 通常能更快响应需求，因为原始数据已经在平台里，业务口径可以通过模型快速迭代。
如果每个新需求都要重新改 ETL 管道、重新抽取、重新加工，周期会很长。
12.2 数据复用率
好的 ELT 分层可以让模型复用。
比如：
stg_orders
-> fct_orders
-> mart_sales
-> mart_finance
-> mart_operation
多个业务场景复用同一套事实表和维表，口径更稳定，重复开发更少。
ETL 也能做到复用，但如果架构不规范，很容易变成每个报表一套任务。
12.3 数据可信度
数据可信度来自三件事：
口径统一
质量可测
血缘可追
ELT 如果结合 Git、测试、文档、血缘和代码评审，会更容易把这些能力工程化。
但如果 ELT 只是“大家随便在仓库里写 SQL”，可信度反而会下降。
12.4 成本透明度
ETL 的成本通常体现在服务器、工具 license、开发维护人力和任务运行资源。
ELT 的成本更多体现在云平台计算、扫描量、存储、任务调度和模型冗余。
所以架构师不能只问：
这个方案能不能跑？
还要问：
这个方案每天跑多少钱？
失败重跑多少钱？
全量刷新多少钱？
增加一个业务线多少钱？
换一个口径多少钱？
能回答这些问题，才算真正理解数据平台的商业价值。
13. 未来趋势：ETL 和 ELT 的边界会越来越模糊
我不认为未来会是 ELT 完全取代 ETL。
更可能的趋势是：
Transform 会变成一种策略化能力，根据数据类型、成本、安全、延迟和业务价值，自动选择最合适的位置执行。
未来的数据转换会有几个明显方向。
13.1 AI 辅助数据转换
AI 会参与字段识别、数据清洗建议、Schema Mapping、SQL 生成、质量规则生成、异常检测和文档生成。
BigQuery 文档已经提到，BigQuery 数据准备能力可以用 Gemini 生成的转换建议来帮助清洗数据，并支持应用转换、数据质量规则、标准化、数据丰富和自动化 schema mapping。
这不意味着数据工程师会被替代。
恰恰相反，越是 AI 辅助，越需要清晰的数据契约、模型边界、测试规则和治理体系。否则 AI 只会更快地产生更多不可控的数据逻辑。
13.2 语义层会更重要
过去大家争的是“数据从哪里来”。
未来大家争的是“指标到底怎么算”。
比如：
活跃用户
新增用户
留存率
GMV
净收入
转化率
客户生命周期价值
这些指标如果没有统一语义层，就会在不同报表、不同模型、不同团队里反复分裂。
ELT 让建模更灵活，但也更需要指标治理。
13.3 Lakehouse 会继续推动混合架构
湖仓架构把数据湖的低成本、开放格式和数据仓库的查询、治理、事务能力结合起来，天然适合“Raw -> Clean -> Curated”的分层模型。
Databricks 的湖仓参考架构中，数据通常存储在云存储系统中，ETL 管道通过 Medallion Architecture 以 Delta 表或 Iceberg 表等形式管理数据，并使用 Spark 和 Photon 做转换和查询。
这类架构下，ETL 和 ELT 的边界会更加模糊。
同一套平台里，既可以做流式 ETL，也可以做仓内 ELT，还可以做 ML 特征工程和 AI 应用数据准备。
13.4 数据转换会更贴近实时
过去很多数据平台是 T+1。
现在业务越来越希望接近实时：
实时风控
实时推荐
实时营销
实时库存
实时监控
实时经营看板
这会让 Flink、Spark Structured Streaming、Kafka、CDC、实时湖仓、流批一体架构更加重要。
Apache Flink 官方文档强调它可以处理有界和无界数据流，并支持有状态计算；Spark 官方文档也把 Structured Streaming 列为增量计算和流处理能力之一。
未来很多场景不会简单说“我是 ETL”或“我是 ELT”，而是：
实时链路做轻量转换
湖仓 Raw 层保留明细
仓内模型做指标加工
服务层输出业务动作
13.5 面向 AI 的数据转换会成为新战场
生成式 AI 和企业 RAG 让数据转换多了一个新目标：不只是生成表，还要生成可被模型消费的知识。
这会带来新的转换对象：
文档切分
Embedding
向量索引
权限继承
知识去重
实体抽取
关系抽取
事实校验
上下文拼接
这些东西和传统数仓建模不完全一样，但本质仍然是 Transform。
所以未来的数据转换策略会从：
面向报表的 Transform
扩展到：
面向业务决策的 Transform
面向 AI 推理的 Transform
面向运营动作的 Transform
面向数据产品的 Transform
这也是 ETL / ELT 继续演进的最大潜力。
14. 一个实用的落地建议：不要先选工具，先设计数据分层
很多公司做数据平台，一上来就问：
我们用 dbt 还是 Spark？
用 BigQuery 还是 Snowflake？
用 Flink 还是 Glue？
用 ETL 还是 ELT？
这其实顺序反了。
更合理的顺序应该是：
1. 明确业务目标
2. 梳理数据源
3. 定义数据分层
4. 确定敏感数据策略
5. 设计数据契约
6. 设计转换位置
7. 再选择工具
我比较推荐这样设计：
Raw Layer
- 保留源系统原始结构
- 只做最小必要处理
- 记录抽取时间、源系统、批次号
Staging Layer
- 字段重命名
- 类型转换
- 时间标准化
- 枚举值统一
- 单表粒度清洗
Intermediate Layer
- 多表关联
- 复杂业务逻辑
- 主数据映射
- 事实明细构建
Mart Layer
- 面向业务主题
- 面向指标消费
- 面向报表和应用
- 面向 AI / 特征服务
Semantic Layer
- 统一指标定义
- 权限控制
- 查询服务
- 指标复用
如果你的平台是传统数据库，可能更偏 ETL。
如果你的平台是云数仓或湖仓，可能更偏 ELT。
如果你有实时链路、隐私约束和多业务分析，那大概率就是混合架构。
15. 最后总结：ETL 和 ELT 的真正区别
ETL 和 ELT 的区别，可以总结成一句话：
ETL 是先把数据变成目标系统需要的样子，再入库；ELT 是先把数据放进强大的目标平台，再根据业务不断建模。
ETL 更强调控制。
ELT 更强调灵活。
ETL 适合强治理、强合规、目标平台能力有限、需求稳定的场景。
ELT 适合云数仓、湖仓、需求快速变化、多团队协作、数据资产需要长期复用的场景。
但真正成熟的架构不会迷信任何一种范式。
架构师真正要做的，不是争 ETL 和 ELT 谁先进，而是回答这几个问题：
哪些数据必须提前处理？
哪些数据应该保留原始形态？
哪些转换适合在流式引擎里做？
哪些转换适合在仓库里做？
哪些指标需要统一语义？
哪些模型需要版本控制？
哪些任务要增量？
哪些数据要脱敏？
哪些成本要监控？
哪些结果要回流业务系统？
当你能回答这些问题时，ETL 和 ELT 就不再是面试八股，也不是工具选型争论，而是数据架构的核心设计能力。
我的判断是：
未来不是 ETL 消失，也不是 ELT 统治一切，而是数据转换会变成一种更智能、更分层、更工程化、更贴近业务价值的能力。
谁能把 Transform 这件事做好，谁就能真正把数据从“存起来”推进到“用起来”。
