1. Giriş

Veri mühendisliği (data engineering), yapay zekâ uygulamalarının başarısında merkezi bir rol oynar. Doğru, temiz ve uygun biçimde sunulmuş veri olmadan modeller güvenilir sonuçlar üretemez; aynı şekilde ölçeklenebilir, düşük gecikmeli ve izlenebilir veri boru hattı olmadan gerçek dünya uygulamalarında sürdürülebilirlik sağlanamaz. AI Data Engineering —yani yapay zekâ odaklı veri mühendisliği— veri toplama, dönüştürme, depolama, servis ve izleme adımlarını AI gereksinimlerine göre yeniden düşünmeyi gerektirir.

Bugün bu konunun neden kritik olduğunu birkaç başlıkla özetleyebiliriz: LLM ve büyük görüntü modelleri daha fazla veri gerektiriyor; gerçek zamanlı uygulamalar düşük gecikme talep ediyor; gizlilik ve regülasyonlar veri işleme yaklaşımlarını etkiliyor. Ayrıca MLOps pratiklerinin yaygınlaşması, veri pipeline'larının tekrarlanabilir, otomatik ve denetlenebilir olmasını zorunlu kılıyor. Bu makale, mühendis, mimar ve teknik lider bakış açısıyla AI Data Engineering'i derinlemesine ele alacak; hem kavramsal hem de pratik düzeyde yol gösterici olacak.

Aşağıdaki sorulara cevap bulacaksınız: AI için veri pipeline'ı nasıl tasarlanır? Hangi teknolojiler hangi senaryolarda avantaj sağlar? Feature store, data contracts ve lineage neden önemlidir? Gerçek dünya örnekleri hangi mimarileri kullanır?

2. Kavramsal Temeller

2.1 Temel Tanımlar

• AI Data Engineering: Yapay zekâ iş yükleri için veri toplanması, temizlenmesi, dönüştürülmesi, depolanması, servis edilmesi ve izlenmesi süreçlerini kapsayan disiplin.
• Data Pipeline (Veri Boru Hattı): Ham veriyi kaynaklardan alıp hedef sistemlere (feature store, training, analytics) taşıyan otomatik iş akışı.
• Feature Store: Model eğitim ve gerçek zamanlı servis için tutarlı, versiyonlanmış ve düşük gecikmeli feature erişimi sağlayan sistem.
• ETL / ELT: Verinin çıkarılması, dönüştürülmesi ve yüklenmesi yaklaşımları; ELT modern data lake senaryolarında yaygındır.
• Data Lineage: Veri öğesinin kaynağından tüketimine kadar izlenebilmesi; audit ve reproducibility için elzemdir.
• Data Contract: Veri sağlayıcı ile tüketici arasında şema, semantik ve SLA beklentilerini tanımlayan anlaşma.

2.2 Temel Bileşenler

AI odaklı veri mimarisi tipik olarak aşağıdaki bileşenlerden oluşur:

• Ingestion Katmanı: Kafka, Pulsar, Kinesis veya batch yüklemeler (S3, gs://) ile ham verinin toplanması.
• Storage: Data lake (S3/Blob), lakehouse (Delta Lake, Iceberg), columnar format (Parquet/ORC) ve OLTP/OLAP çözümleri.
• Processing: Batch (Spark), stream (Flink, Beam), micro‑batch veya serverless dönüşümler.
• Feature Store & Serving: Feast, Hopsworks veya özel API/Redis tabanlı online lookup çözümleri.
• Orchestration & Workflow: Airflow, Dagster, Argo Workflows, Kubeflow Pipelines.
• Monitoring & Data Quality: Prometheus/Grafana, Evidently, WhyLogs, Great Expectations.

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

3.1 Sistem Mimarisi — Veri Akışı

AI veri pipeline'ları genelde dört ana katmanda tasarlanır: ingestion, raw storage, processing/feature generation ve serving. Bu katmanların her biri farklı SLA'lar, depolama formatları ve veri koruma gereksinimleri içerir.

Ingestion

Veri üreticiler (loglar, sensörler, uygulama event'leri, 3rd party API'ler) düşük gecikmeli stream veya dönemsel batch ile ingestion sistemine gönderilir. Event streaming Kafka veya Pulsar üzerinde tutulurken, kritik ham veriler immutable olarak data lake'e saklanır (raw zone).

Raw Storage

Ham verinin saklandığı katmandır. Parquet/ORC formatında, partitioning ve sıkıştırma kullanılarak I/O maliyetleri optimize edilir. Data lake aynı zamanda yeniden eğitim, offline analiz ve audit amaçları için kaynak sağlar.

Processing & Feature Generation

Veri transformları burada yapılır. Batch transformlar büyük toplu işlemler için Spark/Databricks tipik iken, düşük gecikme gerektiren özellikler Flink/Beam tabanlı stream hesaplamayla online olarak üretilebilir. Önemli nokta: Kullanılan transform kodu hem training hem serving için tutarlı olmalı — aksi halde training/serving skew oluşur.

Serving

Feature store offline feature'ları eğitim için, online store ise düşük gecikmeli lookup'ları servis etmek için kullanılır. Online servisler genelde Redis veya DynamoDB gibi hızlı key‑value store'lar ile desteklenir; cache ve projection'lar eklenerek latency daha da düşürülebilir.

3.2 Batch vs Stream Mimarisi

Hangi modele karar vermek için gecikme, veri hacmi ve state yönetimi gereksinimleri değerlendirilir. Özet karar kriterleri:

• Batch: Eğitim, toplu raporlama, backfill işlemleri için uygundur. Basit hata yönetimi ve deterministik sonuç sağlar.
• Stream: Gerçek zamanlı alarmlar, düşük gecikmeli inference feature'ları, anomali tespiti için gereklidir. Ancak stateful processing, exactly‑once semantics ve checkpoint yönetimi karmaşıklık getirir.
• Hybrid: Hem batch hem streaming kombinasyonu en pratik çözümdür: kritik feature'lar online olarak üretilirken, diğerleri offline batch ile hazırlanır.

3.3 Veri Kalitesi ve Testler

Veri kalite kontrolleri ve testler pipeline'ın erken etaplarında uygulanmalıdır. Örnek kontroller:

• Schema assertions (Avro/Protobuf/JSON Schema)
• Null ve missing value oranı takibi
• Value range ve distribution testleri
• Referential integrity ve duplicate detection

Bu testler CI/CD hatlarına bağlanarak her yeni veri kaynağı veya dönüşüm değişikliğinde otomatik çalıştırılmalıdır.

3.4 Lineage, Metadata ve Data Contracts

Lineage, hata ayıklama, regülatif uyum ve reproducibility için zorunludur. Metadata (dataset versiyonu, üretim zamanı, transform hash) saklanmalı ve model registry ile ilişkilendirilmelidir. Data contracts ise kaynak ve tüketici arasındaki beklentileri otomatik olarak doğrulayan testler içerir.

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

4.1 Netflix — İçerik ve Öneri Pipeline'ları

Netflix gibi içerik platformları için veri pipeline'ları clickstream, playback event'leri ve kullanıcı metadata'sını yüksek hacimlerde toplar. Offline batch job'lar embedding ve candidate generation için büyük veri işlemleri yaparken, online feature'lar rekomenasyonların gerçek zamanlı olarak yenilenmesi için servis edilir. A/B testleri model değişikliklerinin kullanıcı davranışına etkisini ölçer.

4.2 Uber — Gerçek Zamanlı Tahminler

Uber gibi gerçek‑zamanlı karar gerektiren sistemlerde stream processing, düşük gecikme feature servisleri ve robust backpressure stratejileri kritik rol oynar. Driver ve rider matching, fiyatlama ve ETA tahminleri için veri pipeline'ları milisaniyeler düzeyinde veri tedarik etmelidir.

4.3 Amazon — Öneri ve Envanter Pipeline'ları

Amazon ölçeği, veri tutarlılığı, embedding güncellemeleri ve katalog sync senaryoları gerektirir. Feature store, embedding store ve hızlı online lookup katmanları entegre çalışır; ayrıca backfill ve retraining süreçleri otomatikleştirilmiştir.

4.4 OpenAI / LLM Veri İşleme

LLM eğitimi ve fine‑tuning için veri pipeline'ları çok büyük metin korpuslarını işler, deduplication, dedup‑sharding, prompt/response pairing ve human feedback etiketlemelerini yönetir. Veri temizleme (toxic content filtering, provenance tracking) ve dataset versiyonlama LLM için temel gereksinimlerdir.

4.5 Stripe — Fraud Detection

Stripe benzeri finansal servislerde gerçek‑zamanlı features, ensemble modeller ve insan onaylı workflow'lar bir arada çalışır. Data lineage ve explainability gereksinimleri regülatif uyum için önceliklidir.

5. Avantajlar ve Sınırlamalar

Avantajlar

• Model performansı: Doğru feature'lar ve temiz veri doğrudan model başarısını artırır.
• Operasyonel verim: Otomatik pipeline'lar insan müdahalesini azaltır ve hata riskini düşürür.
• Uyumluluk ve izlenebilirlik: Lineage ve metadata ile audit süreçleri desteklenir.

Sınırlamalar

• Yüksek mühendislik maliyeti: Doğru pipeline kurmak zaman ve kaynak gerektirir.
• Karmaşıklık: Stream state, exactly‑once semantics ve schema evrimi gibi konular operasyonu zorlaştırır.
• Gizlilik riskleri: PII içeren verinin yönetimi ek süreçler ve maliyetler getirir.

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

7. En İyi Pratikler

Production Kullanımı

• SLA ve SLO tanımları yapın: ingestion latency, feature lookup latency, freshness hedefleri belirleyin.
• Veri sözleşmeleri (data contracts) ile sağlayıcı‑tüketici uyumunu otomatik test edin.
• Feature versiyonlaması ve model‑feature bağını zorunlu kılın; geri dönüş (rollback) senaryoları planlayın.

Performans Optimizasyonu

• Veri partitioning ve partition pruning ile I/O azaltın.
• Columnar storage (Parquet) ve sıkıştırma kullanın; sorgu optimizasyonu için ordere dikkat edin.
• Online lookup için cache stratejileri uygulayın (Redis, DAX, in‑memory projections).

Güvenlik

• PII'yı pipeline'a girmeden önce tokenize veya anonymize edin.
• Erişim kontrollerini (RBAC), encryption ve KMS ile anahtar yönetimini uygulayın.

Observability

• Data quality metriklerini (null rate, cardinality, distribution) toplayın ve uyarılar kurun.
• Lineage ve provenance kayıtlarını otomatik saklayın; incident root cause analysis için hazır bulundurun.

8. Sık Yapılan Hatalar

• Feature logic farklı yerlerde implement edilir: Training ve serving için ayrı kod yolları tutarsızlığa yol açar.
• Schema değişiklikleri kontrolsüz uygulanır: Backwards/forwards uyumluluk testleri olmadan schema evrimi prod bozulmalarına neden olur.
• Monitoring eksikliği: Data drift veya missing data sessizce model performansını bozar.
• Gizlilik süreçlerinin erken düşünülmemesi: PII sonrası ek maliyet ve uyum sorunları ortaya çıkar.

9. Gelecek Trendler

1. Data Mesh & Federated Architectures: Organizasyon içinde veri sahipliğinin dağılması ve domain odaklı veri ürünleri artacak.
2. Lakehouse olgunlaşması: Delta Lake, Iceberg ve benzeri teknolojiler veri yönetimini kolaylaştıracak.
3. AI‑assisted Data Engineering: Veri kalitesi sorunlarını otomatik tespit eden ve öneri getiren araçlar yaygınlaşacak.
4. Privacy‑first pipelines: Differential privacy ve secure enclaves ile PII riskleri minimize edilecek.

Ek Bölümler

Sık Sorulan Sorular (FAQ)

1. AI için veri pipeline'ı neden farklı olmalı?

   AI uygulamaları training/serving tutarlılığı, feature freshness ve lineage gibi özel gereksinimler taşır; standart ETL süreçleri bu gereksinimleri karşılamayabilir.

2. Feature store şart mı?

   Küçük projelerde basit cache'ler yetebilir; ancak üretimde reproducibility ve online lookup gereksinimi varsa feature store güçlü bir yatırım dönüşü sağlar.

3. Batch mi stream mi daha pahalıdır?

   Maliyet, kullanım senaryosuna göre değişir. Stream sürekli kaynak tüketirken, batch yüksek yoğunluklu işlerde daha düşük saatlik maliyet sunabilir. Genelde hybrid tercih edilir.

4. Data contracts nasıl uygulanır?

   Schema registry ile şema versiyonlama, consumer‑driven contract testleri ve CI entegrasyonu ile uygulanır.

5. Lineage için hangi araçlar kullanılabilir?

   OpenLineage, Marquez, Amundsen gibi open source araçlar ile metadata ve lineage toplayabilirsiniz.

6. Veri gizliliğini nasıl sağlarım?

   Tokenization, anonymization, access control, VPC/Security Group ve KMS kullanarak veri erişimini ve saklamayı güvenli hale getirin.

7. Veri kalitesi uyarıları nasıl kurulmalı?

   Evidently, Great Expectations veya custom job'lar ile threshold‑based veya model‑based uyarılar oluşturun.

8. Nasıl başlarım?

   Öncelikle mevcut veri kaynaklarınızı, gecikme gereksinimlerinizi ve iş KPI'larınızı tanımlayın. Basit bir ingestion→raw storage→batch transform pipeline ile başlayın, kritik feature'lar için online path ekleyin ve observability ile genişletin.

Anahtar Kavramlar

Feature Store

Training ve serving için tutarlı feature'ları sağlayan sistem; versiyonlama ve online lookup sağlar.

Data Lineage

Verinin kaynağından tüketimine kadar izlenebilirliğini sağlayan metadata.

Schema Registry

Veri şemalarını ve versiyonlarını yöneten servis (Avro/Protobuf/JSON Schema).

Lakehouse

Data lake ile data warehouse özelliklerini birleştiren mimari (Delta/Iceberg).

Öğrenme Yol Haritası

1. Temel: SQL, Python, veri yapılarına hakimiyet.
2. Storage & Formats: Parquet, Delta Lake, Iceberg ve S3/Blob yapılarını öğrenin.
3. Processing: Spark (batch), Flink/Beam (stream) ile pratik yapın.
4. Orchestration: Airflow, Dagster, Argo Workflows deneyin; basit DAG'lar yazın.
5. Feature Store & Serving: Feast veya benzer çözümlerle online/offline lookup senaryoları uygulayın.
6. Monitoring & Quality: Great Expectations, Evidently, WhyLogs ile data quality testleri kurun.
7. Pratik Proje: End‑to‑end pipeline oluşturun — ingestion, transform, feature store, model training, deploy ve monitoring.