AI ve veri analitiği girişimlerinde “model performansı” çoğu zaman vitrindeki metrik olur; ancak üretimde sorunlar sıkça veri pipeline’larının kırılganlığı, veri kalitesinin tutarsızlığı veya ölçülmeyen operasyonel gecikmeler yüzünden görünür hale gelir. Bu yazı, ölçeklenebilir pipeline kurarken hangi yapı taşlarının kritik olduğunu ve hangi KPI’larla bu sistemi yönetebileceğinizi pratik bir çerçeveyle ele alır.

Not: Aşağıdaki yaklaşım; teknoloji seçimi, mimari tercih ve eşik değerlerde kurum bağlamına göre uyarlama gerektirir. Tek bir “evrensel doğru” eşik seti genellikle yoktur.

Kısa sözlük (ilk okuma için)

  • MTTR: Mean Time To Repair/Recover; bir incident (arıza) başladıktan sonra hizmeti normale döndürmek için geçen ortalama süre.
  • p50 / p95 / p99 gecikme: İsteklerin sırasıyla %50/%95/%99’unun altında kaldığı gecikme değeri (kuyruk/dalgalanma etkisini anlamak için kullanılır).
  • Freshness (tazelik): Verinin, tüketildiği ana göre ne kadar güncel olduğu.

1) Ölçeklenebilir veri pipeline’ı ne demek?

Ölçeklenebilir bir veri pipeline’ı, veri hacmi, hız (batch/stream) ve kullanım senaryoları büyürken şu hedefleri sürdürebilen sistemdir:

  • Güvenilirlik: Çalışmaların düzenli tamamlanması, hataların kontrollü yönetilmesi.
  • Tazelik (freshness): Verinin iş kararları veya model çıkarımı için yeterince güncel kalması.
  • Kalite: Tanımlı kurallara uymayan verinin aşağı akışa yayılmasının engellenmesi.
  • İzlenebilirlik: “Ne bozuldu, ne zaman bozuldu, neden bozuldu?” sorularına hızlı yanıt.
  • Tekrarlanabilirlik: Aynı girdilerle aynı dönüşümleri yeniden üretebilme (özellikle ML için).

AWS Well-Architected Machine Learning Lens, bu hedeflere yaklaşmak için “modern veri mimarisi” kullanmayı (ör. veri gölü + veri ambarı desenleri, uygun dönüşüm pratikleri ve yönetişim) bir iyi uygulama olarak ele alır. Kaynak: AWS Well-Architected – Machine Learning Lens (Modern data architecture).

2) Modern mimari: ETL mi ELT mi, “lakehouse” nerede duruyor?

Birçok organizasyon, analitik ve ML iş yüklerini aynı veri temeli üzerinde daha tutarlı yönetmek için “modern data architecture” desenlerine yöneliyor. Pratikte bu, genellikle şunların bir kombinasyonudur:

  • ELT ağırlığı: Ham veriyi önce merkezi depoya alıp dönüşümleri daha sonra çalıştırma.
  • Veri gölü + ambar desenleri: Esneklik (ham veri) ile performans/yönetişim (modelleme, erişim, kalite) ihtiyaçlarını birlikte ele alma.
  • Batch + streaming birlikte: Bazı tablolar batch yenilenirken, kritik olay verileri akış olarak işlenebilir.

Sektörde “lakehouse” terimi, veri gölü esnekliğini ambar benzeri yönetişim ve performans pratikleriyle birleştirmeyi anlatmak için de kullanılır; ancak hangi yaklaşımın uygun olduğu kurumun güvenlik, maliyet, beceri seti, gecikme toleransı ve yönetişim ihtiyaçlarına göre değerlendirilmelidir.

3) Pipeline’ı modüllere ayırın: Uçtan uca ama parçalı sorumluluk

Ölçeklenebilirlik için pipeline’ı bir “tek büyük job” olarak değil, sorumlulukları ayrılmış modüller olarak tasarlamak pratikte işinizi kolaylaştırır:

3.1 Ingestion (toplama)

  • Kaynak türleri: uygulama olayları, veritabanı replikasyonu/CDC, SaaS entegrasyonları, dosya akışları.
  • Temel ihtiyaçlar: şema takibi, idempotent yazma (tekrar çalıştırınca bozulmama), gecikme görünürlüğü.

