1. GİRİŞ

Verinin üretildiği yerde anlamlı içgörü üretmek, iş süreçlerine entegre etmek ve güvenilir veri ürünleri sunmak günümüzün ölçekli dijital işletmeleri için temel rekabet avantajıdır. Data platformlar, ham veriyi toplayan, işleyen, depolayan, dönüştüren ve tüketicilere sunan sistemlerin birleşimidir. Bu makalede gerçek dünya örnekleri (case studies) üzerinden mimari tercihlerin arkasındaki gerekçeleri, karşılaşılan operasyonel zorlukları ve pratikte işe yarayan çözümleri inceleyeceğiz.

Neden bugün önemli?

• Gerçek zamanlılık talepleri arttı; düşük gecikmeli içgörüler iş akışlarını otomatikleştiriyor.
• ML modellerinin üretime alınması veri platformunun güvenilirliğine dayanıyor.
• Regülasyon ve gizlilik gereksinimleri veri yönetişimini zorunlu kıldı.

Kimler için önemli?

• Veri mühendisleri, platform mühendisleri ve MLOps ekipleri
• Veri bilimciler ve analistler
• Teknik liderler ve CTO'lar

2. KAVRAMSAL TEMELLER

2.1 Data platform bileşenleri

• Ingestion: Telemetry, uygulama event'leri, CDC, batch extracts
• Storage: Object store (S3/ADLS/GCS), data lake/table format (Delta/Iceberg/Hudi), data warehouse
• Processing: Batch (Spark) ve stream (Flink, Kafka Streams, Spark Structured Streaming)
• Orchestration: Airflow, Dagster, Prefect
• Serving: OLAP (Snowflake/BigQuery), feature store, low latency stores (Redis, Cassandra)

2.2 Temel terminoloji

• Event stream: Zaman içinde sıralı, akış halinde gelen veri
• Lakehouse: Lake + Warehouse özelliklerini birleştiren mimari
• CDC: Change Data Capture — veritabanı değişikliklerinin yakalanması
• Feature store: ML için online/offline feature yönetimi

3. NASIL ÇALIŞIR? — MİMARİLERE GENEL BAKIŞ

3.1 Tipik veri akışı

Genel olarak veri şu adımlardan geçer: üretici → ingestion katmanı → broker/queue (Kafka/Pulsar) → processing engine → curated storage (lakehouse/warehouse) → serving/consumers. Orkestrasyon, metadata ve observability bu akışın her noktasında kritik rol oynar.

3.2 Ölçek ve SLA kararları

Tasarım kararları SLA'lara (freshness, latency), veri hacmine, okuma/yazma paternlerine ve maliyet hedeflerine göre verilir. Örneğin gerçek zamanlı scoring isteyen bir sistemde stream processing ve online store tercih edilir; toplu raporlama için ELT + data warehouse daha uygun olur.

4. GERÇEK DÜNYA CASE STUDIES

4.1 Netflix — Telemetry, recommendation ve telemetri tabanlı kalite kontrol

Problemin tanımı

Netflix büyük ölçekte kullanıcı etkileşimlerini (playback, buffering, bitrate değişimleri) toplar. Amaç: gerçek zamanlı kalite izleme, A/B testleri ve recommendation pipeline'larını beslemek.

Mimari özet

• Ingestion: Client SDK'lar üzerinden events Kafka veya benzeri bir event bus'a gönderilir.
• Processing: Hem stream processing (real‑time metrics, anomaly detection) hem de batch processing (daily aggregations, training datasets) kullanılır.
• Storage: Ham veriler obje depolamada tutulur; curated datasets lakehouse ve warehouse'a aktarılır.
• Serving: Recommender sistemleri ve dashboards için OLAP + feature store kombinasyonu.

Öğrenilen dersler

• Client tarafı SDK'larının hafif olması, sampling ve backpressure yönetimini kolaylaştırır.
• Event schema'larını version'lamak ve contract testleri uygulamak kritik; yanlış schema production'ı kırar.
• Realtime anomaly detection için düşük gecikmeli aggregation ve iyi tanımlanmış watermarking gerekir.

4.2 Uber — Gerçek zamanlı yerleşim, routing ve konumsal analitik

Problemin tanımı

Uber, yüz milyonlarca konum, telemetri ve yolculuk event'ini düşük gecikmede işleyerek dispatch kararları, surge pricing ve heatmap'ler üretir.

Mimari özet

