1. GİRİŞ

Veri odaklı karar alma süreçlerinin yaygınlaşmasıyla birlikte, veri boru hatları (pipelines), veri gölleri ve veri ambarları işletme için hayati öneme sahip altyapılar haline geldi. Ancak veri boru hatlarında meydana gelen hatalar, gecikmeler veya veri bozulmaları işletme kararlarını doğrudan etkiler. "Data Monitoring" (veri izleme) konusu, verinin üretim ortamında beklenen kalitede, zamanında ve tutarlı şekilde tüketicilere ulaşmasını sağlamak için gerekli teknik ve organizasyonel yaklaşımları kapsar.

Bu neden bugün önemli?

• ML modelleri ve dashboard'lar yanlış veriyle beslendiğinde hatalı sonuçlar ve finansal kayıplar ortaya çıkabilir.
• Gerçek zamanlı karar sistemleri (fraud detection, pricing, recommendations) için veri gecikmesi veya eksikliği önemli risk oluşturur.
• Regülasyonlar ve denetimler veri doğruluğu ve izlenebilirlik talep eder; veri monitoring otomatik kanıt üretir.

Kimler için önemli?

• Veri mühendisleri ve platform ekipleri — pipeline reliability'yi sağlamak için
• ML mühendisleri ve veri bilimciler — model input kalitesini korumak için
• SRE ve DevOps ekipleri — veri kaynaklı operasyonel olayları izlemek için
• Ürün ve iş birimleri — raporların ve KPI'ların güvenilirliğini sağlamak için

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Data Quality: Verinin doğruluğu, tamlığı, tutarlılığı, güncelliği ve uygun formatta olma durumu.
• Data Freshness: Verinin güncelliği; belirli bir dataset'in en son güncellendiği zaman ile beklenti arasındaki fark.
• Data Freshness SLO: Veri geçişinin belirli bir zaman penceresinde gerçekleşmesi beklentisi; örn. "her 15 dakikada bir güncellenmelidir".
• Data Drift & Concept Drift: Veri dağılımlarındaki veya hedef ilişkilerindeki zaman içinde meydana gelen değişimler.
• Monitoring vs Observability: Monitoring belirli metrikleri izler ve uyarı verir; observability, sistemin iç durumunu anlamak için yeterli sinyalin (logs, metrics, traces) sağlanmasıdır.

2.2 Terminoloji ve bileşenler

• Collector / Agent: Veriyi toplama noktasındaki bileşenler (ör. ingestion agent, Kafka connector).
• Metrics store: Monitoring için sayısal metriklerin saklandığı sistem (Prometheus, InfluxDB).
• Alerting & Notification: Bir koşul bozulduğunda bildirim üreten sistemler (PagerDuty, OpsGenie, Slack).
• Data profiler: Kolon istatistikleri, null oranları, benzersiz değer sayıları gibi profil bilgilerini üreten araçlar (Great Expectations, Deequ).

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE VERİ AKIŞI

3.1 Data monitoring mimarisi

Bir veri izleme sistemi tipik olarak şu katmanlardan oluşur: veri toplama (ingestion) katmanı, profil ve istatistik üretimi, metrik toplama ve saklama, anomali tespiti motoru, alerting/incident orchestration ve dashboard/insight layer. Bu katmanlar pipeline'a yerleştirilen 'instrumentation' ile entegre olur—ör. ETL jobları, Spark job'ları ve stream processor'lar her işlem sonunda profil verisi ve freshness bilgisi yayınlar.

3.2 Telemetri ve veri profili üretimi

Veri profili; kolon bazında ortalama, medyan, min/max, null oranı, benzersiz değer sayısı, value distribution histogram'ları ve örnek satırlardan oluşur. Profiling periyodik batch olarak veya ingestion sırasında streaming olarak yapılabilir. Önemli olan, profil değişikliklerinin geçmişe kıyasla nasıl farklılaştığını izleyebilmektir (change detection).

3.3 Metodolojiler: Passive vs Active monitoring

• Passive monitoring: Mevcut job çıktıları üzerinden metrik toplanır; ör. her ETL job'u bitişinde row count, duration ve error count raporlanır.
• Active monitoring: Sistem, belirli test veri setlerini periyodik olarak işleyerek doğruluk testi yapar; ör. canary dataset replay, synthetic data injection.

3.4 Anomali tespiti ve threshold tasarımı

