我做了十年数据集成，被问得最多的问题里，"ETL 和 ELT 到底怎么选"一定排进前三。这个问题之所以难回答，是因为大多数文章都在讲"ETL 和 ELT 的区别"，却没人讲清楚"什么时候该用哪个"。
ETL 与 ELT 双核架构拆解，FineDataLink 5.0 计算下推与引擎计算的场景选择
一、先把结论说在前面
我直接说结论：ETL 和 ELT 不是二选一的路线之争，而是两种计算位置的选择。ETL 是"引擎计算"，数据在到达目标库之前就被引擎加工好；ELT 是"计算下推"，数据原样进目标库，加工交给目标库的算力去完成。 一个成熟的平台应该同时具备这两种能力，让你根据场景灵活切换，而不是逼你站队。
这条结论下面，藏着三个更具体的判断：
其一，ETL 和 ELT 的核心差异，不在字母顺序，而在"计算发生在哪里"。 ETL 的 T（Transform）发生在中间的 ETL 引擎里，ELT 的 T 发生在目标库（通常是数仓）里。计算位置不同，决定了它们在性能、灵活性、成本上的表现完全不同。
第二，"计算下推"是 ELT 的灵魂，但下推不是万能的。 下推能利用目标库（尤其是 MPP 数仓）的分布式算力，处理海量数据时优势明显；但如果目标库不是 MPP、或者转换逻辑里有目标库不支持的复杂函数，下推就会失效，还得回到引擎计算。
第三，双核架构的价值，是让你"按场景选核"，而不是"被迫用单一引擎硬扛"。 判断一个数据集成平台是否成熟，看它能不能在同一个任务里、甚至同一个流程里，灵活地决定"这段逻辑下推到目标库算，那段逻辑在引擎里算"。
下面我把这套双核架构拆开，讲清楚计算下推和引擎计算各自的适用场景，以及怎么选。
二、先讲一个让我想明白"双核"的项目
2023 年，我参与了一家新能源企业的数据平台建设。这家企业的数据量很有意思：一部分是设备采集的时序数据，单表几亿行，量很大但结构简单；另一部分是 ERP、MES 的业务数据，量不大但转换逻辑极其复杂，涉及几十张表的关联、各种业务规则的清洗。
一开始，团队想统一用 ELT，把所有数据都原样灌进数仓，再在数仓里做加工。结果发现两个问题：业务数据的复杂转换逻辑，在数仓里写 SQL 又长又难维护，而且有些业务规则（比如复杂的字符串处理、正则匹配）数仓的 SQL 引擎支持得不好；反过来，设备数据如果先拉到 ETL 引擎里加工再写数仓，中间的传输和加工时间又太长。
后来我们换成了双核思路：设备数据走 ELT，计算下推到 MPP 数仓，利用数仓的分布式算力做海量数据的清洗和聚合；业务数据走 ETL，在引擎里做复杂的转换，加工好再写数仓。 两条链路各用各的核，各发挥各的优势，问题就解决了。
这个项目让我记住一件事：ETL 和 ELT 没有谁更先进，只有谁更适合当前的数据特征和计算需求。 海量简单数据，下推更划算；复杂业务逻辑，引擎计算更灵活。分清楚数据特征，就分清楚了该用哪个核。
三、先把 ETL 和 ELT 的架构差异讲透
ETL 和 ELT 的差异，我用一张表讲清楚。这张表里，最核心的是"计算位置"这一行，它是理解其他所有差异的钥匙。
| 对比维度 | ETL（引擎计算） | ELT（计算下推） |
|---|---|---|
| 计算位置 | 中间的 ETL 引擎 | 目标库（数仓） |
| 数据流向 | 源库 → 引擎加工 → 目标库 | 源库 → 目标库 → 目标库内加工 |
| 计算资源 | 引擎集群的算力 | 目标库的分布式算力 |
| 适用数据量 | 中小数据量、复杂转换 | 海量数据、简单转换 |
| 转换灵活性 | 高，支持复杂逻辑、自定义脚本 | 中，受限于目标库 SQL 能力 |
| 目标库要求 | 无特殊要求 | 需要目标库有较强算力（如 MPP） |
| 数据落地时机 | 加工后落地 | 原样落地，再加工 |
| 典型场景 | 业务系统集成、复杂清洗 | 数仓建设、海量数据入湖 |
这张表里，最容易被人误解的是"计算资源"这一行。很多人以为 ELT 省掉了中间的引擎，成本更低；实际上，ELT 是把计算成本从引擎转移到了目标库。如果你的目标库是 MPP 数仓，这个转移是划算的，因为数仓的分布式算力处理海量数据更高效；但如果你的目标库只是个普通的业务库，把海量计算压给它，反而会拖垮业务库的性能。
所以 ELT 的"下推"，前提是目标库有足够强的算力。 目标库是 MPP 数仓，下推划算；目标库是普通业务库，下推要谨慎。这个前提，很多讲 ELT 的文章都不提，导致不少人盲目上 ELT，结果把业务库压垮了。
四、计算下推的三种典型形态
计算下推不是"一个开关"，而是有不同粒度的。理解这三种形态，你才能精准地控制"哪些逻辑下推、哪些逻辑留在引擎"。
形态一：整体下推。 整个转换逻辑都下推到目标库，引擎只负责把源数据搬过去，加工全部在目标库里用 SQL 完成。这种形态最彻底，也最依赖目标库的算力和 SQL 能力，适合海量数据、逻辑相对简单的场景。
形态二：部分下推。 转换逻辑拆成两段，适合下推的部分（比如简单的过滤、聚合、关联）下推到目标库，不适合下推的部分（比如复杂字符串处理、自定义函数）留在引擎里。这种形态最灵活，也是实际项目里用得最多的。
形态三：不下推。 所有转换都在引擎里完成，目标库只负责存储。这种形态就是传统的 ETL，适合数据量不大、但转换逻辑极其复杂的场景。
理解这三种形态的关键，是意识到"下推"是一个可以精细控制的过程，而不是一个非黑即白的选择。 一个成熟的平台，应该让你能指定哪些算子下推、哪些算子留在引擎，而不是只能"全下推"或"全不下推"。
四点五、计算下推失效的五个典型场景
下推不是万能的，有五个场景，下推会失效或得不偿失。提前认清这五个场景，能帮你避开"盲目下推"的坑。
场景一：目标库不支持某个函数。 比如复杂的正则匹配、特定的字符串处理函数、或者自定义的 UDF，目标库的 SQL 引擎不支持。这时候这段逻辑必须留在引擎里算，硬下推只会报错。
场景二：转换逻辑依赖多源关联。 如果转换需要把来自 MySQL、Oracle、文件等多个异构源的数据先关联再加工，而下推只能针对单一目标库，那么多源关联的部分就没法下推，只能在引擎里完成。
场景三：目标库不是分布式架构。 如果目标库是传统的集中式单机数据库，下推的收益很有限，甚至可能因为把海量计算压给单机而拖垮性能。下推的前提是目标库有分布式算力。
场景四：转换逻辑里有引擎独有的能力。 比如依赖 Python 脚本做的复杂数据处理、依赖流程控制节点做的条件分支，这些是引擎独有的能力，目标库的 SQL 表达不了，只能留在引擎。
场景五：数据量其实不大。 如果数据量只有几百万行，下推和引擎计算的性能差异微乎其微，这时候硬上 ELT 反而增加了目标库的方言适配复杂度，得不偿失。很多团队在数据量还没起来的时候就急着上 ELT，结果既没享受到下推的性能红利，还多背了一层方言适配的维护负担，属于典型的"为了架构而架构"。
这五个场景，本质上都在提醒同一件事：下推要"看菜下饭"，不是"越多越好"。 下推的价值，只在"海量数据 + 目标库算力强 + 逻辑简单"这三个条件同时满足时才最大化。条件不满足，就该回到引擎计算。
四点六、一个性能对比的实测思路
很多团队纠结 ETL 和 ELT 的性能差异，但又不愿意自己测。我给你一个可复用的实测思路，不用太复杂，一个下午就能测出结论。
步骤一，准备数据。 造一张单表 5000 万行左右的测试表，字段包含几个数值列、几个字符串列，模拟真实的设备数据或订单数据。
步骤二，设计转换。 设计一个典型的转换逻辑：过滤掉无效数据、做几个字段的映射和类型转换、按某个维度做一次聚合。这个逻辑要足够典型，能代表你日常的加工需求。
步骤三，分别跑两遍。 同样的数据和转换逻辑，用 ETL 引擎计算跑一遍，再用 ELT 下推跑一遍，记录各自的耗时、资源占用。
步骤四，对比结论。 如果 ELT 下推明显更快（通常是海量数据 + MPP 数仓的场景），说明你的场景适合下推；如果两者差异不大，甚至 ETL 更快，说明你的数据量还没到需要下推的程度，用 ETL 更简单。
这个实测思路的价值，是让你用自己真实的数据特征做决策，而不是听厂商或文章的一面之词。 数据量、转换复杂度、目标库算力，这三个变量在你的环境里到底是什么组合，只有实测才知道。别偷懒，花一个下午测一下，能省下后面几个月的返工。
五、FineDataLink 5.0 的双核是怎么实现的
FineDataLink 5.0 的 ETL+ELT 双核，核心是两套开发模式：步骤流（ETL）和数据流（ELT）。
步骤流，对应 ETL 引擎计算。 它是"逐步加工"的模式，数据从源库读出来，经过一个个步骤（数据过滤、字段设置、关联、聚合、脚本等）逐步加工，最后写入目标库。步骤流的优势是灵活，每一步都能用可视化节点配置，还能嵌入 SQL 脚本、Shell 脚本、Python 脚本，处理复杂业务逻辑得心应手。它适合数据量中等、但转换逻辑复杂的场景。
数据流，对应 ELT 计算下推。 它是"声明式"的模式，你把数据从哪来、要做什么转换、写到哪去声明清楚，平台自动把转换逻辑翻译成目标库能执行的 SQL，下推到目标库去计算。数据流的优势是高效，利用目标库（尤其是 MPP 数仓）的分布式算力处理海量数据，性能远超在引擎里逐行加工。它适合数据量大、但转换逻辑相对简单的场景。
双核的关键，是"按场景选核"，而不是"被迫站队"。 在 FineDataLink 里，你可以根据数据特征，为不同的任务选择不同的模式：设备时序数据用数据流下推，业务数据用步骤流引擎计算。同一个平台、同一套调度、同一套监控，两种核自由切换。
我特别想强调一个细节：数据流的下推，不是简单的"把 SQL 拼好扔给目标库"。 它要处理很多工程细节——目标库的方言适配（不同数仓的 SQL 语法不同）、下推失败的降级（目标库不支持某个函数时，自动回到引擎计算）、以及下推边界的可视化呈现。这些细节，决定了"计算下推"是真正好用，还是只是宣传话术。
六、怎么选：一个场景选择框架
ETL 和 ELT 怎么选，我总结了一个四问框架。回答这四个问题，答案基本就出来了。
问题一：数据量有多大？ 单表几亿行、几十亿行的海量数据，优先考虑 ELT 下推，利用数仓的分布式算力；单表几百万行以内的中等数据，ETL 引擎计算完全扛得住。
问题二：转换逻辑有多复杂？ 逻辑简单（过滤、聚合、简单关联），适合下推；逻辑复杂（几十张表关联、复杂字符串处理、自定义函数、正则匹配），适合引擎计算，因为引擎的脚本节点更灵活。
问题三：目标库是什么？ 目标库是 MPP 数仓（如 Doris、StarRocks、ClickHouse、GaussDB 等），下推划算；目标库是普通业务库，下推要谨慎，别把业务库压垮。
问题四：团队的技术栈是什么？ 团队擅长写 SQL，ELT 上手快；团队擅长可视化拖拽和脚本开发，ETL 更顺手。这个因素虽然排在最后，但在实际选型里往往很关键。
我把这四个问题的组合，整理成一张决策表：
| 数据量 | 转换复杂度 | 目标库类型 | 推荐模式 | 理由 |
|---|---|---|---|---|
| 海量 | 简单 | MPP 数仓 | ELT 下推 | 利用分布式算力，性能最优 |
| 海量 | 复杂 | MPP 数仓 | 部分下推 | 简单部分下推，复杂部分引擎 |
| 中等 | 复杂 | 任意 | ETL 引擎 | 脚本灵活，逻辑好维护 |
| 中等 | 简单 | 任意 | 两者皆可 | 按团队习惯选 |
| 海量 | 任意 | 普通业务库 | 谨慎下推 | 避免压垮业务库 |
这张决策表的核心，是"数据量"和"转换复杂度"这两个维度的组合。 海量简单 → 下推；中等复杂 → 引擎；海量复杂 → 部分下推。抓住这个组合，就不会选错。
七、双核架构在信创环境下的特殊考量
信创环境下，双核架构的选型还要多考虑一层——国产数据库的算力和 SQL 兼容性。
信创替代后，很多企业的目标库从 Oracle 换成了达梦 DM8、人大金仓 KingbaseES、GaussDB、OceanBase 这些国产数据库。这些数据库里，有的具备不错的分布式算力（比如 GaussDB、OceanBase 的分布式版本），适合下推；有的更偏传统集中式架构，下推的收益有限。
这就带来一个选型要点：信创环境下，ELT 下推能不能发挥优势，取决于你选的国产数据库有没有足够的算力。 如果国产数据库是分布式架构、算力强，下推划算；如果是集中式架构、算力一般，就要谨慎下推，更多依赖引擎计算。
同时，国产数据库的 SQL 方言和 Oracle、MySQL 有差异，下推时平台要能正确适配这些方言。FineDataLink 5.0 对达梦 DM8、KingbaseES、OceanBase、GaussDB、PolarDB-X 都有深度适配，这一点在信创环境里是硬门槛——如果平台不能正确适配国产数据库的方言，下推出来的 SQL 就会报错，双核架构在信创环境里就形同虚设。
七点半、双核架构的运维与团队能力建设
双核架构落地之后，运维和团队能力是两个容易被忽视、但决定成败的环节。很多团队上了双核，却因为运维跟不上、团队只会一种模式，最后又退回到单一模式。
先说运维。双核架构的运维，难点在于"两套计算逻辑的监控要统一"。ETL 引擎计算和 ELT 下推计算，运行在不同的地方，但监控、告警、血缘追踪必须统一在一个平台里。如果 ETL 任务在引擎里跑、ELT 任务在数仓里跑，监控却是两套，运维成本会翻倍。双核的价值，一半在"能切换"，一半在"能统一运维"。 切换灵活但运维割裂的双核，还不如单一模式省心。
再说团队能力。双核架构要求团队同时具备两种能力：既能用步骤流做复杂转换，也能用数据流做下推。这对团队提出了更高的要求，但也是双核架构的隐性收益——它倒逼团队把"数据加工"这件事想得更清楚：哪些数据适合下推、哪些逻辑适合引擎，这种判断力本身就是数据团队的核心能力。 团队如果只会一种模式，双核就形同虚设。
我的建议是，在引入双核架构的同时，同步做两件事：一是统一监控和血缘，让两种模式的任务在同一个平台里可观测、可追溯；二是培养团队"按数据特征选核"的判断力，而不是把双核当成"多一个按钮"。这两件事做好了，双核架构才能真正发挥价值。判断力的培养没有捷径，靠的是团队在一次次真实场景里反复验证"下推快还是引擎快"，把结论沉淀成团队的公共经验，而不是只停留在架构师一个人的脑子里。
七点半又半、一个完整的落地节奏
双核架构的落地，我建议分三步走，不要一上来就两种模式齐上。
阶段一：先跑通 ETL。 用步骤流把核心的业务数据集成链路跑通，解决"数据能集成"的问题。这个阶段不追求下推，先把引擎计算的模式用熟。
阶段二：引入 ELT。 在 ETL 稳定的基础上，识别出海量数据的场景（比如设备时序数据、日志数据），用数据流下推处理。这个阶段的目标是"海量数据能高效加工"，验收标准是：海量数据的加工性能有明显提升。
阶段三：按场景分流。 建立"按数据特征选核"的规范，让团队形成肌肉记忆：海量简单数据下推，复杂业务逻辑引擎计算。这个阶段的目标是"双核各得其所"，验收标准是：团队能自主判断该用哪个核，而不是每次都来问架构师。
这个落地节奏的关键，是"先单核，再双核，最后按场景分流"。 不要一上来就双核齐上，那样团队会无所适从。先把一种模式用熟，再引入另一种，最后形成判断力，这才是双核架构的正确打开方式。
七点七、双核架构最常见的四个认知误区
关于 ETL 和 ELT，市面上流传着不少似是而非的说法。这四个误区，我几乎在每个项目里都能遇到，提前认清能少走很多弯路。
误区一："ELT 是未来，ETL 已经过时了。" 这个说法忽略了"计算位置"这个本质。ELT 只是把计算从引擎搬到了目标库，它并没有让"转换"这件事消失，也没有让转换变得更简单。对于复杂业务逻辑，ETL 的引擎计算依然是最灵活的选择。两者是并存关系，不是替代关系。
误区二："ELT 更省钱，因为省掉了中间的引擎。" 这是把成本算错了。ELT 省掉了引擎的算力成本，但把计算成本转移到了目标库。如果目标库是 MPP 数仓，这个转移划算；如果目标库是普通业务库，把海量计算压给它，轻则性能下降，重则拖垮业务库。成本是"转移"了，不是"消失"了。
误区三："下推就是性能最优，能下推就尽量下推。" 下推的性能优势，只在"海量数据 + 目标库算力强 + 逻辑简单"三个条件同时满足时才成立。条件不满足，下推可能反而更慢、更复杂。下推要"看菜下饭"，不是"越多越好"。
误区四："双核就是两个按钮，团队随便用哪个都行。" 双核的价值，在于"按数据特征选核"的判断力，而不是"多一个按钮"。如果团队不理解两种模式的适用边界，双核反而会造成混乱——同一个数据，有人用 ETL 做、有人用 ELT 做，口径还不一致。
这四个误区，本质上都在提醒同一件事：别被"ELT 更先进""下推更高效"这类口号带偏，回到"计算位置"这个本质去判断。 理解计算发生在哪里，理解目标库的算力，理解数据特征，你才能做出正确的选择。
八、常见问题解答
问：ETL 和 ELT 到底哪个更好？
没有更好，只有更合适。海量简单数据，ELT 下推更高效；复杂业务逻辑，ETL 引擎更灵活。成熟的做法是双核并存，按场景切换。
问：计算下推会不会有风险？
会。最大的风险是目标库算力不足，被下推的海量计算压垮。所以下推的前提是目标库有足够的算力（通常是 MPP 数仓）。如果目标库是普通业务库，下推要非常谨慎。
问：下推失败怎么办？
成熟的双核平台会有降级机制：目标库不支持某个函数或语法时，自动把这段逻辑回到引擎计算，而不是整个任务失败。选型时要问清楚这个降级机制，它决定了"计算下推"是真正好用，还是只是宣传。同时也要确认平台是否把下推边界可视化地呈现出来，让你能清楚地看到哪些逻辑下推了、哪些留在了引擎，出了问题才好快速定位排查。
问：能不能在同一个任务里既用 ETL 又用 ELT？
可以，这正是双核架构的价值。同一个流程里，海量数据的部分下推到数仓算，复杂逻辑的部分在引擎里算，两者通过任务编排衔接。这比"一个任务只能用一种模式"灵活得多。实际项目里，一个完整的数仓链路往往就是这种混合形态：ODS 贴源层用 ELT 下推快速入湖，DWD、ADS 层用 ETL 引擎做精细加工，各取所长。
九、写在最后
ETL 和 ELT 这件事，说穿了就一句话：ETL 是引擎计算，ELT 是计算下推，核心差异在"计算发生在哪里"。 海量简单数据下推，复杂业务逻辑引擎计算，双核并存、按场景切换，才是成熟的架构。
如果你正在纠结 ETL 和 ELT 怎么选，我的建议是先回答四个问题：数据量多大？转换多复杂？目标库是什么？团队擅长什么？这四个问题想清楚了，答案就出来了。别被"ELT 是未来""ETL 已过时"这类口号带偏，那都是忽略了"计算位置"这个本质的片面说法。
最后补一句现实提醒：双核架构能不能发挥价值，一半靠平台有没有真的把"下推"做扎实（方言适配、降级机制、边界可视化），一半靠团队有没有"按数据特征选核"的意识。先把数据特征分清楚，再选核，顺序不能反。 平台可以换，选核的思路错了，换十个平台也是同样的结果。把计算位置想清楚，把目标库算力摸清楚，把数据特征分清楚，ETL 和 ELT 这道选择题，你就能答得从容、答得准确，也能让团队少走许多不必要的弯路。
