ETL和ELT到底有啥区别???

首页 / 常见问题 / 低代码开发 / ETL和ELT到底有啥区别???
作者:数字化 发布时间:07-24 15:53 浏览量:6403
logo
织信企业级低代码开发平台
提供表单、流程、仪表盘、API等功能,非IT用户可通过设计表单来收集数据,设计流程来进行业务协作,使用仪表盘来进行数据分析与展示,IT用户可通过API集成第三方系统平台数据。
免费试用

我最早听说 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 非常适应需求比较清晰、业务比较固定的场景。

大清亡了...

很简单,因为大清亡了啊!

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 里跑,直接拖张宽表扔库里,然后怼到一个报表展示工具完事了。

这又不得不提到那个百度的小伙伴在脉脉上提的问题:

结语

时代一直在变,技术也是在不停的变。我们需要做的事情是持续学习,不断精进,深度思考。关注我,我们携手同行!

大数据

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们微信:Informat_5 处理,核实后本网站将在24小时内删除侵权内容。

最近更新

探索高效创新的低代码平台:AppCube 应用魔方
09-24 10:23
零代码、低代码、APaaS系统应该是什么样、应如何定位
09-15 13:51
Java程序员需要了解低代码吗
09-15 13:51
低代码平台的发展前景怎么样
09-15 13:51
什么是低代码 低代码开发平台靠谱吗
09-15 13:51
低代码平台的使用场景有哪些
09-15 13:51
适合企业的低代码开发平台有哪些 他们各有什么优势
09-15 13:51
做低代码有前景吗
09-15 13:51
低代码系统能够解决哪些痛点
09-15 13:51

立即开启你的数字化管理

用心为每一位用户提供专业的数字化解决方案及业务咨询

  • 深圳市基石协作科技有限公司
  • 地址:深圳市南山区科技中一路大族激光科技中心909室
  • 座机:400-185-5850
  • 手机:137-1379-6908
  • 邮箱:sales@cornerstone365.cn
  • 微信公众号二维码

© copyright 2019-2024. 织信INFORMAT 深圳市基石协作科技有限公司 版权所有 | 粤ICP备15078182号

前往Gitee仓库
微信公众号二维码
咨询织信数字化顾问获取最新资料
数字化咨询热线
400-185-5850
申请预约演示
立即与行业专家交流