1. GİRİŞ

Batch processing (toplu işleme), verinin belirli aralıklarla veya zamanlanmış şekilde işlendiği, büyük hacimli görevlerin yürütüldüğü bir paradigmadır. Gerçek zamanlı (real‑time) sistemlerin yaygınlaştığı bir dönemde bile, toplu işler veri ambarı güncellemeleri, raporlama, ETL/ELT, ML eğitimleri, faturalama ve arşivleme gibi kritik kullanım alanlarında vazgeçilmezdir. Batch sistemleri doğru tasarlanmadığında performans, maliyet ve güvenilirlik açısından darboğaz oluşturur; iyi tasarlandığında ise ölçeklenebilirlik ve maliyet verimliliği sağlar.

Bu konu neden bugün önemli?

• Veri hacimleri hızla artıyor; petabayt düzeyindeki veri setleriyle çalışırken toplu işler verimlilik ve maliyet kontrolü açısından kritik.
• Bulut maliyet modeli ve heterojen kaynak (CPU/GPU/TPU) kullanımı batch işlerinin planlanmasını zorunlu kılıyor.
• ML eğitimleri, büyük ETL pipeline'ları ve gecelik raporlama iş akışları işletme karar süreçlerinin temelini oluşturuyor.

Kimler için önemli?

• Veri mühendisleri ve veri platform ekipleri
• ML mühendisleri ve araştırma ekipleri
• SRE ve altyapı mühendisleri
• Çözüm mimarları ve teknik liderler — operasyonel maliyet ve SLA'lar için

Hangi problemleri çözüyor?

• Günlük/haftalık/aylık toplu veri dönüşümleri
• Toplu raporlama ve OLAP veri hazırlıkları
• Büyük model eğitimlerinin orkestrasyonu ve kaynak yönetimi
• Backfill, retry ve audit gereksinimleri

2. KAVRAMSAL TEMELLER

Batch sistemlerini doğru tasarlamak için temel kavramlar ve terminoloji net olmalıdır. Bu bölüm bu ortak dili sağlar.

2.1. Temel Kavramlar

• Batch job: Belirli bir işi yapan bağımsız yürütülebilir süreç; tekil veya paralel task'lar içerir.
• Task / Stage: Job'un parçalara ayrılmış alt görevleri; bağımlılık grafı ile yönetilebilir.
• Workflow: Job'ların sıralı veya paralel çalıştırıldığı, bağımlılıkların tanımlandığı DAG (directed acyclic graph) yapısı.
• Data locality: Verinin bulunduğu yerde işleme (compute co‑location) yaklaşımı; I/O maliyetlerini düşürür.
• Backfill: Gecikmiş veya eksik geçmiş dönem verilerini yeniden işleme süreci.
• Checkpointing: Uzun süren işler için ara durumun saklanması; kesinti sonrası kaldığı yerden devam etmeyi sağlar.
• Idempotency: Bir job'un tekrar çalıştırıldığında yan etkisinin tekil olması; yeniden denemeler için kritik.

2.2. Mimari Bileşenler

• Scheduler / Orchestrator: İş akışlarını başlatan, bağımlılıkları yöneten ve retry/timeout politikalarını uygulayan bileşen (Airflow, Argo, Prefect, Dagster, Temporal).
• Execution engine: Job'ları çalıştıran altyapı (Kubernetes Jobs, Spark, Hadoop YARN, Mesos).
• Queue / Task broker: Task'ları worker'lara ileten kuyruk sistemleri (Celery/RabbitMQ, Kafka for events, SQS).
• Storage: Input/output verilerin saklandığı yerler (object store, distributed file systems, HDFS, S3).
• Monitoring/Observability: Job metrikleri, loglar, tracing ve alerting sistemleri.

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

Batch processing sistemleri veri akışı, task paralelizasyonu, hata yönetimi ve kaynak tahsisi konularında spesifik davranışlar sergiler. Bu bölümde mimari ve çalışma mantığını açıklıyoruz.

3.1. İki Ana Paradigma: MapReduce‑like vs Stream‑Oriented Batch