Threshold bazlı uyarılar (örn. null oranı %5'in üstünde) basit ve anlaşılırdır ancak dağılım değişiklikleri veya mevsimsel varyasyonlarda çok fazla false positive üretebilir. Bu yüzden istatistiksel ya da ML tabanlı anomaly detection (z‑score, EWMA, isolation forest, Prophet‑based baseline) yöntemleri tercih edilir. Bu yaklaşımlar tarihsel davranışı öğrenir ve beklenen varyasyon aralığını sunar.

3.5 Lineage ve impact analysis entegrasyonu

Bir dataset'te anomali tespit edildiğinde, lineage bilgisi ile hangi downstream rapor veya model etkilendiği hızlıca belirlenebilir. Bu, incident triage sürecini kısaltır ve uygun önceliklendirme sağlar. Katalog ve orchestrator entegrasyonu (dbt, Airflow, Dagster) ile lineage otomatik olarak çekilmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — event pipeline izleme

Büyük ölçekli streaming sistemlerde event loss, schema drift ve watermark gecikmeleri izlenmelidir. Netflix benzeri yapılar, stream metrikleri (lag, throughput, error rate) ile beraber saha‑özgü metrikler (playback success rate, buffering rate) arasında korelasyon kurarak kök neden analizi yapar. Ayrıca canary stream'ler ile yeni ingestion kodlarının etkisi test edilir.

4.2 Uber — telemetri ve SLA monitoring

Uber'de veri gecikmesi doğrudan dispatch kararlarını etkileyebileceğinden Freshness SLO'ları, pipeline latency ve checkpoint süreleri sıkı izlenir. Alerts, otomatik rollback veya failover mekanizmaları tetikleyebilir.

4.3 E‑ticaret (Amazon/Stripe örnekleri)

Ödeme sistemlerinde transaction loss veya duplication kritik olduğundan, end‑to‑end reconciliation (source vs warehouse row counts) ve watermarking ile idempotency kontrolü uygulanır. Ayrıca fraud model input'larının kalitesiz olması, yanlış bloklama veya izinlere yol açabilir; bu nedenle model input monitoring şarttır.

4.4 OpenAI / ML pipeline monitoring

ML platformlarında feature freshness, label drift, data drift ve model performance metric'leri (AUC, accuracy, prediction distribution) eş zamanlı izlenmelidir. Modelın input larındaki sapmalar otomatik retraining veya alarm tetikleyebilir; ayrıca retraining pipeline'ları için canary validation kullanılmalı.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Hızlı müdahale: Otomatik uyarılar sayesinde veri sorunları daha erken tespit edilir ve düzeltilir.
• Güven: İş ve model ekipleri veri kalitesine güvenerek üretim kararları alır.
• Uyumluluk: Denetim için gerekli kanıtlar (freshness, lineage, access logs) otomatik sağlanır.

Sınırlamalar

• False positive/negative riski: Yetersiz modeller veya kötü eşik ayarları operasyonel yükü artırır.
• Instrumentation maliyeti: Her pipeline ve job'a monitoring eklemek geliştirme ve işletme maliyeti getirir.
• Data privacy & PII: Profiling ve sampling aşamasında hassas verinin açığa çıkmaması için masking gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Production kullanımına yönelik öneriler

• Observable by design: Her ETL/ELT job'ını, stream processor'ı ve model pipeline'ını telemetry ile doğrudan instrument edin—row counts, duration, error counts, input/output schema hashes.
• SLO belirleyin: Freshness, completeness ve accuracy için açık SLO'lar yazın; bunları SLAs ile hizalayın.
• Alerting runbook'ları: Her kritik alarm için triage adımlarını ve owner'ları içeren runbook'lar hazırlayın.
• Automated reconciliation: Source vs warehouse row count reconciliation job'ları periyodik olarak çalışsın; sapma durumunda otomatik ticket oluşturulsun.

7.2 Performans ve ölçek

• Metriklerin retention politikasını belirleyin: Yüksek çözünürlüklü metrikler kısa süre saklansın, aggregate metrikler daha uzun süre tutulabilir.
• Sampling stratejileri: Profiling için tam veri yerine akıllı sampling kullanarak maliyeti düşürün ancak temsiliyetlikten ödün vermeyin.
• Distributed monitoring: Büyük organizasyonlarda monitoring pipeline'ı da ölçeklenebilir olmalıdır—Kafka/stream ile metrik toplama pratikleri kullanın.

7.3 Güvenlik ve veri mahremiyeti

• PII masking: Profiling aşamasında hassas alanlar maskelenmeli veya sadece istatistiksel özetler toplanmalıdır.
• Access control: Metrik ve profiling dashboard'larına erişim RBAC ile sınırlandırılmalı.
• Audit logging: Hangi kullanıcı hangi datayı inceledi, hangi alarm tetiklendi gibi kayıtlar saklanmalı.

8. SIK YAPILAN HATALAR

• Monitoring'i geç devreye almak: Veri monitoring'i yıllar sonra eklemek maliyetlidir; baştan instrument etmek daha verimlidir.
• Tekrar eden false alarm'lere müdahale etmemek: Alarm tuning ve suppression politikaları olmadan ekipler alarm yorgunluğu yaşar.
• Lineage entegrasyonunu atlamak: Sorun oluştuğunda hangi raporların etkilendiğini bilmemek triage süresini uzatır.
• Model performansını ayrı izlememek: Modelın online performansı ve input feature kalitesi ayrı metrik olarak izlenmelidir.

9. GELECEK TRENDLER

9.1 AI‑driven monitoring

AI tabanlı izleme araçları, anomali tespitinde bağlamsal korelasyon sağlayacak ve root cause tahmini yapabilecek. Bu araçlar, telemetriyi hem altyapı hem de iş bağlamında analiz ederek öneri veya otomatik remediations sunacak.

9.2 Data contracts ve automatic verification

Schema registry, data contracts ve contract testing (PR ile şema değişikliği ön kontrolü) yaygınlaşacak. Bu sayede ship öncesi veri kalite ihlalleri engellenebilecek.

9.3 Observability standardization ve OpenTelemetry for data

OpenTelemetry benzeri projelerin veriye özgü metrik ve trace standardları geliştirilecek; böylece veri boru hatları için vendor‑agnostic observability sağlanacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Data monitoring'e nereden başlamalıyım?

   Start small: kritik veri setleri (financials, transactions, core metrics) ile pilot başlatın ve temel metrikler (row count, freshness, null rate) izlemeye başlayın.

2. 2. Hangi araçlar kullanılır?

   Great Expectations, Deequ, Soda, Monte Carlo, Databand, Prometheus, Grafana, PagerDuty ve cloud provider monitoring araçları yaygın kullanılır. Seçim organizasyonun ihtiyaçlarına bağlıdır.

3. 3. Threshold mü yoksa ML tabanlı anomali tespiti mi?

   İkisi de: basit uyarılar için threshold, adaptif davranış ve düşük false positive için ML tabanlı modeller önerilir.

4. 4. Freshness SLO nasıl belirlenir?

   İş ihtiyaçlarına göre: raporlama için hourly ok olabilir; gerçek zamanlı kararlar için saniye/dakika SLO'ları belirleyin. SLA'ları iş ekipleriyle birlikte tanımlayın.

5. 5. Monitoring maliyetlerini nasıl kontrol ederim?

   Sampling, aggregation, metrik retention politikasını uygula; yüksek frekanslı raw metrikleri kısa süre tut ve daily/weekly aggregated metrikleri uzun süre sakla.

6. 6. Lineage neden kritik?

   Bir veri sorunu çıktığında hangi dashboard ve modellerin etkilendiğini hızlıca bulmak için lineage olmazsa olmazdır.

7. 7. Model drift tespitinde hangi metriklere bakmalıyım?

   Input feature distribution, prediction distribution, label distribution (varsa), model performance metric'leri ve calibration istatistikleri izlenmelidir.

8. 8. Veri monitoring ekibi nasıl organize edilmeli?

   Cross‑functional bir ekip: veri mühendisleri, SRE/DevOps, veri bilimciler ve domain owner'lar birlikte çalışmalı; SLA/SLO ve runbook'lar paylaşılmalıdır.

Anahtar Kavramlar

• Freshness: Verinin güncel olup olmadığının ölçüsü.
• Completeness: Beklenen kolon/satırların varlığı.
• Drift: Veri dağılımının veya hedef ilişkilerinin zaman içinde değişmesi.
• Profiling: Veri setinin istatistiksel özetinin çıkarılması.
• Reconciliation: Kaynak ve hedef sistemler arasındaki veri tutarlılığının karşılaştırılması.

Öğrenme Yol Haritası

1. 0–1 ay: SQL, temel istatistikler, veri modelleme ve ETL/ELT kavramlarını öğrenin.
2. 1–3 ay: Great Expectations/Deequ gibi araçlarla profiling ve basit data quality checks oluşturun; pipeline'ları instrument edin.
3. 3–6 ay: Anomali tespit yöntemleri (z‑score, EWMA, isolation forest), lineage ve orchestration entegrasyonları üzerinde uygulama yapın.
4. 6–12 ay: SLO tanımlama, alerting ve runbook otomasyonu, model drift monitoring ve production-grade monitoring stack kurma deneyimi kazanın.