2026'da Veri Analistleri için dbt: Modelleme, Test ve Mülakat Soruları

Veri analitiği dünyasında dbt (data build tool), 2026 itibarıyla modern veri ambarı yönetiminin vazgeçilmez bir bileşeni haline gelmiştir. Geleneksel ETL süreçlerinin yerini alan ELT yaklaşımında dbt, dönüşüm (transformation) katmanını tamamen SQL tabanlı bir yapıya kavuşturarak veri analistlerinin iş akışlarını kökten değiştirmiştir. Snowflake, BigQuery veya Redshift gibi bulut veri ambarlarının ham verileri depoladığı ortamlarda dbt, bu verileri anlamlı iş metriklerine dönüştüren katman olarak görev yapmaktadır. Veri mühendisliği ekiplerinin yanı sıra veri analistleri için de dbt bilgisi artık bir tercih değil, kariyer gereksinimi haline gelmiştir. Bu rehberde dbt proje yapısı, materialization stratejileri, veri kalitesi testleri, Jinja makroları ve sıkça karşılaşılan mülakat soruları detaylı olarak ele alınmaktadır.

dbt Proje Yapısı: Staging, Intermediate ve Marts

Başarılı bir dbt projesi, verilerin ham halden iş metriklerine dönüşüm sürecini net katmanlara ayırır. Bu katmanlı mimari, kodun okunabilirliğini artırır, tekrar kullanılabilirliği sağlar ve bakım maliyetlerini düşürür.

Staging katmanı, ham veri kaynaklarının temizlendiği ve standartlaştırıldığı ilk dönüşüm noktasıdır. Her staging modeli yalnızca tek bir kaynağa karşılık gelir; sütun adları düzenlenir, veri tipleri dönüştürülür ve geçersiz kayıtlar filtrelenir. Aşağıdaki örnekte Stripe ödeme verileri staging katmanında işlenmektedir:

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

Bu modelde dikkat çekici birkaç pratik bulunmaktadır: {{ source() }} fonksiyonu ile ham veri kaynağına referans verilmesi, tutarların cent'ten dolara dönüştürülmesi ve başarısız ödemelerin erken aşamada filtrelenmesi. Bu yaklaşım, downstream modellerin temiz ve güvenilir veriyle çalışmasını garantiler.

Intermediate katmanı, birden fazla staging modelinin birleştirildiği ve iş mantığının uygulandığı ara katmandır. Genellikle doğrudan sorgulanmaz; marts katmanına veri hazırlamak amacıyla kullanılır.

Marts katmanı ise iş birimlerinin doğrudan tükettiği, dashboard ve raporlarda kullanılan nihai modellerdir. Aşağıda aylık gelir hesaplamasına yönelik bir mart modeli yer almaktadır:

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

Bu modelde {{ ref() }} fonksiyonu ile staging modeline referans verilmesi, dbt'nin bağımlılık grafiğini (DAG) otomatik olarak oluşturmasını sağlar. ref() kullanımı, modeller arası ilişkilerin açıkça tanımlanmasının yanı sıra çalıştırma sırasının doğru belirlenmesini de garanti eder. SQL window functions ve CTE'ler konusundaki bilgiler, bu tür modellerin yazımında büyük avantaj sağlamaktadır.

Materialization Stratejileri: Doğru Yaklaşımı Seçmek

dbt'de materialization, bir modelin veri ambarında nasıl depolanacağını belirler. Doğru strateji seçimi, hem sorgu performansını hem de veri ambarı maliyetlerini doğrudan etkiler.

| Materialization | Kullanım Alanı | Yeniden Oluşturma Davranışı | |----------------|----------|-------------------| | view | Hafif staging modelleri, düşük sorgu sıklığı | Her çalıştırmada SQL view olarak yeniden oluşturulur | | table | Dashboard'lar tarafından sık sorgulanan mart modelleri | Her çalıştırmada tablo tamamen yeniden oluşturulur | | incremental | Büyük fact tabloları (olaylar, loglar) | Yalnızca yeni satırları ekler veya birleştirir | | ephemeral | Yeniden kullanılabilir CTE'ler, doğrudan sorgulanmaz | Satır içi alt sorgu olarak derlenir |

Büyük veri hacimlerinde incremental materialization, performans ve maliyet açısından kritik önem taşır. Aşağıdaki örnekte sayfa görüntüleme olayları incremental bir modelle işlenmektedir:

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

is_incremental() makrosu, modelin ilk çalıştırma mı yoksa artımlı güncelleme mi yapacağını belirler. {{ this }} ifadesi mevcut tabloya referans vererek yalnızca son çalıştırmadan sonraki yeni verilerin işlenmesini sağlar. Bu yaklaşım, milyarlarca satırlık olay tablolarında çalıştırma süresini saatlerden dakikalara indirebilmektedir.

