我意识到我的公司使用的是 ELT（提取-加载-转换）流程，而不是使用 ETL（提取-转换-加载）流程。
这两种方法有什么区别，在哪些情况下一种会比另一种“更好”？如果您能提供一些示例，那就太好了。
AskOverflow.Dev
那里有很多关于 ETL 与 ELT 的讨论。
ETL 与 ELT 之间的主要区别在于处理发生的位置 ETL 数据处理发生在 ETL 工具中（通常是一次记录和内存中） ELT 数据处理发生在数据库引擎中
数据相同，两种方法都可以达到数据的最终结果。
这在很大程度上取决于您和您的环境如果您拥有强大的数据库引擎和良好的硬件并且您可以对其进行繁重的处理，那么 ELT 对您有好处，如果您有一个繁忙的数据仓库引擎并且您需要将其从处理中解放出来用于 ETL。
请注意，拥有 ETL 工具可为您提供两种选择，例如 ETL(T)，您可以在 ETL 工具中进行转换，也可以在数据库引擎中进行转换
但是 ELT 您只能选择在数据库引擎中进行转换，但您应该知道数据库在基于集合的操作方面比一次记录 ETL 工具更好。
在SO上提出了类似的问题，但支持 ETL，还有一篇比较 ETL 与 ELT 的好文章，但支持 ELT
这几乎是语义问题。在关于这个问题的讨论中释放了很多热空气，但我并不相信两者之间的区别有任何真正的哲学深度。
在某种程度上，您可以将 ETL 视为在最终加载之前在客户端工具中转换数据，ELT 意味着数据被传输到某种暂存区域，而格式的变化相对较小。之后会发生“转变”。
这些是非常模糊的定义，可以应用于各种各样的技术架构，并且有许多可能的设计可以用任何一个术语来描述。
我非常支持所有转换和业务逻辑都可以构建到或多或少同质的代码库中的架构，并且我已经完成了很多转换逻辑非常复杂的系统。这往往只是使用 ETL 工具来获取数据，然后所有的转换都在存储过程中完成。可以说，这可以描述为 ETL 或 ELT，区别仅在于语义之一。
但是，有些工具非常以数据库为中心（例如，Oracle Data Integrator 通常被称为 ELT 工具）。如果您订阅此视图，则“提取”和“加载”在数据被转换之前发生，因为它们被降落到暂存区域，然后由 SQL 或 PL/SQL 代码（可能由工具或手写）。与我交谈过的几个人似乎认为 ODI 的主要优点是它不是 OWB。
如果您使用 Informatica Powercentre 或 MS SQL Server Integration Services 等客户端工具，则该工具可以对数据客户端进行广泛的转换。一些 ETL 工具（例如 Ascential Datastage 和 Ab Initio）旨在对平面文件和内存数据结构进行大量工作以提高速度。在这种架构中，转换在加载之前就已经完成。也许这种类型的架构可以明确归类为“ETL”，尽管我见过许多以工具为中心的项目，其中所有实际工作都是由一堆存储过程代码完成的。
各种工具和架构方法各有优势，但不能一概而论地说明“ETL”与“ELT”方法的优点，因为术语太宽泛以至于差异几乎没有意义。某些工具和架构可能具有特定优势 - 例如，Ab Initio 大量使用平面文件使其在处理大数据量时具有显着的性能优势。
在实践中，如果不对系统需求、平台和技术架构进行更深入的讨论，那么区分“ETL”和“ELT”是毫无意义的。
这也是钱的问题。正如您所指出的那样，在数据量很高的情况下，基于平面文件的解决方案（如 Ab Initio 和 DataStage Parallel Extender）确实更快，但可能是中高的六位数命题。IRI CoSort 非常以 ETL 为中心（根据他们的 ELT 比较），除了复杂的 Hadoop 实现之外，这是我见过的以文件系统速度解决转换量的唯一经济实惠的方法。我还认为通常将硬件用于解决问题（ELT 设备和内存数据库也这样做），在成本方面也不能很好地扩展。