# dbt dla analityków danych w 2026: modelowanie, testowanie i pytania rekrutacyjne

> dbt dla analityków danych — modelowanie SQL, testowanie jakości danych, struktura projektów i przygotowanie do pytań rekrutacyjnych z praktycznymi przykładami.

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

---

dbt (data build tool) zajmuje w 2026 roku ugruntowaną pozycję jako standardowe narzędzie do transformacji danych w nowoczesnym stosie analitycznym. Coraz więcej organizacji wymaga od analityków danych praktycznej znajomości dbt — zarówno przy budowaniu modeli SQL, jak i przy zapewnianiu jakości danych w hurtowniach takich jak Snowflake, BigQuery czy Redshift. Wraz z wersją dbt Core v2.0 w fazie alfa i stabilną wersją v1.12, framework obejmuje obecnie wszystko — od modelowania SQL, przez zautomatyzowane testowanie, po dokumentację — a całość kontrolowana jest w systemie wersji Git.

Niniejszy przewodnik obejmuje strukturę projektu dbt, wzorce modelowania warstwowego, strategie materializacji, testowanie jakości danych, makra Jinja oraz pytania, które najczęściej pojawiają się na rozmowach kwalifikacyjnych na stanowiska z zakresu [analityki danych](/technologies/data-analytics) i [inżynierii danych](/technologies/data-engineering).

> **dbt w architekturze ELT**
>
> dbt realizuje krok T (Transform) w architekturze ELT. Narzędzia ingestion (Fivetran, Airbyte, Stitch) ładują surowe dane do hurtowni, a dbt przekształca je w czyste, przetestowane i udokumentowane modele gotowe do analizy. W odróżnieniu od tradycyjnego ETL, transformacje wykonywane są bezpośrednio w hurtowni za pomocą czystego SQL — bez konieczności przenoszenia danych do zewnętrznego silnika obliczeniowego.

## Struktura projektu dbt: Staging, Intermediate i Marts

Dobrze zorganizowany projekt dbt opiera się na architekturze warstwowej, w której każda warstwa pełni ściśle określoną funkcję. Takie rozdzielenie odpowiedzialności zapobiega powstawaniu skomplikowanych, monolitycznych zapytań SQL, których utrzymanie z czasem staje się niewykonalne.

Standardowa konwencja wyróżnia trzy warstwy:

- **Staging** — lekkie modele, które pobierają surowe dane ze źródeł, zmieniają nazwy kolumn, rzutują typy i filtrują nieprawidłowe rekordy. Na każdą tabelę źródłową przypada dokładnie jeden model staging.
- **Intermediate** — modele zawierające logikę biznesową: złączenia tabel staging, agregacje i obliczenia pośrednie. Służą jako wewnętrzne bloki konstrukcyjne, niedostępne bezpośrednio dla użytkowników końcowych.
- **Marts** — finalne modele konsumowane przez dashboardy, raporty i analityków. Każdy mart reprezentuje konkretną encję biznesową lub metrykę.

```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
```

```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
```

Model staging odpowiada za konwersję typów i ujednolicenie nazewnictwa. Model mart zawiera logikę biznesową — w tym przypadku kalkulację przychodu netto. Taka separacja oznacza, że zmiana schematu w źródle danych wymaga modyfikacji wyłącznie jednego modelu staging, a nie każdego zapytania downstream, które korzysta z tych danych.

## Materializacje: wybór właściwej strategii

