# dbt для аналітиків даних у 2026: моделювання, тестування та питання на співбесідах

> dbt для аналітиків даних — SQL-моделювання, тестування якості даних, структура проєктів та підготовка до питань на співбесідах з практичними прикладами.

- Published: 2026-06-17
- Updated: 2026-06-17
- Author: SharpSkill
- Tags: dbt, data-analytics, sql, data-modeling, interview
- Reading time: 10 min

---

У 2026 році dbt (data build tool) залишається одним із найважливіших інструментів у стеку сучасного аналітика даних. Якщо раніше аналітики обмежувалися написанням ad-hoc запитів у SQL-редакторах, то сьогодні від них очікують побудови повноцінних data-пайплайнів із версіонуванням, тестуванням та документацією. dbt перетворює сирий SQL на структуровані, повторювані та надійні трансформації, що робить його незамінним як у повсякденній роботі, так і на технічних співбесідах. Ця стаття охоплює ключові концепції dbt — від структури проєкту та матеріалізацій до тестування якості даних, макросів на Jinja та типових питань, які зустрічаються на інтерв'ю для позицій у сфері [аналітики даних](/technologies/data-analytics).

> **Роль dbt у пайплайні ELT**
>
> dbt працює на етапі Transform у пайплайні ELT (Extract, Load, Transform). Інструменти на кшталт Fivetran, Airbyte або Stitch завантажують сирі дані у сховище (Snowflake, BigQuery, Redshift), а dbt відповідає виключно за їхню трансформацію — очищення, агрегацію та побудову бізнес-метрик. На відміну від ETL-підходу, де трансформація відбувається до завантаження, ELT дозволяє зберігати повну історію сирих даних та змінювати логіку трансформацій без повторного завантаження. Це критично для команд, які працюють з [data engineering](/technologies/data-engineering) та аналітикою.

## Структура проєкту dbt: Staging, Intermediate та Marts

Правильна організація моделей — фундамент будь-якого dbt-проєкту. Стандартна архітектура передбачає три шари, кожен із яких виконує чітко визначену функцію.

**Staging (шар підготовки)** — це перший рівень трансформацій, де сирі дані з джерел очищуються та перейменовуються. Моделі staging мають співвідношення один-до-одного із таблицями-джерелами. Тут не відбувається жодної бізнес-логіки — лише стандартизація назв колонок, приведення типів та базова фільтрація:

```sql
-- models/staging/stripe/stg_stripe__payments.sql
with source as (
    select * from {{ source('stripe', 'payments') }}
),

renamed as (
    select
        id as payment_id,
        amount / 100.0 as amount_usd,  -- Stripe stores cents
        status as payment_status,
        created::timestamp as created_at,
        customer_id
    from source
    where status != 'failed'  -- Filter invalid records early
)

select * from renamed
```

**Intermediate (проміжний шар)** використовується для складних трансформацій, які необхідні кільком кінцевим моделям. Це можуть бути з'єднання таблиць, обчислення проміжних метрик або фільтрація за складними умовами. Проміжні моделі зазвичай матеріалізуються як ephemeral або view.

**Marts (шар бізнес-метрик)** — це фінальний рівень, з якого споживачі (дашборди, BI-інструменти, аналітики) отримують дані. Моделі marts організовані за бізнес-доменами: finance, marketing, product. Кожна модель marts відповідає на конкретне бізнес-запитання:

```sql
-- models/marts/finance/fct_monthly_revenue.sql
with payments as (
    select * from {{ ref('stg_stripe__payments') }}
),

monthly as (
    select
        date_trunc('month', created_at) as revenue_month,
        count(*) as total_transactions,
        sum(amount_usd) as gross_revenue,
        sum(case when payment_status = 'refunded' then amount_usd else 0 end) as refunds
    from payments
    group by 1
)

select
    revenue_month,
    total_transactions,
    gross_revenue,
    refunds,
    gross_revenue - refunds as net_revenue  -- Key business metric
from monthly
```

Функція `{{ ref() }}` створює залежність між моделями, що дозволяє dbt автоматично визначати порядок виконання та будувати DAG (Directed Acyclic Graph) — візуальну карту всього пайплайну.

## Матеріалізації: вибір правильної стратегії

Матеріалізація визначає, яким чином dbt зберігає результат моделі у сховищі даних. Вибір правильної стратегії суттєво впливає на продуктивність запитів та час виконання пайплайну.

| Materialization | Use Case | Rebuild Behavior |
|----------------|----------|-------------------|
| `view` | Lightweight staging models, low query frequency | Recreated as SQL view on each run |
| `table` | Mart models queried often by dashboards | Full table rebuild on each run |
| `incremental` | Large fact tables (events, logs) | Appends/merges new rows only |
| `ephemeral` | Reusable CTEs, never queried directly | Compiled inline as subquery |

Для staging-моделей зазвичай обирають `view` — це найпростіший варіант, який не створює фізичних таблиць. Для marts, до яких часто звертаються дашборди, оптимальним буде `table`, оскільки попередньо обчислені дані пришвидшують запити.