3.2 Storage (ham/temizlenmiş/ürünleştirilmiş katmanlar)

  • Ham katman: geri dönüp doğrulama yapabilmek için.
  • Temizlenmiş katman: temel standartlaştırmalar.
  • Servis katmanı (gold/mart/feature): BI ve ML tüketimi.

3.3 Transform (dönüşüm)

  • Tekrarlanabilir dönüşümler (versiyonlu kod, veri sözlüğü, değişiklik günlüğü).
  • Kalite kontrollerini dönüşümün “yan ürünü” değil, birinci sınıf çıktı haline getirme.

3.4 Serving (sunum)

  • Analitik sunum: sorgu performansı, veri ürünleri, semantik katman.
  • ML sunumu: feature serving, çevrimiçi/çevrimdışı tutarlılık, düşük gecikme.

4) Veri kalite kapıları (data quality gates): “Kötü veri”yi aşağı akışa bırakmayın

Üretimde en maliyetli senaryolardan biri, kalite problemi olan verinin sessizce downstream sistemlere akmasıdır. Bu yüzden pipeline’ın belirli noktalarına kalite kuralları eklemek ve sonuçlara göre dur-düşün (gate) mekanizması uygulamak iyi bir pratiktir.

AWS Glue Data Quality, pipeline içinde veri kalite kuralları tanımlama, kural önerme ve kalite sonuçlarına göre aksiyon alma gibi yetenekleri dokümantasyonunda açıklar. Kaynak: AWS Glue Data Quality.

4.1 Hangi kalite kontrolleriyle başlayabilirsiniz?

  • Şema/format: Beklenen kolonlar var mı, veri tipleri uyuyor mu?
  • Tamlık: Kritik alanlarda boş değer oranı artıyor mu?
  • Aralık/kurallar: Negatif olamaz, tarih gelecekte olamaz gibi iş kuralları.
  • Benzersizlik: Tekil olması gereken anahtarlar çoğalıyor mu?
  • Tutarlılık: Bir tablodaki değer, referans tablolarla çelişiyor mu?
  • Dağılım kayması: Kategori dağılımı olağandışı değişti mi? (özellikle ML özelliklerinde)

4.2 “Gate” kararları: durdur, karantinaya al, uyar

Her kalite ihlalinde job durdurmak gerçekçi olmayabilir. Pratik bir sınıflandırma:

  • Bloklayıcı: Kritik iş metriklerini veya finansal raporlamayı etkileyebilecek hatalar → pipeline durabilir ya da sürüm geri alınabilir.
  • Karantina: Veri işlenir ama “quarantine” katmanına ayrılır; tüketimden gizlenir.
  • Uyarı: Anomali kaydı açılır; trend kötüleşirse bloklayıcıya yükseltilir.

5) Data observability: metrik izleme + anomali yakalama

Veri kalitesi kuralları “beklenen şartları” doğrular. Observability ise, sistemin gerçekte nasıl davrandığını sürekli ölçerek sorunları erken yakalamayı hedefler. Sektör içeriklerinde bu yaklaşım genellikle sürekli metrik izleme ve anomali tespiti birleşimi olarak ele alınır. Kaynak: TDWI whitepaper.

Tarafsızlık notu: Bu TDWI içeriği vendor örnekleri içeren bir endüstri whitepaper’ıdır; observability yaklaşımını ve araçlarını seçerken kendi veri/iş bağlamınıza göre (maliyet, yetkinlik, risk) değerlendirme yapın.

5.1 İzlenecek temel sinyaller

  • Hacim metrikleri: satır sayısı, dosya sayısı, event sayısı.
  • Kalite metrikleri: null oranı, benzersizlik ihlali sayısı, kural geçiş oranı.
  • Tazelik/latency: son başarılı çalışma zamanı, gecikme dağılımı.
  • Şema değişimleri: kolon eklendi/silindi, tip değişti.
  • Aşağı akış etkisi: hangi dashboard, model veya API tüketimi etkilendi.

5.2 Anomali tespitini nasıl konumlandırmalı?

