650 GB veri (S3 üzerindeki Delta Lake): Polars vs. DuckDB vs. Daft vs. Spark

 (dataengineeringcentral.substack.com)
8 puan yazan GN⁺ 2025-11-16 | 1 yorum | WhatsApp'ta paylaş
  • S3 üzerinde 650 GB ölçeğinde Delta Lake verisi depolayıp, bunun tek düğümlü bir ortamda Polars, DuckDB, Daft, Spark ile işlendiği bir performans karşılaştırma deneyi
  • 32 GB bellekli bir EC2 örneğinde her motorun büyük veriyi işleyip işleyemediği doğrulandı; küme tabanlı Spark’a karşı tek düğüm yaklaşımının olanakları araştırıldı
  • DuckDB 16 dakikada, Polars 12 dakikada, Daft 50 dakikada, PySpark ise 1 saatten uzun sürede tamamlayarak, tek düğümde de pratik işlem olasılığını gösterdi
  • Polars Deletion Vector desteği sunmuyor; bu özelliği yalnızca DuckDB desteklediği için Lake House uyumluluğunda fark bulunuyor
  • Sonuç olarak tek düğümlü framework’lerin düşük maliyetli donanımda da büyük ölçekli veri işleyebileceği gösterildi ve dağıtık hesaplamaya bağımlılığın yeniden değerlendirilmesi gerektiği ortaya kondu

Küme yorgunluğu ve tek düğüm alternatifi

  • SaaS tabanlı Lake House kümelerini işletmenin maliyeti ve karmaşıklığı arttıkça “cluster fatigue” olgusundan söz ediliyor
  • Geçmişte Pandas dışında seçenek olmadığından Spark kullanılıyordu; ancak DuckDB·Polars·Daft (D.P.D.) ile tek düğümde işleme olasılığı genişledi
  • D.P.D., bellekten büyük (LTM) veri kümelerini işleyebiliyor ve yüksek hızlı hesaplama sunabiliyor
  • Yazı, dağıtık ve dağıtıksız olmak üzere iki seçeneği ortaya koyarken “Single Node Rebellion” kavramını vurguluyor

Deney ortamının kurulumu

  • S3 üzerinde bir Delta Lake tablosu oluşturulup yaklaşık 650 GB veri depolandı (hedef 1 TB idi ancak durduruldu)
  • EC2 örneğinde (32 GB RAM, 16 CPU) DuckDB, Polars ve Daft çalıştırıldı; ardından Spark ile karşılaştırıldı
  • Veri, sosyal medya gönderileri biçiminde sahte veri olarak Python dict ile üretildi, ardından Daft DataFrame’e dönüştürülüp Parquet dosyalarına kaydedildi
  • Sonrasında Parquet dosyaları Databricks üzerinde Delta Lake tablosuna dönüştürüldü, yıl ve ay bazlı bölümleme yapıldı
  • Delta log hariç tutulduğunda yaklaşık 650 GB veri olduğu doğrulandı

Bellek kısıtı ve streaming ihtiyacı

  • Tek düğümde (32 GB bellek) 650 GB verinin işlenmesi gerektiğinden streaming tarzı sorgu yürütmenin gerekliliği gündeme geldi
  • Polars GitHub issue’suna atıfla, Iceberg için streaming write özelliği talep edilen örnekten bahsediliyor
  • Polars ve DuckDB gibi yeni nesil framework’lerin Lake House formatlarını streaming biçimde okuyup yazmaya yönelik yerleşik desteğe ihtiyaç duyduğu vurgulanıyor

Motorlara göre test sonuçları

  • DuckDB
    • Deletion Vector desteği sunan tek seçenek
    • 650 GB veriyi 32 GB’lık Linux makinede yalnızca 16 dakikada işlemeyi başardı
    • Kod basit ve çıktı dosyası sorunsuz üretildi
  • Polars
    • Deletion Vector desteği olmadığından Lake House ortamında bazı sınırlamalar var
    • Lazy API (Scan/Sink) kullanmak gerekiyor
    • İşlemi 12 dakikada tamamladı; DuckDB’den daha hızlıydı
  • Daft
    • Rust tabanlı; kullanım hissi iyi olsa da 50 dakikalık işlem süresiyle en yavaşı oldu
    • Iceberg ile ilgili işlerde kararlı çalıştığı görüldü
  • PySpark (Databricks Single Node)
    • 1 saatten uzun sürdü, herhangi bir tuning yapılmadan çalıştırıldı
    • Tek düğümlü motorlara kıyasla verimliliği daha düşüktü
    • Deneyin amacı hızdan çok tek düğüm yaklaşımının uygulanabilirliğini doğrulamaktı

