1. GİRİŞ: VERİ İŞLEME SAVAŞLARI NEDEN ÖNEMLİ?

Dijital dünyanın kalbi artık "veriyi saklamak" değil, "veriyi işlemek" etrafında atıyor. Her saniye üretilen petabaytlarca veri; siber güvenlikten finansta dolandırıcılık tespitine, e-ticaret tavsiye sistemlerinden otonom araçlara kadar her noktada anlık kararlar alınmasını gerektiriyor. Bu noktada karşımıza iki devasa teknoloji çıkıyor: **Apache Spark** ve **Apache Flink**.

Bu teknolojiler neden bugün bu kadar popüler?

Veri mühendisliğinde "gecikme" (latency) artık bir tercih değil, bir hayatta kalma meselesidir. Bir banka işleminin şüpheli olup olmadığını 5 saniye sonra fark etmek "geç kalmaktır"; çünkü o para çoktan sistemden çıkmış olabilir. Ya da bir e-ticaret sitesinde kullanıcının o an baktığı ürüne göre kampanya sunmak, dönüşüm oranlarını dramatik ölçüde artırır. Spark ve Flink, bu "karar verme" süreçlerini devasa ölçeklerde (terabaytlarca veri üzerinde) milisaniyeler seviyesine indirmek için yarışıyor.

Kimler için önemli?

Bu makale; veri mühendisleri, veri bilimciler, sistem mimarları ve teknoloji liderleri için bir rehber niteliğindedir. Hangi aracın projeniz için "en doğru" olduğunu anlamak, sadece teknik bir seçim değil, aynı zamanda operasyonel maliyet ve ölçeklenebilirlik stratejisidir.

Hangi problemleri çözüyorlar?

Dağıtık sistemlerin en büyük zorlukları olan; veri kaybını önleme (fault tolerance), tam olarak bir kez işleme garantisi (exactly-once semantics) ve binlerce sunucuda paralel çalışma karmaşıklığını bu iki framework kendi yöntemleriyle çözüyor. Biri "geniş ekosistem ve işlem gücü" (Spark) vaat ederken, diğeri "ultra düşük gecikme ve mükemmel akış yönetimi" (Flink) sunuyor.

2. KAVRAMSAL TEMELLER: İKİ FARKLI DÜNYA GÖRÜŞÜ

Spark ve Flink'i anlamak için her iki projenin de hangi felsefe ile doğduğunu bilmek gerekir.

2.1 Apache Spark: "Batch as a Foundation"

Spark, MapReduce'un yavaşlığına bir tepki olarak doğdu. Ana odağı **yığın işleme (batch processing)** idi. Veriyi bellek içinde (in-memory) tutarak disk I/O işlemlerini minimize etti. Spark dünyasında her şey bir "RDD" (Resilient Distributed Dataset) veya modern anlamda "DataFrame"dir.
Streaming yaklaşımı: Spark için akış (streaming), aslında çok küçük yığınların (micro-batches) ardı ardına işlenmesidir.

2.2 Apache Flink: "Streaming as a Foundation"

Flink ise "her şey bir akıştır" mantığıyla tasarlandı. Flink için dünya, sonu gelmeyen bir veri nehridir. Batch (yığın) işleme, Flink için sadece "sonu olan" bir akıştır.
Streaming yaklaşımı: Veri geldiği anda, beklemeden işlenir (event-at-a-time). Bu, teorik olarak en düşük gecikmeyi sağlar.

2.3 Temel Terminoloji

• State (Durum): İşlemcinin o ana kadar ne gördüğünü hatırlama yeteneği (örneğin; son 1 saatin toplam satışı).
• Windowing (Pencereler): Sonsuz veri akışını anlamlı zaman dilimlerine (5 dakikalık dilimler gibi) bölme tekniği.
• Watermarks (Filigranlar): Geciken veya sırasız gelen verilerin ne kadar bekleneceğini belirleyen kontrol mekanizması.
• Exactly-Once: Bir verinin sistemde hata olsa dahi tam olarak bir kez işlenmesi garantisi.

3. NASIL ÇALIŞIR? TEKNİK MİMARİ VE ÇALISMA MANTIĞI

Her iki sistem de dağıtık çalışır ancak veriyi işleme motorları taban tabana zıttır.

3.1 Spark: DAG ve Mikro-Yığınlar

