Veri Kalitesini Sağlamak İçin dbt Testlerine Kapsamlı Bir Rehber

dbt, veri dönüşümü ve test işlevleri sayesinde analitik alanında giderek daha popüler hale geliyor. Bu yazıda, dbt’nin ne olduğunu ve veri kalitesini sağlamak için bazı dbt testlerini nasıl uygulayabileceğinizi paylaşacağız. dbt’ye yeni başlıyorsanız, daha fazla bilgi edinmek için mutlaka dbt’ye Giriş kursumuza göz atın. 

dbt Nedir?

Ayrı rehberimizde ele aldığımız üzere, dbt (data build tool), veri ekiplerinin ambarlarındaki ham verileri temiz, test edilmiş, belgelenmiş ve analize hazır veri kümelerine dönüştürmek için kullandığı popüler bir açık kaynak aracıdır. 

ETL araçlarından farklı olarak dbt, veri hattının yalnızca "T" (Transform) bileşenine odaklanır ve BigQuery, Snowflake, Redshift ve Databricks gibi modern bulut veri ambarlarının üzerinde çalışır.

dbt’nin en güçlü özelliklerinden biri, veriye ilişkin varsayımları doğrulayan testler yazmaya olanak tanıyan yerleşik veri test çerçevesidir. Bu test çerçevesi yalnızca sorunları erken yakalamaya yardımcı olmakla kalmaz, büyüyen, modüler bir analitik kod tabanında veri kalitesini ve güvenini sürdürmek için de kritik öneme sahiptir.

Neden dbt’de Test Yapmalısınız?

Test, analitik mühendisliğinin temel bir parçasıdır. Veri kümeleri büyüdükçe ve daha fazla paydaş veriye bağımlı hale geldikçe, fark edilmeyen veri sorunlarının maliyeti artar. dbt’nin test yetenekleri şunları yapmanıza yardımcı olur:

• Veri sorunlarını erken tespit edin: Aşağı akıştaki panolar ve raporlar etkilenmeden önce.
• Kalite kontrollerini otomatikleştirin: Manuel doğrulama işinden kaçının.
• İyi veri modelleme uygulamalarını teşvik edin: Modüler ve test edilebilir dönüşümleri destekleyin.
• CI/CD uygulamalarını destekleyin: Otomatik iş akışlarına sorunsuz entegre edin.
• Veri sözleşmelerini uygulayın: Temel kısıtların (örn. yinelenen kayıtların olmaması) zaman içinde geçerli kaldığını doğrulayın.

dbt Test Türleri

dbt’de testler, veri varsayımlarını doğrulayan SQL tabanlı iddialardır. dbt’deki testler iki ana kategoriye ayrılır:

1. Genel (yerleşik) testler

Bu testler dbt tarafından önceden tanımlanmıştır ve YAML dosyalarında deklaratif olarak uygulanır. Genel testler genellikle veri modelleme ve veri ambarlamada bulunan yaygın kısıtları kapsar. 

Özellikleri şunlardır:

• Yapılandırması kolay
• Sütunlar ve modeller arasında yeniden kullanılabilir
• Basit kontroller için yüksek performanslı

Dört yerleşik genel test türü şunlardır:

• not_null: Bir sütunda NULL değer bulunmadığını garantiler.
• unique: Bir sütundaki değerlerin satırlar arasında benzersiz olmasını sağlar (genellikle birincil anahtarlar için kullanılır).
• accepted_values: Bir sütunu önceden tanımlı izin verilen değerler kümesiyle sınırlar.
• relationships: Tablolar arasında başvuru bütünlüğünü doğrular ve yabancı anahtarların başka bir tablodaki değerlere karşılık geldiğinden emin olur.

Bu testler, özellikle anahtarlar, kategorik alanlar ve temel tablo ilişkileri etrafında temel veri bütünlüğünü sağlamak için idealdir.

Genel testler, arka planda otomatik olarak SQL üreterek çalışır. 

Örneğin, customer_id sütunundaki bir not_null testi, şuna benzer bir SQL üretir:

SELECT *
FROM {{ ref('customers') }}
WHERE customer_id IS NULL

Bu sorgu herhangi bir satır döndürürse test başarısız olur.

2. Özel (tekil) testler

Özel veya tekil testler, tests/ dizininde .sql dosyaları olarak kaydedilen, kullanıcı tarafından tanımlanmış SQL sorgularıdır. Şunlar için kullanılırlar:

• Genel testlerin ifade edemediği karmaşık doğrulamalar
• İş kuralı uygulamaları
• Modeller arası mantık
• İstatistiksel veya koşullu eşikler

