2026'da dbt: Veri Dönüşümleri, Test Stratejileri ve Mülakat Soruları

dbt (data build tool), modern veri ambarlarında veri dönüşümlerini yönetmek için standart çerçeve haline geldi. 2026 itibarıyla dünya genelinde 40.000'den fazla şirket dbt'yi üretim ortamında kullanıyor ve bu sayı her geçen çeyrek artmaya devam ediyor. Araç, veri mühendislerinin SQL bilgilerini doğrudan dönüşüm mantığına dönüştürmesini sağlarken, yazılım mühendisliğinin versiyon kontrolü, test ve modülerlik gibi temel prensiplerini veri pipeline'larına taşıyor. Bu rehber, dbt dönüşümlerinin temel mekaniklerini, test stratejilerini ve veri mühendisliği mülakatlarında gerçekten sorulan soruları uygulamalı kod örnekleriyle ele almaktadır.

Katmanlı Modelleme: Staging, Intermediate ve Marts

İyi yapılandırılmış bir dbt projesi, dönüşümleri üç katmana ayırır. dbt topluluğu tarafından yaygınlaştırılan bu yaklaşım, tek sorumluluk prensibini her modelde zorunlu kılar ve hata ayıklamayı önemli ölçüde kolaylaştırır.

Staging modelleri ham veriye en yakın katmandır. Görevleri dar kapsamlıdır: sütun isimlerini yeniden adlandırmak, veri tiplerini dönüştürmek ve geçersiz satırları filtrelemek. Bu katmanda birleşim (JOIN) veya toplama (aggregation) işlemi yapılmaz. Amaç, ham verinin temiz ve tutarlı bir ara temsile dönüştürülmesidir.

-- models/staging/stg_orders.sql
WITH source AS (
    SELECT * FROM {{ source('ecommerce', 'raw_orders') }}
)
SELECT
    id AS order_id,
    customer_id,
    CAST(order_date AS DATE) AS order_date,
    CAST(amount AS DECIMAL(10, 2)) AS order_amount,
    LOWER(status) AS order_status
FROM source
WHERE id IS NOT NULL

Intermediate modelleri iş mantığını uygular: birleşimler, toplamalar ve pencere fonksiyonları bu katmanda yer alır. ref() aracılığıyla staging modellerine referans vererek DAG'daki bağımlılıkları otomatik olarak kaydeder. Bu katman, karmaşık dönüşümleri küçük ve test edilebilir parçalara ayırmanın en etkili yoludur.

-- models/intermediate/int_customer_orders.sql
WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
    SELECT * FROM {{ ref('stg_customers') }}
)
SELECT
    c.customer_id,
    c.customer_name,
    COUNT(o.order_id) AS total_orders,
    SUM(o.order_amount) AS lifetime_value,
    MIN(o.order_date) AS first_order_date,
    MAX(o.order_date) AS last_order_date
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.customer_name

Marts katmanı, nihai tüketim katmanıdır. Temiz, dokümante edilmiş tablolar olarak panolar ve analistler tarafından doğrudan sorgulanır. Bu tablolar, iş birimlerinin ihtiyaçlarına göre organize edilir: finans, pazarlama veya operasyon gibi alan bazlı dizinler altında gruplandırılır.

Bu katmanlı yaklaşım, bozuk bir kaynağın yalnızca staging katmanını etkilemesini sağlar; tüm pipeline bundan etkilenmez. Her katman bağımsız olarak test edilebilir ve hata izolasyonu doğrudan mümkün hale gelir.

ref() Fonksiyonu ve DAG Çözümlemesi

ref() basit bir takma ad (alias) değildir. {{ ref('stg_orders') }} çağrısı iki iş yapar: derleme zamanında tam nitelikli tablo adını çözer ve dbt'nin yönlü döngüsüz grafiğinde (DAG) bir bağımlılık kenarı kaydeder. ref() olmadan dbt, modellerin çalışma sırasını belirleyemez ve pipeline'ın doğru bir şekilde yürütülmesi garanti edilemez.

Yaygın bir hata, ref() yerine tablo adlarını doğrudan kodlamaktır. Bu, bağımlılık takibini bozar ve modellerin, yukarı akış bağımlılıkları hazır olmadan çalışmaya başlamasına yol açabilir.

