ETL vs ELT

Зачем

Если есть аналитика — есть pipeline данных. Order-сервис пишет в Postgres, marketing хочет «sales by country by week», finance — «MRR cohort», ML — «user features». Сырые данные надо transport'ировать, joining, aggregat'ить, моделировать — это и есть ETL/ELT.

Выбор между ETL и ELT — архитектурный, не стилистический. Определяет:

• Где живёт компьют (отдельный ETL-кластер vs warehouse)
• Есть ли вообще raw layer (immutable копия source)
• Кто пишет transforms (data engineer на Python/Scala vs analyst на SQL)
• Сколько стоит хранение и пересчёт

ETL доминировал 1995-2015 — Informatica, Talend, Pentaho, Ab Initio. Огромные ETL-серверы трансформировали данные до Teradata/Oracle DWH, потому что DWH compute был дорогой и дефицитный. ELT захватил 2015-2025 на трёх волнах: дешёвый object storage (S3), elastic warehouse compute (Snowflake, BigQuery), и dbt как стандарт для SQL-трансформаций. Сегодня >90% новых data stack'ов — ELT.

Mental model

ETL — transform до load. Compute отдельный, warehouse «чист», raw layer'а нет. ELT — load raw, transform внутри warehouse. Compute = warehouse, raw layer всегда доступен для replay.

Один абзац разницы:

• ETL: Sources → ETL Server (Informatica) → DWH (final tables only). Bug в transform → re-extract из source (часто невозможно).
• ELT: Sources → Ingestion (Fivetran) → S3 raw → Warehouse (raw → staging → marts via dbt) → BI / Reverse ETL. Bug? dbt run --full-refresh — raw layer всё помнит.

Что на диаграмме

Шипанная диаграмма (/s/etl-vs-elt) показывает обе эры рядом + PII-edge для compliance ADR:

• Sources: pg (Postgres orders), stripe (Stripe API), segment (Segment events).
• Classic ETL group: informatica (PowerCenter), mssql (MS SQL DW final tables).
• Modern ELT path: fivetran (ingestion) → s3 (parquet, immutable) → Snowflake group.
• Snowflake (warehouse + compute): raw.* (landing) → stg (dbt views) → mart (incremental tables).
• Transforms: dbt (dbt Cloud — SQL + Jinja).
• Activation: looker (BI), hightouch (Reverse ETL) → salesforce (CRM).
• PII edge: pii-redactor (Spark, pre-load) — для compliance-сценария.

Edges — только физические провода. Ответы и replay идут по тем же edges (reverse animation в FlowBuilder).

Сценарии