Tekil testler maksimum esneklik sunar. SQL sorgunuz beklentileri ihlal eden satırları döndürdüğü sürece veriyi neredeyse her şekilde doğrulayabilirsiniz.

Örneğin:

• Bir ürünün lansman tarihinin emeklilik tarihinden sonra olmamasını sağlamak
• Olağandışı yüksek veya düşük değerleri tespit etmek (aykırı değer saptama)
• Toplulaştırılmış değerlerin iş toplamlarıyla uyumlu olduğunu doğrulamak

Esneklikleri sayesinde özel testler, üretimde incelikli veri kalitesi sözleşmelerini uygulamak isteyen analitik ekipleri için idealdir.

dbt ile birlikte gelen makrolar da test için kullanılabilir; örneğin dbt-utils paketi.

Özetle:

Her iki türü birleştirmek size iki dünyanın en iyisini sunar: genel testlerden tutarlılık ve kapsama alanı, özel testlerden ise hassasiyet. Şimdi her türü daha ayrıntılı inceleyelim. 

1. Genel (Yerleşik) Testler

Genel testler dbt tarafından önceden tanımlanmıştır ve modelinizin schema.yml dosyasına eklenerek deklaratif şekilde kullanılır. 

Bu testler tipik olarak benzersizlik, null olmama, başvuru bütünlüğü veya tanımlı bir kümedeki değerlere ilişkin kısıtları doğrular.

dbt’de genel testleri denemek için basit bir eğitim inceleyelim.

Genel bir test nasıl beyan edilir

Modelinizin ilgili schema.yml dosyasında, testleri columns: bölümünde tanımlayın:

version: 2

models:
  - name: customers
    description: "Customer dimension table"
    columns:
      - name: customer_id
        description: "Unique customer identifier"
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null

Örnek: not_null ve unique

yaml
columns:
  - name: customer_id
    tests:
      - not_null
      - unique

Yukarıdaki test, customer_id’nin her satırda mevcut ve benzersiz olmasını sağlar. Bu, genellikle tablonun birincil anahtarının customer_id olduğu varsayımını zorlamak için kullanılır.

Örnek: accepted_values

columns:
  - name: customer_type
    tests:
      - accepted_values:
          values: ['new', 'returning', 'vip']

Bu, customer_type alanının yalnızca üç izin verilen dizeden birini içermesini kontrol eder: new, returning veya vip. Bu test genellikle enum’lar veya durumlar gibi bilinen bir değer kümesine uyması gereken kategorik alanlar için kullanılır.

Örnek: relationships

columns:
  - name: customer_id
    tests:
      - relationships:
          to: ref('customers')
          field: id

Bu, geçerli modeldeki her customer_id’nin customers tablosundaki bir id olarak mevcut olduğunu doğrulayarak bir başvuru bütünlüğü kısıtını uygular. SQL’deki bir yabancı anahtar kısıtını analitik katmanda taklit eder.

2. Özel (Tekil) Testler

Yerleşik testler kullanım senaryonuz için yetersiz kaldığında, örneğin karmaşık iş mantığını doğrulamak istediğinizde, SQL kullanarak özel testler yazabilirsiniz. Bunlara tekil testler denir.

Özel bir test nasıl oluşturulur

1. dbt projenizde tests/ dizini içinde bir .sql dosyası oluşturun.

2. Testi başarısız kılan satırları döndüren bir SQL sorgusu yazın.

Örnek: orders tablosunda gelecekteki tarih olmaması

tests klasöründe no_future_dates.sql adlı bir dosya oluşturun.

SELECT *
FROM {{ ref('orders') }}
WHERE order_date > current_date

Bu test, orders tablosundaki herhangi bir kaydın gelecekte bir order_date değeri olup olmadığını kontrol eder. Satırlar dönerse test başarısız olur ve bunu saat dilimi hataları, ETL bug’ları veya hatalı kaynak sistem girişlerinden kaynaklanabilecek geçersiz veriler için uyarı olarak görürsünüz.

Örnek: Bölge başına yinelenen e-postalar

-- Dosya: tests/duplicate_emails_per_region.sql

SELECT email, region, COUNT(*) as occurrences
FROM {{ ref('customers') }}
GROUP BY email, region
HAVING COUNT(*) > 1

Bu test, her e-postanın belirli bir bölge içinde benzersiz olmasını sağlar. Bu, aynı kişinin aynı bölgede iki kez kayıt olamayacağına dair bir iş kuralını yansıtabilir. Döndürülen her satır, bir veri kalitesi ihlalini gösterir.