Spark, bir işi (job) aldığında onu bir **DAG (Directed Acyclic Graph)** olarak modeller. Bu grafik, verinin hangi aşamalardan geçeceğini planlar.
Structured Streaming tarafında Spark, gelen veriyi örneğin 500ms'lik dilimler halinde toplar ve bunları standart bir batch işi gibi çalıştırır.
Performans Notu (2025/2026): Spark 4.1 ile gelen **RTM (Real-Time Mode)**, bu mikro-yığın bariyerini kırarak sürekli işlemeyi Spark ekosistemine daha entegre bir şekilde getirmiştir.

3.2 Flink: Sürekli Veri Akışı ve Dağıtık Snapshotlar

Flink'te bir "scheduler" veriyi paketlemek için beklemez. Veri üretim hattındaki bir ürün gibi bant üzerinde sürekli ilerler.
Mimarinin Kalbi: Flink, hata toleransı için **Chandy-Lamport** algoritmasına dayanan dağıtık snapshotlar (çekimler) kullanır. Veri akışı arasına "bariyerler" atar ve bu bariyerler tüm operatörlerden geçtiğinde sistemin o anki durumunu (state) diskte kalıcı hale getirir. Hata anında sistem sadece son snapshot'a geri döner.

3.3 State Management (Durum Yönetimi) Karşılaştırması

Stateful (durumlu) işlemler büyük veri için en zor kısımdır. - **Flink:** Yerleşik olarak RocksDB bazlı devlet saklama mekanizmasına sahiptir. Terabaytlarca durumu (state) başarıyla yönetebilir. Flink 2.0 ile gelen "disaggregated state storage", durumu hesaplama birimlerinden ayırarak bulut üzerinde sonsuz ölçeklenebilirlik sağlar. - **Spark:** Checkpointing mekanizmasını kullanır. State Store API'ları son yıllarda (Özellikle Databricks Lightspeed projesiyle) çok gelişmiştir ancak hala Flink'in sunduğu kadar ince ayarlı kontrol sunmamaktadır.

4. GERÇEK DÜNYA KULLANIMLARI: ENDÜSTRİ DEVLERİ NE YAPIYOR?

Her iki teknoloji de teoride mükemmeldir, ancak pratikte devlerin seçimleri sistemlerin "gerçek" limitlerini belirler.

4.1 Netflix: Hybrid Bir Yaklaşım

Netflix dünyasında iki dünya da iç içedir. - **Spark:** Netflix, kullanıcı öneri motorlarının eğitimi (training) ve günlük büyük ölçekli ETL işleri için Spark'ı kullanır. Petabaytlarca geçmiş veriyi taramak için Spark'ın ekosistemi paha biçilemezdir. - **Flink:** Operasyonel monitoring ve gerçek zamanlı hata tespiti için Flink kullanılır. Bir film içeriği yayınlandığında, cihazlardan gelen anlık metrikler Flink üzerinden akıtılarak sistemin sağlığı milisaniyeler içinde kontrol edilir.

4.2 Uber: Surge Pricing ve Marketplace Sağlığı

Uber, **Marmaray** adını verdiği veri altyapısıyla Spark ve Flink'i harmanlar. - Lokasyon bazlı dinamik fiyatlandırma (Surge Pricing) **Flink** ile yönetilir. Binlerce sürücü ve yolcunun değişken lokasyonu "state" olarak Flink üzerinde tutulur ve fiyatlar anlık güncellenir. - Uber'in devasa veri gölüne (Data Lake) veri yazma ve temizleme işleri ise verimlilik nedeniyle **Spark** ile yapılır.

4.3 Alibaba: Single's Day ve Flink Dominasyonu

Dünyanın en büyük online alışveriş etkinliği olan Single's Day'de Alibaba, saniyede milyonlarca işlemi işlemek zorundadır. Alibaba, bu devasa yükü yönetmek için Flink'in en büyük destekçilerindendir. Tüm envanter takibi, ödeme analitiği ve sahtekarlık tespiti Flink üzerinde gerçek zamanlı akar.

4.4 OpenAI ve Amazon: AI Pipeline'ları

- **Amazon**, tedarik zinciri tahminlemelerinde Spark MLlib'i yaygın olarak kullanır. - **OpenAI**, LLM modelleri için veri hazırlama (data preprocessing) süreçlerinde Spark'ın dağıtık gücünden faydalanır. Devasa metin setlerinin temizlenmesi ve tokenizasyonu Spark kümeleri üzerinde paralel olarak yürütülür.

5. AVANTAJLAR VE SINIRLAMALAR: DÜRÜST BİR ANALİZ

Apache Spark Avantajları

