在过去的十年，我们对存储和管理数据的方式发生了很大的变化，并从ETL模式逐渐转向ELT，然而，小编认为这并不会是终点；未来极有可能会向EL(T)发展，也就是EL和T进行完全解耦。当然这只是一种猜想。本篇主要对ETL和ELT两种模式进行展开来说，如果有朋友对这两个概念有些困惑的话，希望本篇文章能够帮助你。

ELT和ETL这两种模式从字面上来看就是一个顺序颠倒的问题，每个单词拆开来看其实都是一样的。E代表的是Extract，即抽取，也就是从源端拉取数据；T代表的是Transform即转换，对一些结构化或者半结构化的数据进行一些处理，比如数据加密，字段转换映射，拼接等等操作；L代表的是Load即加载，也就是将数据写入到目标系统中。

ETL

如上图所示,我们来回顾一下ETL的流程：1、首先从源端拉取数据，这个过程就是extract。通常我们所熟知的sqoop,datax这些数据同步工具就是干这个事情的。

2、当从源端拉取数据后，并没有直接灌入到目标表，大家可以理解成是先放到一个缓冲区，在这个区域内进行一些符合目标系统标准的预处理，比如我们建设数仓的时候对于数据同步后会把一些空值置为一些默认值，以此来保障数据完整性，对于不同源端的同一种含义的字段信息会进行统一格式转换，对于敏感数据会进行加密等等这些操作，一般是在入仓之前处理掉的。大家也可以当作是在ODS层。

3、当预处理完之后，将数据写入到目标系统中，那么这个时候也就是真正的入仓，也就是说仓中的数据都是要符合数仓标准的。
那么这种流程有什么好处呢？1、首先入仓之后的数据肯定是已经标准化的了，那么对于下游的使用方是不是很方便了呢？比如说分析师想要统计一些指标，直接使用数仓的表是不是可以省略掉复杂的数据规范处理。

2、对于一些敏感数据，如果在入仓之前就进行加密处理，这种模式更加符合GDPR、HIPAA 和 CCPA 标准。

3、目前市面上有很多集成的ETL工具，可以很容易实施并完成这一整套的流程，而不需要过于复杂的操作。

任何事物都有正反两面，既然ETL有以上的好处，那么肯定是有一些缺点的。这里以敏感数据加密场景为例：比如敏感数据12332234在入仓之前，要对敏感数据进行一些定制的加密算法处理，而这种算法需要调用三方接口或者外部接口才能够完成(即要把加密后的结果Encryt_sdfdsfsfd入仓)，那么大家思考一下，如果敏感数据量达到上千万，那么ETL整个流程所需的耗时是不是肯定会很长（考虑到外部接口限流的情况）？那么或许有朋友说这种可以通过大数据技术（比如写MR或者Spark程序）来解决，也不会很慢的。但是想一想，这个时候数据是不是已经入仓了呢？为什么这样说，请问数据这个时候是不是已经落到了ODS层了呢?这种模式就是等下介绍的ELT模式。通过这个示例也足以看出，ETL模式适用于小数据量集

ELT

如上图所示，我们来介绍下ELT的流程：
1、和ETL中的E作用一样，即从源端系统抽取数据，比如Mysql,Oracle,PG等等。
2、该步骤的流程就和ETL不一样了，T和L进行了位置置换，这里是先加载到目标系统，大家也可以理解成是数据入了仓
3、当数据入了仓之后，再进行T操作，也就是进行转换。也就是说数据转换标准化操作由缓冲区转移到了仓中进行。
那么T和L进行置换之后，有什么好处呢？
1、首先针对于ETL模式下介绍的敏感数据加密的例子就得到了很好的效率提升，借助于我们目前所使用的大数据技术，比如定义UDF之类的在仓中进行加密处理，那么速度肯定会比在ETL模型下要快。这也就是说ELT其实是适用于大数据量集的，但是需要注意安全管控防止出现数据泄露问题。

2、站在消费方来说，当要使用数据的时候，无需等待转换标准化处理完成入仓之后才能使用，而是可以直接在仓中访问原始数据，但是这样一来会加重分析师对数据清洗的操作。

3、目前大多数公司都有现成的平台来建设数仓，而且随着云上数仓的模式逐渐成熟，ELT受益于这种平台生态系统，这样一来转换过程通常是自动化或者说是配置化的，所以在维护方面带来了便利。

ETL vs ELT

在实际场景中，小编认为这两种模式普遍是共存的。只是针对不同的场景选择不同的模式来解决而已。对于小数据量集而且转换过程不会过于耗时的场景可以采取ETL处理，例如使用sqoop同步数据，日志采集过程当中直接清洗数据这类场景；对于数据体量较大而且转换逻辑比较复杂的场景可以采取ELT处理，例如前面提到的数据加密场景。目前比较火的数据湖和中台的建设多数是以ELT模式开展的，当然这两种处理模式之间的区别不仅仅局限于这一点，这里做一下汇总便于大家理解：加下方好友，领取670页大数据技术架构手册，无套路!