• Event ingestion: Yüksek hacimli telemetri Kafka benzeri sistemlerle ingested edilir.
• Stream processing: Stateful computations (sessionization, windowed aggregates) Flink benzeri motorlarla yapılır.
• State store: RocksDB veya benzeri embedded state store ile dağıtık state yönetimi.
• Serving: Low latency cache'ler, geospatial index'ler ve ML scoring endpoints.

Öğrenilen dersler

• Geospatial veri işleme özel optimizasyonlar gerektirir: tiling, geohash ve spatial index kullanımı performansı artırır.
• State büyüklüğü kontrolü (TTL, compaction) olmazsa state explosion maliyeti yükseltir.
• Topology tasarımında partition key seçimleri hotspot'ları önlemek için kritik önemdedir.

4.3 Amazon — Katalog, inventory ve reconciliation

Problemin tanımı

Amazon ölçeğinde milyonlarca ürün ve yüksek frekanslı inventory değişimleri bulunur. Amaç: doğru katalog, fiyatlama ve stok yönetimi ile müşteri deneyimini korumak ve reconciliations sağlamak.

Mimari özet

• Event sourcing + CDC pattern'leri inventory değişikliklerini düşük gecikmede modele alır.
• Data lake ve warehouse üzerinden reconciliations ve audit süreçleri yürür.
• Operational dashboards için OLAP sistemler ve near real‑time ingestion kullanılır.

Öğrenilen dersler

• Transactional sistemler ile analytic sistemler arasındaki tutarlılık için CDC ve idempotent sink'ler gerekir.
• Reconciliation job'ları düzenli otomasyon ve sampling ile desteklenmelidir.

4.4 OpenAI — Eğitim veri işleme, provenance ve reproducibility

Problemin tanımı

Büyük dil modellerinin eğitimi için devasa veri setleri kullanılır. Amaç: veri kaynağı provenance, etik inceleme, deduplama ve reproducibility sağlamak.

Mimari özet

• Data ingestion: Çok çeşitli kaynaklardan (web, partner data, licensed corpora) ingestion.
• Processing: Aggressive deduplication, filtering, dedikasyon ve labeling pipeline'ları.
• Storage: Versioned dataset storage, snapshot ve lineage metadata ile provenance sağlanır.

Öğrenilen dersler

• Dataset provenance olmadan reproducibility sağlamak neredeyse imkansızdır.
• Large‑scale dedup ve normalization ciddi compute kaynakları gerektirir — incremental yaklaşımlar ve sharding işe yarar.
• Etik ve PII kontrollerini pipeline'ın başından dahil etmek gerekir; sonradan düzeltmek zor ve maliyetlidir.

4.5 Stripe — Ödemeler, fraud detection ve reconciliation

Problemin tanımı

Stripe gibi ödeme altyapıları düşük gecikmede fraud detection, chargeback yönetimi ve mutabakat (reconciliation) gerektirir.

Mimari özet

• Event ingestion: Transactional events yüksek güvenlikle işlendiği için güvenli ve idempotent ingestion gereklidir.
• Real‑time scoring: Streaming pipeline'lar ML tabanlı fraud scoring'i besler; rule engine ile kombine edilir.
• Reconciliation: Settlement ve accounting pipeline'ları idempotent ve audit‑ready olmalıdır.

Öğrenilen dersler

• Financial data pipeline'larında audit trail, immutability ve strong lineage zorunludur.
• Fraud detection için hem rule‑based hem ML tabanlı yaklaşımlar hibrit olarak kullanılır; feedback loop çok önemlidir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru araç ve desen seçildiğinde latency azaltılır, cost optimize edilir ve veri doğruluğu artar.
• Birleşik lakehouse yaklaşımları hem ETL/ELT esnekliğini hem de analitik performansı sağlar.
• Observability ve lineage sayesinde MTTR azalır ve güven artar.

Sınırlamalar

• Operasyonel karmaşıklık: Çok sayıda bileşen yönetimi maliyeti artırır.
• Maliyet yönetimi: Yanlış partitioning veya sorgu paternleri beklenmeyen maliyet artışı yaratır.
• Gizlilik/uyumluluk: PII yönetimi ve regülasyonlara uyum ekstra süreç ve kontrol gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo bazı yaygın platform ve desenlerin avantaj/dezavantajlarını özetler:

7. EN İYİ PRATİKLER

7.1 Mimari ve tasarım

• Contract‑first yaklaşımı: Event ve dataset şemalarını önceden tanımlayın ve schema registry kullanın.
• Partitioning ve clustering stratejilerini veri tüketim paternlerine göre tasarlayın.
• Idempotency ve replay yeteneklerini baştan düşünün; sink'lerde transactional veya idempotent yazma uygulayın.