• Geniş Ekosistem: MLlib (Makine Öğrenmesi), GraphX (Graf Analitiği) ve Spark SQL ile hepsi bir arada bir çözüm sunar.
• Geliştirici Deneyimi: Python (PySpark) desteği mükemmeldir. Veri bilimciler için öğrenme eğrisi düşüktür.
• Maturity (Olgunluk): Çok geniş bir topluluğa ve binlerce hazır kütüphaneye sahiptir. StackOverflow'da çözüm bulmak çok kolaydır.

Apache Spark Sınırlamaları

• Latency (Gecikme): Geleneksel mikro-yığın yapısı nedeniyle 100ms altı gecikmelerde Flink kadar performanslı değildir.
• State Management: Çok büyük boyutlu state'lerde checkpointing maliyeti yüksek olabilir.

Apache Flink Avantajları

• Gerçek Zamanlılık: Milisaniyeler seviyesinde düşük gecikme. Olay zamanı (event-time) desteği kusursuzdur.
• Güçlü State: RocksDB entegrasyonu ile yerel diskleri kullanarak devasa durumları bellek dışına taşma (OOM) riski olmadan yönetir.
• Exactly-Once: Dağıtık snapshotlar sayesinde hata anında veri tutarlılığı garantisi çok daha sağlamdır.

Apache Flink Sınırlamaları

• Kurulum ve Operasyon: Bir Flink kümesini yönetmek ve optimize etmek (Checkpointing tuning) Spark'a göre daha zordur.
• Ekosistem: Makine öğrenmesi ve diğer kütüphaneler Spark kadar olgun ve zengin değildir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA: TEKNİK MATRİS

Hangi aracın projenize uygun olduğunu belirlemek için bu matrisi kullanabilirsiniz:

7. EN İYİ PRATİKLER: UZMAN MİMAR TAVSİYESİ

Spark İçin Production Tavsiyeleri

• Broadcast Joins: Küçük bir tabloyu büyük bir tabloyla birleştirirken `broadcast()` kullanarak verinin tüm işçilere ağ üzerinden yayılmasını sağlayın ve devasa bir "shuffle" maliyetinden kurtulun.
• Serialization: Varsayılan Java serileştiricisi yerine `Kryo` serileştiricisini kullanarak veri iletim hızını 2-3 kat artırın.
• Partition Tuning: `spark.sql.shuffle.partitions` ayarını veri boyutunuza göre optimize edin. Veri azsa 200 çok fazladır, veri petabayt seviyesindeyse az partition OOM hatalarına yol açar.

Flink İçin Production Tavsiyeleri

• RocksDB Tuning: Çok büyük state'leriniz varsa `RocksDBStateBackend` kullanın ve SSD disklerin performansından yararlanın.
• Unordered Output: Eğer sonuçların sırası önemli değilse `Rebalance` veya `Rescale` kullanarak veriyi daha hızlı dağıtın.
• Incremental Checkpoints: Flink'te her seferinde tüm durumu (state) kaydetmek yerine sadece değişen kısımları kaydeden "incremental checkpoint" özelliğini aktif edin. Bu, diske yazma yükünü %90 azaltabilir.

8. SIK YAPILAN HATALAR: GELİŞTİRİCİLER NEREDE TAKILIYOR?

• Data Skew (Veri Eğriliği): Belirli bir partition'a diğerlerinden çok daha fazla veri gitmesi. Bu, tüm kümenin o tek işçinin bitmesini beklemesine neden olur. `Salting` tekniklerini kullanmamak en büyük hatadır.
• Too Many Small Files: Hem Spark hem Flink için "küçük dosya problemi" performansı mahveder. Veriyi diske yazarken `coalesce` veya `repartition` yapmayı unutmak.
• Gereksiz Shuffling: Veriyi ağ üzerinden taşımak en pahalı işlemdir. Gruplama ve birleştirme işlemlerini doğru partition key'ler üzerine kurgulamamak.
• UDF (User Defined Functions) Kötüye Kullanımı: Spark'ın yerleşik SQL optimizasyonunu (Catalyst Optimizer) bypass eden Python veya Java UDF'lerini her yerde kullanmak. Mümkün olduğunca native fonksiyonlar kullanılmalıdır.
• Hatalı Checkpoint Sıklığı: Flink'te checkpointleri gereğinden fazla sık (örn. her 1 saniyede bir) yapmak, sistemin asıl işi yapmak yerine sürekli kayıt almasına neden olur.

9. GELECEK TRENDLER: 2026 VE SONRASI

9.1 AI-Native Veri İşleme

