ELT 表示“抽取、加载和转换”，是另一种类型的数据集成过程，类似于对应的 ETL，即“抽取、转换和加载”。 这个过程将原始数据从源系统移动到目标资源，例如数据仓库。 虽然与 ETL 相似，但 ELT 是一种完全不同的数据预处理方法，它最近才随着企业向云环境的迁移而逐步受到青睐。

ELT 包含三个主要阶段：抽取、加载和转换。 接下来我们将详细介绍这其中的每一个阶段。

抽取

在数据抽取期间，会将数据从源位置复制或导出到暂存区。 数据集可包含众多数据类型，来自几乎任何结构化或非结构化数据源，包括但不限于：

• SQL 或 NoSQL 服务器
• CRM 和 ERP 系统
• 文本和文档文件
• 电子邮件
• 网页

也就是说，它更常用于处理非结构化数据。

加载

在这一步中，转换后的数据从暂存区移动到数据存储区，例如数据仓库或数据湖。

对于大多数组织而言，数据加载过程是明确定义而且持续的自动化批处理过程。 一般情况下，ELT 在上班时间进行，此时源系统和数据仓库上的流量处于峰值，使用者则等待使用数据执行分析或其他任务。

转换

在这个阶段，会采用写时模式 (schema-on-write) 方法，也就是在分析之前，使用 SQL 为数据应用模式，或者转换数据。 这个阶段可能包括以下操作：

• 对数据进行过滤、清理、去重、验证和认证。
• 根据原始数据执行计算、转换、数据分析或汇总。 这可能包括满足组织特定的 BI 或分析目标所需的一切操作，例如更改行和列的标头以保持一致性，转换货币或度量单位，编辑文本字符串以及添加值或计算平均值等。
• 删除、加密、隐藏或以其他方式保护受政府或行业法规管制的数据。
• 根据数据仓库中部署的模式，将数据格式化为表或联接表。

ELT 与其首字母缩写几乎相同的姊妹过程很容易混淆。 但 ELT 和 ETL 之间有几个明显的区别，ETL 表示“抽取、转换和加载”。 它是一个数据集成过程，用于将来自多个数据源的数据合并到单个统一的数据存储中，然后加载到 数据仓库 或其他目标系统中。  传统的 ETL 工具旨在创建数据仓储，以支持商业智能 (BI) 和人工智能 (AI) 应用。

ETL 和 ELT – 有何区别？

一个明显的区别就在于，ELT 过程在转换功能之前执行加载功能，这与 ETL 过程的第二步和第三步正好颠倒。 ELT 从源位置复制或导出数据，但不是将其移动到暂存区进行转换，而是将原始数据直接加载到目标数据存储中，然后在这里根据需要进行转换。 ELT 不会在传输中转换任何数据。

然而，步骤的顺序并非唯一的区别。 在 ELT 中，目标数据存储可以是数据仓库，但更多时候则是数据湖，后者是大型中央存储，旨在大规模保存结构化和非结构化数据。

数据湖由大数据平台（如 Apache Hadoop）或分布式 NoSQL 数据管理系统进行管理。 它们可能支持商业智能，但更多时候则是用于支持人工智能、机器学习、预测性分析，以及由实时数据和事件流驱动的应用。

ETL 和 ELT 之间还存在其他差异。 例如，与 ELT 相比，ETL 会在将数据移动到中央存储库之前对其进行转换，因此可以更简单、更系统地实现数据隐私合规性（例如，如果分析师在需要使用敏感数据之前未对其进行转换，那么该数据可能会直接存储到数据湖中而未实施任何保护措施）。 然而，数据科学家可能更喜欢使用 ELT，因为这让他们可以在原始数据的“沙箱”中进行操作，根据特定应用自行执行数据转换。 但在大多数情况下，选择 ETL 还是 ELT 取决于更侧重于可用的业务资源还是需求。

对于希望将该过程集成到工作流程中的用户而言，ELT 具有多项优点。 以下是一些比较显著的优点。

能够更快地将数据移动到目的地，从而加快实现可用性

