Veri Yönetimi

Data Contract'lar: Pipeline Güvenilirliğini SLA'ya Bağlamak

Producer ve consumer arasındaki sözsüz beklentiyi yazılı bir kontrata dönüştüren data contract'lar; veri ambarındaki sürpriz kırılmaları neredeyse sıfıra indirir.

BIART Ekibi3 dk okuma1 görüntüleme
Data contract şeması ve veri pipeline diyagramı

Veri ambarınız bugün öğleden sonra 'Customer' tablosundaki birinci-isim alanı NULL gelmeye başladığında ne olur? Marketing kampanyası 12.000 kişiye 'Sayın ' diye başlayan e-mail atar. Bu kırılmaların çoğu producer-consumer arasında sözsüz bir beklentinin sessizce ihlal edilmesinden gelir. Data contract'lar o sessiz beklentiyi yazılı hale getirir.

Data contract nedir?

Üretici sistem (örn. CRM) ile tüketici sistem (DWH, ML modeli, dashboard) arasında veri için imzalanmış bir SLA'dır. Şema, freshness, kalite eşikleri, semantik anlam, sahiplik, change yönetimi tek bir YAML / JSON belgede yer alır.

Örnek (kısaltılmış):

yaml contract: customer.v3 owner: crm-team schema: customer_id: string, not_null, unique first_name: string, not_null, max_len=100 email: string, format=email, nullable=true freshness: max_lag=15m quality: uniqueness_customer_id: 100% null_rate_first_name: <1% breaking_change_policy: 30d_notice

Sözsüz beklenti nasıl kırılır?

Gerçek senaryolardan örnekler:

  • CRM ekibi 'first_name' alanına 'middle_name' birleştirme projesi yapar; uzunluk 100'den 200'e çıkar; DWH ETL hata vermez ama BI'da text wrapping bozulur.
  • Lookup tablosundaki 'status' kodu yıllarca 1-5 arası iken bir update'te 6 eklenir; ML model 6'yı görmediği için segmenti yanlış sınıflandırır.
  • Üretim sırasında bir hotfix 'order_id'yi int'ten string'e çevirir; downstream ödeme mutabakatı sessizce yanlış kayar.

Her biri saatler süren incident'a dönüşür. Data contract bu kırılmaları deploy zamanında yakalar.

Contract'ın 5 bileşeni

  1. Şema garanti: alan adları, tipleri, zorunluluk, format. CDC pipeline schema-registry üstünde dolaşır.
  2. Freshness: en geç ne kadar eski veri kabul edilir.
  3. Kalite eşikleri: uniqueness, null oranı, value-range, regex match.
  4. Semantik tanım: 'first_name' nedir? Hangi sistem otoritedir? Veri sözlüğüne link.
  5. Change policy: breaking change için bildirim süresi (tipik 30 gün), versiyon stratejisi.

Production'da nasıl uygulanır?

Kontrat statik dosya olarak repo'da durur. Üç çalıştırma noktası:

  • CI gate: producer kod değişikliği contract ile çakışıyorsa PR bloklanır.
  • Pipeline test: her ETL run sonunda Soda Core / dbt-test / custom asserts contract metriklerini ölçer; ihlalde alarm.
  • Catalog UI: tüm aktif contract'lar veri kataloğundaki tablo üstünde görünür; consumer 'bu tabloya güvenebilir miyim' sorusuna evet/hayır cevabı görür.

SLA'ya bağlanması

Contract ihlali otomatik olarak incident'a dönüşür ve producer ekibinin SLA'sına yazılır. Bu noktadan sonra contract kâğıt üzerinde değildir; producer'ın aylık raporunda eksi puandır. Bu basit yaptırım kontratları aktif tutmanın tek garantisidir.

Versiyon yönetimi

Contract'lar customer.v1, customer.v2 olarak versiyonlanır. Breaking change v3'te kararlaştırıldıysa:

  • v2 ve v3 paralel yayınlanır 60 gün.
  • Consumer'lar v3'e taşınır, telemetri ile takip edilir.
  • v2 bütün consumer'lar geçince retire edilir.

Bu schema-registry tabanlı stream platformlarında (Kafka + Avro / Protobuf) doğal bir patern; batch dünyasında dbt models + manuel disiplinle aynı sonuç alınabilir.

CentraQL ve data contract

CentraQL'ın DataQuality modülü contract dosyasını okur, kuralları otomatik üretir, Trust Score hesabına ağırlıklı olarak ekler. Bir tablonun Trust Score'u kontratının sağlığı oranında düşer/yükselir; CFO dashboard'unda 'Customer tablosu Trust 87 — son 7 gün contract.v3 freshness 2 ihlal' satırı görünür.

Nereden başlamalı?

Tipik 3 aylık plan:

  1. Hafta 1-2: en kritik 5 tablonun consumer'ları toplanır; mevcut sözsüz beklenti listesi çıkarılır.
  2. Hafta 3-6: ilk 5 contract yazılır, producer ve consumer imzalar.
  3. Hafta 7-10: CI gate + Soda Core entegrasyonu, ilk ihlal alarmları.
  4. Hafta 11-12: aylık review forumu, ilk 5'ten genişleme planı.

12 hafta sonra kurum 'sürpriz' kırılma sayısının ~%80 düştüğünü, kalan %20'nin ise yakalanma süresinin saatlerden dakikalara indiğini görür.

Sonuç

Data contract sihir değil; producer ve consumer arasındaki sözsüz anlaşmayı yazılı, ölçülebilir, denetlenebilir hale getirir. Pipeline güvenilirliği bu kontratın aktif uygulanmasıyla artar; veri kalitesi konusunda 'iyi mi kötü mü' tartışmasından 'contract.v3 freshness ihlal: 2 / 7 gün' tartışmasına geçilir. Trust Score, MDM ve veri yönetişimi çerçevesi bu kontrata dayandığında bir bütündür.

Paylaş