dbt’de Testler Nasıl Uygulanır

Bu bölüm, projenizde ve dağıtım hatlarınızda dbt testlerini uygulama, yapılandırma ve çalıştırma adımlarını pratik olarak ele alır.

Adım 1: dbt’nin kurulumu

Test veya model yazmaya başlamadan önce, dbt’nin kurulu ve yeni bir projenin başlatılmış olması gerekir.

Adım adım talimatlar:

1. Proje klasörü oluşturun:

Seçtiğiniz bir konumda bir klasör oluşturun.

2. Proje klasörüne gidin:

cd dbt-test-project

3. Sanal Python ortamı oluşturun:

python3 -m venv dbt-env

Oluşturulduktan sonra ortamı etkinleştirin.

dbt-venv\Scripts\activate

4. dbt’yi kurun

pip dbt install

5. .dbt klasörü oluşturun

mkdir $home\.dbt

6. dbt’yi başlatın

dbt init

7. profiles.yml dosyası oluşturun

.dbt klasörünüzde aşağıdaki içerikle yeni bir dosya oluşturun:

austi:
  target: dev
  outputs:
    dev:
      type: sqlite
      threads: 1
      database: ./dbt_project.db
      schema: main
      schema_directory: ./schemas
      schemas_and_paths:
        main: ./dbt_project.db

Windows bilgisayarınızdaki kullanıcı profilinizin adıyla “austi”yi değiştirebilirsiniz.

8. dbt_project.yml dosyasını oluşturun

Ardından, .dbt klasöründe aşağıdaki içerikle bir başka yapılandırma dosyası oluşturmanız gerekir.

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Yine “austi”yi kullanıcı profil adınızla değiştirin.

9. Projenin çalıştığını doğrulayın:

dbt debug

Kurulum tamamlandığında, veri kümeleri oluşturmaya ve dbt modelleri inşa etmeye hazırsınız.

Adım 2: Veri kümesini oluşturma

Bir veri ambarına erişiminiz olmadan çalışıyorsanız, CSV dosyaları ve dbt’nin seed işlevini kullanarak dbt testlerini yerelde simüle edebilirsiniz.

Adım adım talimatlar:

1. CSV dosyaları oluşturun: Bunları dbt projenizde yeni bir /seeds klasörü içine yerleştirin.

Adlandırma şöyle olmalı:

seeds/customers.csv

customer_id,name,email,customer_type
1,Alice Smith,alice@example.com,new
2,Bob Jones,bob@example.com,returning
3,Carol Lee,carol@example.com,vip
4,David Wu,david@example.com,new

2. Aynı dizinde başka bir dosya oluşturun:

Şu adlandırmayı kullanın:

seeds/orders.csv

order_id,customer_id,order_date,order_total,order_status
1001,1,2023-12-01,150.00,shipped
1002,2,2023-12-03,200.00,delivered
1003,1,2023-12-05,175.00,cancelled
1004,3,2024-01-01,225.00,pending

3. Seed’leri tanımlamak için bir yapılandırma dosyası oluşturun:

Ardından, dbt_project.yml adlı bir yapılandırma dosyası oluşturmanız gerekir.

Aşağıdaki içerikleri yapılandırma dosyasına yapıştırın. 

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

profile alanını, Windows bilgisayarınızdaki kullanıcı profilinizin adıyla eşleşecek şekilde değiştirin.

4. Seed verilerini yükleyin:

dbt seed

Bu komut, CSV dosyalarından main.customers ve main.orders tablolarını oluşturur. Bunlar, bir veritabanının yerini almak için gereken seed’lerdir.

Yukarıdaki görselde de görüldüğü gibi iki seed bulundu ve yüklendi.

Adım 3: dbt’ye alma

Şimdi, ham verinizi dönüştürmek ve test etmek için hazırlık (staging) modelleri oluşturacağız.

Adım adım talimatlar:

1. Staging modellerini oluşturun:

Proje klasörünüzde models adlı yeni bir klasör oluşturun. Bu klasörde stg_customers.sql adlı bir dosya oluşturun.

Aşağıdaki kodu dosyaya yapıştırın:

SELECT
  *
FROM {{ ref('customers') }}

stg_orders.sql adlı diğer bir dosyada aşağıdaki kodu yapıştırın:

SELECT
  *
FROM {{ ref('orders') }}

2. Şema testlerini tanımlayın:

Aşağıdaki konumda yeni bir dosya oluşturun:

models/schema.yml

Aşağıdakileri dosyaya yapıştırın

version: 2

