大数据实战之ETL&ELT 一、前言二、规规矩矩数仓人二、明明白白数仓魂总结
最近突然听到了一个ELT的名词，众所周知，ETL: Extract（抽取）、Transform（转换）、Load（加载） ;那ELT难道是Extract（抽取）、Load（加载）、Transform（转换），还有这种简写???相信这是大部分读者看到ELT的第一反应（这也是笔者听到这个名词时的第一反应，并且内心OS:现在数仓人都这么具有创新意识吗？换个顺序就造就一个新名词，这把必不可能让你装到）。
一、前言随着分布式数据库和数据湖的发展，大家对数据处理的实时性，和计算与存储分离的需求越来越高。而传统的ETL方案 是对数据进行抽取、转换、加载的一系列过程，数据从数据源移动到中间区域（Staging Area），然后再进入数据仓库，所有转换都在数据加载到仓库之前执行 。而这些转换清洗操作就会使得数据出现跟起始来源数据（System-of-Record）不同的情况，也使得下游处理遇到垃圾数据的风险变大。
在这种方案的缺点下也就逐渐出现了另一种方案 ELT（Extract-Load-Transform），当分析师等在转换数据之前就将数据全部加载到数据仓库中了,ELT方案解耦了ETL中的TL使得下游的处理流程变的灵活和敏捷
二、规规矩矩数仓人身为一个规规矩矩的数仓人，往往充满着章法，必须从业务系统开始调研，摸清业务数据所有表结构，了解业务流程，搞清楚业务究竟是怎么运转的。一般这个时候如果是一个经验丰富的数仓人，那么脑子里已经大致勾勒出用户的需求开始设计报表了，那么接下来就是去获取用户具体的需求，规划即时查询，多维分析，报表，仪表盘等数据应用了，然后就是划分主题域、分层、维度建模等等操作
而只有在进行物理建模时，我们才开始了我们的ETL过程，从业务系统倒数（ Extract抽取 ），然后像流水线一样处理（ Transform转换 ），最后再放到其他数仓中（ Load加载 ）
所以这样的整个流程就是ETL，先进行 Extract（抽取），再Transform（转换），最后Load（加载） 。这样做的好处就是在固定环节前提下，建设效率最快，成本最优，建好之后基本上只需要维护就行了。一般数据建设工作结束后，团队都会相对比较轻松，基本就是处理任务是否出错，以及一些简单的报表工作。所以想必你也大致知道了如果在一个需求比较清晰、业务比较固定的场景，ETL就相对很合适
二、明明白白数仓魂ETL 很好用：自动处理所有数据，并且能使数据规规整整的码放在数据仓库里让各方去调用
ETL 很简单：基本上都是可视化、低代码的形式，设计好流程就行
ETL 很人性化：基本上一次建设，之后就不需要太多的重复投入，只需要每天看看任务是否有问题即可
但是ETL有个相对致命的缺点：流程长、运行长、并且笨重，改起来成本太高（小编是不愿修改别人的ETL，属实痛苦）！
DolphinScheduler代总发的一个文艺ETL(苦笑):
这个看完你可能觉得还好吧，但如果这个数仓任务节点变为999+，你感动吗？你不敢动。这时的你可能只能烧香祈祷需求不改，业务库不改！！不然你光找任务节点可能就得找死（别问我为什么知道），所以ETL虽然开发相对简单，但是一个笨重的ETL流程维护成本、复杂度都奇高无比。
所以我们需要一个处理方式去应对灵活多变的需求和奇思妙想的分析师，所以ELT架构应运而生，依托于云数据仓库极强的可扩展性和存算分离架构设计，充分利用数据仓库（或数据湖）优异的计算和存储能力，在数据加载完之后再进行数据转换 ， 提供更加灵活的转换模式，也使得分析人员更清楚地掌控转换规则和逻辑，从而提升分析作业效率 。
糟糕竟然被他装到了！！！