什么是ELT（提取、加载、转换）？

虽然与 ETL 类似，但 ELT 是一种截然不同的数据预处理方法，且直到最近随着向云环境的过渡才得以开始采用。

ELT 由三大阶段组成：提取、加载和转换。ELT 每个阶段的详细说明如下。

在数据提取过程中，数据将从源位置复制或导出到暂存区域。数据集可以包含多种数据类型，几乎来自任何结构化或非结构化来源，包括但不限于：

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

换言之，它更常用于非结构化数据。

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

对于大多数组织，数据加载流程是自动执行、定义明确、连续执行且可批量进行的。通常，ELT 出现于工作时段，且此时针对源系统和数据仓库的流量正处于峰值，而使用者则在等待将这些数据用于分析或其他用途。

在此阶段，系统会采用“写时模式”方法，即在分析之前使用 SQL 为这些数据应用该模式或转换这些数据。此阶段可能涉及以下操作：

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

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

其中明显的区别在于：ELT 流程会在“转换”功能之前执行“加载”功能，而这与 ETL 流程的第二步和第三步相反。ELT 会从源位置复制或导出这些数据，但不是将其加载到暂存区域进行转换，而是将原始数据直接加载到目标数据存储，以便按需在此进行转换。ELT 不会转换任何传输中的数据。

但是，这些步骤的顺序并不是唯一的区别所在。在 ELT 中，目标数据存储可以是数据仓库，但通常则是 数据湖；后者是一个大型中央存储，旨在大规模存储（或容纳）结构化和非结构化数据的大型中央存储库。

数据湖的管理需使用大数据平台（如 Apache Hadoop）或分布式 NoSQL 数据管理系统。它们可为商业智能提供支持，但更多时候，它们则是为支持人工智能、机器学习、预测分析以及由实时数据与事件流驱动的应用程序而创建的。

此外，ETL 与 ELT 之间还存在其他差异。例如，由于 ETL 在将数据移动到中央存储库之前会对数据进行转换，因此较之 ELT，ETL 可进一步简化或系统化数据隐私合规性（例如，如果分析人员在需要使用敏感数据之前不对其进行转换，则可能会在数据湖中将其暴露。）然而，数据科学家可能更偏爱 ELT，因为此模式可让他们在原始数据的“沙盒”中随意操作，并根据特定应用程序进行自己的数据转换。但在大多数情况下，选择 ETL 还是 ELT 取决于在可用业务资源与需求之间进行选择。

对于想将此流程集成到工作流程中的用户，ELT 可提供多种优势。其中部分显著的好处如下：

生成大量流数据时，ELT 允许立即加载数据并在数据到达目标位置后对其进行转换。此举可防止在“加载”功能之前进行转换时（例如在 ETL 中）经常出现的所有降速情况。
通常，需根据这些数据做出决策，而无法接受延迟。与此相关的其中一个示例是股票市场，它会产生大量实时使用的数据。在此类场景中，ELT 是首选解决方案，因为转换操作会在这些数据到达其目标位置后进行。

由于这些数据在到达目标位置时会进行转换，因此 ELT 允许这些数据的接收者控制数据操作。使用 ELT 时，转换阶段与加载阶段的解耦可确保转换阶段中的编码错误或其他错误不至影响其他阶段。

ELT 利用数据仓库的强大功能和规模来实现大规模转换或可扩展计算。目标数据仓库可按需增加或减少节点，尤其是在每个集群中存在多个节点且可使用多个集群的云场景中。如此，便可实现按需提供的灵活性和可扩展性。

ELT 只需功能较弱的服务器进行数据转换，并利用仓库中已有的资源。如此一来，便可节省成本并提高资源效率。

ELT 支持使用所选的目标存储库，以实现成本与资源灵活性。数据仓库使用 MPP（大规模并行处理）架构，其中包括基于列式内存的数据量存储。此外，它还支持在收到数据后立即应用某一模式或转换模型（也称为“读时模式”）的数据湖流程。这些高效流程可实现对大量数据的灵活处理。

连续操作非常适合需要快速访问数据的任意环境。ELT 非常适合在云环境中使用的数据，而这些环境通常会包含按需连续访问的应用程序。同样，云原生 ELT 转换也可提供上述的可扩展性和灵活性。

组织可选择从 ETL 过渡到 ELT 架构。此过渡的原因可能是产品或服务的使用方式发生变化，因此需进行实时响应和交互；或是数据量呈指数级增长，而由于对基础设施存在大量处理需求，因而此转换会延缓“加载”阶段。如果组织已迁移到云端并想更快地消除处理工作负载或在目标位置使用数据，也可选择从 ETL 过渡到 ELT。

在过渡场景中，很可能会遇到挑战。首先，ELT 与 ETL 中使用了截然不同的逻辑和代码。为此，可能需彻底重新配置或在云端采用新的基础设施或新的基础设施提供商。此外，采用 ELT 模式时，还会将原始数据发送到目标仓库。因此，必需考虑并实现安全性以确保这些数据的安全。

ELT 并非一项新技术。此前，暂存表被用于将数据迁移到数据仓库以便进行处理和转换，且通常会使用 SQL 脚本。由于 SQL 脚本采用硬编码，因此可能会出现编码错误。使用 SQL 时，客户必须在使用 SQL 脚本的本机仓库执行与声明式编程（也称为“声明式创作”）之间进行选择。
声明式创作可通过创建代码来描述该程序必须实现的目标而不是具体实现方法，从而提供更现代化且基于云的数据仓库环境的优点。此流程可防止出现其他流程中固有的编码错误，尤其是当转换发生在“加载”功能之前时。

ELT 通常用于大容量或实时数据使用环境。具体示例包括：

• 需要即时访问的组织。具体示例包括证券交易所或股票、工业部件和其他材料的大型批发商；此类组织需实时访问最新数据，以便立即获取商业情报。
• 拥有大量数据的组织。具体示例包括气象服务等气象系统；此类服务会定期收集、整理和使用大量数据。存在较大交易量的公司也可能属于此类别。拥有超大望远镜的天文学实验室等组织会生成大量需进行整理和分析的数据。这两个类别之间可能存在重叠，因为很多行业会生成和使用大量数据，且需实时访问这些数据。