dbt obsługuje cztery podstawowe [materializacje](https://docs.getdbt.com/docs/build/materializations), które decydują o sposobie persystowania modeli w hurtowni danych. Niewłaściwy wybór prowadzi albo do wolnych zapytań, albo do niepotrzebnych kosztów obliczeniowych.

| 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 |

Modele inkrementalne zasługują na szczególną uwagę, ponieważ rozwiązują najczęstszy problem wydajnościowy — przetwarzanie miliardów wierszy przy każdym uruchomieniu pipeline.

```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
```

Makro `is_incremental()` sprawdza, czy model docelowy już istnieje w hurtowni. Przy pierwszym uruchomieniu dbt przetwarza wszystkie dane. Przy kolejnych uruchomieniach przetwarzane są wyłącznie nowe wiersze — zadanie, które trwało dwie godziny, redukuje się do kilku minut.

## Testowanie jakości danych w dbt

Testowanie danych w dbt działa na dwóch poziomach: testy schematowe definiowane w plikach YAML oraz niestandardowe testy SQL zapisywane jako osobne pliki. Oba uruchamiane są poleceniem `dbt test` i powodują awarię pipeline w przypadku wykrycia naruszeń.

Testy schematowe pokrywają najczęstsze kontrole jakości danych bez konieczności pisania SQL:

```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
```

Dla złożonej logiki walidacyjnej, której nie da się wyrazić w YAML, stosowane są niestandardowe testy jednostkowe (singular tests):

```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
```

Każdy wiersz zwrócony przez test jednostkowy oznacza wykryty problem. Ten wzorzec wykrywa uszkodzenia danych, błędy w systemach upstream i pomyłki logiczne zanim trafią one do dashboardów i raportów konsumowanych przez decydentów biznesowych.

## Jinja i makra: wielokrotnie używana logika SQL

dbt wykorzystuje [silnik szablonów Jinja](https://docs.getdbt.com/docs/build/jinja-macros) do dynamicznego generowania SQL. Dwie najważniejsze funkcje wbudowane to `ref()` do odwoływania się do modeli dbt oraz `source()` do odwoływania się do surowych tabel źródłowych. Poza nimi makra pozwalają na eliminację powtarzalnych wzorców SQL w całym projekcie.

```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') }}
```

Makro kompilowane jest w czasie budowania do standardowego SQL. Takie podejście gwarantuje spójną logikę konwersji walutowej w każdym modelu operującym na wartościach pieniężnych. Pojedyncza zmiana w definicji makra automatycznie propaguje się do wszystkich modeli, które z niego korzystają — eliminując ryzyko niespójności i zmniejszając narzut utrzymaniowy.

## Pytania rekrutacyjne dotyczące dbt dla analityków danych

Na rozmowach kwalifikacyjnych z zakresu [analityki danych](/technologies/data-analytics) pytania o dbt koncentrują się na praktycznym rozumieniu narzędzia, a nie na wyuczonych definicjach. Poniższe pytania pojawiają się regularnie w procesach rekrutacyjnych w 2026 roku.

**P1: Jaka jest różnica między `ref()` a `source()`?**

`source()` wskazuje na surowe tabele ładowane przez narzędzia ingestion i zdefiniowane w pliku `sources.yml`. `ref()` wskazuje na inne modele dbt. Użycie `ref()` buduje graf DAG (Directed Acyclic Graph), który dbt wykorzystuje do określenia kolejności wykonania modeli i śledzenia pochodzenia danych (lineage). Kodowanie nazw tabel na sztywno zamiast stosowania `ref()` przerywa śledzenie zależności i uniemożliwia dbt uruchamianie modeli we właściwej kolejności.

**P2: Kiedy należy użyć materializacji incremental zamiast table?**

Materializacja inkrementalna sprawdza się, gdy dane źródłowe są typu append-only lub posiadają wiarygodną kolumnę ze znacznikiem czasu, a tabela jest na tyle duża, że pełna przebudowa byłaby zbyt wolna lub kosztowna. Tabele zdarzeń (events), logi i dane szeregów czasowych to typowe przypadki użycia. Małe tabele wymiarowe powinny pozostać z materializacją `table`, ponieważ złożoność logiki inkrementalnej nie uzasadnia się przy niewielkich wolumenach danych.

**P3: W jaki sposób dbt obsługuje wolno zmieniające się wymiary (SCD Type 2)?**

Mechanizm snapshotów w dbt implementuje śledzenie zmian typu SCD-2. Snapshot monitoruje tabelę źródłową i rejestruje zmiany w czasie, dodając kolumny `dbt_valid_from` i `dbt_valid_to`. Dostępne są dwie strategie: `timestamp` (wykorzystuje kolumnę `updated_at`) i `check` (porównuje wartości kolumn bezpośrednio). Snapshoty uruchamiane są poleceniem `dbt snapshot` oddzielnie od `dbt run`.

**P4: Na czym polega wzorzec staging/intermediate/marts?**

Modele staging oczyszczają i ujednolicają nazewnictwo surowych danych ze źródeł — jeden model na tabelę źródłową, bez złączeń, bez agregacji. Modele intermediate zawierają logikę biznesową: złączenia, filtry i obliczenia służące jako bloki konstrukcyjne. Modele mart to finalne wyniki konsumowane przez analityków i dashboardy. Takie warstwowanie zapewnia, że każdy model ma jedną odpowiedzialność, a zmiany w schemacie źródłowym wpływają wyłącznie na warstwę staging.

**P5: Czym różnią się niestandardowe testy (singular tests) od testów schematowych?**

Testy schematowe deklarowane są w YAML i obejmują standardowe kontrole: `unique`, `not_null`, `accepted_values`, `relationships`. Niestandardowe testy jednostkowe to zapytania SQL umieszczone w katalogu `tests/` — każdy zwrócony wiersz sygnalizuje wykryty problem. Niestandardowe testy generyczne to sparametryzowane makra, które mogą być wielokrotnie stosowane w różnych modelach na wzór testów schematowych. Testy schematowe nadają się do typowych ograniczeń, natomiast testy jednostkowe — do złożonych reguł biznesowych, takich jak warunek, że przychód netto nigdy nie powinien być ujemny.

## Dobre praktyki w produkcyjnych projektach dbt

Projekty dbt w środowiskach produkcyjnych, które przekraczają kilkanaście modeli, wymagają spójnych konwencji. Przestrzeganie poniższych praktyk zapobiega narastaniu długu technicznego, gdy wielu analityków współtworzy ten sam projekt.

**Konwencje nazewnicze** utrzymują porządek w projekcie. Modele staging stosują prefiks `stg_`, modele intermediate — `int_`, a tabele faktów i wymiarów odpowiednio `fct_` i `dim_`. Podkatalogi specyficzne dla źródeł (`models/staging/stripe/`, `models/staging/salesforce/`) grupują powiązane modele logicznie.

**Dokumentacja żyje obok kodu.** Każdy model i każda kolumna powinny mieć opis (`description`) w towarzyszącym pliku YAML. Polecenie `dbt docs generate` generuje przeszukiwalną stronę dokumentacji z wizualnym grafem DAG — nieocenione przy wdrażaniu nowych członków zespołu i audytowaniu pochodzenia danych (data lineage).

**Kontrola świeżości źródeł** wykrywa problemy upstream zanim zdążą się rozprzestrzenić na dalsze warstwy modeli:

```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
```

Polecenie `dbt source freshness` weryfikuje, czy dane źródłowe zostały zaktualizowane w oczekiwanym oknie czasowym. Dwudziestoczterogodzinna przerwa w danych płatności sygnalizuje awarię ingestion, która wymaga zbadania przed uruchomieniem transformacji.

Aby pogłębić umiejętności SQL wykorzystywane w modelach dbt, przewodniki dotyczące [funkcji okna i CTE w SQL](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) oraz [zaawansowanego SQL na rozmowach rekrutacyjnych](/blog/data-analytics/advanced-sql-data-analyst-interviews) omawiają wzorce zapytań najczęściej stosowane w modelach staging i mart.

## Podsumowanie

- dbt realizuje warstwę transformacji w pipeline ELT, wykonując SQL bezpośrednio w hurtowni danych bez potrzeby osobnego silnika obliczeniowego
- Wzorzec staging/intermediate/marts separuje oczyszczanie danych źródłowych od logiki biznesowej, czyniąc zmiany przewidywalnymi i izolowanymi w poszczególnych warstwach
- Materializacja inkrementalna redukuje czas przetwarzania dużych tabel, operując wyłącznie na nowych lub zaktualizowanych wierszach
- Testy schematowe (YAML) pokrywają standardowe ograniczenia; testy jednostkowe (SQL) walidują złożone reguły biznesowe specyficzne dla danej organizacji
- Makra Jinja eliminują powtarzalną logikę SQL i zapewniają spójność we wszystkich modelach projektu
- Kontrola świeżości źródeł wykrywa awarie ingestion zanim zafałszują modele downstream i raporty budowane na ich podstawie
- Przygotowanie do rozmów kwalifikacyjnych powinno koncentrować się na praktycznych scenariuszach — lineage w grafie DAG, kompromisy między materializacjami i strategie testowania — nie na wyuczonych definicjach

---

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