Blog yazısına göre Pandas'ın verimsizlikleri veri ekiplerini dağıtık sistemlere erkenden itiyor

İddia

eddie.codes'ta yayınlanan ve Hacker News ana sayfasına düşen "Pandas Should Go Extinct" başlıklı bir blog yazısı, bilinçli olarak provokatif bir iddiayı dile getiriyor: yaygın olarak kullanılan bu Python DataFrame kütüphanesi emekliye ayrılmalı, çünkü verimsizlikleri geliştiricileri, iş yükleri gerekmeden çok önce dağıtık sistemlere itiyor. Yazara göre çoğu ekip bu sistemlere asla ihtiyaç duymayacak; yazar bunları, az sayıda kuruluşun gerçekte sahip olduğu sorunlara yönelik agresif şekilde pazarlanan çözümler olarak tanımlıyor.

Yazı tipik bir benimseme yolunu haritalıyor. Analistler Excel'de başlıyor, gigabayt aralığında bir yerde Pandas'a geçiyor ve onlarca gigabayta kadar rahatça çalışıyor; tam o noktada bellek limitlerine, yavaş hesaplamalara veya yazarın şişmiş diye nitelendirdiği bir API'ye takılıyor. Geleneksel cevap, Spark, Databricks, Snowflake veya Dask gibi büyük ölçekli işleme için tasarlanmış araçlara geçmektir. Yazarın vurguladığı nokta, Pandas'ın takviyesinin bittiği yer — kabaca 100GB sınırı — ile dağıtık sistemlerin gerçekten gerekli olduğu ölçek arasında bir boşluğun açılmış olması ve modern tek makine araçlarının artık bu boşluğu doldurabilmesi.

Amazon'un kendi filosundan kanıtlar

Gerçekten büyük ölçekli verinin sanıldığından daha nadir olduğu iddiasını desteklemek için yazı, Amazon'un müşteri tabanı genelinde sorgu çalışma süreleri ve tablo boyutlarına ilişkin istatistikler yayınlayan, Redshift filosunu analiz eden 2024 tarihli bir Amazon makalesine dayanıyor. Yazar, belirtilen birkaç varsayımdan yola çıkarak — ortalama 1KB satır boyutu ve S3'ten saniyede 8GB okuma yapan on makinelik kümeler — filodaki tabloların yüzde 94,68'inin 100GB'den küçük olduğunu ve sorguların yüzde 86,9'unun 80GB veya daha az veriye dokunduğunu hesaplıyor, çünkü bunlar varsayılan işleme hızıyla bir saniyenin altında tamamlanıyor. Satırların çok daha şişman 10KB olduğu varsayılsa bile, karşılık gelen tablo boyutları 1TB civarında kalıyor.

Yazarın vardığı sonuç net: uygulayıcıların çoğu orta boyutlu veri sorunlarına sahip ve orta ölçekli veri çözümlerine ihtiyaç duyuyor. Okuyucuları ayrıca MotherDuck'tan Jordan Tigani'nin aynı veri kümesine dair daha derin bir analizine yönlendirirken, MotherDuck'ın barındırılan DuckDB sattığını ve bu yüzden bir miktar kuşkuyla yaklaşmayı hak ettiğini belirtiyor.

Yerine geçecekler: DuckDB ve Polars

Önerilen halefler, Pandas kullanıcılarına tanıdık gelen ama runtime'da çok farklı davranan Rust tabanlı DataFrame kütüphanesi Polars ile, yazarın analize yönelik bir SQLite'a benzettiği süreç içi analitik veritabanı DuckDB.

Farkı göstermek için yazı, bir milyar satırlık hava istasyonu verisi içeren CSV dosyasından minimum, ortalama ve maksimum ölçümleri hesaplamak için düzenlenen bir yarışma olan 1 Billion Row Challenge'ın uygulamalarını benchmark'lara tabi tutuyor; kabul edilen en hızlı Java girdisi 1,5 saniyede koşmuştu. Orijinal yarışma 32 çekirdekli, 128GB RAM'li fiziksel bir sunucu kullanmıştı; yazar ise testlerini aynı çekirdek sayısı ve belleğe sahip bir AWS m7a.8xlarge üzerinde koştu ve özel donanım atlanmasının tekrarlanabilirliği etkileyebileceğini kabul etti.

Ham sayılardan daha önemli olan teknik ayrım. Yazının örneğinde Pandas sürümü tüm veri kümesini belleğe yüklüyor ve ardından hesaplamanın her adımını sırayla çalıştırıyor. Polars sürümü ise lazy scan kullanıyor, dosyayı parçalar halinde akıtıyor ve yalnızca collect çağrıldığında sonuçları somutlaştırıyor. Bu, bir veritabanı motoru tarzında optimize edilmiş bir sorgu planı oluşturmasına, işi thread'ler arasında paralelleştirmesine ve her satırı önce yüklemek yerine filtreleri agregasyondan önce aşağı itme gibi teknikleri uygulamasına olanak tanıyor.

Neden önemli

Araç seçimleri bileşik maliyetler taşır. Dağıtık sistemler masraf, operasyonel yük ve hata ayıklama karmaşıklığı ekler; analitik tabloların ezici çoğunluğu 100GB altındaysa, küme benimseyen birçok ekip hiç kullanmayacağı bir kapasite için ödeme yapıyor demektir. Modern tek makine motorları onlarca yıllık veritabanı optimizasyonundan yararlanarak bu aralığı kapsayabiliyorsa, Pandas'tan Spark'a varsayılan yükselme yolu sorgulanmayı değil de varsayılmayı hak ediyor olamaz.

Yazının tetiklediği tartışma da alanın ne kadar çekişmeli kaldığını gösteriyor. Redshift aritmetiği yazarın satır boyutları ve küme yapılandırmalarına dair kendi varsayımlarına dayanıyor ve benchmark bir dizüstü bilgisayar değil, 32 çekirdekli bir sunucuda koşuldu. Dağıtık platform satıcılarının ölçeği vurgulamak için ticari nedenleri var; tıpkı DuckDB çevresindeki işletmelerin tersini savunmak için nedenleri olduğu gibi. Yine de yazı, veri topluluğundaki gerçek bir değişimi yakalıyor: Polars ve DuckDB gibi araçlar merak konusu olmaktan çıkıp günlük analitik iş için ciddi varsayılanlar olmaya doğru ilerliyor.