1. Giriş

Veri, yapay zekânın yakıtıdır. Ancak verinin toplanması, temizlenmesi, dönüştürülmesi ve modele güvenilir şekilde sunulması çok sayıda teknik zorluk yaratır. AI sistemlerinin üretimde güvenilir biçimde çalışabilmesi için tasarlanmış veri pipeline'ları (data pipelines) yalnızca ETL süreçleri değildir; aynı zamanda özellik (feature) tutarlılığı, gecikme gereksinimleri, veri kalitesi, gizlilik ve izlenebilirlik (lineage) gibi gereksinimleri karşılamalıdır.

Bu makale, mühendis ve mimar bakış açısıyla AI için veri pipeline'larını detaylandırır. Amaç; ekiplerin gerçek dünya uygulamaları için doğru mimari kararlarını vermesine yardımcı olacak, teknik derinlik ve pratik öneriler sunan bir referans oluşturmak. İçerik veri mühendislerinden MLOps ekiplerine, veri bilimcilere ve teknik yöneticilere yöneliktir.

Bu konu neden bugün önemli? Çünkü LLM'ler, edge inferencing ve gerçek zamanlı karar sistemleri veri gecikmesine ve kalitesine karşı hassastır. Yanlış veya hatalı veri pipeline'ları model performansını bozar; drift, bias veya işletme riskleri doğurur. Doğru tasarım ise model güvenilirliğini, yeniden üretilebilirliği ve operasyonel verimliliği artırır.

2. Kavramsal Temeller

2.1 Temel Kavramlar

• Data Pipeline: Veri kaynaklarından başlayıp işlenmiş veriyi hedef sistemlere (feature store, model training, analytics) taşıyan otomatikleştirilmiş iş akışı.
• ETL / ELT: Extract‑Transform‑Load (önceden dönüştürme) veya Extract‑Load‑Transform (sahneleme sonrası dönüştürme) yaklaşımları.
• Feature Store: Training ve serving arasındaki tutarlılığı sağlayan, feature'ları versiyonlayan ve düşük gecikmeli lookup destekleyen katman.
• Data Lineage: Bir feature'ın veya dataset'in kökeni, değişiklik geçmişi ve bağımlılıklarını gösteren izleme.
• Data Contracts: Veri sağlayıcılar ile tüketiciler arasındaki format, semantik ve SLA garantilerini tanımlayan sözleşmeler.

2.2 Mimari Bileşenler

• Veri Kaynakları: DB, event stream (Kafka/Pulsar), sensörler, loglar, 3rd‑party API'ler.
• Ingestion Katmanı: Kafka, Pub/Sub, Kinesis, log collector'lar.
• Storage: Data lake (S3/Blob), OLTP/OLAP, columnar store (Parquet), lakehouse (Delta, Iceberg).
• Processing: Batch (Spark), stream (Flink, Beam), microbatch yaklaşımları.
• Feature Store & Serving: Feast, Hopsworks veya özel çözümler.
• Orchestration: Airflow, Dagster, Kubeflow Pipelines, Argo Workflows.
• Monitoring & Observability: Prometheus, Grafana, WhyLogs, Evidently, data quality tooling (Great Expectations).

3. Nasıl Çalışır?

3.1 Veri Akışı ve Dönüşümler

AI pipeline'ları genelde şu adımlar etrafında şekillenir:

1. Collect: Ham verinin toplanması: event stream, database change capture (CDC), batch exports.
2. Ingest: Veri akışının güvenli ve dayanıklı bir aracıya (Kafka, Pulsar) gönderilmesi.
3. Store: Ham verinin data lake'e yazılması (genellikle sıkıştırılmış, kolon formatında Parquet/ORC).
4. Transform: Temizlik, normalizasyon, join'ler ve feature extraction; batch veya streaming olarak uygulanır.
5. Serve: Son feature'ların model training veya online serving için feature store'a veya cache'e yazılması.
6. Monitor: Data quality, schema değişiklikleri, latency, data drift, cardinality değişimleri izlenir.

3.2 Batch vs Stream: Hangisini Ne Zaman Seçmeli?

Seçim üç parametre etrafında yapılır: gecikme (latency) gereksinimi, veri hacmi ve işlem kompleksliği.

• Batch: Büyük veri işleme, offline training, dönüşümlü ve tutarlı işlemler için uygundur. Maliyet etkin ve hataya dayanıklıdır.
• Stream: Gerçek zamanlı veya near‑real time feature üretimi, anomali tespiti ve düşük gecikme gerektiren sistemler için gereklidir. Ancak daha karmaşık hata yönetimi ve stateful processing gerektirir.
• Hybrid: Çok yaygın. Offline batch ile feature'lar hazırlanır; kritik özellikler için stream path paralel çalışır.