models:
  - name: stg_customers
    description: "Customer staging table"
    columns:
      - name: customer_id
        description: "Unique identifier for each customer"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: email
        description: "Email address of the customer"
        tests:
          - not_null

  - name: stg_orders
    description: "Orders staging table"
    columns:
      - name: order_id
        description: "Unique identifier for each order"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: customer_id
        description: "Foreign key to stg_customers"
        tests:
          - not_null:
              tags: [critical]

3. Staging modellerini oluşturmak için dbt’yi çalıştırın:

dbt run --select stg_customers stg_orders

Bu staging modelleri artık yerelde tohumladığınız veriler kullanılarak dbt testlerini uygulamak için temel görevi görür.

Örnek bir çıktı şöyle olabilir:

Adım 4: İlk testinizi oluşturma

Veriniz staging’e alındığına göre, yerleşik genel test çerçevesini kullanarak ilk dbt testinizi uygulayalım.

Adım adım talimatlar:

1. Staging modelinizin tanımlı olduğu schema.yml dosyasını açın.

2. Modelinizin columns: bölümünde not_null veya unique gibi bir test tanımlayın.

Örnek:

models:

  - name: stg_customers

    columns:

      - name: customer_id

        tests:

          - not_null

          - unique

3. Testi CLI üzerinden çalıştırın:

dbt test --select stg_customers

Beklenen sonuç şöyle olacaktır:

Adım 5: Özel ve tekil testler geliştirme

İhtiyaçlarınız yerleşik testlerin ötesine geçtiğinde, SQL kullanarak özel testler oluşturabilirsiniz.

Adım adım talimatlar:

1. tests/ klasöründe yeni bir dosya oluşturun, örneğin: tests/no_future_orders.sql

2. Başarısız satırları döndüren SQL mantığını ekleyin:

SELECT *
FROM {{ ref('stg_orders') }}
WHERE order_date > current_date

3. Testi çalıştırın:

dbt test --select no_future_orders

Herhangi bir siparişte geleceğe ait order_date değerleri varsa bu test başarısız olur.

Beklenen sonuç şöyledir:

Adım 6: Testleri CI/CD hatlarında çalıştırma

Tutarlı test yürütmeyi sağlamak için dbt testlerini geliştirme hattınıza entegre edin.

Adım adım talimatlar:

1. Testlere öncelik vermek veya testleri yalıtmak için etiketleri kullanın:

Herhangi bir model şemasını aşağıdaki biçimde etiketleri içerecek şekilde değiştirebilirsiniz:

columns:
  - name: customer_id
    tests:
      - not_null:
          tags: [critical]

2. Seçici testleri yerelde çalıştırın:

dbt test --select tag:critical

Testler doğru şekilde çalışırsa şu çıktıyı bekleyebilirsiniz:

3. CI iş akışınızı dbt testlerini otomatik olarak çalıştıracak şekilde yapılandırın. Bunu GitHub Actions gibi bir CI platformuna bağlayabilirsiniz. 

dbt Testleri için En İyi Uygulamalar

dbt testlerini etkili bir şekilde uygulamak yalnızca onları yazmakla ilgili değildir; test etmeyi ekibinizin geliştirme yaşam döngüsüne ve kültürüne entegre etmekle ilgilidir. İşte size yol gösterecek bazı en iyi uygulamalar:

1. Birincil anahtarlarla başlayın

Boyut ve olgu tablolarındaki birincil anahtar sütunlarına her zaman not_null ve unique testlerini uygulayın. Bu iki kısıt, aşağı akış sorgularında güvenilir birleştirmelerin ve tekilleştirme mantığının temelidir.

2. Yabancı anahtarları relationships ile doğrulayın

Yabancı anahtarlar, başvuru bütünlüğünü korumak için kritiktir. Özellikle yerel olarak uygulamayan veri ambarlarında, relationships testini kullanarak yabancı anahtar kısıtlarını taklit edin.

3. Kategorik sütunlar için accepted_values kullanın

status, region veya product_type gibi sütunlarda belirli değerleri zorunlu kılarak boyutsal tutarlılığı kontrol edin. Bu, yazım hataları veya ele alınmamış enum genişletmelerinin riskini azaltır.

4. İş mantığı için özel testler yazın

İş mantığı her zaman genel kurallarla net biçimde örtüşmeyebilir. Özel test yazmanız gereken mantık örnekleri şunlardır:

• Satışlar negatif olmamalıdır
• Sipariş tarihleri gelecekte olamaz
• Bir kullanıcının birden fazla aktif aboneliği olamaz

5. Testleri net şekilde organize edin

Çok sayıda testiniz varsa işler hızla karmaşıklaşabilir. Düzenli tutmak için şu en iyi uygulamaları dikkate alın:

• Özel testleri tests/ klasörüne yerleştirin ve açıklayıcı biçimde adlandırın.
• Aşırı karmaşık SQL’den kaçının—mantığı odaklı ve okunabilir tutun.
• Mümkünse testleri modele veya alana göre gruplayın.

6. Hızlı başarısız olun ve CI/CD ile entegre edin

CI hattınızın bir parçası olarak dbt test çalıştırın. Bu, veri kalitesi kısıtları geçmeden kodun birleştirilememesini sağlar. Testleri CI/CD’ye entegre etmek veri hattında hesap verebilirliği ve güveni pekiştirir.

7. Aşırı testten kaçının

Aşırı veya gereksiz testler (özellikle büyük veri hacimlerinde) dağıtımları yavaşlatabilir. Şu testlere odaklanın:

• İş açısından kritik
• Yukarı akış sorunları nedeniyle bozulma olasılığı yüksek
• Bozulduğunda hata ayıklamaya yardımcı

Sözleşmesel bir SLA’nın parçası olmadıkça hesaplanan alanları test etmekten kaçının.

İleri Düzey Örnek: Aykırı Değer Saptama

İleri düzey bir test örneği için aykırı değer saptama testi gerçekleştirebiliriz.

tests klasörünüzde aşağıdaki kodla bir SQL dosyası oluşturun:

SELECT *
FROM {{ ref('orders') }}
WHERE order_total > 100000

Bu, temel bir aykırı değer saptama testidir. İşiniz tipik olarak 10.000 $’ın altındaki siparişleri görüyorsa, 100.000 $’ın üzerindeki siparişleri manuel inceleme için işaretleyebilirsiniz. Bu, katı bir veri kalitesi ihlali olmasa da sahtekarlık tespiti veya operasyonel izleme için değerli olabilir.

Performansla İlgili Hususlar

dbt projeniz ölçeklendikçe ve test kapsamı arttıkça performans giderek daha önemli hale gelir. Bu bölüm, test verimliliğini korumak ve hesaplama maliyetlerini kontrol etmek için teknikleri ve stratejileri açıklar.

Test optimizasyon teknikleri

Testlerde performansı optimize etmek için şu teknikleri deneyin:

• Artımlı test: dbt’nin artımlı model yapısını kullanarak testleri yalnızca yeni eklenen veya değiştirilen veriye odaklayın. Bu, tam veri kümeleri üzerinde gereksiz taramaları azaltır.
• Sorgu paralelleştirme: dbt_project.yml içindeki threads: parametresini yapılandırarak dbt’nin yerleşik paralel yürütmesini kullanın ve birden çok testi eşzamanlı çalıştırın.
• Seçici test yürütme: Özellikle geliştirme sırasında yalnızca ilgili testleri çalıştırmak için --select ve --exclude gibi bayrakları kullanın. Örneğin:

dbt test --select customers
dbt test --exclude tag:slow

Maliyet yönetimi stratejileri

Maliyet yönetimi stratejilerinin uygulanması, özellikle hesaplama faturalandırmasının sorgu karmaşıklığı ve sıklığına bağlı olduğu ortamlarda, dbt testlerinin performanslı ve maliyet açısından verimli kalmasını sağlar.

Bazı stratejiler şunlardır:

• Etiket tabanlı test yürütme: Kaynak yoğun veya isteğe bağlı testlere etiket atayın; böylece açıkça gerekmedikçe standart çalıştırmalardan hariç tutulabilirler.
• Sonuç önbellekleme: Mümkün olduğunda yinelenen hesaplamalardan kaçınmak için ambarınıza özgü özellikleri (ör. BigQuery veya Snowflake’te sonuç önbellekleme) kullanın. Daha önce yürütülen sorguların önbelleğe alınmış sonuçlarından yararlanacak şekilde testleri düzenleyin.
• Zamanlanmış test gruplama: Daha ağır test paketlerini, ambar iş yükleri üzerindeki etkiyi en aza indirmek için yoğun olmayan saatlerde veya üretim pencereleri dışında zamanlayın.

Sonuç

dbt testleri, yüksek veri kalitesini sağlamak, doğrulama kontrollerini otomatikleştirmek ve dönüşüm hattınızda sorunları erken yakalamak için güçlü bir yoldur. Sağlam ve bakımı kolay veri iş akışları oluşturmak için genel ve özel testler birlikte kullanılabilir.

dbt hakkında daha fazla bilgiyi dbt’ye Giriş kursumuzda veya dbt öğreticimizde bulabilirsiniz.