Spark'te küçük dosya sorunu, özellikle shuffle aşamalarından sonra binlerce küçük Parquet dosyası oluştuğunda, alt sistem performansını ciddi şekilde düşürdüğünden, sayamayacağım kadar çok kez karşılaştım. İş mantığınız doğru olsa da, fiziksel düzenleme performansı bozar. Ortamımda, adaptif sorgu yürütmeyi (AQE) etkinleştirmek ve özellikle shuffle sonrası birleştirmeyi (coalesce post-shuffle) açmak, tekrarlanabilir bir iyileşme sağladı. İşte benim yaklaşımm bu.
Küçük Dosyaların Shuffle Sonrası Oluşma Nedenleri
Spark bir shuffle gerçekleştirdiğinde — örneğin, groupBy veya join sırasında — veriyi shuffle anahtarlarına göre diskte bölümlere ayırarak yazar. Eğer veri çarpıksa veya ilk bölümlendirme çok ince ise, çok sayıda küçük çıktı dosyası elde edilir. Bu dosyalar sadece rahatsız edici değildir; aynı zamanda excessive görev başlatma, meta veri yükü ve Parquet veya ORC gibi formatlarda sütun bazlı tarama verimselliği gibi sorunlara yol açar. 50.000+ dosyadan her biri 10KB’tan küçük olan bir işte, çalışma süresinin %90’u sadece görev zamanlama yükünden kaynaklanmıştı — bu durumu kendi gözlemlerimle gördüm.
Bu bölüm metnini Türkçeye çevir. Anlam aynı kalsın. İngilizce cümle bırakma.
Uyumlu birleştirme nasıl yardımcı olur
Spark 3.0+ uyarlanabilir sorgu yürütmeyi tanıttı; bu, çalışma zamanı istatistiklerine göre aşamaları yeniden planlamaya olanak tanır. Bu özelliklerin bir parçası spark.sql.adaptive.coalescePartitions.enabled'dir. True olduğunda, bir karıştırma aşamasından sonra Spark, sonuç bölümlerinin çok küçük olup olmadığını değerlendirir ve ilerlemeden önce bunları daha az, daha büyük birleştirir. Bu, mantığı değiştirmez — sadece yazma görevlerinin ve çıktı dosyalarının sayısını azaltır.
Bu ayarı temel AQE bayrağıyla birlikte kullandım:
spark.sql.adaptive.enabled=true
spark.sql.adaptive.coalescePartitions.enabled=true
spark.sql.adaptive.coalescePartitions.minPartitionNum=10
spark.sql.adaptive.advisoryPartitionSizeInBytes=128MBÖnerilen boyut, Spark'e iyi bir bölüm boyutunun nasıl görünmesi gerektiğini söyler; minPartitionNum aşırı birleştirmeyi önler. YARN üzerinde çalışan ETL ardışık düzenlerimde, bu ayar karıştırma sonrası dosya sayısını ~20k'dan 500'in altına düşürdü, veri kaybı olmadan ve yazma aşamasında 3–5 kat hızlandırma sağladı.
Çalıştığını Doğrulama
Spark UI'da birleşme (coalesce) gerçekleştiğini kontrol edebilirsiniz. Shuffle okuma aşamasına bakın — o aşamanın girdi bölüm sayısından çıktı bölüm sayısı daha azsa ve fiziksel planda "Coalesce Partitions" düğümü görüyorsanız, bu işlem aktif demektir. Ayrıca, SQL sekmesindeki açıklama planına bakmayı da severim:
EXPLAIN COST SELECT user_id, COUNT(*) FROM events GROUP BY user_idAQE aktifse, adaptif planlama hakkında bir not ve muhtemelen bir birleşme adımı göreceksiniz.
Ulaştığım Uyarılar
Bu sihirbazlık değil. Verileriniz ekstrem şekilde çarpıksa, birleştirme (coalescing) temel dengesizliği düzeltmez — hâlâ birkaç büyük bölüm ve birçok küçük bölüm alabilirsiniz. Bu durumlarda, bunu tuzlama (salting) veya özel bölümlendirme ile birleştiririm. Ayrıca, bir arada kullanırım. Ayrıca, birleştirme küçük bir bariyer karıştırma (shuffle) adımı ekler, bu yüzden karıştırmanız zaten optimal ise, gecikme artırabilir. Bu yüzden, tavsiye edilen boyutu gerçek küme G/Ç ve dosya formatına göre ayarlıyorum.
Tuning notlarındaki gibi söylediğim gibi, her zaman varsayılanlardan başlarım ve AQE'yi etkinleştirdikten sonra hâlâ kalıcı küçük dosyalar görüyorsam sadece yukarı doğru ayarlama yaparım.
Ne zaman kullanılmalı
Bu özellik, shuffle işlemi içeren tüm üretim Spark işlerinde varsayılan olarak etkinleştiririm — özellikle ETL, agregasyon ve veri göllerine yazma yapan join işlemlerinde. Düşük riskli, tersine çevirilebilir ve kazançlar tutarlıdır. Spark 3.2+ kullanıyorsanız ve shuffle sonrası küçük dosyalar görüyorsanız, bu özelliği açın ve çıktıyı ölçün.
Son düşünceler
Küçük dosya sorunu gidemeyecek, ancak uyarlamalı birleştirme, işleri yeniden yazmadan çalışma zamanında bu sorunu kontrol etmenizi sağlayan bir kolaylık sunar. Bunu doğru bölümlendirme ve izlemeyle birleştirirseniz, dosya sayısıyla uğraşmak yerine gerçek veri çalışmalarına daha fazla zaman ayırabilirsiniz.
Kapak görseli: learn_tek · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/153724200@N07/27774351928