3.3 Feature Engineering ve Tutarlılık

Training ve serving ortamları arasındaki feature tutarsızlığı (training/serving skew) AI sistemlerinin en sık karşılaştığı hatalardan biridir. Bu yüzden:

• Feature kodu tek bir yerde — tercihen feature store pipeline'ında — olmalı ve hem training hem serving bu kodu kullanmalı.
• Feature'lar versiyonlanmalı; hangi modelin hangi feature versiyonuyla eğitildiği kayıtlı olmalı.
• Online lookup latency hedefleri belirlenmeli; cache (Redis) veya projection'lar düşünülmelidir.

3.4 Data Contracts ve Schema Yönetimi

Veri sağlayıcılarla veri tüketicilerinin uyumlu çalışması için schema registry (Avro/Protobuf) ve data contracts kullanılmalı. Breaking change’ler otomatik olarak pipeline'ları bozabileceği için schema evrimi kontrollü yapılmalı ve backward/forward compatibility testleri CI süreçlerine entegre edilmelidir.

3.5 Veri Kalitesi, Test ve İzlenebilirlik

Veri kalite kontrolleri pipeline'ın erken adımlarında çalıştırılmalı. Örnek kontroller:

• Missing value oranı, null imalar
• Value distribution ve outlier tespiti
• Referential integrity ve schema assertions

Testler CI/CD'e eklenmeli (unit tests for transforms, integration tests for pipelines). Ayrıca lineage ve audit log'ları saklanmalıdır.

4. Gerçek Dünya Kullanımları

4.1 Öneri Sistemleri

Öneri motorları yüksek hacimli kullanıcı‑item etkileşimleri ile çalışır. Pipeline tipik olarak clickstream ingestion, sessionization, embedding generation, offline training ve online serving aşamalarına sahiptir. Embedding'ler periyotlarla yeniden hesaplanır; cold start problemlerini azaltmak için hybrid content‑based stratejiler uygulanır.

4.2 Finans ve Fraud Detection

Fraud detection sistemleri düşük false positive ile yüksek recall gerektirir. Real‑time feature hesaplama, risk skorlaması ve insan‑in‑the‑loop inceleme süreçleri pipeline'lara entegre edilmelidir. Ayrıca explainability ve audit logları regülasyon için kritiktir.

4.3 Sağlık ve Medikal Veri

Sağlık verisi hassasiyeti nedeniyle pipeline'lar privacy‑by‑design yaklaşımıyla kurulmalıdır. Federated learning veya differential privacy teknikleri veri paylaşımını minimize ederken modellerin öğrenmesine izin verir. Ayrıca veri lineage ve hasta onay süreçleri sıkı tutulmalıdır.

4.4 Edge ve IoT Senaryoları

Edge cihazlardan gelen sensör verileri için lokal preprocess, compression ve batch upload stratejileri uygulanır. Kritik gerçek‑zaman uyarıları için stream path kullanılır; uzun dönem eğitim için aggregated data lake'e gönderilir.

5. Avantajlar ve Sınırlamalar

Avantajlar

• Scale: Doğru planlanmış pipeline'lar yüksek veri hacimlerini verimli işlemenizi sağlar.
• Reproducibility: Versiyonlanan veriler ve feature'larla modeller tekrar üretilebilir.
• Operationalization: Otomatik retraining ve drift detection ile model ömrü uzatılabilir.

Sınırlamalar

• Yüksek başlangıç maliyeti: Mühendislik ve altyapı yatırımı gerektirir.
• Karmaşıklık: Stream processing, state management ve fault tolerance tasarımı zorlayıcıdır.
• Gizlilik ve uyumluluk: Kişisel veri içeren pipeline'larda ekstra süreçler eklenmelidir.

6. Alternatifler ve Karşılaştırma

7. En İyi Pratikler

Production Kullanımı

• Veri sözleşmelerini (data contracts) açıkça tanımlayın ve CI ile doğrulayın.
• Feature'ları versiyonlayın ve model registry ile bağlayın; hangi modelin hangi feature versiyonunu kullandığını kayıt altına alın.
• Retrain tetiklerini iş KPI'larına göre tanımlayın (drift, KPI degradation).

Performans Optimizasyonu

• Data partitioning, partition pruning ve columnar format (Parquet) kullanarak I/O maliyetlerini azaltın.
• Streaming state backend (RocksDB) ve checkpointing ile fault tolerance sağlayın.
• Cache ve precomputed projection'lar ile online lookup latency'yi düşürün.