Tarihsel olarak map/reduce paradigması (Hadoop, Spark) büyük verinin paralel parçalanması ve birleşimi üzerine kuruludur. Modern yaklaşımlar ise batch işlerini stream altyapısı üzerinde micro‑batch (Flink, Spark Structured Streaming) olarak çalıştırabilir — böylece hem throughput hem de düşük gecikme arasında denge kurulur.

3.2. Workflow ve DAG Yönetimi

Batch job'lar genelde DAG olarak modellenir: veri hazırlama → temizleme → transformasyon → agregasyon → yükleme adımları. Orkestratör DAG'ı çözerek adımları sırayla veya paralel çalıştırır, başarısız adımları izler ve policy'lere göre retry veya alert oluşturur.

3.3. Paralellik ve Partitioning

Büyük veri setleri partition'lara bölünerek paralel olarak işlenir. Partitioning stratejileri (hash, range, time‑based) işin doğasına göre seçilir. Paralellik seviyesi kaynaklarla uyumlu ve downstream dar boğazları göz önünde bulundurarak ayarlanmalıdır.

3.4. Checkpointing ve State Management

Uzun süren batch işlerinde düzenli checkpoint almak, iş kesintilerinde yeniden başlamayı hızlandırır. Checkpoint verileri genelde object store veya distributed DB'lerde tutulur. Checkpoint granularitesi, performans ve kurtarma süresinin (RTO) dengesi için önemlidir.

3.5. Backfill, Idempotency ve Determinism

Backfill işlemleri geçmiş veri setlerini tekrar işlerken, idempotency konusuna dikkat edilmelidir; aksi halde duplicate kayıtlar veya hesaplama sapmaları oluşur. Deterministic transformasyonlar, tekrar çalıştırmalarda tutarlı sonuç sağlar.

3.6. Kaynak Yönetimi ve Heterojen Donanım

CPU‑bound işlerle GPU‑bound ML eğitimleri aynı platformda çalıştırıldığında scheduler'ın heterojen kaynakları bilmesi gerekir. Kaynak talepleri (requests/limits), affinity/anti‑affinity kuralları ve gang scheduling (tüm process'lerin aynı anda çalışması gereken paralel işler) desteklenmelidir.

3.7. Failure Handling ve Retry Semantics

Başarısız işlerin yeniden denenmesi politikaları (exponential backoff, max attempts), transient hatalarla kalıcı hataların ayrılmasını sağlar. Persistent hatalar DLQ'ya düştüğünde insan müdahalesi gerektirir. Retry öncesi idempotency ve checkpoint kontrolü önemlidir.

4. GERÇEK DÜNYA KULLANIMLARI

Büyük ölçekli şirketler batch sistemlerini farklı ihtiyaçlara göre özelleştirir. Aşağıdaki örnekler pratik yaklaşımları gösterir.

Netflix

Veri ambarı güncellemeleri, müşteri analizleri ve öneri sistemleri için geniş ETL pipeline'ları kullanır. Veri locality, incremental processing ve backfill politikaları kritik rol oynar. Spark ve internal scheduling çözümleri yoğun kullanılır.

Uber

Zaman serisi telemetri, fatura hesaplama ve analiz pipeline'ları büyük toplu işler gerektirir. Uber, gecelik toplu işler ile real‑time stream'in birleşimini etkin şekilde yönetir; locality ve low‑latency reporting için custom çözümler uygular.

Amazon (AWS)

AWS Batch, EMR, Glue gibi hizmetlerle müşterilere farklı batch işleme altyapıları sunar. Managed servisler, spot instance entegrasyonu ve autoscaling ile maliyet optimizasyonu sağlar.

OpenAI

Büyük model eğitimleri uzun süreli ve büyük kaynak tüketimine sahiptir; distributed training, data sharding ve checkpointing stratejileri eğitimin başarısı için kritiktir. Job scheduler'lar GPU/TPU havuzlarını verimli kullanacak şekilde yapılandırılır.

Stripe