-- Bad: hardcoded reference, no dependency tracking
SELECT * FROM analytics.stg_orders

-- Good: ref() registers the dependency
SELECT * FROM {{ ref('stg_orders') }}

DAG aynı zamanda dbt run --select stg_orders+ gibi komutları da destekler. Bu komut, bir modeli ve onun alt akışındaki tüm modelleri çalıştırır; kaynak şema değişikliklerinden sonra hedefli yeniden yapılandırmalar için oldukça kullanışlıdır. Tersi yönde +stg_orders kullanımı ise bir modelin tüm yukarı akış bağımlılıklarını çalıştırır.

Materyalizasyonlar: Doğru Depolama Stratejisini Seçmek

dbt, farklı erişim kalıplarına ve veri hacimlerine uygun dört yerleşik materyalizasyon sunar. Doğru materyalizasyonu seçmek, performans ve maliyet arasındaki dengeyi doğrudan etkiler.

| Materyalizasyon | Depolama | En uygun kullanım | Ödünleşim | |----------------|---------|----------|----------| | view | Depolama yok (okuma sırasında hesaplanır) | Hafif dönüşümler, küçük veri setleri | Büyük verilerde yavaş okuma | | table | Her çalışmada tam tablo yeniden oluşturma | Mart katmanı modelleri, hızlı okumalar | Her şeyi yeniden oluşturur, daha yüksek maliyet | | incremental | Yalnızca yeni satırları ekler/birleştirir | Büyük fact tabloları, olay akışları | Daha karmaşık mantık, unique_key gerektirir | | ephemeral | CTE olarak satır içi eklenir, materyalize edilmez | Modeller arası paylaşılan yeniden kullanılabilir mantık | Doğrudan sorgulanamaz |

Varsayılan materyalizasyon view'dir. Model config bloğunda veya dbt_project.yml içerisinde geçersiz kılınabilir:

-- models/marts/fct_daily_revenue.sql
{{
    config(
        materialized='incremental',
        unique_key='revenue_date',
        incremental_strategy='merge'
    )
}}
SELECT
    DATE(order_date) AS revenue_date,
    SUM(order_amount) AS daily_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers
FROM {{ ref('stg_orders') }}
WHERE order_status = 'completed'
{% if is_incremental() %}
    AND order_date > (SELECT MAX(revenue_date) FROM {{ this }})
{% endif %}
GROUP BY DATE(order_date)

is_incremental() bloğu yalnızca artımlı derlemelerde çalışır. Tam yenileme işleminde (dbt run --full-refresh) bu blok atlanır ve tablonun tamamı sıfırdan yeniden oluşturulur. Üretim ortamında artımlı modellerin düzgün çalışıp çalışmadığını doğrulamak için target/compiled/ dizinindeki derlenmiş SQL kontrol edilmelidir.

Her Katmanda Veri Kalitesini Test Etmek

dbt, iki kategori test sunar: YAML içerisinde tanımlanan jenerik testler ve başarısız olduğunda satır döndüren bağımsız SQL dosyaları olarak yazılan tekil testler. Test, veri mühendisliğinde kalite güvencesinin temel taşıdır ve dbt bu süreci pipeline'ın ayrılmaz bir parçası haline getirir.

Jenerik testler yapısal kısıtlamaları kapsar:

# models/staging/_stg_models.yml
version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: order_status
        tests:
          - accepted_values:
              values: ['completed', 'pending', 'cancelled', 'refunded']
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id

Tekil testler, jenerik testlerin ifade edemediği iş kurallarını doğrular. Aşağıdaki test, günlük gelirin negatif olamayacağını kontrol eder; herhangi bir satır döndüğünde test başarısız sayılır:

-- tests/assert_revenue_never_negative.sql
SELECT
    revenue_date,
    daily_revenue
FROM {{ ref('fct_daily_revenue') }}
WHERE daily_revenue < 0

dbt 1.8 ile tanıtılan birim testleri (unit tests), dönüşüm mantığını kontrol edilen girdiler ve beklenen çıktılarla doğrular; veri ambarı erişimi gerektirmez. Doğrudan dbt test aşamasında çalıştırılır ve özellikle karmaşık Jinja mantığı içeren modellerin doğrulanmasında kritik rol oynar.