Güvenlik

• PII verileri tokenize/anonimize edin; erişim politikalarını (RBAC) sıkı uygulayın.
• Encryption at rest ve in transit, KMS ve audit log kullanın.

Observability

• Data quality metriklerini (null rate, uniqueness, distribution) toplayın ve alertleyin.
• Lineage, provenance ve dataset snapshot'larını saklayın.

8. Sık Yapılan Hatalar

• Tek katmana güvenmek: Sadece batch veya sadece stream ile çözüm üretmeye çalışmak genellikle yetersiz kalır.
• Feature duplication: Aynı feature'ın farklı kod yollarıyla yaratılması tutarsızlığa neden olur; merkezi feature logic şarttır.
• Test eksikliği: Data contracts ve transform testing yapılmadan deploy edilen pipeline'lar prod hatalarına yol açar.
• Monitoring unutulması: Pipeline düzgün çalışıyor görünse bile data drift sessizce performansı düşürebilir.

9. Gelecek Trendler

1. Lakehouse ve veri mesh: Delta Lake/Iceberg tabanlı çözümler veri erişimini kolaylaştıracak; veri mesh organizasyonel ölçeklenebilirlik sağlayacak.
2. Automated data contracts: Schema değişikliklerini otomatik test eden ve rollback öneren sistemler yaygınlaşacak.
3. Privacy‑first pipelines: Federated pipelines ve secure enclaves ile veri paylaşımı sınırlandırılacak.
4. AI‑assisted data engineering: Veri kalitesi sorunlarını otomatik öneren ve düzelten araçlar ortaya çıkacak.

Ek Bölümler

Sık Sorulan Sorular (FAQ)

1. Data pipeline ile feature store arasındaki fark nedir?

   Data pipeline ham veriyi toplar ve dönüştürür; feature store ise hazır feature'ları training ve serving için düzenler, versiyonlar ve düşük gecikmeli erişim sağlar.

2. Batch mi yoksa stream mi tercih etmeliyim?

   İhtiyaçlarınıza göre hybrid bir yaklaşım genelde en uygun çözümdür. Gerçek zamanlı karar gerekiyorsa stream, büyük offline işler için batch uygundur.

3. Veri drift nasıl tespit edilir?

   Feature distribution monitoring, label‑prediction correlation ve model KPI'ları ile drift tespit edilir; Evidently, WhyLogs gibi araçlar yardımcı olur.

4. Pipeline testlerini nasıl otomatikleştiririm?

   Unit testler (transform'lar için), integration testler (küçük data snapshot'ları) ve contract tests CI'e eklenmelidir.

5. Feature versiyonlaması neden önemli?

   Model reproducibility ve rollback için hangi veri ve feature versiyonunun kullanıldığını bilmek kritiktir.

6. PII verisini pipeline'da nasıl yönetmeliyim?

   Tokenization, anonymization, erişim kontrolleri ve audit log'ları kullanın; KMS ve secure storage tavsiye edilir.

7. Data contracts nasıl uygulanır?

   Schema registry (Avro/Protobuf), contract tests ve SLA'lar ile sağlayıcı/ tüketici tarafı uyumu sağlanır.

8. Pipeline için hangi orkestratör kullanılmalı?

   Airflow veya Dagster batch işlerde, Flink/Beam stream işlerde; Kubeflow Pipelines veya Argo Workflows MLOps odaklı orkestrasyon için uygundur.

Anahtar Kavramlar

Data Lineage

Verinin kaynağından son tüketimine kadar izlenebilirliğini sağlayan kayıtlar.

Feature Store

Training ve serving için consistent feature sunan, versiyonlayan katman.

Schema Registry

Veri şemalarını saklayan ve evolüsyon kontrolü yapan servis.

Drift Detection

Veri veya model performansındaki sapmaları tespit eden mekanizma.

Öğrenme Yol Haritası

1. Temel: Python, SQL, veri mühendisliği temelleri.
2. Storage & Formats: S3, Parquet, Delta Lake/Iceberg öğrenin.
3. Processing: Spark, Flink, Beam ve stream/batch paradigmasını anlayın.
4. Feature Store: Feast veya benzeri ile çalışın; online lookup ve latency testleri yapın.
5. Orchestration: Airflow, Dagster, Argo Workflows deneyin.
6. Monitoring: Prometheus/Grafana, Evidently, WhyLogs ile data quality izleme kurun.
7. Pratik Proje: Gerçek veriyle end‑to‑end pipeline inşa edin — ingestion, transform, feature store, training, deploy ve monitor.