В прошлом уроке мы говорили об ELT как о шаблоне. Теперь посмотрим, во что этот шаблон превратился на практике в районе 2020-2026 годов. Появилось устойчивое словосочетание Modern Data Stack (MDS), которым описывают типичный набор инструментов для построения аналитической инфраструктуры с нуля в облаке. Этот стек не один — но архитектурный шаблон очень узнаваемый, и понимать его обязан любой DE.

Из чего состоит современный стек

MDS — это четыре основных слоя, каждый со своими инструментами:

Эти четыре слоя — концептуальные. В реальной компании могут быть дополнительные элементы: оркестратор (Airflow, Dagster, Prefect), data quality (Great Expectations, Monte Carlo), data catalog (Atlan, DataHub), feature store, lakehouse-слой. Но базовый каркас именно такой.

Слой ingestion: Fivetran, Airbyte, dlt, Stitch

Задача этого слоя — забрать данные из источников и положить в DWH в сыром виде. Никаких трансформаций, никаких бизнес-правил. Один в один, инкрементально, надёжно, с обработкой schema evolution.

Fivetran. Платный managed-сервис. Сотни коннекторов: Salesforce, Stripe, Hubspot, Shopify, Google Ads, Facebook Ads, Postgres, MySQL и т.д. Платишь за объём строк, экономишь на разработке коннекторов. Для большинства SaaS-источников это базовый выбор.

Airbyte. Open-source альтернатива Fivetran. Можно поднять у себя, можно использовать managed cloud. Меньшая стабильность коннекторов, но бесплатный self-hosted вариант. Хорошо подходит командам, у которых много custom-источников.

dlt (data load tool). Open-source Python-библиотека. Не managed-сервис, а просто библиотека, которой ты пишешь свой коннектор за 20-30 строк кода. Хорошо, когда нужен максимальный контроль или коннектора нет у Fivetran/Airbyte.

Stitch. Старший родственник Fivetran, теперь часть Talend. Меньше используется в новых проектах.

Слой Cloud DWH: Snowflake, BigQuery, Redshift, Databricks

Это сердце стека. Сюда приезжают данные, тут живут SQL-трансформации, отсюда читают BI-инструменты.

Snowflake. Самое популярное независимое облачное DWH. Работает поверх AWS/GCP/Azure. Главная фишка — разделение compute (виртуальные warehouses) и storage. Можно поднять кластер любого размера для тяжёлого job-а и тут же погасить. Удобная модель прав и share-функциональность.

Google BigQuery. DWH от Google, нативно serverless. Не нужно поднимать warehouses — просто пишешь SQL, BigQuery сам распределяет compute. Платишь за просканированные данные или за зарезервированные слоты. Лучше всего интегрируется с GCP-экосистемой.

AWS Redshift. Старый игрок, теперь обновлённый до Redshift Serverless. Тесно интегрирован с AWS-сервисами. Чуть менее популярен в новых проектах MDS, но всё ещё широко встречается.

Databricks SQL. Эволюция от Spark-кластера к полноценному lakehouse. Хорош, когда у тебя уже есть Spark-нагрузки и хочется аналитику поверх того же data lake без копирования данных.

Слой transformation: dbt

dbt де-факто стал стандартом для SQL-трансформаций внутри DWH. Его модель проста:

• Ты пишешь SQL-модели — файлы .sql, каждый из которых — это SELECT для одной таблицы или view.
• Между моделями ссылаешься через ref() — макрос, который превращается в полное имя таблицы и автоматически строит граф зависимостей.
• Запускаешь dbt run — dbt компилирует SQL и выполняет модели в правильном порядке.
• Параллельно dbt test прогоняет тесты на колонки (unique, not_null, кастомные) и проверяет инварианты.
• Сгенерированная документация и lineage-граф автоматически собираются в dbt docs.

Это переворачивает работу с пайплайнами: они становятся обычным кодом, который лежит в git, проходит через pull request, прогоняется в CI/CD. Многим командам это даёт первый раз в жизни нормальные практики версионирования трансформаций.

Слой BI и reverse ETL

После того, как данные очищены в DWH, их нужно показать пользователям. Тут два основных направления:

BI-инструменты — дашборды для людей. Looker (теперь Looker Studio Pro от Google), Tableau, Power BI, Metabase, Superset. Все они читают SQL из DWH и рисуют графики.

