議論： ETL versus ELT: where the transformation runs and what that changes

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

'An ELT transformation is a query over data that is still there, so a fix means re-running SQL' holds only while the raw layer is retained unchanged, and the warehouse features that people rely on for that are short-lived. Snowflake's Time Travel defaults to one day of history (extendable to 90 days on Enterprise edition), BigQuery's time travel window is seven days by default; raw tables that are loaded with merge or truncate-and-reload semantics, which is what most ingestion tools do to keep the raw copy current, lose the previous state as soon as that window closes. So a transformation fix that needs last quarter's input is only a query if the team also kept append-only raw history, which costs storage at warehouse prices and is a design decision, not a property of ELT. The comparison should say: ELT makes reruns cheap given an immutable, retained raw layer; without one, ELT and ETL both depend on re-extraction, and ETL's staging area (files in object storage, which are cheap to keep forever) is often the more durable raw archive of the two.