Data contract; veri setinin yapısını, kolon ve veri tiplerini, iş anlamını, kalite kurallarını, güncellik ve erişilebilirlik hedeflerini, sahipleri, kullanım koşullarını, sürümünü ve breaking change sürecini tanımlar. Şema testi veya SLA tek başına sözleşme değildir. Amaç değişikliği tamamen engellemek değil; üretici ve tüketicilerin etkisini önceden görmesini, otomatik kontrollerle doğrulamasını ve uyum için geçiş süresi yönetmesini sağlamaktır.
Data contract veri değişikliğini üretici ve tüketici arasında görünür kılar
Kaynak ekip bir kolonun adını, veri tipini veya anlamını değiştirdiğinde downstream pipeline, rapor, model ve AI uygulamaları sessizce bozulabilir. Data contract, veri ürününün beklenen biçimini ve hizmet düzeyini tanımlayarak değişikliği sürpriz olmaktan çıkarır. Sözleşme üreticinin her talebi kabul etmesi değil; taahhüt ettiği alanları, sınırları ve değişiklik sürecini açıklaştırmasıdır.
Ne sunuyor?
Şema, anlam, kalite, güncellik ve destek taahhüdü verir.
Neye dayanıyor?
Kullandığı alan, kalite eşiği ve değişiklik ihtiyacını bildirir.
Nasıl doğruluyor?
Lint, şema, kalite, lineage ve dağıtım kontrolleri çalıştırır.
Kim karar veriyor?
Sahip, sürüm, istisna ve emeklilik sürecini yönetir.
İyi sözleşme şema kadar anlam ve hizmet beklentisini de tanımlar
| Bölüm | Örnek içerik | Kontrol |
|---|---|---|
| Kimlik | Ad, sürüm, durum, alan ve sahip | Tekil ve bulunabilir kayıt |
| Şema | Tablo, kolon, veri tipi, null, anahtar | Makinece doğrulama |
| Semantik | Tanım, birim, grain, kod ve ilişki | İş anlamı onayı |
| Kalite | Tamlık, benzersizlik, geçerlilik, tutarlılık | Kural ve eşik testi |
| Hizmet | Güncellik, çalışma sıklığı, gecikme, destek | SLO ve olay yönetimi |
| Kullanım | Sınıflandırma, erişim, lisans, amaç | Politika ve yetki |
| Değişiklik | Sürüm, deprecation, bildirim, geçiş | Uyumluluk kapısı |
Open Data Contract Standard gibi açık standartlar; şema, kalite, sahiplik, sunucu, hizmet düzeyi ve kullanım koşullarının yapılandırılmış biçimde tanımlanmasını destekler. Kurum standardı olduğu gibi almak yerine kendi kritik alanlarını ve kontrol araçlarını eşlemelidir.
Şema, test ve SLA data contract’ın parçalarıdır; tamamı değildir
| Kavram | Ne doğrular? | Sınırı |
|---|---|---|
| Schema contract | Kolon, veri tipi ve bazı kısıtlar | İş anlamı ve kaliteyi tam kapsamaz |
| Data test | Belirli kuralın mevcut veride sonucu | Sahiplik ve değişiklik sürecini tanımlamaz |
| SLA/SLO | Zaman, erişilebilirlik ve destek hedefi | Şema ve semantik bağlamı vermez |
| Data contract | Ürün beklentilerinin ortak ve sürümlü bütünü | Uygulanmazsa yalnız doküman kalır |
dbt model contracts örneğinde, model çıktısının beklenen kolon ve veri tipine uymaması build’i durdurabilir. Bu güçlü bir şema enforcement kontrolüdür; tam kurumsal data contract için semantik, kalite, sahiplik ve hizmet düzeyi katmanları ayrıca gerekir.
Sözleşme tasarımdan emekliliğe kadar yaşam döngüsünde yönetilmelidir
- Veri ürününün iş amacı ve tüketicilerini tanımlayın.
- Mevcut kullanım ve lineage üzerinden kritik alanları çıkarın.
- Şema, semantik, kalite ve hizmet beklentilerini müzakere edin.
- Sözleşmeyi sürümlü ve makinece okunabilir depoda yayınlayın.
- CI/CD içinde lint, şema ve kalite kontrolleri çalıştırın.
- Canlıda güncellik, kalite ve sözleşme ihlallerini izleyin.
- Değişiklik etkisini lineage ve tüketici kaydıyla değerlendirin.
- Deprecation süresi ve geçiş desteği sağlayın.
- Kullanılmayan sürümü kontrollü biçimde emekliye ayırın.
Breaking change yalnız kolon silmek değildir
- Kolon adı, veri tipi veya null davranışının değişmesi
- Primary key veya grain’in değişmesi
- Enum değerinin anlam veya kapsam değiştirmesi
- Zaman alanı ve zaman bölgesi kuralının değişmesi
- Hesaplama veya filtre mantığının değişmesi
- Güncellik ve çalışma sıklığının düşmesi
- Hassasiyet ve erişim sınıfının değişmesi
- Kaynak sistem veya survivorship kuralının değişmesi
Uyumlu ekleme ile kırıcı değişiklik ayrımı kurum standardında açıkça tanımlanmalıdır. Yeni sürüm paralel yayınlanabilir; tüketici kullanımı ölçülerek eski sürüm için son tarih belirlenebilir.
| Değişiklik | Olası sınıf | Gerekli eylem |
|---|---|---|
| Opsiyonel yeni kolon | Geriye uyumlu | Bildirim ve test |
| Kolon silme | Breaking | Yeni sürüm ve geçiş |
| String → integer | Breaking | Uyumluluk testi ve dönüşüm |
| Tanım değişikliği | Semantik breaking | Yeni metrik/veri sürümü |
| Gecikme artışı | Hizmet ihlali | Tüketici etkisi ve onay |
Enforcement geliştirici akışına ve platform kontrollerine gömülmelidir
Sözleşme repository’de değiştiğinde otomatik lint, standarda uygunluk, şema farkı, kalite kuralı ve breaking change analizi çalıştırılabilir. Pipeline, onaysız kritik değişikliği durdurabilir. Canlı sistemde sözleşme ihlali olay üretmeli; yalnız dashboard’da kırmızı kutu olarak kalmamalıdır.
- Pull request içinde sözleşme farkı
- Şema registry veya model contract doğrulaması
- Örnek ve üretim benzeri veri kalite testleri
- Lineage üzerinden tüketici etki analizi
- Sahip ve tüketici onay iş akışı
- Sürüm ve changelog üretimi
- Canlı SLO ve kalite ihlali alarmı
- İstisna için süre ve risk sahibi
Senaryo: Sipariş verisinde status alanı değiştiriliyor
Üretici ekip cancelled ve refunded değerlerini tek closed statüsünde birleştirmek ister. Şema değişmemektedir; fakat semantik breaking change vardır. Finans iade, operasyon iptal, müşteri ekibi kapanış davranışını farklı kullanır. Data contract fark analizi tüketicileri gösterir. Yeni status_v2 alanı eklenir, eşleme tablosu yayımlanır, iki sürüm paralel çalışır ve eski alan tüketim sıfıra düştüğünde emekliye ayrılır.
Yanlış data contract programı yeni bürokrasi üretebilir
- Her geçici tablo için ağır sözleşme zorunluluğu koymak
- Tüketici olmadan üreticinin tek taraflı sözleşme yazması
- Binlerce alanı elle dokümante edip güncel tutamamak
- Sözleşmeyi test ve pipeline’a bağlamamak
- Semantik değişiklikleri yalnız şema farkıyla değerlendirmek
- Breaking change’i sonsuza kadar yasaklamak
- Lineage ve gerçek tüketici kullanımını izlememek
- Sahip, destek ve olay sürecini tanımlamamak
Öncelik, kurumsal rapor, müşteri süreci, regülasyon ve AI sistemi için kritik veri ürünlerine verilmelidir. Sözleşme kapsamı risk ve tüketici etkisiyle orantılı olmalıdır.
Üretici sahipliği ile tüketici etkisi ortak karar modelinde buluşmalıdır
Data product owner sözleşme ve hizmetten; mühendislik ekibi teknik uygulamadan; veri steward semantik ve kalite tanımından; tüketici sahibi kritik kullanım ve kabul testinden; platform ekibi enforcement altyapısından; yönetişim ekibi standart, istisna ve portföy görünürlüğünden sorumludur.
| KPI | Sağlıklı gösterge | Yanlış teşvik |
|---|---|---|
| Sözleşme kapsamı | Kritik veri ürünleri oranı | Toplam sözleşme sayısı |
| İhlal | Tüketiciyi etkileyen ihlal ve çözüm süresi | Alarm sayısını sıfırlamak |
| Değişiklik | Önceden bildirilen breaking change oranı | Hiç değişiklik yapmamak |
| Uyum | Geçiş süresinde taşınan tüketici oranı | Eski sürümü sınırsız açık tutmak |
| Kalite | Sözleşme eşiği ve gerçek iş sonucu | Yalnız test geçiş yüzdesi |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01Open Data Contract Standard — Specification v3.1.0
Şema, kalite, sahiplik, sunucu, hizmet düzeyi ve kullanım koşullarını tanımlayan açık sözleşme standardını açıklar.
- 02Bitol — Open Data Contract Standard
ODCS’nin Linux Foundation AI & Data altında açık ve vendor-neutral standart olarak yönetişimini açıklar.
- 03dbt Developer Hub — Model Contracts
Model çıktısının kolon, veri tipi ve kısıtlarla build aşamasında doğrulanmasını açıklar.
- 04dbt Developer Hub — Model Versions
Breaking change için sürümleme ve tüketici geçiş yolunu açıklar.
- 05Data Contract CLI — Open Data Contract Standard
ODCS sözleşmelerinin lint, test ve makinece uygulanabilir biçimde kullanılmasını açıklar.