Reverse ETL — выгрузка обработанных данных обратно в операционные системы. Например, агрегаты по клиентам нужно отправить в Salesforce, чтобы менеджеры видели их в CRM. Этим занимаются Hightouch, Census, Polytomic.

Реальный пример: Salesforce -> Snowflake -> dbt -> Looker

Чтобы стек был не абстракцией, давай пройдём конкретный кейс. Компания продаёт софт по подписке, использует Salesforce как CRM, и хочет видеть в Looker метрику Monthly Recurring Revenue (MRR) по сегментам клиентов.

Шаг 1: Extract + Load. В Fivetran подключаем коннектор Salesforce. Он каждый час забирает обновления из объектов Account, Opportunity, Contract и пишет их в Snowflake в схему raw.salesforce. Никаких трансформаций — таблицы один в один как в Salesforce, со всеми внутренними полями типа IsDeleted и SystemModstamp.

Шаг 2: Staging-слой в dbt. Пишем модель stg_salesforce__accounts.sql:

SELECT
  id                          AS account_id,
  name                        AS account_name,
  industry                    AS industry,
  type                        AS account_type,
  CASE
    WHEN annual_revenue > 1000000 THEN 'enterprise'
    WHEN annual_revenue > 100000  THEN 'mid-market'
    ELSE 'smb'
  END                         AS segment,
  created_date::DATE          AS created_at
FROM {{ source('salesforce', 'account') }}
WHERE is_deleted = FALSE

Эта модель типизирует данные, переименовывает колонки, исключает удалённые записи и считает базовый сегмент.

Шаг 3: Mart-слой. Пишем модель fct_mrr_monthly.sql, которая собирает данные о подписках и считает MRR по месяцам и сегментам:

SELECT
  DATE_TRUNC('month', contract_start_date) AS month,
  a.segment,
  COUNT(DISTINCT c.account_id)             AS active_accounts,
  SUM(c.monthly_amount)                    AS mrr
FROM {{ ref('stg_salesforce__contracts') }} c
JOIN {{ ref('stg_salesforce__accounts') }}  a ON c.account_id = a.account_id
WHERE c.status = 'active'
GROUP BY 1, 2

dbt автоматически понимает, что fct_mrr_monthly зависит от stg_salesforce__contracts и stg_salesforce__accounts, и запускает их в правильном порядке.

Шаг 4: Тесты. В schema.yml рядом с моделью:

models:
  - name: fct_mrr_monthly
    columns:
      - name: mrr
        tests:
          - not_null
      - name: month
        tests:
          - not_null

dbt при каждом запуске проверит, что MRR не пустой и месяц заполнен.

Шаг 5: BI. В Looker создаём дашборд, который читает fct_mrr_monthly и рисует график MRR по месяцам, разрезанный по сегментам. Бизнес-пользователи открывают дашборд утром в понедельник и видят актуальные цифры.

Весь этот пайплайн отрабатывает за несколько минут каждый час. Никакого Informatica, никакого отдельного сервера трансформаций. Только Fivetran + Snowflake + dbt + Looker, и SQL в git.

Альтернативные стеки

Описанный выше — каноничный MDS. Существуют альтернативы:

• GCP-нативный. BigQuery + Dataform + Looker Studio. Тесно интегрирован, дешевле для маленьких объёмов.
• AWS-нативный. Redshift + Glue + QuickSight. Меньше популярен в новых проектах, но встречается.
• Databricks-нативный. Databricks + Delta Lake + dbt + Lakeview. Подходит, когда уже есть тяжёлые Spark-нагрузки и хочется единый lakehouse.
• Self-hosted/open-source. ClickHouse/Postgres + dbt + Metabase + Airbyte. Дешевле в проде, дороже в поддержке.

Попробуй сам

Зайди на сайт любой data-команды (Spotify, Netflix, Airbnb, Shopify публикуют свои стеки в инженерных блогах). Прочитай один пост про их пайплайн и составь mental map: где у них ingestion, где DWH/lakehouse, где transformation, где BI. Часто стек будет отличаться от классического MDS — это нормально, у больших компаний всегда есть исторический контекст. Но базовые слои всегда узнаваемы.