Test stratejisi veri akışını takip etmelidir: kaynak düzeyinde tazelik kontrolleri ve satır sayısı doğrulamaları, staging düzeyinde şema testleri (not_null, unique), intermediate düzeyinde referans bütünlüğü ve mart düzeyinde iş mantığı iddiaları. Tüm testler CI sürecinde pull request üzerinde çalıştırılmalı ve üretim ortamında dağıtım sonrası uyarılarla desteklenmelidir.

dbt Core v1.10 ve Fusion Engine

dbt Core v1.10, run ve build komutları için --sample bayrağını tanıttı. Bu bayrak, ref() ve source() üzerinde zamana dayalı örnekleme uygulayarak geliştiricilerin, tam derleme maliyeti olmadan dönüşümleri bir veri alt kümesinde doğrulamasını sağlar. Milyarlarca satırlık fact tablolarıyla desteklenen modeller üzerinde iterasyon yaparken hem zaman hem de veri ambarı maliyetinden önemli tasarruf sağlar.

dbt Fusion engine, sıfırdan Rust ile yeniden yazılmış bir motor olup dbt Cloud'da Snowflake, BigQuery, Redshift ve Databricks için yeni projelerin varsayılan motoru haline geldi. Fusion, 2.0 ile başlayan semantik versiyonlama sunar ve derleme ile çalıştırma performansında ciddi iyileştirmeler getirir. Özellikle büyük projelerde derleme süreleri önceki Python tabanlı motora kıyasla belirgin şekilde kısalmıştır.

2026'daki diğer önemli yenilikler arasında merkezî metrik tanımları için Semantic Layer YAML spesifikasyonu, model başına veri ambarı hesaplama maliyetini tahmin eden Cost Insights (beta) ve artık genel kullanıma sunulan yerel özel paketler yer almaktadır.

Makrolar ve Jinja ile Yeniden Kullanılabilir Mantık

Aynı SQL kalıbının birden fazla modelde tekrarlanması durumunda, bu kalıp bir makroya çıkarılmalıdır. Makrolar, macros/ dizininde saklanan Jinja fonksiyonlarıdır ve dbt projelerinde kodun tekrar kullanılabilirliğini en üst düzeye çıkarır.

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ROUND(CAST({{ column_name }} AS DECIMAL(10, 4)) / 100, 2)
{% endmacro %}

Herhangi bir modelde şu şekilde çağrılır:

-- models/staging/stg_payments.sql
SELECT
    payment_id,
    order_id,
    {{ cents_to_dollars('amount_cents') }} AS amount_dollars,
    payment_method
FROM {{ source('stripe', 'payments') }}