Для великих таблиць фактів, таких як події користувачів або логи, інкрементальна матеріалізація стає критичною. Замість повної перебудови таблиці dbt обробляє лише нові записи:

```sql
-- models/marts/product/fct_page_views.sql
{{ config(
    materialized='incremental',
    unique_key='page_view_id',
    incremental_strategy='merge'
) }}

with events as (
    select
        event_id as page_view_id,
        user_id,
        page_url,
        session_id,
        event_timestamp
    from {{ ref('stg_snowplow__events') }}
    where event_type = 'page_view'

    {% if is_incremental() %}
        -- Only process new events since last run
        and event_timestamp > (select max(event_timestamp) from {{ this }})
    {% endif %}
)

select * from events
```

Блок `{% if is_incremental() %}` гарантує, що під час інкрементального запуску будуть оброблені лише події, які з'явилися після останнього виконання. Параметр `unique_key` забезпечує дедуплікацію через стратегію merge. Для повної перебудови використовується прапорець `--full-refresh`.

## Тестування якості даних у dbt

Тестування — одна з найсильніших сторін dbt, яка відрізняє його від простого написання SQL-запитів. dbt пропонує два типи тестів: вбудовані (generic) та спеціалізовані (singular).

**Вбудовані тести** оголошуються у YAML-файлах і перевіряють окремі колонки. dbt поставляється з чотирма стандартними тестами: `unique`, `not_null`, `accepted_values` та `relationships`. Пакет `dbt_utils` розширює цей набір десятками додаткових перевірок:

```yaml
# models/staging/stripe/_stripe__models.yml
version: 2

models:
  - name: stg_stripe__payments
    description: "Cleaned payment records from Stripe"
    columns:
      - name: payment_id
        description: "Unique payment identifier"
        tests:
          - unique
          - not_null
      - name: payment_status
        tests:
          - accepted_values:
              values: ['succeeded', 'pending', 'refunded']
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"  # No negative payments
```

**Спеціалізовані тести** — це повноцінні SQL-запити, які перевіряють складнішу бізнес-логіку. Якщо запит повертає хоча б один рядок, тест вважається проваленим:

```sql
-- tests/assert_revenue_not_negative.sql
-- This test fails if any month has negative net revenue
select
    revenue_month,
    net_revenue
from {{ ref('fct_monthly_revenue') }}
where net_revenue < 0  -- Should never happen
```

Окрім тестування моделей, dbt підтримує перевірку свіжості джерел через директиву `freshness`. Це дозволяє виявляти ситуації, коли дані з джерела перестали оновлюватися. Ці знання безпосередньо пов'язані з темами, які розглядаються у матеріалі про [SQL window functions та CTE](/blog/data-analytics/sql-window-functions-ctes-advanced-queries).

## Jinja та макроси: повторюваний SQL

Одна з ключових переваг dbt — це шаблонізатор Jinja, який перетворює статичний SQL на гнучку мову програмування. Макроси дозволяють інкапсулювати часто використовувану логіку та повторно застосовувати її у будь-якій моделі проєкту.

Розглянемо типовий приклад — конвертація центів у долари, яка зустрічається в десятках моделей, пов'язаних із платіжними системами:

```sql
-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ({{ column_name }} / 100.0)::numeric(12, 2)
{% endmacro %}
```

Після створення макросу його можна використовувати у будь-якій моделі через синтаксис `{{ }}`:

```sql
-- Usage in any model
select
    payment_id,
    {{ cents_to_dollars('amount_cents') }} as amount_usd,
    {{ cents_to_dollars('tax_cents') }} as tax_usd
from {{ source('stripe', 'payments') }}
```

Макроси особливо цінні для стандартизації бізнес-логіки. Якщо формула конвертації зміниться (наприклад, зміниться точність округлення), достатньо оновити один макрос замість десятків моделей. Jinja також підтримує цикли (`{% for %}`), умовні конструкції (`{% if %}`), змінні та фільтри, що дозволяє генерувати динамічний SQL для складних сценаріїв — наприклад, автоматичного створення union-запитів для таблиць із різних шард.

## Питання на співбесідах із dbt для аналітиків даних

На технічних інтерв'ю у 2026 році dbt — одна з обов'язкових тем для позицій аналітиків та інженерів даних. Нижче наведено п'ять найпоширеніших питань із розгорнутими відповідями, які допоможуть при підготовці поряд із матеріалом про [просунутий SQL для співбесід](/blog/data-analytics/advanced-sql-data-analyst-interviews).

**Q1: У чому різниця між `{{ source() }}` та `{{ ref() }}` у dbt?**

Функція `{{ source() }}` посилається на сирі таблиці, визначені у YAML-файлах джерел. Вона використовується виключно у staging-моделях для отримання даних із зовнішніх систем. Функція `{{ ref() }}` посилається на інші dbt-моделі та створює залежність у DAG-графі. Завдяки `ref()` dbt автоматично визначає правильний порядок виконання моделей та підставляє коректні назви схем та таблиць залежно від середовища (dev, staging, production).

**Q2: Коли варто використовувати інкрементальну матеріалізацію замість table?**

