Veri kalitesi yönetimi, 2026 itibarıyla data ekiplerinin omurgasına dönüşen, “ML modelleri üretime alınmadan iptal olmasın” diyen herkesin günlük operasyonel kaygısı haline geldi. Gartner’ın Ocak 2026 Data Quality Maturity raporuna göre kötü veri kalitesinin ortalama bir kurumsal şirkete yıllık maliyeti 12,9 milyon dolara çıktı; Monte Carlo’nun State of Data Quality 2026 anketi data ekiplerinin haftada ortalama 39 saat boyunca veri olayı (data incident) ile uğraştığını ortaya koydu. IDC’nin Şubat 2026 raporu ise üretime alınan ML modellerinin %42’sinin ilk altı ayda iptal edilmesinin tek sebebinin upstream veri kalitesi olduğunu belgeledi. Bu rehber, sektörde en çok benimsenen üç aracı (Great Expectations, Soda Core, Monte Carlo) ve onları çevreleyen dbt tests, Anomalo gibi tamamlayıcı çözümleri mimari, kapsam, maliyet, SLO ve veri kontratı eksenlerinde 2026 perspektifiyle karşılaştırır.
2026’nın asıl hikayesi tek bir aracın “kazanması” değil; deklaratif kural ile ML tabanlı anomali yaklaşımının birlikte uygulanması ve veri kontratları + observability SLO’larının veri ekibinin standart bütçe kalemine girmesidir.
Veri Kalitesinin Altı Boyutu ve 2026 Olgunluk Seviyesi
DAMA-DMBOK 2 çerçevesi, veri kalitesini altı temel boyutta tanımlar: doğruluk (accuracy), tamlık (completeness), tutarlılık (consistency), güncellik (timeliness), benzersizlik (uniqueness) ve geçerlilik (validity). Forrester’ın Mart 2026 Data Quality Wave raporuna göre data ekiplerinin %71’i tamlık ve güncellik metriklerini her gün otomatik ölçüyor; ancak tutarlılık ve benzersizlik için cross-system kural yoğunluğu hâlâ ortalama %38 seviyesinde. dbt Labs Coalesce 2025 sunumlarında öne çıkan tema, “altı boyut” çerçevesinin SLO formatında ifade edilmesi gerektiği yönündeydi: hangi boyut, hangi tabloda, hangi eşik, hangi pencere.
| Boyut | Tanım | Tipik Kural | 2026 Olgunluk (%) |
|---|---|---|---|
| Doğruluk (Accuracy) | Veri gerçeği yansıtıyor mu? | Cross-source reconciliation | 34 |
| Tamlık (Completeness) | Beklenen alanlar dolu mu? | NOT NULL, doluluk % | 78 |
| Tutarlılık (Consistency) | Sistemler arası çelişki var mı? | FK, referential check | 41 |
| Güncellik (Timeliness) | Veri yeterince taze mi? | Freshness SLA, lag < N dk | 73 |
| Benzersizlik (Uniqueness) | Aynı varlık tekrar var mı? | Unique key, dedupe | 52 |
| Geçerlilik (Validity) | Biçim/aralık kurallara uyuyor mu? | Regex, range, enum | 67 |
- Doğruluk: ML modelinin “müşteri yaşı” alanı, CRM ve fatura sisteminde aynı mı? Karşılaştırma kuralları otomatize edilmediği sürece düşük olgunlukta kalıyor.
- Tamlık: Beklenen alanların ne kadarı dolu — declarative araçların ilk halletmek için seçtiği boyut.
- Tutarlılık: FK ihlali, “müşteri_id 7891 sipariş tablosunda var ama müşteri tablosunda yok” gibi yetim kayıt vakaları.
- Güncellik: ETL gecikmesi, freshness SLA, dakika cinsinden lag.
- Benzersizlik: Aynı kullanıcının iki kez kayıt olması, dedupe ihtiyacı.
- Geçerlilik: Tarih formatı, ülke kodu, e-posta regex, enum sınırları.
Great Expectations: Açık Kaynak, Geliştirici Odaklı, Python Yerel
Great Expectations (GX), Python tabanlı açık kaynaklı bir veri kalitesi kütüphanesidir. Beklentiler (“expectation”) Python kodu veya JSON şemalarıyla tanımlanır; veri kümesine karşı validate edilir ve sonuç HTML data docs olarak yayımlanır. GX dokümantasyonu, 1.0 sürümüyle birlikte API’yi sadeleştirdi; “Validator”, “Checkpoint” ve “Data Source” abstraksiyonları artık eski “BatchRequest” cümbüşünün yerini aldı. GX Cloud 2025’te genel kullanıma açıldı ve takım bazlı kural envanteri sunuyor; ücretsiz tier küçük ekipler için yeterli.
GX’in güçlü yanı, geliştirici workflow’una doğal entegrasyon: Airflow PythonOperator, Prefect task, Dagster asset olarak çağrılabiliyor. dbt projeleriyle birlikte kullanımı için “dbt-expectations” paketi mevcut; ancak resmi öneri, GX’i dbt’den ayrı bir orkestrasyon adımı olarak çalıştırmak. dbt analytics engineering 2026 rehberimizde bahsettiğimiz “test, run, snapshot” akışına GX validation step’i eklemek, deployment’ı yavaşlatmadan kapsamı genişletir. Apache Spark, Kafka pipeline yazımızda ele alınan büyük veri akışlarında GX’in Spark backend’i, in-cluster validation için pratiktir.
Soda Core: Deklaratif SQL Tabanlı, İş Analistlerine Yakın
Soda Core, kural setlerini YAML formatında SodaCL (Soda Checks Language) dili ile tanımlar; arka planda SQL üretir ve doğrudan veri ambarında çalıştırır. Soda dokümantasyonu, 2025 yılı boyunca SodaCL’i declarative data contract yaklaşımıyla uyumlu hâle getirdi: “schema”, “freshness”, “row_count anomaly”, “duplicate_percent” gibi metrik isimleri doğrudan Markdown’a benzer okunabilirlikte. Soda Cloud (ticari katman) kural ihlallerini incident’a dönüştürür, Slack/Teams entegrasyonu ile bildirir ve trend grafikleri sunar.
Soda’nın 2026 annual report’una göre Soda topluluğu 14 binin üzerinde aktif kurulum sayısına ulaştı; en yoğun benimseme analytics engineering takımlarında. dbt test ile birlikte (veya yerine) kullanılan bir araç olarak konumlanıyor. DataOps Trends 2025 anketinde ankete katılan ekiplerin %48’i Soda’yı dbt test’in tamamlayıcısı olarak çalıştırdığını belirtti; en sık argüman “dbt test sadece transform sonrası modelleri kontrol ediyor, Soda kaynak (raw / staging) katmanı için daha esnek”. Soda’nın asıl satış noktası okunabilirliği: iş analisti SodaCL dosyasına bakıp ne yaptığını anlayabiliyor.
Monte Carlo: ML Tabanlı Veri Gözlemlenebilirliği Platformu
Monte Carlo, “data observability” kategorisini ticari olarak tanımlayan firmadır. Kural yazmadan ML tabanlı anomali tespiti yapar: tablo şemasını, satır hacmini, freshness pattern’ini ve sıralı dağılımları otomatik öğrenir; sapma olursa alarm üretir. Monte Carlo blog, “five pillars of data observability” çerçevesini (freshness, volume, schema, lineage, distribution) yayımladı; sektör de büyük ölçüde bu sınıflandırmayı benimsedi. Monte Carlo State of Data Quality 2026 raporuna göre platform Fortune 500’ün %23’ünde kullanılıyor ve müşterilerinde MTTR (mean time to resolution) ortalamasını 9 saatten 1,2 saate indirdiği belgelendi.
Monte Carlo, lineage çıkarımını da yerleşik sunar: dbt manifest, Airflow DAG, BigQuery information_schema, Snowflake account_usage kaynaklarını tarayarak bağımlılığı çıkarır. Bir tabloda anomali patladığında downstream’de etkilenecek dashboard listesini gösterir.
Beş Araç Karşılaştırması: GX, Soda, Monte Carlo, dbt tests, Anomalo
Tek bir araç tüm yelpazeyi kapsamadığı için, olgun ekipler genelde iki veya üç aracı birleştirir. Aşağıdaki matris, beş yaygın seçeneği eksen eksen kıyaslar. Anomalo, Monte Carlo’ya benzer ML-anomali yaklaşımı sunan bir alternatif; dbt tests ise dbt model build adımının doğal parçası olarak en yaygın “ilk adım” durumunda.
| Kriter | Great Expectations | Soda Core | Monte Carlo | dbt tests | Anomalo |
|---|---|---|---|---|---|
| Lisans modeli | OSS + Cloud | OSS + Cloud | SaaS (ticari) | OSS (dbt Core) | SaaS (ticari) |
| Kural dili | Python / JSON | YAML (SodaCL) | Otomatik ML + opsiyonel kural | SQL + YAML | Otomatik ML + UI |
| ML anomali | Sınırlı (deneysel) | Sınırlı (basic z-score) | Tam (5 pillar) | Yok | Tam |
| Data warehouse desteği | 30+ (Spark dahil) | 20+ | 15+ (yalnızca yönetilen) | 20+ | 10+ |
| Yerleşik lineage | Yok | Sınırlı (Cloud) | Yerleşik (column-level) | Yok (manifest) | Yerleşik (table-level) |
| Incident yönetimi | Cloud’da | Cloud’da | Yerleşik | Yok | Yerleşik |
| Tipik yıllık maliyet | 0–25 bin USD | 0–60 bin USD | 80–250 bin USD | 0 USD (Core) | 60–180 bin USD |
| Tipik kullanıcı | Data engineer | Analytics engineer | Data platform | Analytics engineer | Data analyst |
Declarative Rule vs ML Anomaly: İki Felsefenin Karşılaştırması
Declarative kural yaklaşımı, “ne olmalı” sorusuna deterministik cevap verir: “siparis_tutari sütunu 0’dan büyük olmalı, NULL olmamalı, müşteri_id FK referansı olmalı”. ML anomali yaklaşımı, “ne alışılmadık” sorusuna istatistiksel cevap verir: tarihsel pattern’i öğrenir, sapmayı bildirir. İki yaklaşım birbirini tamamlar; ne biri ne diğeri tek başına yeterli değildir. Monte Carlo’nun yayımladığı 2026 kıyaslamalarına göre ML modelleri hacim ve şema sapmalarının %94’ünü, sıralı dağılım sapmalarının %71’ini ilk 30 dakikada yakalar; ancak yanlış pozitif oranı tuning yapılmadığında %18’e ulaşır.
| Boyut | Declarative Rule (GX, Soda, dbt) | ML Anomaly (Monte Carlo, Anomalo) |
|---|---|---|
| Felsefe | “Ne olmalı” | “Ne alışılmadık” |
| Kurulum süresi | Saatler – günler (per tablo) | Dakikalar (auto-onboard) |
| İlk değer | Hızlı ama dar | Yavaş ama geniş |
| Yanlış pozitif riski | Düşük (kural net) | Orta-yüksek (tuning gerekli) |
| Yeni hata türleri | Yakalamaz (kural yoksa) | Yakalar (pattern dışı) |
| Sahiplik | Domain ekibi yazar | Platform ekibi yönetir |
| Maliyet eğimi | Linear (tablo başına) | SaaS lisansı, fixed + tablo |
| Açıklanabilirlik | Yüksek (SQL) | Orta (ML iç içe) |
2026 olgun mimarisinin tipik formülü şu: declarative araç (GX veya Soda) ile kritik 50-100 tablonun temel kuralları yazılır, ML platform (Monte Carlo veya Anomalo) ile tüm data warehouse “background” anomali izlemesine alınır. RAG altyapısı yazımızda belirttiğimiz gibi, ML pipeline’larında upstream veri kalitesi, model performansından önce gelmesi gereken kontroldür; aksi halde model “garbage in, garbage out” durumuna düşer.
Veri Kontratları (Data Contracts): Spec, Schema ve SLA
Veri kontratı, üretici (producer) ile tüketici (consumer) arasında bağlayıcı sözleşmedir: hangi şema, hangi freshness SLA, hangi semantik garanti, hangi breaking change politikası. Data Contract Specification ve Open Data Contract Standard (ODCS), 2025 yılı boyunca olgunlaşan iki açık standarttır. Spec’ler genelde YAML; “models”, “quality” (GX/Soda checks gömülebilir), “servicelevels” (freshness, retention, latency) ve “examples” bölümlerini içerir. CI/CD’de üretici tarafında validate edilir; tüketici tarafında okunup downstream test’lere dönüştürülür.
| Kontrat Bileşeni | Tanım | 2026 Pratik |
|---|---|---|
| Schema | Sütun adı, tip, NOT NULL | Spec.yaml + JSON Schema |
| Quality | Doluluk, unique, range kuralları | Inline GX/Soda checks |
| Service Level | Freshness, retention, lag | SLA tablosu (cron, saat) |
| Ownership | Producer + consumer takım | data product owner alanı |
| Breaking Change Policy | Versiyon, deprecation süresi | Semver + 90 gün notice |
| Examples | Geçerli/geçersiz örnekler | YAML inline + dbt seed |
Kontrat yaklaşımı, “veri ürünü” (data product) felsefesinin operasyonel ifadesidir. Data Mesh yazımızda ele aldığımız domain-owned veri prensibi, ancak veri kontratlarıyla birleştiğinde gerçek anlamda işliyor; aksi halde “her domain kendi başına” ifadesi pratikte yalnızca tablonun adının başka bir prefix almasına denk geliyor.
Data Quality SLO ve SLA: Ölçülebilir Hedefler
Sitelerinde SRE pratiği uygulayan ekipler için SLO (Service Level Objective) ve SLA kavramları tanıdık; veri tarafında bu pratik 2024-2026 arası yaygınlaştı. Veri SLO’su tipik olarak şu formatta: “fact_orders tablosu, %99,5 oranında saat başı 30 dakika içinde güncellenecek; doluluk %99,9 üzerinde olacak; benzersizlik ihlali %0,01 altında olacak”. SLO ihlali budget’ı aşarsa, yeni feature deployment durur; SRE “error budget” kavramının veri eşdeğeri.
| SLO Tipi | Metrik | Tipik Hedef | Pencere | Eşik İhlal Aksiyonu |
|---|---|---|---|---|
| Freshness | Son güncelleme yaşı (dk) | < 30 dk | 30 günlük | PagerDuty data-eng |
| Completeness | Doluluk % | ≥ 99,9 | Saatlik | Slack #data-quality |
| Uniqueness | Duplicate % | ≤ 0,01 | Günlük | Ticket + 24h SLA |
| Volume | Satır sayısı sapması | ±20% (z-score 3) | Saatlik | Anomali alarm |
| Schema | Breaking change | 0 | Anlık | Pipeline halt |
| Validity | Regex/range ihlal % | ≤ 0,1 | Günlük | Quarantine + ticket |
Observability Platform Fiyatlandırma: 2026 Sektör Bandı
Veri gözlemcilik platformları fiyatlandırma modeli açısından henüz “data warehouse satır × birim fiyat” gibi standart bir kurala oturmadı. Üreticilerin çoğu data warehouse’taki tablo sayısı, monitör edilen tablo sayısı veya satır hacmi üzerinden değişken paketleme yapıyor. Aşağıdaki tablo, 2026 başı vendor görüşmelerinden ve IDC raporlarından derlenmiş yaklaşık bantlardır; sözleşme bazlı pazarlık marjı genelde %20-30.
| Platform | Model | Küçük (50 tablo) | Orta (500 tablo) | Büyük (5k+ tablo) |
|---|---|---|---|---|
| Great Expectations Cloud | Per user / seat | 0–8k USD | 15–35k USD | 40–80k USD |
| Soda Cloud | Per dataset | 0–18k USD | 30–70k USD | 80–150k USD |
| Monte Carlo | Per monitored table | 60–90k USD | 120–180k USD | 200–350k USD |
| Anomalo | Per table + per warehouse | 50–80k USD | 100–160k USD | 180–280k USD |
| Bigeye | Per warehouse + asset | 40–70k USD | 90–150k USD | 170–250k USD |
- Open source başlangıç: dbt Core + GX + Soda Core. Yıllık altyapı maliyeti yalnızca compute (warehouse’ta SQL çalıştırma).
- Hibrit kurumsal: Open source declarative + Monte Carlo (veya Anomalo) ML katmanı. Yıllık 80-200k USD bandı.
- Tam yönetilen kurumsal: Monte Carlo + Collibra/Atlan data catalog + Soda Cloud. 200-450k USD bandı, Fortune 1000 tipik profili.
- Maliyet kontrolü: Tüm platformlar “monitored table” cinsinden ücretlendirildiği için ölü tabloları silmek ve düşük öncelikli tabloları monitör dışı bırakmak %30’a varan tasarruf sağlar.
Üretim Akışı: 8 Adımda Pilottan Tam Yayılıma
- Inventory ve önceliklendirme: Tüm tabloları listele, “tier 1” (gelir, finans, müşteri) için kontrat zorunlu, “tier 2/3” daha gevşek. Dijital dönüşüm KPI yazımızda ele aldığımız kritiklik matrisi tablo bazına da uygulanabilir.
- Ownership atama: Her tier 1 tablo için “data product owner” tayin et; isim takım değil kişi olsun (RACI’da R sorumlusu).
- Veri kontratı yaz: Schema + quality + SLA YAML’i üreticiyle birlikte hazırla, git repo’sunda versiyonla.
- Declarative kural seti: GX veya Soda ile temel kuralları (NOT NULL, unique, FK, range, freshness) yaz; dbt test’ten kademeli taşıma.
- Orchestration entegre: Airflow/Prefect/Dagster pipeline’larında validation step’i; ihlal halinde “fail fast” politikası.
- ML observability bağla: Monte Carlo veya Anomalo üst katmanda; tüm warehouse’u tarayacak şekilde. Stream processing yazımızda belirtildiği gibi streaming pipeline’larda da freshness/volume monitoring kritik.
- Incident yönetimi: Alarm → triage → root cause → postmortem akışı; DevSecOps kültüründeki “blameless postmortem” prensibi veri için de geçerli.
- Quarterly review: Kural envanteri, alarm yorgunluğu metriği, MTTR, SLO ihlal yüzdesi. Ölü kuralları sil, yeni pattern’ler için kural ekle.
OpenLineage, Lineage ve Root Cause Analizi
Lineage (veri soyağacı), bir tabloda anomali çıktığında “hangi upstream tablo bozuldu, hangi downstream dashboard etkilendi” sorusuna cevap verir. OpenLineage, lineage event’lerinin açık standardı; Airflow, dbt, Spark, Flink gibi orkestratörler OpenLineage event’i yayımlayarak ortak bir lineage backend’e (örneğin Marquez) feed eder. Monte Carlo, Anomalo, Atlan gibi platformlar OpenLineage uyumluluğunu 2025-2026 boyunca standardize etti. Data catalog yazımızda Atlan/Collibra/Atlas karşılaştırmasında lineage entegrasyonunun katalogla birleşmesinin önemini detaylandırdık.
Yönetişim, Sahiplik ve Alarm Yorgunluğu
Veri kalitesi araçları tek başına teknik bir katman değil, sahiplik modeli gerektirir. Data Mesh prensiplerine göre her veri ürününün bir “product owner”ı bulunur ve kalite metriklerinden sorumludur. Sorumluluk dağılımı net değilse alarmlar her sabah farklı kanallarda dolaşır ve kimse aksiyon almaz; bu durum 2026’nın en yaygın yakınması olan “alarm yorgunluğu”nun (alert fatigue) en yaygın sebebidir. Gartner Ocak 2026 raporu, “data quality alarm fatigue” indeksinin son iki yılda %47 arttığını belgeledi.
Olgun ekipler veri ürünleri için “data product canvas” dokümanı tutar: tablonun amacı, SLA, kabul edilen şema değişiklikleri, tüketici listesi ve eskalasyon zinciri yazılıdır. Quarterly review’da bu doküman güncellenir, kullanılmayan tablolar deprecate edilir ve sahipsiz veri silinir. Alarm yorgunluğunu azaltmanın somut taktikleri: severity tiering (P0/P1/P2), alarm gruplanması (aynı root cause’tan gelenleri birleştir), suppression rules (planlı bakımda alarm bastır) ve haftalık alarm-deduplication ritüeli.
Maliyet, ROI ve Sınırlamalar
McKinsey’nin 2025 Data Maturity çalışmasına göre veri gözlemcilik yatırımı yapan şirketler hatalı raporlama olaylarını %63 azalttı, karar süresini %29 hızlandırdı ve ML modellerinin üretime ulaşma oranını %38’den %71’e çıkardı. Monte Carlo gibi tam yönetilen platformların yıllık maliyeti orta ölçek için 80-200 bin dolar bandında; bütçesi sınırlı ekipler açık kaynak GX + Soda + dbt test üçlüsüyle başlar ve gözlemcilik katmanını sonra ekler. Açık kaynak araçların sınırı genelde üç noktada: ML anomali yetkinliği, cross-table column-level lineage ve incident workflow yönetimi.
Sık Sorulan Sorular
Great Expectations, Soda ve Monte Carlo’dan birini seçmek zorunda mıyım?
Hayır. Olgun veri ekiplerinin çoğu hibrit yapı kurar: dbt tests koddaki temel kuralları, GX veya Soda kaynak/staging katmanı için ekstra deklaratif kuralları, Monte Carlo (veya Anomalo) ise üst katmanda ML tabanlı anomali tespitini sağlar. Önemli olan kuralları çift tanımlamamak ve sahipliği netleştirmektir. Tablo başına tek bir “doğruluk kaynağı” aracı seçilmeli ve diğer araçlar tamamlayıcı rolde tutulmalıdır.
dbt tests yetmiyor mu?
dbt tests, modelin çıktısı için temel kural setini (NOT NULL, unique, relationships, accepted_values) sağlar ve dbt Core’un parçasıdır. Ancak ML tabanlı anomali, freshness SLA görselleştirme, cross-model bağımlılık takibi, incident workflow yönetimi ve column-level lineage dbt tests’in kapsamı dışındadır. Küçük analytics engineering ekipleri için dbt tests doğru başlangıçtır; veri ürünleri büyüdükçe Soda veya Monte Carlo gibi tamamlayıcı katman eklenir.
ML tabanlı anomali tespiti gerçekten işe yarıyor mu?
Evet, ama tuning şart. Monte Carlo’nun 2026 kıyaslamalarına göre ML modelleri hacim ve şema sapmalarının %94’ünü, sıralı dağılım sapmalarının %71’ini ilk 30 dakikada yakalıyor. Yanlış pozitif riski tuning yapılmadığında %18’e ulaşıyor, doğru tuning ile %3-5 bandına iniyor. En sağlıklı yaklaşım declarative kural + ML hibrit modeli; kural deterministik kontrol için, ML “bilmediğimiz bilinmeyenler” için.
Veri kontratları nasıl uygulanır, üretici ekipler buna direnir mi?
Veri kontratları üretici ile tüketici arasındaki şema, kalite ve SLA sözleşmesidir. YAML formatında (Data Contract Specification veya ODCS) yazılır, git’te versiyonlanır, CI pipeline’ında üretici tarafında doğrulanır ve breaking change durumunda tüketiciye otomatik uyarı iletilir. GX ve Soda kontrat dosyalarını test runner’a dönüştürür. Direnç beklenir; ilk pilotu kritik 5-10 tabloda yap, başarıyı ölç, yaygınlaştır. Üreticiye “kontrat yazmazsan downstream’in seni tag’leyemediği bir vakada sorumluluk sende” mesajı verilmeli.
Data quality SLO ve SLA arasındaki fark nedir?
SLO (Service Level Objective) iç hedeftir, ihlal halinde aksiyon ve error budget tüketimini tetikler; SLA (Service Level Agreement) tüketici ile yapılan dış sözleşmedir, ihlal halinde finansal veya operasyonel taahhüt doğurur. Pratikte SLA, SLO’dan daha gevşek tutulur (örneğin SLO %99,5 freshness; SLA %99). SRE pratiğinden veri tarafına geçen bu ayrım, “error budget” kavramını da getirir: SLO ihlal budget’ı tükendiğinde yeni feature deployment durur, kalite iyileştirme önceliğe geçer.
Sonuç ve Framework Verdict
Great Expectations, Soda Core ve Monte Carlo, veri kalitesi yönetiminin üç farklı katmanını temsil eder: kod merkezli declarative kural (GX), iş analistine yakın declarative kural (Soda) ve ML tabanlı gözlemcilik (Monte Carlo). 2026’da olgun data ekipleri bu araçları rakip değil tamamlayıcı olarak konuşlandırır; açık kaynakla temel deklaratif rejimi kurar, ticari ML katmanını ölçek için ekler. Veri kontratları ve SLO/SLA katmanı, teknik araçları organizasyonel sahiplik ve sorumlulukla birleştirir.
- Küçük ekip (5 kişi altı, <100 tablo): dbt tests + Great Expectations Core. Yıllık maliyet 0-5k USD. Kontrat şart değil ama YAML schema kontrolü.
- Orta ölçek (analytics engineering ekibi, 100-1000 tablo): dbt tests + Soda Cloud + opsiyonel Monte Carlo deneme tier. Veri kontratı pilot 10-20 kritik tabloda.
- Kurumsal (data platform ekibi, 1000+ tablo): dbt tests + GX/Soda hibrit + Monte Carlo veya Anomalo + Data Catalog. Veri kontratı tier 1 zorunlu, SLO/SLA standart.
- ML pipeline odaklı: Monte Carlo veya Anomalo ML anomali şart; GX/Soda feature store ve training data için zorunlu; freshness SLA model retrain pencereleri ile senkron.
Doğru kombinasyon, hatalı raporları azaltır, ML modellerinin üretime ulaşma oranını artırır, alarm yorgunluğunu yönetilebilir tutar ve karar hızını somut biçimde yükseltir. 2026’da kazanan ekipler, tek bir araca bel bağlayanlar değil, declarative + ML + kontrat + SLO katmanlarını birlikte konuşlandıran ve quarterly review ritmiyle sürdürenler olacak.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.