Anomali tespiti, özellikle değişken iş yüklerinde yararlıdır; ancak tek başına “hakem” olmamalıdır. Pratik öneri:

  • Önce basit eşikler (ör. tazelik gecikmesi beklenenden uzun) + iş kuralı kontrolleri ile başlayın.
  • Zamanla, periyodik dalgalanmaları öğrenen yaklaşımları (mevsimsellik, gün/saat paterni) ekleyin.
  • Her alarm için doğrulama adımı tanımlayın: gerçek olay mı, beklenen bir kampanya etkisi mi?

6) Özellik mühendisliği ve feature store: ML tutarlılığı için kritik halka

ML sistemlerinde pipeline’ın “son kilometresi” çoğu zaman özellik (feature) üretimi ve sunumudur. Feature hesapları farklı ekiplerce, farklı job’larda tekrarlandığında; eğitim (offline) ile servis (online) arasında tutarsızlık riski artar.

Feature store mimarileri, çevrimdışı/çevrimiçi ayrım, tekrar kullanılabilir tanımlar ve API tabanlı erişim gibi yaklaşımlarla bu tutarsızlık riskini azaltmayı hedefler. Teknik arka plan için: The Hopsworks Feature Store for Machine Learning.

6.1 Ne zaman feature store düşünmelisiniz?

  • Aynı özellikler birden fazla model ve ekip tarafından tekrar tekrar üretiliyorsa
  • Online çıkarımda gecikme hedefleri sıkıysa ve “feature serving” darboğaz oluyorsa
  • Model izleme/yeniden eğitim süreçlerinde tutarlılık sorunları yaşıyorsanız

6.2 Feature store KPI’ları (örnek alanlar)

  • Feature serving latency: online isteklerde p50/p95/p99 gecikme dağılımı ve timeout oranı
  • Training-serving consistency: aynı feature tanımının offline ve online ortamda tutarlılığı
  • Feature freshness: online serviste kullanılan feature’ın güncelliği

Gecikme hedefleri (ör. “X ms altında”) kullanım senaryosuna göre ciddi değişir; bu yüzden hedefleri belirlerken QPS, feature sayısı, cardinality ve altyapı kısıtlarını birlikte değerlendirin.

7) KPI çerçevesi: Pipeline’ı yönetecek metrik setini nasıl kurarsınız?

Birçok ekip yalnızca “job başarılı mı?” sorusunu ölçer. Oysa operasyonel kalite; güvenilirlik, tazelik, kalite geçiş oranı ve onarım hızı (MTTR) gibi metriklerin birlikte ele alınmasını gerektirir. Bu metrik seti, observability yaklaşımı ve kalite kapılarıyla birlikte düşünülür. Kaynaklar: AWS Glue Data Quality, TDWI whitepaper.

7.1 KPI’ları üç seviyede toplayın

  • Pipeline sağlık KPI’ları: sistem çalışıyor mu, gecikiyor mu?
  • Veri ürün KPI’ları: BI tabloları/raporlar doğru ve güncel mi?
  • ML KPI’ları: feature ve model servis kalitesi sürdürülebilir mi?

7.2 KPI şablonu (kopyalayıp uyarlayın)

KPI Ne ölçer? Nasıl ölçülür? Operasyonel kullanım
Pipeline reliability Çalışmaların başarıyla tamamlanma oranı ve stabilite Job run durumları, hata kodları, retry sayıları SLA/SLO takibi, kapasite planlama
Freshness / latency Verinin ne kadar güncel olduğu Son başarılı run zamanı, event time vs processing time farkı Karar mekanizmaları ve model çıkarım doğruluğu için erken uyarı
Data quality pass rate Kalite kurallarından geçiş oranı Kural bazlı test sonuçları, bloklayıcı/uyarı sınıfları Gate tetikleme, karantina yönetimi
Feature serving latency (p50/p95/p99) Online feature erişim gecikmesi dağılımı Servis metrikleri, timeout oranı Ürün deneyimi ve inference SLA yönetimi
Incident MTTR Arızayı giderme hızınız (ortalama onarım/iyileşme süresi) Olay açılış-kapanış süreleri, runbook adımları Operasyonel olgunluk ve ekip verimliliği

7.3 Eşik değerler: neden “tek doğru” yok?