dbt ile Veri Kalitesi Testleri

Veri kalitesi, veri analitiği projelerinin güvenilirliğinin temel taşıdır. dbt, veri kalitesini kod olarak tanımlama imkanı sunarak testleri CI/CD süreçlerine entegre edilebilir hale getirir. dbt'de iki temel test türü bulunmaktadır: şema testleri ve tekil testler.

Şema testleri (generic tests), YAML dosyalarında tanımlanır ve yaygın veri doğrulama senaryolarını kapsar:

# 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

Bu yapılandırmada unique testi anahtar sütunun benzersizliğini, not_null testi boş değer olmamasını, accepted_values testi yalnızca geçerli durumların bulunmasını ve dbt_utils.expression_is_true testi ise iş kurallarına uygunluğu doğrular. dbt test komutu çalıştırıldığında bu testlerin her biri bağımsız SQL sorguları olarak yürütülür.

Tekil testler (singular tests) ise daha karmaşık iş kurallarını doğrulamak için özel SQL sorguları olarak yazılır:

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

Bu test, herhangi bir satır döndürürse başarısız olur. Negatif net gelir iş mantığına aykırı bir durum olduğundan, bu tür bir anomali erken aşamada yakalanmalıdır.

Jinja ve Makrolar: Yeniden Kullanılabilir SQL Mantığı

dbt'nin Jinja şablon motoru, SQL'e programlama dili yetenekleri kazandırır. Makrolar, tekrar eden SQL kalıplarını fonksiyonlara dönüştürerek kod tekrarını ortadan kaldırır ve tutarlılığı artırır.

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

Bu makro, cent cinsinden saklanan tutarları dolar cinsine dönüştüren standart bir formüldür. Proje genelinde tutarlı bir şekilde kullanılabilir:

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

Makrolar sayesinde dönüşüm mantığı tek bir noktada tanımlanır. Hesaplama formülünün değişmesi gerektiğinde yalnızca makro dosyası güncellenir; tüm referans noktaları otomatik olarak güncellenir. Bu yaklaşım, özellikle büyük projelerde onlarca modelde aynı dönüşümün uygulandığı senaryolarda bakım maliyetini büyük ölçüde azaltır. Jinja ayrıca döngüler, koşullu ifadeler ve değişkenler gibi programatik yapılar sunarak dinamik SQL üretimini mümkün kılar.

dbt Mülakat Soruları: Veri Analistleri İçin

dbt bilgisi, veri analitiği mülakat süreçlerinde giderek daha fazla sorgulanan bir yetkinlik haline gelmiştir. Aşağıda sıkça karşılaşılan beş mülakat sorusu ve kapsamlı yanıtları yer almaktadır.

S1: {{ ref() }} ve {{ source() }} arasındaki fark nedir?

{{ source() }} fonksiyonu, dbt projesinin dışındaki ham veri kaynaklarına (raw data) referans vermek için kullanılır. Genellikle staging katmanındaki modellerde, ELT araçlarının yüklediği ham tablolara erişmek amacıyla kullanılır. {{ ref() }} fonksiyonu ise dbt projesi içindeki diğer modellere referans vermek için kullanılır. dbt, ref() çağrılarını analiz ederek modeller arasındaki bağımlılık grafiğini (DAG) otomatik olarak oluşturur ve çalıştırma sırasını belirler. source() veri girişini, ref() ise model içi bağımlılıkları temsil eder.

S2: Incremental modeller ne zaman kullanılmalıdır ve riskleri nelerdir?

Incremental modeller, milyonlarca veya milyarlarca satır içeren büyük fact tablolarında kullanılmalıdır. Olay logları, sayfa görüntülemeleri ve işlem kayıtları tipik kullanım alanlarıdır. Her çalıştırmada yalnızca yeni veya değişen satırlar işlendiğinden çalıştırma süresi ve hesaplama maliyeti önemli ölçüde azalır. Ancak riskleri de bulunmaktadır: geç gelen veriler (late-arriving facts) atlanabilir, şema değişiklikleri tam yeniden oluşturma (full refresh) gerektirebilir ve unique_key doğru tanımlanmazsa veri tekrarı oluşabilir. Bu nedenle periyodik --full-refresh çalıştırmaları planlanmalıdır.

S3: dbt'de test stratejisi nasıl oluşturulmalıdır?

Etkili bir test stratejisi katmanlı olmalıdır. Staging katmanında her modelin birincil anahtarında unique ve not_null testleri bulunmalıdır. Kategorik sütunlarda accepted_values testi uygulanmalıdır. Mart katmanında iş kurallarını doğrulayan tekil testler yazılmalıdır — örneğin negatif gelir kontrolü. Kaynak tazeliği testleri pipeline arızalarını erken tespit eder. Tüm testler CI/CD sürecine entegre edilerek her pull request'te otomatik çalıştırılmalıdır.

