前言
昨天群里突然有人问了一个这个问题：
我最早听说 ELT 的时候也楞了一下，只不过简单琢磨了一下就放下了。今天重新听到，其实也没啥感觉。
反正有人也给出了最言简意赅的解释：
只是换个顺序？
然后就有人蒙圈了啊！这都行？
还有人猜：
额。。。其实吧， ETL 和 ELT 还真的只是顺序不一样。
ETL 是Extract（抽取）、Transform（转换）、Load（加载）；
ELT 是Extract（抽取）、Load（加载）、Transform（转换）。
你是不是会感觉这帮搞数仓的整天就知道装神弄鬼，整点新词儿忽悠人！
额...你要是这么想，那可就小看了我们数仓人了，小看了架构这件事情了。来，我今天就给你细细的讲一讲 ETL 和 ELT 到底是咋回事。
你可以瞧不起我，但是你不能瞧不起我的专业！
那时候...
老数仓人做项目，都是一板一眼，很有章法的。
我们一般会先从业务系统开始调研，摸清楚所有数据来源的数据结构。
同时会去了解业务流程，看看业务到底是怎么运转的，系统又是怎么留痕的，这样两下验证，逻辑上就通了。
其实到这一步，我们就能知道很多信息了，经验丰富的人基本上已经在脑子里猜到用户的需求，开始设计报表了。
那下一步自然是去获取用户需求，规划上面的即席查询、多维分析、固定报表、仪表盘啥的数据应用了。
然后就是各种的分主题域、分层、逻辑模型咔咔一顿操作猛如虎。
如果您还有印象，应该记得我之前写过数仓建设步骤：
注意看上图最后一个步骤“物理建模”，从这时候起，我们才真正开始大规模的在数据仓库中建表，也就是落地执行了。
再往后呢？就是 ETL 了，从业务系统搬数据到ODS（Extract抽取），然后像流水线一样，处理一个环节（Transform转换），再放到一个框里（Load加载），再处理一个环节，再放到一个框里（数仓某一层）。
这就是DWD、DWB、DWS、DM等数仓各层的建设，就这样一层层的先处理数据，再加载到本层数仓，然后下一层再处理数据，再加载到过去。
所以，整个数据处理和流转的过程就是 ETL ，也就是先Extract（抽取），再Transform（转换），最后Load（加载）了。
流水线最大的好处是在固定的处理环节前提下，建设效率最快，成本最优，建好之后基本上只需要维护就行了。
我有几个朋友是普通公司数据负责人，数据建设工作结束后，整个团队很轻松。每天基本上就是看看任务有没有问题，处理一些简单的报表维护工作。
想必你也看出来了， ETL 非常适应需求比较清晰、业务比较固定的场景。
但是，为啥又出来一个 ELT ？？？
大清亡了...
很简单，因为大清亡了啊！
ETL 很好用，自动处理所有数据，把数据规规整整的码放在数据仓库里供各方调取。
ETL 也很简单，基本上都是可视化、低代码的形式，设计好流程就行了。
ETL 的成本很低，一次性建设，之后就不用重复投入，只需要每天看看跑批任务有没有问题就行了。所以很多人的重点工作都是运维。
但是 ETL 也有非常致命的缺点：流程太长、太笨重、时间太长，改起来成本太高了！！！
反正我是不想改别人做的 ETL 的，太痛苦了。我甚至连自己写的都不想动。因为 ETL 程序通常是把 E 和 L 放在一起做，这就导致单个程序中的逻辑经常非常非常复杂的。
先给你来一个简单的：
Dolphin Schedul 的代立冬代总还给了我一个文艺一些的：
是不是挺复杂的？这还不算啥，我再给你看一个复杂的：
好像没啥是吧？还没上面一张图里的节点多是吧？其实这是因为一张图根本放不下！
提供这张图的兄弟“跨越新生”告诉我，这一共 1100 多个节点！他亲手设计的！
不过我就想问问他，现在敢动不敢动！敢不敢？嘿嘿~~~
他不敢啊！所以他最怕什么？最怕改需求，最怕改业务库！
如果业务或者底层数据要动一下， ETL 流程就要随之进行调整。简单的逻辑还好处理，一旦遇到“跨越新生”兄弟的这个局面，别的不说，光找节点就得找死人啊！
所以， ETL 开发很简单，但是维护成本奇高无比！复杂度奇高无比！工作难度奇高无比！
业务的频繁变化，再加上 ETL 的时间成本和吞吐量限制（堵塞），所以导致 ETL 这种数据加工的方式不能满足于现在的企业发展需要啊。
那咋办？
改变！
当然是改变了！
但是，咋变？
诶，有聪明的兄弟就说了，把 ETL 变成 ELT 啊！
对，但是没说到点子上。
并不是单纯的把流程倒置这么简单的，咱还得回到 ETL 问题的根本。
ETL 之所以这么复杂，是因为 Transform （转换）和 Load （加载）两个环节耦合过紧导致的。
我们用最朴素的架构思维想一下就明白了，让复杂的事情变简单，最简单的方式是啥？
“拆”字诀！
把 Transform （转换）和 Load （加载）哥俩拆开了就行了，这样处理数据的部分就专心计算就行了，搬运数据的部分就专心搬运就好了，别混在一起四脚八叉的。
所以， ETL 工具就变成了搬运组件、计算引擎和调度引擎。
搬运组件专门负责搬运数据，不做任何数据处理的操作；
计算引擎专门负责进行数据处理，其他事情跟我没关系；
调度引擎专门负责做流程编排，其他事情也跟我没关系。
有哥们会问， ETL 工具跑哪里去了？是这样的，我们需要把 ETL 和 ETL 工具分开哈。这里的 ETL 特指数据处理流程。
在上面的步骤中，也是可以用 ETL 工具代替的。毕竟 ETL 工具全能嘛，这三件事情都是能做的哈。
既然是整个工作流都拆开了，那流程也自然就有变化了。第一步没啥变化，但是之后的事情就不太一样了，整体就变成这个德行：
需要注意的是：上面这个架构只是示意哈，里面的所有具体的组件都是可以换的。
比如说抽取这个动作，你可以用 ETL 工具，可以用 Kafka，这种神奇的东西最大的好处就是吞吐量极大，任你来多少数据都能吃的下。
ODS 可以是数仓的 ODS，也可以是数据湖，奇葩一些用 Kafka 也没问题，别重复了就行。
加载这个动作也可以用 Kafka 或者啥 ETL 工具都行；
计算引擎你用 Spark 还是 Flink 还是 MR 都随意，反正只要能跑任务就行，最后直接输出到 HBase 也行，扔到 Kafka 或者 Redis 都可以。
你现在再看看对比一下两张图就会发现为啥是 ETL 和 ELT 了。
那 ELT 有啥好处呢？
最底层的改变是E、T、L彻底的解耦了。解耦之后好处多多，比如突破性能瓶颈、程序简化、组件替换、维护成本降低等等。
不过最重要的还是解耦导致的极致的灵活，可以适应当前复杂多变的市场环境。
因为在复杂多变的环境下， ETL 这种传统的数据处理套路是极度不适应的。
等你慢慢分主题域、抽取实体、建好模型、写各种代码、各种调试，好不容易出一张报表的时候，业务过来跟你说：哥，咱的打法变了，APP 都迭代了 3 轮了，这是新需求。你上哪哭去？
所以现在很多大厂的新业务中，都在弱化建模，强化效率，用的其实就是 ELT 的逻辑。
数据直接入湖，然后写个脚本扔 Spark 里跑，直接拖张宽表扔库里，然后怼到一个报表展示工具完事了。
这又不得不提到那个百度的小伙伴在脉脉上提的问题：
其实，哥们就是在 ELT ，而不是在 ETL 啊。因为ETL得建模，ELT就能灵活到直接拖个宽表完事的地步。
结语
时代一直在变，技术也是在不停的变。我们需要做的事情是持续学习，不断精进，深度思考。关注我，我们携手同行！
