Analytics engineering и роль dbt

До 2018-2019 годов в данных существовало два больших профессиональных лагеря: data engineers, которые собирали и доставляли данные в warehouse, и data analysts/BI, которые писали SQL поверх готовых таблиц для отчётов. Между этими лагерями была дыра — кто-то должен был превращать «сырые таблицы из source-систем» в «удобные таблицы для аналитики». На практике этим занимались либо data engineers (которые писали Spark/Airflow без аналитической интуиции), либо аналитики (которые делали 200-строчные SQL-запросы с CTE-вложенностью семь уровней).

Analytics engineer — это роль, выросшая из этой дыры. И dbt — инструмент, который сделал эту роль масштабируемой как профессию.

Откуда взялась роль

Раньше пайплайн данных выглядел так:

Трансформации жили в Python/Spark коде data engineers. Аналитики видели только финальные таблицы и общались с инженерами через тикеты вида «добавь поле gross_margin в table_orders». Цикл обратной связи — недели. Бизнес-логика — у инженеров. SQL-навыки аналитиков — недоиспользованы.

В 2014-2018 случилась революция: облачные columnar warehouses (Snowflake, BigQuery, Redshift) стали достаточно дешёвыми и быстрыми, чтобы хранить и пересчитывать всё. Стало возможно загружать данные в warehouse сырыми (без трансформации) и трансформировать их уже внутри warehouse, чистым SQL. Так родился паттерн ELT (Extract -> Load -> Transform) на смену ETL.

ELT vs ETL: разница в одном слове

ETL и ELT отличаются местом, где живёт буква T (transform).

Ключевая идея ELT: сырые данные грузятся «как есть», а трансформации происходят уже внутри warehouse через SQL. Это становится возможным, только когда warehouse достаточно быстрый, чтобы за минуты пересчитать 100 млн строк — что и сделали Snowflake / BigQuery / Redshift / Databricks.

Вот сравнительная таблица:

ELT не убил ETL полностью. ETL остаётся валидным для случаев: PII-фильтрация ДО загрузки в warehouse, реал-тайм стриминг (Kafka), source-системы с очень дорогим компьютом (S3 на большом объёме). Но для 95% типичных BI-задач ELT с dbt — стандарт 2026 года.

Что такое analytics engineering

Analytics engineering — это роль на стыке data engineering и data analysis. Analytics engineer:

• Знает SQL хорошо (window functions, CTE, оптимизация планов)
• Понимает бизнес-метрики и общается с stakeholders
• Применяет software engineering практики: version control, code review, тесты, документация, CI/CD
• Не пишет low-level Spark/Python код (это data engineer)
• Не делает дашборды и не презентует слайды (это analyst)

В малой команде один человек может играть все три роли. В средней обычно есть analytics engineer как отдельная позиция. В большой — целая команда analytics engineers, разделённая по доменам (revenue, marketing, product).

Конкретные обязанности типичного analytics engineer:

1. Получает требование от бизнеса: «нужна метрика monthly revenue с разбивкой по сегментам клиентов»
2. Идёт в raw данные warehouse, находит нужные таблицы (Stripe payments, Salesforce accounts)
3. Пишет dbt-модели: stg_stripe__payments, stg_salesforce__accounts, int_payments_with_account, mart_monthly_revenue
4. Добавляет тесты: not_null на foreign keys, unique на primary keys, custom test «revenue не может быть отрицательной»
5. Пишет документацию: descriptions для каждой колонки, doc-block с бизнес-определением «revenue»
6. Открывает PR, code review от другого AE
7. Merge -> CI запускает dbt run в production warehouse -> метрика появляется в Tableau

Это цикл от 4 часов до 2 дней. В старой ETL-схеме на это уходили недели.

Где здесь dbt

dbt — это инструмент, который делает T в ELT. Он:

1. Превращает SQL-файлы в дерево зависимостей (DAG) через функцию ref()
2. Запускает модели в правильном порядке (топологическая сортировка DAG)
3. Поддерживает несколько стратегий материализации (view, table, incremental, ephemeral)
4. Декларативно описывает тесты в YAML
5. Генерирует документацию + lineage диаграммы из кода
6. Управляет средами (dev/prod) через profiles.yml
7. Поддерживает шаблонизацию через Jinja (циклы, условия, макросы)