Faturalama, reconciliation ve finansal raporlama gibi batch işler yüksek doğruluk ve auditability gerektirir. Transactional integrity ve idempotency stratejileri ön plandadır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Toplu olarak işlem yaparak büyük veri setlerinde yüksek throughput sağlar.
• Kaynakların topluca planlanması maliyetleri düşürebilir (spot instance optimizasyonu).
• Deterministic ve tekrarlanabilir iş akışlarıyla güvenilir raporlama ve ML eğitimleri sağlar.

Sınırlamalar

• Gecikme (latency) yüksek olabilir; gerçek zamanlı ihtiyaçlar için uygun değildir.
• Stateful ve uzun süren işler kompleks recovery ve checkpoint stratejileri gerektirir.
• Optimal packing ve scheduling NP‑hard problemlerdir; heuristikler yeterli olmayabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Batch işlerini çalıştırmak için kullanılan yaygın teknolojiler ve yaklaşımlar arasındaki farklar aşağıdaki tabloda özetlenmiştir.

7. EN İYİ PRATİKLER

Batch sistemlerini üretimde güvenli, verimli ve sürdürülebilir şekilde çalıştırmak için aşağıdaki pratikler önemlidir. Kod örneği yoktur; mimari ve operasyonel tavsiyelere odaklanılmıştır.

Production Kullanımı

• Job'ları küçük, modüler ve idempotent olacak şekilde tasarlayın.
• Resource requests/limits beyan ederek scheduler'a doğru bilgi verin; GPU, memory ve I/O taleplerini belirtin.
• Out-of-band metadata (job owner, SLA, business priority) ile operational süreçleri entegre edin.

Performans Optimizasyonu

• Data locality'yi önemseyin: veri bulunduğu node'a compute getirmek I/O maliyetlerini düşürür.
• Checkpointing stratejisi belirleyin; sık checkpoint almak RTO'yu düşürür ama I/O maliyetini artırır.
• Batch vs micro-batch trade‑off'larını iş yüküne göre değerlendirin (throughput vs latency).

Güvenlik

• Job secrets ve credentials yönetimini KMS/secret manager ile yapın; least‑privilege prensibini uygulayın.
• Audit log'ları ve immutable job run kayıtları saklayın; düzenleyici gereksinimler için bu kritik olabilir.

Ölçeklenebilirlik ve Operasyon

• Autoscaling: worker sayısını queue depth veya resource utilization'a göre otomatik artırın.
• Chaos testing ile node eviction, preemption ve network partition senaryolarını düzenli test edin.
• DLQ ve alerting: failing job'ları otomatik olarak DLQ'ya gönderip ekipleri alarmlandırın.

8. SIK YAPILAN HATALAR

• Resource taleplerini beyan etmeden job'ları submit etmek: scheduler yanlış yerleştirme veya OOM hatalarına yol açar.
• Idempotency olmadan retry politikaları uygulamak: duplicate side‑effect'ler oluşur.
• Checkpointing planı olmadan uzun süren job'lar çalıştırmak: kesinti sonrası uzun recovery süreleri.
• Observability eksikliği: failure root cause bulma ve SLA yönetimi zorlaşır.
• Veriyi yanlış yerde kopyalamak: gereksiz egress maliyetleri ve gecikme.

9. GELECEK TRENDLER

AI‑Assisted Scheduling ve Optimization

Makine öğrenimi, job talep tahmini, optimal packing ve preemption zamanlaması gibi konularda karar desteği sunacak. Reinforcement learning tabanlı scheduler'lar uzun vadeli maliyet‑performans hedeflerini optimize edebilir.

Serverless Batch ve Managed GPU Havuzları

Serverless batch ve paylaşımlı GPU/TPU havuzları geliştiricinin altyapı yönetimini azaltacak. Ancak cold start, resource contention ve maliyet yönetimi problemleri devam edecek.

Edge‑Native Batch ve Geo‑aware Processing

Edge cihazlarında veri ön işleme ve hafif batch aktiviteleri artacak; geo‑aware scheduling ile veri residency ve latency optimizasyonu önem kazanacak.