了解ETL和ELT，这样你就可以决定哪种方法适合你。
首字母缩写“ETL”经常用来指数据集成;支持分析所需的活动。这些活动包括:
收集和提取数据
把它装载到目的地
将其转换为分析员可以使用的模型
这些活动的执行顺序可能会有所不同。在这篇文章中，我们将描述两种主要的数据集成概念方法，ETL和ELT。
数据集成的传统方法提取-转换-加载(Extract-Transform-Load, ETL)可以追溯到20世纪70年代，它是如此普遍，以至于“ETL”经常可以与数据集成互换使用。在ETL下，数据管道从数据源提取数据，将数据转换为数据模型，以便分析师将其转换为报告和仪表板，然后将数据加载到数据仓库。
数据转换通常聚合或汇总数据，缩小其总体体积。通过加载前的转换，ETL限制了存储的数据量，在整个工作流中保留了存储、计算和带宽资源。当20世纪70年代首次设计ETL时，大多数组织都在非常严格的技术限制下运作。存储、计算和带宽都极其稀缺。
ETL的项目工作流包括以下步骤:
确定所需的数据源
项目的精确分析需要解决的范围
定义分析师和其他终端用户需要的数据模型/模式
构建管道，包括提取、转换和加载功能
进行分析工作并提取见解
因为在ETL中，提取和转换都是在将任何数据加载到目的地之前执行的，所以它们是紧密耦合的。此外，由于转换是由分析人员的特定需求决定的，所以每个ETL管道都是一个复杂的、定制的解决方案。这些管道的定制特性使得扩展非常困难，特别是添加数据源和数据模型。
有两种常见的情况下，这个工作流必须重复:
上游模式更改，导致用于将原始数据转换为所需数据模型的代码无效。当在源上添加、删除或更改字段时，就会发生这种情况。
下游分析需要改变，需要重写转换代码以生成新的数据模型。当分析师希望构建仪表板或报告时，需要配置中的数据，而配置中还不存在数据时，通常会发生这种情况。
任何不断提高其数据素养的组织都会经常遇到这两种情况。
提取和转换之间的紧密耦合意味着转换停止还会阻止将数据加载到目标，从而产生停机时间。
因此，使用ETL进行数据集成涉及到以下挑战:
持续维护-由于数据管道同时提取和转换数据，一旦上游模式或下游数据模型发生变化，管道就会中断，通常需要对代码库进行广泛的修订。
定制和复杂性-数据管道不仅提取数据，而且根据终端用户的具体分析需求执行复杂的转换。这意味着需要大量的定制代码。
Labor-intensiveness和费用-因为系统运行在定制的代码基础上，它需要一个专门的数据工程师团队来构建和维护。
这些挑战源于ETL下的关键权衡，即以人工为代价节省计算和存储资源。
在计算、存储和带宽极其稀缺和昂贵、数据量和种类有限的时代，劳动强度是可以接受的。ETL是一个时代的产物，它受到当前流行的技术限制。
在过去的四十年里，存储成本从近100万美元/千兆字节下降到大约1美分/千兆字节(相当于5000万倍):
自20世纪70年代以来，计算成本已经缩减了数百万倍:
互联网运输的成本下降了上千倍:
这些趋势在两个方面使ETL在大多数目的上过时了。首先，计算、存储和互联网带宽的可承受性导致了云计算和基于云的服务的爆炸性增长。随着云的发展，数据的数量、多样性和复杂性也在增长。集成有限的数据量和粒度的脆弱的定制管道已经不够用了。
其次，现代数据集成技术在存储的数据量和在仓库中执行查询的频率方面受到较少的限制。计算、存储和网络带宽的可承受性使得重新安排数据集成工作流成为现实。最重要的是，组织现在可以将未转换的数据存储在数据仓库中。
在数据仓库中存储未转换数据的能力支持新的数据集成体系结构Extract-Load-Transform (ELT)，在该体系结构中，转换步骤被移动到工作流的末尾，数据在提取时立即被加载到目的地。
这可以防止ETL的两种失败状态(即更改上游模式和下游数据模型)影响提取和加载，从而实现更简单、更健壮的数据集成方法。
与ETL相比，ELT工作流具有更短的周期:
确定所需的数据源
执行自动提取和装载
项目的精确分析需要解决的范围
通过构建转换来创建数据模型
进行实际的分析工作并提取见解
在ELT下，数据的提取和加载都是在转换的上游，与转换无关。尽管在上游模式或下游数据模型更改时，转换层仍然可能失败，但这些失败不会阻止数据加载到目的地。相反，即使分析人员定期重写转换，组织也可以继续提取和加载数据。由于这些数据到达目的地时几乎没有变化，所以它是一个全面的、最新的真相来源。
最重要的是，提取和加载与转换的解耦意味着提取和加载的输出不再需要定制。可以直接使用来自源的数据填充目标，只需要简单的清理和规范化。结合云的增长，这意味着提取和加载可以:
外包给外部
自动化
根据需要在云上伸缩
自动提取和装载产生标准化输出，允许衍生产品，如模板化分析产品被生产出来并在目的地的顶部分层。
此外，由于转换是在数据仓库环境中执行的，因此不再需要通过拖放转换接口设计转换，使用Python等脚本语言编写转换，或者在不同数据源之间构建复杂的编排。相反，可以用大多数分析人员的母语SQL编写转换。这将数据集成从以IT或工程师为中心的活动转移到可以直接且容易地由分析师拥有的活动。
下表总结了ETL和ELT的区别:
| ETL | 英语教学 |
|---|---|
| 提取、转换、加载 | 提取、负载变换 |
| 积分，汇总或细分 数据 |
整合所有原始数据 |
| 加载和转换紧密 耦合 |
加载和转换解耦 |
| 加载数据的时间更长 | 加载数据的时间更短 |
| 改造故障停止管路 | 转换失败不会停止管道 |
| 预测用例和设计数据 模型预先或完全 修改数据管道 |
创建新的用例和设计 任何时候的数据模型 |
| 定制 | 现成的 |
| 经常建造和维修 | 自动化 |
| 节省计算和存储 | 节约劳动力 |
| 使用脚本语言 转换 |
使用SQL进行转换 |
| 工程/以it为中心的;专家系统 | Analyst-centric;可访问的 非技术性用户 |
| 基于云计算的或可用的 | 几乎完全基于云计算的 |
在某些情况下，ETL仍然比ELT更好。具体包括以下情况:
所需的数据模型是众所周知的，并且不太可能快速更改。当组织还构建和维护生成源数据的系统时，尤其如此。
对于数据有严格的安全性和法规遵从性要求，它绝对不能存储在任何可能被泄露的位置。
这些情况往往是专门从事软件即服务产品的大型企业和组织的特征。在这种情况下，使用ELT与第三方SaaS产品进行数据集成，同时保留ETL集成内部专有数据源可能是有意义的。
将自动化与ELT结合起来的组织可以显著简化其数据集成工作流。简化的数据集成工作流对数据工程来说是一个力量倍增器，使数据工程师不再关注构建和维护数据管道，而是关注更关键的项目，如优化组织的数据基础设施或生产预测模型。分析师和数据科学家，他们的职责通常是包含更多的数据集成活动而不是实际的分析，最终可以利用他们对业务需求的理解来建模和分析数据，而不是争论或抹黑它，或要求开发人员代表他们进行抹黑或抹黑。
要了解更多关于如何使ELT和数据集成为您的组织工作的信息，请查看我们的数据集成基本指南．