Informatica nightly batch: extract → transform на dedicated ETL server → load final shape в MS SQL DW. Bug в country mapping → re-extract из source (slow, sometimes impossible — source могла уже truncate'нуть старые rows). DWH compute был дорогой (Teradata $$$), поэтому transform держали off-warehouse. Эпоха «raw layer'а не существует».

Fivetran CDC из Postgres + Stripe API poll каждые 15min + Segment events → S3 partitioned parquet → COPY INTO Snowflake raw.orders (immutable history) → dbt run: raw → staging.stg_orders (view, минимальный cleanup) → marts.orders_summary (incremental table) → Looker dashboard. Bug? dbt run --full-refresh — raw layer на месте, replay бесплатный.

customer_segments (ML scores + cohorts) builds в marts; Hightouch читает changed rows; пушит update в Salesforce contact fields; sales reps видят ML-сегмент в CRM утром. Failure: backfill 100M rows → Salesforce API throttled → enable Hightouch rate limiting + batch sync. Reverse ETL — это «активация» данных: warehouse становится source of truth для operational систем.

EU GDPR: raw PII (emails, SSN) нельзя класть в Snowflake. Option A (pure ELT — mask в dbt) REJECTED: auditor находит PII в raw.* schema, compliance violation. Option B (ETL-style pre-load): Spark redactor hashes emails / drops SSN / tokenizes names; только masked rows достигают S3 → Snowflake raw.* безопасен (no PII ever there); dbt models continue как обычно. Decision: hybrid — ETL для PII step, ELT для всего остального.

Trade-offs (ADR)

Контекст. Команда выбирает архитектуру для нового аналитического стека. Source — Postgres + Stripe + Segment. Warehouse — Snowflake. Compliance — нужно соблюдать GDPR для EU customers.

Decision drivers:

Choice: ELT по умолчанию, ETL hybrid для PII.

• Sources → Fivetran → S3 → Snowflake (raw → stg → mart via dbt) → Looker / Hightouch
• Для PII-сенситивных таблиц вставляем Spark redactor между source и S3 (ETL pre-load).
• Раздельные dbt-проекты для production-marts и ad-hoc analytics.
• Monte Carlo для observability (freshness, volume, schema anomalies).

Trade-offs принятые:

• Snowflake bill будет расти с queries → автосуспенд warehouses + incremental материализации.
• Fivetran cost (per-row) станет проблемой на 100M+ rows/day → план миграции на Airbyte или custom CDC.
• dbt build time растёт с числом моделей → defer to prod artifacts в PR-builds, parallel execution.

Реальные системы

• HubSpot — canonical modern data stack: Snowflake + dbt + Airflow + Hex + Hightouch.
• Monzo — BigQuery + dbt + Looker, всё cloud-native, one стек.
• JetBlue — Snowflake + dbt для real-time ops + customer 360.
• Netflix — S3 + Iceberg + Trino + Spark + dbt-like internal tools (raньше custom ETL фреймворк, движутся к ELT).
• Airbnb — Druid + Hive + Presto + custom dbt-like (Minerva).
• Slack Data Platform — S3 + Iceberg + Spark + dbt + Airflow (lakehouse style).
• Stripe Sigma — Snowflake-like internal warehouse + custom transforms.

Стандартная стартап-стека 2026: Fivetran/Airbyte → Snowflake/BigQuery → dbt → Looker/Hex/Lightdash. Hightouch если нужна активация. Monte Carlo / Elementary для observability. Dagster или Airflow для orchestration.

Anti-patterns

• Skip raw layer. Transformly прямо в marts без raw. Любой bug = re-extract из source (медленно, иногда невозможно). Raw layer = страховка.
• «ETL python script in cron» для production. Нет retry, нет lineage, нет alerts, нет idempotency. Используйте Airflow/Dagster/Prefect.
• dbt models без тестов. Prod dashboard показывает -100% — никто не знает что упало. Минимум: not_null, unique, accepted_values, source freshness.
• Один большой dbt model на 5000 строк SQL. Невозможно дебажить. Layered: staging → intermediate → marts.
• Truncate-and-load для огромных таблиц вместо incremental. 10× медленнее, в 100× дороже.
• Reverse ETL вместо proper ETL. Sync 100M rows из warehouse в Salesforce 5 раз в день — Salesforce throttle'нёт. Reverse ETL только для derived data (segments, scores), не для replication.
• Schema drift без отслеживания. Source добавил столбец, dbt модель не обновилась → silent data loss. dbt source freshness + DataHub catalog отлавливают.
• Snowflake без auto-suspend. Warehouse работает 24/7 за $1500/month впустую.
• Fivetran cost explosion. На росте users bill вырос с $5K до $50K/month за месяц. План B (Airbyte / custom CDC) должен быть готов заранее.

Когда НЕ использовать

ELT не подходит, когда:

• PII compliance требует не класть raw PII в warehouse (GDPR, HIPAA, PCI). Используйте ETL-style pre-load (Spark redactor) хотя бы для compliance-bound шагов.
• DWH compute дорогой/фиксированный (legacy on-prem Teradata, лицензированный Oracle). Transform на отдельном Spark-кластере дешевле.
• Heavy ML feature engineering который не выражается через SQL. Spark на отдельном кластере → готовые features в warehouse — это de facto ETL.
• Streaming aggregations с миллисекундным окном (real-time fraud). Flink/Materialize pre-aggregates, warehouse получает уже посчитанное.

ETL не подходит, когда:

• Schema source меняется часто → re-extract'ить ETL-pipelines каждый раз дорого.
• Analytics-команда состоит из аналитиков на SQL, не data engineers на Python.
• Нужен frequent replay / debugging моделей — без raw layer'а это боль.
• Cost-sensitive стартап — Informatica/Talend лицензии стоят как Snowflake bill.

Ни ETL ни ELT не нужны, когда:

• Один Postgres + один dashboard в Metabase. Не строй data platform на ровном месте — Postgres replica + read-only queries хватит до первой реальной потребности.

Дальше читать

• change-data-capture — фундамент streaming ETL/ELT, как Debezium читает WAL.
• iceberg-deltalake-hudi — современные table formats для S3 raw layer.
• data-mesh — domain-oriented decomposition data platform.
• lambda-vs-kappa — batch vs streaming архитектуры.
• dbt docs — docs.getdbt.com, стандартный onboarding.
• «Fundamentals of Data Engineering» — Reis & Housley (O'Reilly 2022), главы про ETL/ELT/lakehouse.
• Tristan Handy (dbt founder) — Roundup blog — analytics engineering мысли.
• Benn Stancil — benn.substack.com — thought leadership по modern data stack.
• Locally Optimistic — комьюнити-блог analytics engineering best practices.
• System Design Space — data-pipeline-etl-elt-architecture.