在生成大量流式数据的情况下，ELT 能够立即加载数据，并在数据到达目的地后才对其进行转换。 这可以防止在加载功能之前进行转换时经常会发生的数据性能下降状况，这种情况在 ETL 中比较常见。 由于通常需要根据这些数据做出决策，因此延迟是无法接受的。 股票市场就是这方面的一个例子，该市场会生成海量数据以供实时使用。 在这种场景中，ELT 是首选的解决方案，这是因为在数据到达目的地之后才会进行转换。

隔离各种问题

因为数据在到达目的地之后才进行转换，所以 ELT 使数据接收方能够控制数据操作。 在 ELT 中，转换和加载阶段解耦，这有助于确保转换阶段中的编码错误或其他错误不会影响另一个阶段。

避免服务器扩展问题

ELT 利用数据仓库的强大功能和规模，实现大规模转换或可扩展的计算。 目标数据仓库可以根据需要增加或减少节点，特别是在每个集群中有多个节点以及可以使用多个集群的云场景中。 这样就能够实现随需应变的灵活性和可扩展性。

节约成本

ELT 无需功能强大的服务器即可进行数据转换，并能够充分利用仓库中已有的资源。 这最终可以节约成本并提高资源效率。

灵活性

ELT 支持使用所选的目标存储库，从而能够灵活控制成本和使用资源。 数据仓库使用 MPP（大规模并行处理）架构，包括使用基于内存的列式存储进行海量数据存储。 此外，还支持数据湖流程 — 在接收到数据后立即应用模式（即转换模型），也称为“读时模式”(schema-on-read)。 这些高效的流程为处理海量数据带来了灵活性。

持续运营

对于需要快速访问数据的任何环境，持续运营无疑是理想状态。 ELT 非常适合处理在云环境中使用的数据，这些环境中通常包括持续按需访问的应用。 同样，云原生 ELT 转换也提供了上述的可扩展性和灵活性。

组织可选择从 ETL 转变为 ELT 架构。 进行这种转变的原因可能是因为其产品或服务的使用方式发生了变化，因而需要实时响应和互动；或者是因为数据量呈指数级增长，由于基础架构上存在大量处理需求，转换过程使得加载阶段一再延迟。 如果组织已迁移到云端，并希望尽快将数据的处理或使用转移到目标位置，那么也可能会选择从 ETL 转变为 ELT。

在转变过程中，当然会遇到一些挑战。 首先，ELT 与 ETL 使用完全不同的逻辑和代码。 这可能需要彻底的重新配置，也可能需要新的基础架构，或者需要新的云基础架构提供商。 此外，ELT 将原始数据发送到目标数据仓库。 因此，安全性是一个考虑因素，必须实施安全措施以保障数据安全。

ELT 并不是一项新技术。 登台表以前就用于将数据移动到仓库以进行处理和转换，通常会使用 SQL 脚本。 SQL 脚本是硬编码的，因此可能存在编码错误。 在使用 SQL 时，客户必须在使用 SQL 脚本的本机仓库执行和声明式编程（也称声明式编写）之间做出选择。 声明式编写通过创建代码以描述程序必须实现的目标而不是说明如何实现目标，让用户体验到更为现代的基于云的数据仓库环境的优点。 这个过程可防止其他过程中内在的编码错误，尤其是在加载功能之前进行转换的情况下。

ELT 通常用于海量数据或实时数据的使用环境。 具体例子有：

• 需要即时访问数据的组织。 例子包括证券交易所或者股票、工业部件和其他材料的大型批发分销商，他们需要实时访问最新数据，以便即时运行商业智能。
• 拥有海量数据的组织。 例子包括气象系统，比如需要定期收集、整理和使用海量数据的气象服务。 具有海量交易的企业也可归入这一类别。 某些组织，例如拥有超大型望远镜的天文实验室会生成海量数据，需要进行整理和分析。 这两个类别之间可能存在重叠，因为许多行业不仅会产生和使用海量数据，也需要实时访问这些数据。