Sonuç ve çıkarımlar

  • Deney, tek düğümlü framework’lerin büyük ölçekli Lake House verisini işleyebildiğini gösterdi
  • Düşük maliyetli donanımda bile makul çalışma süresi ve basit kod yapısı elde edildi
  • DuckDB, Polars ve Daft’ın tümü dağıtık küme olmadan da pratik performans sundu
  • Dağıtık hesaplama tek çözüm değil mesajı verilerek modern Lake House mimarisinin yeniden düşünülmesi gerektiği öne sürüldü
  • “Single Node Rebellion” kavramı üzerinden maliyet etkin veri mühendisliği yaklaşımının mümkün olduğu vurgulandı

İlgili okumalar

1 yorum

 
GN⁺ 2025-11-16
Hacker News görüşleri
  • Eventual'da çalışan bir yazılım mühendisiyim; ekibimizin geliştirdiği Daft için yapılan benchmark'ı paylaştığınız için teşekkür etmek istiyorum
    Daft, AI iş yükleri için yüksek performanslı bir veri işleme motoru ve hem tek düğümde hem de dağıtık ortamlarda çalışıyor
    Bu benchmark sayesinde paralellik ve pipelining tarafında geliştirebileceğimiz çok şey gördük. Özellikle deltalake reader ve groupby operatöründe optimize edilecek pek çok nokta vardı
    Bu iyileştirmeleri gelecek sürümlere yansıtmayı planlıyoruz; ayrıntılar için GitHub, Twitter, LinkedIn sayfalarına bakabilirsiniz
    Daft ilginizi çekiyorsa pip install daft ile doğrudan deneyebilirsiniz
    • Daft'ı ibis için bir backend olarak sunma planınız var mı diye merak ediyorum. Öyle olursa diğer motorlardan yumuşak bir geçişle test etmek güzel olurdu
    • Bu, şirket tanıtımı için oluşturulmuş bir hesap gibi görünüyor
  • Awk? Bununla ilgili ilginç bir yazı var — Command-line tools can be 235x faster than your Hadoop cluster
  • 650GB mı, telefonuma bile sığacak kadar küçük bir veri
    Aşırı araç kullanımına gerek yok, doğrudan GNU araçlarını kullanın
    Bu arada eski bir yazı ama hâlâ ilginç — command-line tools can be 235x faster than your Hadoop cluster
    • Artık o yazının ele aldığı 2014 Hadoop döneminde değiliz
      650GB JSON verisini CLI araçlarıyla aggregate etmeye çalışırsanız DuckDB ya da ClickHouse'un paralel işleme performansına yetişmeniz zor olur. GNU Parallel ile de denedim ama sınırları vardı
    • Eğer 650TB olsaydı konu tamamen değişirdi. O yazı sadece bir mikrobenchmark
      Gerçekte veri kataloğu ve cluster tabanlı işler gerekir
    • “Bu kadar küçük sayıları saymayı unuttum” diye şaka yapıp bu videoyu paylaşıyor
  • Ben sık sık DuckDB ile tek düğümde 'bir hayli büyük' veriler işliyorum
    Delta ya da Iceberg yerine Parquet dosyalarını doğrudan dolaşarak sorguluyorum
    BigQuery'de sorguladığım sonuçları yerel Parquet dosyaları olarak indiriyorum (yaklaşık 1GB'lık parçalar halinde) ve sonra DuckDB ile analiz ediyorum. RAM'den çok daha büyük veriler olsa da iyi çalışıyor
    Hatta bazen BigQuery ile DuckDB'nin agregasyon performansını karşılaştırıp işi iki motor arasında bölüştürüyorum. Veri mühendisliğinin eğlenceli tarafı da bu
    • 650GB civarı bir veri yerel dosya sisteminde de rahatça işlenebilir. Karmaşık araçlara gerek yok
  • Bu benchmark tamamen NIC bant genişliği tarafından belirlenmiş bir deney gibi görünüyor
    c5.4xlarge instance'ının azami 10Gbps bant genişliğiyle S3'ten 650GB okumak en az 9 dakika sürer
    I/O scheduling yöntemindeki küçük farklar sonuçları ciddi biçimde etkilemiş gibi duruyor
    Hatta daha büyük bir instance kullanıp işi hızlı bitirmek daha ekonomik bile olabilir
    • Sıradan bir masaüstü ya da iyi bir dizüstünde de denemek ilginç olabilir
      NVMe depolama S3'ten çok daha hızlıdır ve yereldeki 8–16 çekirdekli bir CPU buluttakinden daha iyi sonuç verebilir
      S3 harika bir ürün ama yerel depolama performansına yaklaşamaz
    • Gerçek sorgunun tüm dosyaları taramadığı, bunun yerine S3 byte-range read ile yalnızca bazı sütunları işlediği çok muhtemel
      Dosya boyutu dağılımı ya da API çağrılarındaki skew daha büyük değişkenler olmuş olabilir
      “Daha büyük instance daha ucuza bitirebilir” yorumuna tamamen katılıyorum
    • Deneyin değeri belirsiz
      Spark, çok aşamalı büyük veri kümeleri için uygundur ve backend olarak S3 kullandığınızda ağ darboğazı doğrudan maliyete dönüşür
      DuckDB/Polars'ın tek düğüm performansı etkileyici ama bu biraz pistteki bir uçakla motosikleti yarıştırmak gibi
    • 10Gbps fazla düşük. Google'da 400Gbps NIC ve iyileştirilmiş TCP congestion control kullanıyorduk
      Bu tür farklar yüzünden dağıtık hesaplamadan yorulan çok kişi var
    • Bu tespite katılıyorum. 30 yıl önce Wall Street'te öğrendiğim bir ders var — bir sistemin performansını test etmeden önce teorik üst sınırı anlamak gerekir
      Kaynak sınırlarını belirleyip gerçek performansı bu sınıra oranlayınca tablo çok daha netleşiyor
  • Bu yazı iki açıdan yanlış sunulmuş bir haber
    1. Gerçekte column pruning uygulanmış ve muhtemelen yalnızca 2 sütun + metadata'ya erişilmiş
    2. Zamanın çoğu S3 I/O'da geçmiş olmalı; eşzamanlı bağlantı sınırı daha büyük etken gibi duruyor
      Farklı sistemlerin denenmiş olması güzel ama keşke bellekten büyük sorgular daha ciddi şekilde ele alınsaydı
    • Sorgunun tüm 650GB yerine yalnızca bir kısmını döndüren bir projection olması önemli
      DuckDB bellek aşımı durumunda streaming konusunda güçlü, ama Polars burada hâlâ olgunlaşma aşamasında
      S3'ün varsayılan ayarları paralel okumayı engellemez; dolayısıyla asıl darboğaz büyük ihtimalle VM'in ağ bant genişliği
  • Yakın zamanda birkaç TB JSON verisi işlemek zorunda kaldım; asıl sorun çok sayıdaki 10–20MB'lık küçük dosyalardı
    ClickHouse en hızlısıydı, DuckDB ise sadelik ve kararlılık açısından en iyisiydi
    Flink ve PySpark 3–5 kat daha yavaştı, Dask ve Ray de fazla yavaştı
    Artık çoğu iş yükünde DuckDB ya da ClickHouse ile başlamayı öneriyorum. Pandas yavaş kaldığında DuckDB ile değiştirmek benim varsayılan yaklaşımım
    • JSON verisini önce başka bir formata dönüştürüp dönüştürmediğinizi, yoksa doğrudan JSON üzerinde mi çalıştığınızı merak ediyorum
  • Polars, Delta Lake desteği için delta-rs'ye bağımlı ve bu implementasyon Deletion vectors desteği sunmuyor
    Tek düğümlü bir kütüphane ile 1TB civarı veri gayet rahat işlenebilir; 10TB üstüne çıkınca Spark'a geçmek yeterlidir
    İlgili issue
    • Birçok kişi “Spark ile paralelleştirmek kolay” diye çok erken Spark'a geçiyor
      Oysa çoğu durumda daha iyi araçlarla sorun çözülebilir
      Bir zamanlar junior bir mühendis, yüzlerce 5GB'lık JSON dosyasını Python string birleştirme ile işlemeye çalışıp 18 saat harcamıştı
      Bunu basit konsol araçları ve multiprocessing ile değiştirince süre 35 dakikaya düştü
      Esas mesele doğru aracı seçmek
  • Presto (AWS Athena) daha hızlı ve daha iyi bir alternatif olabilir. 650GB veriyi yerelde de test etmek isterim
    • Presto'nun adı artık Trino oldu
      Bakımı ve çalıştırma maliyeti oldukça düşük, fiyat/performans açısından güçlü bir araç
  • DuckDB'nin yeni DuckLake katalog formatı da test için iyi bir aday olabilir — ducklake.select
    • DuckLake'in data inlining flush özelliği hâlâ alfa aşamasında
      Küçük batch write işlemlerinde çok fazla Parquet dosyası oluşması sorununu çözmek için DuckLake bunu DBMS'e (Postgres gibi) inline olarak kaydediyor
      Yakın zamanda yeniden Parquet'e yazma özelliği geldi ama hâlâ daha fazla olgunlaşması gerekiyor
      İlgili doküman
    • DuckLake formatında SQL bağımlılığı şeklinde bir tavuk-yumurta problemi var
      Katalogu bir SQL veritabanı olarak ifade etmek gerekiyor, oysa Parquet'in avantajı tam da bu karmaşıklıktan kaçınmak
      Katalog da Parquet tabanlı olursa kendi kendini bootstrap eden bir format olabilir gibi görünüyor