一文讲透数据加工流程
做数据平台时，ETL几乎是绕不开的一个词。
但现在又经常看到：
ELT、ETLT、Reverse ETL、实时ETL……
很多人记住了几个缩写，却没有真正理解它们之间到底差在哪里。
其实ETL、ELT、ETLT讨论的根本不是三个字母怎么排列，而是一个非常核心的数据架构问题：
- 数据应该在哪里加工？
- 是在进入数据仓库之前就清洗好？
- 还是先把原始数据完整保存下来，再利用数仓算力处理？
- 或者一部分转换放在进入平台之前，另一部分留到进入平台以后？
这个问题看起来只是技术选择，实际上会直接影响：
数据时效、计算成本、原始数据保留、数据质量、指标迭代，以及整个平台后期的维护难度。
在正式展开之前，先分享一套《数据仓库建设解决方案》，里面涉及数据集成、数据仓库、数据治理、数据平台建设等内容。如果正在搭建数据底座，或者正在梳理ETL任务，可以结合本文一起看。
一、别先背ETL，先搞清楚E、T、L到底在干什么
ETL其实只包含三个动作。
E：Extract，抽取。
从业务系统中把数据拿出来。
企业里的数据来源可能非常复杂：
ERP里的订单、CRM里的客户、MES里的生产数据、数据库日志、Excel文件、API接口，甚至Kafka里的实时消息。
第一步解决的是：
数据从哪里来，以及怎样稳定地拿到。
T：Transform，转换。
把原始数据变成可使用的数据。
这一层包含的动作很多，例如：
- 字段类型转换；
- 空值和异常值处理；
- 数据去重；
- 编码统一；
- 多表关联；
- 主数据映射；
- 金额、数量等指标计算；
- 行列转换；
- 聚合汇总。
真正复杂的数据加工，大部分都发生在这里。
L：Load，装载。
把处理后的数据写入目标端。
目标端可能是ODS、数据仓库、数据湖、ClickHouse、StarRocks，也可能是某个业务数据库。
因此，ETL、ELT和ETLT其实都有E、T、L。
真正发生变化的，是T的位置。
实际做数据集成时，这一点非常重要。比如企业同时需要接Oracle、MySQL、文件和接口数据，并不一定要先决定“整个项目采用ETL还是ELT”。
在 FineDataLink 5.0 里，先把不同数据源接入同一条数据开发链路，再根据任务本身决定哪些转换在同步过程中完成、哪些逻辑留给目标数仓。架构不是先选一个缩写，再强迫所有任务遵守，而是让不同类型的转换待在合适的位置。
二、ETL：先加工，再把“成品数据”送进数仓
传统ETL的顺序是：
Extract → Transform → Load
也就是：
抽取 → 转换 → 装载。
假设企业需要把ERP中的销售订单同步到数据仓库。
原始数据中可能存在：
客户编码不统一、日期格式不同、金额字段为空、测试订单没有剔除、商品编码和主数据不一致等问题。
ETL会先处理这些问题：
抽取数据 → 清洗 → 标准化 → 关联 → 计算 → 写入目标表。
进入数据仓库的数据，已经是一轮加工后的结果。
这也是传统ETL最明显的特点：
数据先变成“合格产品”，再进入目标系统。
这种方式特别适合几类场景。
第一，目标库只希望接收相对干净的数据。
比如核心财务库、监管库或者经营主题库，不希望大量脏数据直接进入正式数据层。
第二，必须在进入目标系统之前处理敏感信息。
例如手机号、身份证号、银行卡号等字段，在跨环境流转前就需要进行脱敏或裁剪。
第三，目标端计算能力有限。
传统数据库如果既负责查询，又承担大量关联、清洗和聚合，很容易影响业务性能。
所以早期数仓体系中，常常把计算放到独立ETL引擎。
但ETL的问题也很明显：
T挡在了L前面。
只要Transformation越来越重，Load就必须等待。
假设每天只有100万条数据，这个问题并不明显。
可如果每天新增几十亿条日志，同时还要求10分钟甚至1分钟更新一次，所有数据都必须先经过复杂计算再入仓，整条链路延迟就会不断增加。
这也是ELT逐渐兴起的重要原因。
三、ELT：先把原始数据存下来，再利用目标平台加工
ELT的顺序变成：
Extract → Load → Transform
也就是：
先拿数据，再存数据，最后处理数据。
这个变化看起来只是T和L换了位置，背后的数据架构思想却发生了很大变化。
ELT首先强调：
原始数据本身也是一种资产。
例如今天业务规定：
“过去12个月购买过商品的客户，属于活跃客户。”
半年后规则改成：
“过去6个月发生交易，并且累计消费超过1万元。”
如果过去ETL只保留了最终的“活跃/非活跃”标签，而没有保存交易明细，那么新规则出现以后，历史数据就很难重新计算。
但如果采用ELT，把原始订单先完整落到ODS、Raw Layer或者数据湖中，后面业务规则变化以后，就可以重新加工。
因此ELT特别适合：
数据量大、计算能力强、业务逻辑变化频繁、需要保留原始数据的场景。
云数仓、MPP数据库、Spark、湖仓一体架构越来越普及以后，目标平台本身已经具备很强的计算能力。
这时候再把大量计算全部塞到数据同步工具里，反而可能没有必要。
比如在实际的数据建设中，一条订单流水可以先借助 FineDataLink 5.0 持续同步到ODS，先把源端变化可靠地留下来；
到了DWD、DWS层，再利用SQL或者数仓计算资源统一完成客户维度关联、指标加工和公共口径沉淀。这样一来，数据采集与业务建模就不会被绑在同一个任务里，后续某个指标发生变化，也不需要重新从源系统抽一遍数据。
但ELT也有一个很大的误区：
很多人把“先Load”理解成“什么都不处理，先扔进去再说”。
真正成熟的ELT并不是无条件保留所有垃圾数据。
例如：
结构完全错误的数据、必须脱敏的字段、无法解析的消息、明显不合法的记录，
依然可能需要在进入平台之前处理。
于是现实项目中，又逐渐形成了ETLT这种混合模式。
四、ETLT：先做必要处理，落库以后再完成业务转换
ETLT可以理解为：
Extract → Transform → Load → Transform
更准确一点，可以写成：
E → t → L → T
为什么前一个T可以写成小写？
因为前后两个Transform承担的职责通常并不一样。
前面的转换更偏向：
技术型转换。
例如：
字段类型修正、JSON解析、明显异常数据过滤、敏感字段脱敏、基础编码转换、CDC事件整理。
这些工作解决的是：
这批数据能不能安全、规范地进入数据平台。
而后面的Transform更偏向：
业务型转换。
例如：
客户分层、收入计算、利润口径、主题宽表、公共指标、区域销售汇总、经营分析模型。
它解决的是：
进入平台的数据怎样变成真正可分析的数据。
举一个实时订单场景。
源数据库发生变化后，通过CDC捕获订单新增、修改和删除。
进入数据平台以前，可以先完成：
事件解析 → 字段转换 → 必要过滤 → 基础标准化。
随后把订单明细写入ODS。
再由后续任务完成：
ODS → DWD → DWS → ADS。
这其实就是一种典型的ETLT思路。
如果链路里既有实时同步又有离线数仓加工，FineDataLink 5.0 的角色也可以按这个边界来拆：实时数据管道负责把源端变化持续送到目标端，并处理进入平台之前必须解决的问题；后续数据开发任务再承担跨表关联、主题加工和汇总计算。
这样处理以后，实时链路不会因为塞入过多业务规则而越来越重，复杂业务口径也能够集中留在数仓层维护。
需要注意的是：
ETLT不像ETL、ELT那样是一个严格统一的标准术语。
实际项目里，人们更多是用它描述一种：
前置轻转换 + 原始数据落地 + 后置重转换
的混合数据加工模式。
而这种模式，其实越来越符合现代企业的数据架构现实。
五、ETL、ELT、ETLT，到底应该怎么选？
真正做项目时，不建议问：
“我们到底应该选择ETL还是ELT？”
因为一个企业完全可能同时存在三种模式。
真正应该判断的是：
- 这项转换能不能等到Load以后？
如果不能，就必须前置。
例如：
敏感字段必须脱敏以后才能离开生产环境，那么这个T不能等。
- 这项逻辑以后会不会经常变化？
如果会，尽量后置。
比如：
客户等级、利润口径、渠道分类、有效订单规则。
因为业务逻辑越容易变化，越不应该过早“写死”在采集链路里。
- 原始数据有没有保留价值？
如果未来需要：
历史回溯、模型训练、指标重算、问题排查、算法分析，
那就应该尽可能保留原始数据。
- 计算应该放在哪里成本最低？
这里说的成本不只是服务器成本。
还包括：
开发成本、维护成本、任务耦合、计算资源和链路延迟。
如果目标数仓本身计算能力很强，那么大型Join和聚合未必需要放在ETL引擎。
- 数据到底要求多快？
T+1报表、小时级经营分析和秒级设备监控，根本不是一个问题。
对实时链路来说，通常应该尽量保证：
采集路径短、转换动作少、同步过程稳定。
复杂计算可以适当后移。
所以真正成熟的数据架构不是：
ETL和ELT二选一。
而是：
不同数据、不同阶段、不同Transformation，分别选择合适的位置。
六、真正困难的不是ETL，而是让整条数据链路长期稳定
很多企业第一次建设数据平台时，最关注的是：
数据能不能跑通？
但真正进入生产以后，问题会迅速变成：
它能不能一直跑？
例如凌晨2点某个任务失败。
后面的十几个任务怎么办？
源库新增一个字段，下游是否同步变化？
5000万条数据同步到一半断了，是重新开始，还是从断点继续？
某条异常记录失败，是整批任务停掉，还是进入脏数据队列？
如果上游数据晚到半小时，下游指标什么时候更新？
真正的数据加工链路，实际上应该是：
数据源 → 抽取 → 转换 → 装载 → 调度 → 依赖 → 监控 → 告警 → 重试 → 补数 → 校验。
只讨论ETL、ELT，其实只讨论了中间很小的一部分。
当任务规模从十几条增长到几百、几千条以后，开发人员真正花时间的，往往已经不是再写一个字段转换，而是排查：
哪条链路失败了、为什么失败、影响到哪里、能不能恢复。
这也是数据集成平台进入生产以后价值最明显的地方。比如用 FineDataLink 5.0 管理大量数据任务时，除了数据同步和转换本身，还需要把任务调度、上下游依赖、运行记录、异常处理和失败重跑一起纳入管理。否则即便每一条ETL逻辑都写得没问题，几百条任务叠在一起以后，最终依然可能变成一套很难维护的“数据脚本森林”。
所以企业真正需要建设的，从来不只是：
ETL流程。
而是：
Data Pipeline——可长期运行的数据生产链路。
七、最后，用三个问题真正理解ETL、ELT和ETLT
如果以后再遇到ETL、ELT、ETLT，不需要死记三个缩写。
只需要问三个问题。
第一，数据什么时候进入目标平台？
先加工完再进，是ETL。
先进入平台再加工，是ELT。
第二，原始数据是否需要保留？
越强调原始数据沉淀、历史重算和灵活建模，架构通常越偏向ELT。
第三，Transformation应该全部放在同一个地方吗？
多数现代数据平台的答案其实是：
不应该。
安全、格式、协议、基础质量问题，可以前置。
指标、主题、模型和业务口径，可以后置。
所以ETLT真正值得理解的地方，并不是多出来一个字母T，而是它告诉我们：
数据转换本身也应该分层。
ETL代表的是：
先做饭，再端上桌。
ELT代表的是：
先把食材放进厨房，需要什么再做什么。
ETLT则是：
食材先完成必要的清洗和预处理，再进入厨房完成正式加工。
三种模式没有绝对的先进与落后。
真正优秀的数据架构，也不是坚定地站在ETL或者ELT某一边。
而是能够判断：
什么数据应该尽快落地，什么规则应该提前执行，什么逻辑应该留到数仓，什么原始信息必须保留下来。
理解了这一点，你真正理解的就不只是ETL。
而是整个数据加工体系背后最关键的架构原则：
把每一次Transform，放在最合适的位置。
浙公网安备 33010602011771号