Под капотом dbt делает очень простую штуку:

# Псевдокод того, что делает dbt при `dbt run`:
for model in topological_sort(parse_dag()):
    compiled_sql = jinja_render(model.sql)
    if model.materialization == "view":
        warehouse.execute(f"CREATE OR REPLACE VIEW {model.name} AS {compiled_sql}")
    elif model.materialization == "table":
        warehouse.execute(f"CREATE OR REPLACE TABLE {model.name} AS {compiled_sql}")
    elif model.materialization == "incremental":
        ... # сложнее, но в основе тот же CREATE/MERGE

Главное «волшебство» dbt — ref(). Когда вы пишете внутри models/marts/orders.sql:

SELECT *
FROM {{ ref('stg_orders') }}
WHERE order_date >= '2026-01-01'

dbt при компиляции делает три вещи:

1. Подставляет полное имя таблицы — database.schema.stg_orders — в зависимости от target environment (dev/prod)
2. Записывает ребро в DAG: orders зависит от stg_orders
3. Гарантирует порядок выполнения: stg_orders будет построен раньше orders

Это превращает разрозненные SQL-файлы в связный граф. Когда вы добавляете новую модель — DAG обновляется автоматически. Когда вы запускаете dbt run --select orders+ — dbt пересчитывает orders и всё, что зависит от него вниз.

Зачем именно SQL, а не Python

Частый вопрос джунов: «Если есть pandas/Spark, зачем учить отдельный SQL-инструмент?» Несколько причин, по которым dbt-SQL стал стандартом:

1. SQL — уже декларативный язык. Вы пишете «что должно быть в результате», а оптимизатор warehouse решает «как». Это снимает огромный класс ошибок.
2. Warehouse-движки заточены на SQL. Snowflake/BigQuery/Redshift/Databricks за 20 лет научились исполнять SQL в десятки раз эффективнее, чем тот же код в pandas-DataFrame.
3. SQL знают аналитики. Это снимает разрыв между «инженерами» и «аналитиками» — они работают на одном языке.
4. SQL легче ревьюить. Прочитать 100 строк SQL проще, чем 100 строк Spark на Scala.
5. SQL portable между warehouses. dbt-модель на Snowflake и dbt-модель на BigQuery различаются в основном диалектными нюансами; код Spark не переносится в SQL warehouse вообще.

dbt поддерживает и Python-модели (models/*.py) на адаптерах, которые умеют Python execution (Snowpark, BigQuery Python, Spark/Databricks, dbt-duckdb). Но это для случаев, где SQL действительно не подходит: ML inference, сложные numerical computations, использование Python-библиотек. Для типичных трансформаций — это SQL.

Junior-уровень: что вы должны вынести из этого урока

Три якорные мысли:

1. dbt — это T в ELT. Не E (загрузка — Fivetran/Airbyte), не L (тоже отдельный инструмент), а именно T — превращение raw данных в clean/modeled таблицы внутри warehouse.

2. Analytics engineer — это роль, а не должность. В малой команде один человек может играть все роли; в средней-большой это отдельная позиция. dbt — основной инструмент этой роли.

3. Главная ценность dbt — ref() и DAG. Без ref() это просто набор SQL-файлов. С ref() — связный граф зависимостей, который dbt сам топологически сортирует и выполняет в правильном порядке.

Попробуй сам

Откройте https://www.getdbt.com/what-is-analytics-engineering (статья от dbt Labs про роль) и сравните три задачи:

1. «Загрузить данные из Stripe API в Snowflake каждые 6 часов»
2. «Превратить raw.stripe_payments в analytics.fct_payments с метриками gross_revenue, net_revenue»
3. «Сделать дашборд Tableau с MRR по неделям»

Какую из них делает data engineer, какую analytics engineer, и какую analyst/BI? Ответ — в порядке: engineer -> analytics engineer -> analyst. Понимание этого разделения — основа всех следующих модулей курса.