Інкрементальна матеріалізація оптимальна для великих таблиць фактів, де повна перебудова займає надто багато часу або ресурсів. Типові приклади — таблиці подій (page views, clicks), логів або транзакцій. Головна умова — наявність надійного поля для визначення нових записів (наприклад, timestamp). Слід пам'ятати про потенційні проблеми: late-arriving data може бути пропущена, тому періодичний `--full-refresh` є рекомендованою практикою.

**Q3: Як dbt забезпечує якість даних?**

dbt надає два механізми тестування. Generic-тести (`unique`, `not_null`, `accepted_values`, `relationships`) оголошуються у YAML-файлах і перевіряють окремі колонки. Singular-тести — це SQL-файли в директорії `tests/`, де будь-який запит, що повертає результати, вважається проваленим тестом. Додатково dbt підтримує перевірку свіжості джерел (source freshness) та контракти моделей (model contracts), які гарантують відповідність схеми даних очікуваному формату.

**Q4: Що таке Jinja-макроси у dbt і навіщо їх використовувати?**

Макроси — це повторювані фрагменти SQL-логіки, написані з використанням шаблонізатора Jinja. Вони дозволяють уникнути дублювання коду, стандартизувати бізнес-логіку та спростити підтримку проєкту. Наприклад, макрос конвертації валют можна використовувати у всіх моделях, пов'язаних із фінансовими даними. Макроси також лежать в основі пакетів dbt (dbt packages), таких як `dbt_utils` та `dbt_expectations`.

**Q5: Як організувати dbt-проєкт для команди з кількох аналітиків?**

Стандартна структура передбачає три шари: staging (очищення сирих даних, один-до-одного з джерелами), intermediate (проміжні трансформації, з'єднання таблиць) та marts (фінальні бізнес-моделі, організовані за доменами). Кожна директорія має власний YAML-файл із описами та тестами. Для командної роботи критично важливі: конвенції іменування (наприклад, `stg_`, `int_`, `fct_`, `dim_`), обов'язкові тести для ключових колонок, CI/CD-інтеграція для запуску `dbt build` на pull requests та документація через `dbt docs generate`.

## Найкращі практики dbt для продакшн-проєктів

Для побудови надійних та масштабованих dbt-проєктів варто дотримуватися перевірених практик, які сформувалися у спільноті.

**Конвенції іменування.** Staging-моделі мають префікс `stg_` та подвійне підкреслення для розділення джерела та сутності: `stg_stripe__payments`. Факт-таблиці починаються з `fct_`, а таблиці розмірностей — з `dim_`. Ця конвенція робить призначення кожної моделі зрозумілим з першого погляду.

**Один джерело — одна staging-модель.** Кожна таблиця-джерело має рівно одну staging-модель, яка є єдиною точкою входу для цих даних у пайплайні. Це спрощує відстеження залежностей та ізолює зміни у джерелах.

**Тестування на всіх рівнях.** Primary keys мають тести `unique` та `not_null` у кожній моделі. Foreign keys перевіряються через тест `relationships`. Бізнес-правила фіксуються у singular-тестах. Мінімальний поріг — 100% покриття тестами для staging та marts моделей.

**CI/CD-інтеграція.** Кожний pull request повинен автоматично запускати `dbt build --select state:modified+` для перевірки лише змінених моделей та їхніх залежностей. Це скорочує час перевірки та гарантує, що зламаний код не потрапить у продакшн.

**Документація як код.** YAML-файли з описами моделей та колонок є обов'язковими. Команда `dbt docs generate` створює інтерактивний вебсайт із повною документацією проєкту, включаючи DAG-граф залежностей.

**Моніторинг свіжості джерел.** Перевірка `dbt source freshness` має виконуватися за розкладом. Інтеграція з системами сповіщень (Slack, PagerDuty) допомагає оперативно реагувати на затримки у завантаженні даних.

```yaml
# models/staging/stripe/_stripe__sources.yml
version: 2

sources:
  - name: stripe
    database: raw
    schema: stripe
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _fivetran_synced
    tables:
      - name: payments
      - name: customers
```

## Висновок

dbt став стандартом трансформації даних у сучасних аналітичних стеках, і розуміння його можливостей є необхідним для кожного аналітика даних у 2026 році. Ключові висновки:

- **Структура проєкту** з трьома шарами (staging, intermediate, marts) забезпечує чіткий розподіл відповідальності та спрощує підтримку
- **Матеріалізації** (view, table, incremental, ephemeral) дозволяють оптимізувати продуктивність для різних сценаріїв використання
- **Тестування** через generic та singular тести, а також перевірка свіжості джерел гарантують якість та актуальність даних
- **Jinja-макроси** усувають дублювання коду та стандартизують бізнес-логіку на рівні всього проєкту
- **Підготовка до співбесід** вимагає не лише теоретичних знань, а й практичного досвіду роботи з `ref()`, `source()`, інкрементальними моделями та тестами
- Поєднання dbt із навичками [просунутого SQL](/blog/data-analytics/advanced-sql-data-analyst-interviews) та розумінням архітектури [data engineering](/technologies/data-engineering) значно підвищує конкурентоспроможність кандидата на ринку праці

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/data-analytics/dbt-data-analysts-modeling-testing-interview-2026