探索BI系统搭建的必要性与AI技术的应用潜力
950
2022-05-29
我最早听说 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 里跑,直接拖张宽表扔库里,然后怼到一个报表展示工具完事了。
这又不得不提到那个百度的小伙伴在脉脉上提的问题:
结语
时代一直在变,技术也是在不停的变。我们需要做的事情是持续学习,不断精进,深度思考。关注我,我们携手同行!
大数据
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。