7.2 Operasyon ve güvenlik

• Metrik, trace ve log'ları entegre ederek Uptime SLO'ları oluşturun.
• Secrets management, least privilege IAM ve field level encryption uygulayın.
• PII discovery ve masking pipeline'larını ingestion'ın başına koyun.

7.3 ML ve data science entegrasyonu

• Feature store kullanarak offline/online feature uyumluluğu sağlayın.
• Training dataset'lerini versiyonlayın ve provenance metadata toplayın.
• Model scoring latency hedeflerini SLA'lara göre belirleyin; canary/blue‑green deploy stratejileri uygulayın.

8. SIK YAPILAN HATALAR

• Schema ve contract yönetimini ihmal etmek: downstream kırılmalar.
• Monitoring eksikliği: lateness ve data quality sorunları geç fark edilir.
• State kontrolünü planlamamak: state explosion ve maliyet artışı.
• Replay ve backfill stratejisi olmadan hızlı schema değişiklikleri uygulamak.

9. GELECEK TRENDLER

9.1 AI destekli otomasyon

AI, pipeline tuning, anomaly detection ve otomatik remediation önerileri ile operasyonu daha öngörülebilir kılacak. Veri kalitesi bozulduğunda root cause analysis için ML tabanlı araçlar daha fazla kullanılacak.

9.2 Declarative ve metadata‑driven platformlar

Deklaratif pipeline tanımları, metadata‑first yaklaşımlar ve semantic layer çözümleri karar verme süreçlerini hızlandıracak; data contracts otomatik olarak enforce edilebilecek.

9.3 Edge ve federated processing

Veri kaynağına yakın işleme (edge analytics) ile bant genişliği ve gizlilik kazanımları sağlanacak; federated processing ile merkezi state ihtiyacı azalacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi durumlarda stream processing tercih edilmeli?

   Low latency gereksinimi, real‑time scoring veya anlık alerting ihtiyaçları varsa stream processing tercih edilmelidir.

2. 2. Lakehouse neden popüler?

   Lakehouse, obje depolamanın maliyet avantajını korurken ACID ve schema evolution özellikleri sayesinde analitik iş yüklerini daha güvenilir hale getirir.

3. 3. State management maliyetleri nasıl kontrol edilir?

   State TTL, incremental snapshots, compaction ve state sharding ile state footprint azaltılabilir.

4. 4. Replay stratejisi neden önemli?

   Data bug veya schema değişikliklerinde geçmiş verilerin yeniden işlenmesi gerekir; replay planı olmadan bu işlemler gecikmeli ve hataya açık olur.

5. 5. Observability için hangi metrikler kritik?

   Freshness, processing lag, consumer lag, job success rate, checkpoint duration, state size ve data quality skorları en kritik metriklerdir.

6. 6. Feature store kullanmak şart mı?

   Online serving ve offline training arasında tutarlılık istiyorsanız feature store güçlü bir çözüm sunar; küçük projelerde basit ETL'ler yeterli olabilir.

7. 7. Data governance nasıl ölçeklendirilir?

   Metadata catalog, lineage, access controls ve policy as code ile governance otomatikleştirilebilir; domain‑oriented ownership modeli (data mesh) etkili olabilir.

8. 8. Hangi durumlarda managed servisler tercih edilmeli?

   Hızlı POC, düşük operasyonel kaynak veya maliyet‑benefit analizinde managed servisler tercih edilebilir. Uzun vadede vendor lock‑in riski değerlendirilmelidir.

Anahtar Kavramlar

• Lakehouse: Lake + Warehouse özelliklerini birleştiren veri mimarisi.
• CDC: Change Data Capture — transactional değişiklikleri stream'e çevirmek için kullanılan pattern.
• Watermark: Stream processing'de lateness yönetimi için kullanılan zaman işareti.
• Idempotency: Yeniden çalıştırmalarda yan etki yaratmama garantisi.

Öğrenme Yol Haritası

1. 0–1 ay: Temel SQL, Unix, HTTP ve veri formatları (JSON, Parquet) üzerine sağlam bir temel oluşturun.
2. 1–3 ay: Kafka ve temel stream processing kavramları; küçük bir streaming pipeline implementasyonu yapın.
3. 3–6 ay: Spark/Databricks ile büyük veri işleme, partitioning, compaction ve dosya formatları üzerine projeler geliştirin.
4. 6–12 ay: Orchestration (Airflow/Dagster), monitoring (Prometheus, OpenTelemetry), data governance ve feature store uygulamaları üzerine çalışın.