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

举报
寒六先生 发表于 2021/04/22 10:20:36 2021/04/22
【摘要】 文章转载于其它空间,文章语言诙谐幽默,并能对ETL和ELT讲述的言简意赅,清晰明了
转载:作者彭文华
全文共2736个字,建议阅读需7分钟

昨天群里突然有人问了一个这个问题:

图片

我最早听说 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就能灵活到直接拖个宽表完事的地步。

结语

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

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。