Geleceğin veri işleme motorları artık sadece veriyi taşımayacak; veri akarken üzerinde çıkarım (inference) yapacak. Spark'ın **Project Lightspeed** ve Flink'in **AI Extended** kütüphaneleri, LLM (Büyük Dil Modelleri) içindeki vektör dönüşümlerini doğrudan boru hattı (pipeline) içinde gerçekleştirecek.

9.2 Ray ve Unified Compute

Sadece Spark veya Flink değil, **Ray** gibi daha esnek dağıtık hesaplama kütüphaneleriyle entegrasyon artacak. "Serverless Data Processing" sayesinde artık cluster ayağa kaldırmak yerine sadece kodumuzu buluta yükleyip milyarlarca satır için otomatik ölçeklenme bekleyeceğiz.

9.3 Lakehouse Standartlaşması

**Apache Iceberg**, **Delta Lake** ve **Hudi** formatları arasındaki savaş yerini standartlaşmaya bırakacak. Spark ve Flink, bu formatlar üzerinde "Direct-on-storage" sorgulama yeteneklerini mükemmelleştirerek veri transfer maliyetlerini sıfıra yaklaştıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Küçük bir startup için hangisi daha iyidir?

   Genellikle **Spark**. Çünkü öğrenmesi daha kolay, PySpark ile hızla prototip üretilebilir ve yönetilen servisleri (AWS Glue, Databricks) çok yaygındır.

2. Hangi teknoloji daha yüksek throughput (işlem hacmi) sağlar?

   Spark, büyük yığınlarda (batch) genellikle daha yüksek throughput sağlar. Ancak Flink, düşük gecikmeli akışlarda (streaming) rakipsizdir.

3. Flink Python (PyFlink) kullanılabilir mi?

   Evet, ancak PySpark kadar olgun değildir. Karmaşık durumlu (stateful) işlemler yapacaksanız hala Java veya Scala önerilir.

4. İki sistemi beraber kullanmak mantıklı mı?

   Evet, buna "Lambda Architecture" yerine modern bir yaklaşım olarak "Hybrid Model" denir. Batch ETL için Spark, Real-time alerting için Flink standart bir mimari karardır.

5. Exactly-once garantisi her zaman şart mı?

   Hayır. Eğer bir log analizi yapıyorsanız ve birkaç satırın mükerrer (duplicate) olması önem arz etmiyorsa, "at-least-once" kullanarak performansı artırabilirsiniz.

6. Spark'ın yeni 'Continuous Processing' modu Flink'i geçer mi?

   Spark bu alanda çok gelişti ancak Flink'in temel mimarisi hala "native streaming" üzerine kurulu olduğu için karmaşık pencereli işlemlerde Flink liderliğini koruyor.

7. Maliyet açısından hangisi daha avantajlı?

   Bu kullanım senaryosuna bağlıdır. 7/24 çalışan bir Flink kümesi pahalı olabilir. Ancak Spark'ın "on-demand" yığın işleri maliyet optimizasyonu için daha kolay yönetilebilir.

8. Streaming veritabanları (örn. RisingWave) bu araçların yerini alır mı?

   Basit SQL dönüşümleri için evet, ancak karmaşık iş mantığı ve ML entegrasyonu gerektiren "heavy-lifting" işler için Spark/Flink hala standarttır.

Anahtar Kavramlar

Shuffle

Verinin farklı partition'lar arasında ağ üzerinden yeniden dağıtılması süreci.

Lineage

Verinin hangi kaynaklardan ve hangi işlemlerden geçerek oluştuğunun "soyağacı" (Spark'ın hata toleransı temeli).

Checkpointing

Sistemin o anki durumunun hata kurtarma amacıyla kalıcı bir depolamaya yazılması.

Event Time vs. Processing Time

Verinin oluştuğu zaman ile sunucuya ulaştığı zaman arasındaki hayati fark.

Öğrenme Yol Haritası

1. Temeller: Dağıtık sistemlerin temellerini ve CAP teoremini öğrenin.
2. SQL ve Programlama: SQL bilgisini uzmanlık seviyesine çıkarın ve Java/Scala veya Python (PySpark) üzerinde pratik yapın.
3. Spark Pratiği: Bir veri setiyle (örn. Kaggle) DataFrame API kullanarak temel ETL süreçlerini kurgulayın.
4. Streaming Dünyasına Giriş: Kafka ile veri üretip Spark Structured Streaming veya Flink ile bu veriyi işleyin.
5. İleri Seviye Optimizasyon: Query planlarını (Explain plan) okumayı ve state yönetimi üzerine uzmanlaşmayı hedefleyin.