Databricks 2025 Photon Performance raporu, Photon engine’in Spark 3.5’in JVM execution’ına göre vektörize ETL iş yüklerinde 12x hızlandırma getirdiğini, TPC-DS 10TB üzerinde %72 daha düşük TCO sunduğunu gösteriyor. Ancak AQE aktif olmayan üretim cluster’larında veri eğriliği ortalama %35 wallclock kaybı yaratıyor.
Spark 3.5+ ve 2026 Performance Tuning Bağlamı
Apache Spark 3.5 (2024 ortası) ve 4.0 önizleme sürümleri ile birlikte adaptive query execution (AQE), Photon native engine ve dynamic partition pruning artık üretim standardı haline geldi. Databricks 2025 raporuna göre Spark 3.5+ kullanan ekiplerde aynı iş yükünün maliyeti Spark 2.4’e kıyasla %58 düşük, p99 latency %42 daha iyi. Apache 2025 Spark Summit verilerine göre AQE production’da aktif olan cluster oranı son 12 ayda %38’den %71’e çıktı.
Müşterilerimde gördüğüm en pahalı hata “cluster büyütelim” refleksi. Cluster başına node sayısını iki katına çıkarmak %60 ek maliyet getirirken çoğu zaman gerçek darboğaz cluster büyüklüğü değil, partition skew veya yanlış broadcast eşiği oluyor. Doğru tuning bu reflex’i frenleyip 3-5 parametre değişimiyle aynı kazanımı sağlıyor.
Adaptive Query Execution: 2026 Standart Parametreleri
AQE üç ana özellik sunar: coalesce shuffle partitions, skew join handling ve switch join strategies. Bunlar Spark 3.5’te varsayılan açık ancak default parametreler tüm iş yüklerine uygun değil. Production’da en sık değiştirilen parametreler aşağıdaki tabloda.
| Parametre | Default | Önerilen | Etki |
|---|---|---|---|
| spark.sql.adaptive.enabled | true | true | AQE’nin ana switch’i |
| spark.sql.adaptive.coalescePartitions | true | true | Small partition birleştirme |
| advisoryPartitionSizeInBytes | 64MB | 128-256MB | Coalesce target boyut |
| skewedPartitionFactor | 5 | 3-5 | Skew detect eşiği |
| skewedPartitionThresholdInBytes | 256MB | 128-512MB | Skew min boyut |
Photon Engine: Ne Zaman Devreye Girer, Ne Zaman Devre Dışı Kalır
Photon vectorized columnar execution engine’i C++ ile yazılmış ve SIMD instruction’larını yoğun kullanıyor. Databricks 2025 Photon Performance Brief’inde TPC-DS 10TB üzerinde Photon olmayan Spark’a kıyasla 12x hızlandırma, TPC-H 10TB’de 8x hızlandırma raporlanıyor. Ancak Photon her operasyonu desteklemiyor; UDF’lerin Python kısmı, custom data source’lar ve bazı complex aggregate’ler Spark JVM’e geri düşüyor (fallback). Bu fallback’ler tespit edilmediğinde Photon avantajı kayboluyor.
- Python UDF kullanan query’lerde Photon devre dışı kalıyor; Scala UDF veya higher-order function kullanılmalı
- Window function’ların büyük çoğunluğu Photon’da çalışıyor, ancak FIRST/LAST gibi bazıları fallback
- Complex MAP/STRUCT işlemleri Spark 3.5+ Photon’da destekleniyor
- Sparse aggregation Photon’da JVM’den 3-7x daha hızlı çalışıyor
Photon karşılaştırma detayları için Snowflake Databricks BigQuery TCO analizimize bakabilirsiniz.
Partition Stratejisi ve Skew Çözümleri
Veri eğriliği (skew) Spark performance’ın en yaygın katiidir. Databricks 2025 raporuna göre üretim Spark cluster’larının %47’sinde en az bir aktif skew partition var ve bu partition’lar toplam wallclock’un %35’ini tek başına tüketiyor. Çözüm yelpazesi: salt key tekniği, broadcast join eşiği ayarlama, dynamic partition pruning ve AQE skew handling.
Spark UI’da Darboğaz Teşhisi
Spark UI 3.5+ ile birlikte AQE plan değişikliklerini ve skew detect olaylarını görsel olarak gösteriyor. Production tuning’in temel adımı Spark UI’da “Stages” sekmesinden en uzun süren stage’i bulmak, “Tasks” sekmesinde p99/median oranını kontrol etmek (>2 ise skew var), “SQL/DataFrame” sekmesinde AQE rewrite’larını incelemek. Apache Spark resmi tuning rehberi bu pattern’leri detaylandırıyor.
| Belirti | Spark UI Tanı | Çözüm | Beklenen Kazanım |
|---|---|---|---|
| Tek task çok uzun | Task p99/median > 2 | AQE skew enable + salt key | %40-60 |
| Çok small file | Tasks > 10K | advisoryPartitionSize 256MB | %25-35 |
| Shuffle çok büyük | Shuffle Read > 100GB | Broadcast hint + partition pruning | %50-70 |
| GC time yüksek | Task GC > %30 | Executor memory artır | %20-30 |
| Photon fallback | “Photon: PARTIAL” | UDF kaldır veya Scala’ya çevir | %200-400 |
Dynamic Partition Pruning ve Broadcast Join Optimizasyonu
Dynamic partition pruning (DPP), join’in küçük tarafından dönen değerlere göre büyük tablonun partition’larını runtime’da filtreliyor. Bu özellik Spark 3.0+ ile geldi ancak ekiplerin %62’si konfigürasyon hatası nedeniyle aktif kullanmıyor. Broadcast join eşiği spark.sql.autoBroadcastJoinThreshold default 10MB; modern cluster’larda 100-200MB’a çıkarmak join performance’ı 5-10x artırıyor. Ancak çok yüksek değer driver memory’sini bloke ediyor.
Kurumsal Spark Performance Tuning’de Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- “Cluster büyütelim” refleksi: gerçek sorun partition stratejisinde, %60 ek maliyet boşa gidiyor
- AQE skewedPartitionFactor default 5’te kalıyor, üretim skew’leri tetikleyemiyor
- Python UDF’lerin Photon fallback yaptığı tespit edilmiyor; Photon faturası ödeniyor, kazanım yok
- Broadcast join threshold ayarlanmıyor; her join shuffle ile çalışıyor, p99 patlıyor
- Spill to disk gözlenmiyor; executor memory yetersiz, IO darboğazı kabusu
- Dynamic partition pruning konfigürasyon eksik, büyük tablolar tam taranıyor
Sonuç
Spark 3.5+ tuning’i 2026’da artık “spark.executor.memory artır” değil, AQE+Photon+partition stratejisinin birlikte kalibre edilmesi. Doğru tuning için önce profil çıkarın: Spark UI’da en uzun stage, task p99/median oranı, shuffle read miktarı, GC time. Sonra targeted parametre değişiklikleri yapın; her değişikliği A/B test edin. Cluster büyütmek son çare olmalı, çünkü doğru parametre değişiklikleri çoğu zaman aynı iş yükünde %40-70 maliyet düşürüyor. Photon kullanıyorsanız fallback’leri Spark UI’da takip edin; UDF’ler Photon avantajını öldürür.
Sıkça Sorulan Sorular
AQE’yi production’da güvenle açık tutmak doğru mu?
Evet. Spark 3.5’te AQE varsayılan açık ve Databricks 2025 raporuna göre üretim ekiplerinin %71’i aktif kullanıyor. Default parametreler çoğu iş yükü için iyi başlangıç; sadece skewedPartitionFactor ve advisoryPartitionSize değerleri iş yüküne göre ayarlanmalı.
Photon her senaryoda kazandırır mı?
Hayır. Photon ETL ve SQL ağırlıklı iş yüklerinde 8-12x hızlandırma getiriyor, ancak Python UDF ağırlıklı kodda fallback yaparak avantajını kaybediyor. Photon’a geçmeden önce iş yükünüzde UDF oranını analiz edin; %30+ Python UDF varsa Photon ROI tartışmalı.
Cluster’ı büyütmek mi yoksa partition’ı düzeltmek mi daha hızlı sonuç verir?
Çoğu zaman partition. Databricks 2025 verisine göre üretim cluster’larının %47’sinde skew partition var ve bu skew’i çözmek cluster büyütmenin maliyetinin 1/4’ünde aynı kazanımı sağlıyor. Önce Spark UI’da p99/median oranını kontrol edin.
Spill to disk olduğunda ne yapmalı?
Önce executor memory’yi artırın (8-16GB civarı tipik), sonra spark.sql.shuffle.partitions değerini cluster core sayısının 2-3 katı yapın. Bu değişikliklerin spill’i çözmemesi durumunda partition stratejisinde sorun var demektir.
Spark 3.5’ten 4.0’a geçmek için doğru zaman ne?
2026 ortasında Spark 4.0 stable bekleniyor. Production geçişi için 4.0.1+ önerilir; ilk minor release’i atlamak Apache Spark için tipik production stratejisi. Erken adopt edenler için Spark Connect ve geliştirilmiş ANSI mode özellikleri öne çıkıyor.
Ömer ÖNAL
Mayıs 23, 2026Spark tuning’de en pahalı hata ‘cluster büyütelim’ refleksidir. Müşterilerimin %60’ında darboğaz cluster büyüklüğü değil, partition skew veya broadcast eşik ayarıydı. AQE 3.0+ ile skew otomatik split ediliyor, ama yanlış spark.sql.adaptive.skewJoin.skewedPartitionFactor değeri tetiklemiyor. Photon ise ETL ağırlıklı iş yüklerinde 8-12x hızlandırma getiriyor, ancak UDF ağırlıklı kodda devre dışı kalıyor. — Ömer ÖNAL