Eşikler kullanım senaryosu ve risk iştahına göre değişir. Örneğin aynı “freshness” metriği, gerçek zamanlı dolandırıcılık tespiti ile haftalık yönetim raporu için aynı anlama gelmez. Bu nedenle:

  • Eşik belirlerken tüketici (dashboard, API, model) ve iş etkisi (gelir, operasyon, müşteri deneyimi) baz alın.
  • Önce mevcut durumu ölçün; sonra hedefleri kademeli iyileştirme olarak koyun.
  • Her KPI için “alarm yorgunluğu” riskini azaltacak olay sınıflandırması yapın.

8) Enstrümantasyon: KPI’ları ölçmeden yönetemezsiniz

8.1 Minimum izleme paketi

  • Run metadata: job adı, sürüm, giriş/çıkış dataset’leri, süre, çıktı satır sayısı.
  • Kalite sonuçları: kural bazında geçiş/kalış, örnek hata kayıtları, trend.
  • Lineage (soy ağacı): hangi tabloların hangi dönüşümlerle üretildiği.
  • Tüketim sinyali: hangi veri ürünleri aktif kullanılıyor, hangileri kritik?

8.2 Alarm tasarımı: “Aksiyon alınabilir” olmalı

Her alarmın şu bilgileri içermesi pratikte MTTR’ı düşürür:

  • Etkilenen veri ürünü (tablo/dashboard/model)
  • İhlal tipi (tazelik, kalite, hacim anomali)
  • Son iyi durum zamanı
  • Muhtemel kök nedenler (örn. kaynak kesintisi, şema değişimi)
  • İlk müdahale adımları (runbook linki)

9) 30-60-90 günlük uygulama planı (pratik yol haritası)

İlk 30 gün: görünürlük ve temel kontroller

  • Kritik veri ürünlerini envanterleyin (en çok kullanılan 10 tablo/model).
  • Pipeline run metadata toplamayı standartlaştırın.
  • 3–5 temel veri kalite kuralını devreye alın (şema, null, benzersizlik gibi).
  • Freshness ve reliability için ilk dashboard’u oluşturun.

60 gün: gate politikası ve observability olgunlaştırma

  • Kalite ihlallerini bloklayıcı/karantina/uyarı olarak sınıflandırın.
  • Anomali tespiti için hacim ve tazelik sinyallerinde baseline oluşturun.
  • Olay yönetimi akışını netleştirin: kim sahip, hangi sürede müdahale?

90 gün: ML üretimi ve feature standardizasyonu

  • Tekrarlanan feature tanımlarını toplayın, yeniden kullanılabilir hale getirin.
  • Online serving için gecikme ve tazelik KPI’larını netleştirin.
  • Lineage ve etki analizi ile “hangi değişiklik kimi bozar?” sorusunu kısaltın.

10) Sık hatalar ve kaçınma önerileri

  • Hata: Kalite kontrollerini yalnızca raporlama amaçlı tutmak.
    Çözüm: En azından kritik tablolarda gate/karantina politikası belirleyin.
  • Hata: Her şeyi ölçmeye çalışıp hiçbir şeyi iyileştirememek.
    Çözüm: KPI’ları “en çok iş etkisi” olan 5–8 metrikte sabitleyin.
  • Hata: Feature’ları farklı yerlerde farklı hesaplamak.
    Çözüm: Feature tanımlarını merkezi hale getirin; offline/online tutarlılığını hedefleyin.
  • Hata: Alarmların aksiyon üretmemesi.
    Çözüm: Alarm mesajına runbook ve etki bilgisini ekleyin.

Sonuç: AI çıktısı, veri operasyonu kadar güçlüdür

AI ve veri analitiğinde sürdürülebilir başarı; ölçeklenebilir bir mimari, pipeline içine gömülü veri kalite kapıları, sürekli observability ve doğru KPI setiyle gelir. Modern veri mimarisi pratikleri, kalite kurallarıyla “kötü verinin” yayılmasını azaltmayı; observability ise metrik trendlerini izleyerek sapmaları daha erken görmeyi hedefler. ML tarafında feature store yaklaşımı, eğitim ve servis tutarlılığını güçlendirebilir. Başlangıç için en önemli adım: KPI’ları tanımlayıp ölçmeye başlamak ve bu ölçümlere bağlı net operasyonel aksiyonlar belirlemektir.

İlgili kaynaklar: AWS Glue Data Quality, AWS Well-Architected ML Lens, TDWI observability whitepaper, Hopsworks feature store araştırması.