S4: Staging, intermediate ve marts katmanları arasındaki fark nedir?

Staging katmanı, 1:1 kaynak eşlemesiyle ham verilerin temizlendiği ve standartlaştırıldığı katmandır. İş mantığı uygulanmaz; yalnızca yeniden adlandırma, tip dönüşümü ve temel filtreleme yapılır. Intermediate katmanı, birden fazla staging modelinin birleştirildiği ve karmaşık iş mantığının uygulandığı ara katmandır; doğrudan son kullanıcılar tarafından sorgulanmaz. Marts katmanı ise iş birimlerine özel, dashboard ve raporlarda kullanılan nihai modellerdir. fct_ (fact) ve dim_ (dimension) ön ekleriyle adlandırılır ve dimensional modelleme prensiplerini takip eder.

S5: dbt'de paket (package) yönetimi nasıl çalışır?

dbt, packages.yml dosyası aracılığıyla harici paketlerin projeye dahil edilmesini sağlar. dbt_utils en yaygın kullanılan pakettir ve surrogate_key, expression_is_true, pivot gibi yardımcı makroları içerir. dbt_expectations paketi ise Great Expectations tarzı gelişmiş veri kalitesi testleri sunar. dbt deps komutuyla paketler yüklenir. Paketler, topluluk tarafından geliştirilmiş ve test edilmiş makro ve model kütüphaneleri sunarak geliştirme süresini kısaltır.

Üretim Projeleri İçin dbt En İyi Pratikleri

Kurumsal ölçekte dbt projelerinin sürdürülebilirliği için belirli disiplinler gereklidir. Her modelin _models.yml dosyasında belgelenmesi, sütun açıklamalarının eksiksiz olması ve testlerin tanımlanması temel gereksinimlerdir. Model isimlendirmesinde tutarlı bir konvansiyon uygulanmalıdır: staging modelleri stg_{kaynak}__{tablo}, fact modelleri fct_{iş_süreci}, dimension modelleri dim_{varlık} formatında adlandırılmalıdır.

Versiyon kontrolü pratikleri açısından, her değişiklik ayrı bir branch'te geliştirilmeli, pull request sürecinde kod incelemesi yapılmalı ve dbt build komutuyla hem modellerin hem testlerin başarılı olduğu doğrulanmalıdır. CI/CD pipeline'ında dbt test adımının başarısız olması deployment'ı engellemelidir.

Kaynak veri tazeliğinin izlenmesi de veri kalitesinin önemli bir boyutudur:

# 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 source freshness komutu, kaynakların son güncelleme zamanını kontrol eder. 12 saat geçtiyse uyarı, 24 saat geçtiyse hata verilir. Bu mekanizma, pipeline arızalarının erken tespit edilmesini sağlar.

Performans optimizasyonu için büyük modellerde incremental materialization tercih edilmeli, staging modelleri view olarak bırakılmalı ve sıklıkla sorgulanan mart modelleri table olarak materialize edilmelidir. dbt run --select tag:daily gibi etiket tabanlı çalıştırmalar, yalnızca gerekli modellerin güncelenmesini sağlayarak kaynak kullanımını optimize eder.

Sonuç

dbt, 2026 itibarıyla veri analistlerinin araç setinde merkezi bir konuma sahiptir. Bu rehberde ele alınan temel noktalar şu şekilde özetlenebilir:

• Katmanlı mimari (staging, intermediate, marts) ile veri dönüşüm süreçleri modüler ve bakımı kolay bir yapıya kavuşturulur
• Materialization stratejileri doğru seçildiğinde sorgu performansı ve veri ambarı maliyetleri optimize edilir; özellikle büyük veri hacimlerinde incremental modeller kritik avantaj sağlar
• Veri kalitesi testleri — şema testleri, tekil testler ve kaynak tazeliği kontrolleri — güvenilir veri pipeline'larının temelini oluşturur
• Jinja makroları ile SQL mantığı yeniden kullanılabilir hale getirilerek kod tekrarı ortadan kaldırılır ve proje genelinde tutarlılık sağlanır
• Mülakat hazırlığı kapsamında ref() ve source() farkı, incremental model riskleri, test stratejileri ve katman mimarisi gibi konulara hakimiyet beklenmektedir
• dbt bilgisi, veri mühendisliği ve veri analitiği rollerinde standart bir beklenti haline gelmiş olup, pratik proje deneyimiyle desteklenen adaylar mülakat süreçlerinde belirgin avantaj elde etmektedir