Bu yaklaşım, kod tabanını DRY (Don't Repeat Yourself) prensibine uygun tutar. Alternatif olan dönüşüm formülünü ihtiyaç duyan her modele kopyalamak, bakım yükünü artırır ve modeller arasında tutarsızlıklara yol açar. Makrolar ayrıca parametrik olarak yapılandırılabilir, bu da farklı bağlamlarda aynı mantığın esnek bir şekilde uygulanmasını sağlar.

Mülakatlarda Gerçekten Sorulan Sorular

2026'da veri mühendisliği mülakatları, dbt bilgisini temel kavramların ötesinde test etmektedir. Aşağıdaki sorular, modern veri yığınlarını kullanan şirketlerdeki mülakat kalıplarından derlenmiş olup adayları birbirinden ayıran kritik sorulardır.

S: Artımlı bir model gece boyunca tablonun tamamını yeniden işledi. Ne olmuş olabilir?

En yaygın neden: unique_key sütununun NULL değerler içermesidir. dbt, NULL anahtar üzerinden MERGE işlemini denediğinde eşleme her satır için başarısız olur ve yinelenen satırlar eklenir. İkinci neden: birinin farkında olmadan dbt run --full-refresh çalıştırmış olmasıdır; bu komut tabloyu sıfırdan yeniden oluşturur. Üçüncü neden: is_incremental() filtresinin, hedef tabloda henüz mevcut olmayan bir sütuna referans vermesidir (ilk çalıştırma ile sonraki çalıştırmalar arasındaki fark). Hata ayıklama, target/compiled/ dizinindeki derlenmiş SQL'in incelenmesiyle başlar.

S: Üretim ortamında bir dbt projesinde testler nasıl katmanlandırılmalıdır?

Önce kaynak tazelik kontrolleri çalıştırılır; kaynak güncellenmemişse, alt akış modelleri eski veriler üzerinde çalıştırılmamalıdır. Staging testleri şema kısıtlamalarını doğrular: birincil anahtarlar (unique + not_null), kabul edilen değerler ve tip dönüşümleri. Intermediate testleri birleşimler arasında referans bütünlüğünü kontrol eder. Mart testleri iş değişmezlerini ileri sürer: gelir >= 0, aktif kullanıcılar >= ödeme yapan kullanıcılar ve parçaların toplamı bütüne eşit olmalıdır. Tüm testler CI'da pull request üzerinde geliştirme şemasına karşı çalışır, ardından üretimde dağıtım sonrası uyarılarla birlikte tekrar çalıştırılır.

S: Bir model ne zaman ephemeral, ne zaman view olmalıdır?

Ephemeral modeller, SQL'lerini tüketen modellere CTE olarak satır içi ekler; bağımsız olarak sorgulanması gerekmeyen yeniden kullanılabilir mantık için uygundur. View'lar okuma sırasında hesaplanır ve sorgulanabilir nesneler olarak var olur. Ödünleşim şudur: ephemeral modeller doğrudan test edilemez (üzerinde iddia çalıştırılacak bir tablo yoktur) ve veri soy ağacı araçlarında görünmez. Dahili yardımcı mantık için ephemeral; bağımsız test veya izleme gerektiren her şey için view kullanılmalıdır.

S: source() ve ref() arasındaki farkı açıklayın.

source(), bir sources.yml dosyasında tanımlanan ham tablolara işaret eder; bunlar dbt'nin yönetmediği tablolardır. ref() ise diğer dbt modellerine işaret eder. Her ikisi de DAG bağımlılıklarını kaydeder, ancak source() aynı zamanda tazelik kontrollerini (dbt source freshness) etkinleştirir; ref() bunu yapmaz. Ham tablolar için source(), geri kalan her şey için ref() kullanmak isteğe bağlı değildir — dbt'nin neyi kontrol ettiğini ve neyi etmediğini bilmesinin tek yolu budur.

Daha kapsamlı veri mühendisliği mülakat soruları için, ETL vs ELT pipeline mimarisi konuları dahil olmak üzere, SharpSkill'in dbt temelleri ve ileri düzey dbt kalıpları pratik modülleri bu kavramları interaktif alıştırmalarla kapsamaktadır.

Sonuç

• dbt, ham veri ambarı verilerini SQL SELECT ifadeleri aracılığıyla dönüştürür ve bunları otomatik olarak DDL'e derler; katmanlı staging/intermediate/mart yapısı her modeli tek bir sorumlulukla sınırlar
• ref() fonksiyonu bağımlılık yönetiminin bel kemiğidir: tablo adlarını çözer ve çalışma sırasını kontrol eden DAG'ı oluşturur
• Artımlı materyalizasyonlar büyük tablolarda maliyeti önemli ölçüde azaltır, ancak unique_key, NULL değerler ve is_incremental() filtresinin dikkatli yönetimini gerektirir
• Test stratejisi veri akışını izlemelidir: kaynak tazeliğinden başlayarak staging'de şema kısıtlamaları, intermediate'da referans bütünlüğü ve mart düzeyinde iş mantığı iddiaları
• dbt Core v1.10, daha hızlı iterasyon için --sample bayrağını sunarken, Fusion engine (Rust tabanlı, versiyon 2.0) dbt Cloud'da varsayılan motor haline geldi
• dbt mülakat soruları, tanımlardan ziyade gerçek hataların ayıklanmasına odaklanır (artımlı yeniden işleme, NULL anahtarlar, eski kaynaklar); derlenmiş SQL ve CI pipeline'larıyla uygulamalı deneyim, ezberden cevaplardan çok daha değerlidir