4 puan yazan GN⁺ 2024-01-09 | 1 yorum | WhatsApp'ta paylaş
  • Tek bir makinede hızlı veri işleme gerektiren ortamları hedefleyen açık kaynaklı bir DataFrame kütüphanesi olup 575 milyondan fazla indirme ve 38 binden fazla GitHub yıldızına ulaşmıştır
  • Performansın temelinde Rust tabanlı çok iş parçacıklı sorgu motoru ile sütun odaklı işleme, vektörizasyon, SIMD ve paralel yürütme yer alır
  • MIT lisanslı açık kaynaklı bir kütüphane olarak sunulmaya devam eder; aynı API ile production iş yüklerine kadar ölçeklenebilen Polars Cloud da ayrıca sunulur
  • pandas'a kıyasla 30 kattan fazla performans artışı iddia eder; türetilmiş TPC-H benchmark'ı c3-highmem-22 üzerinde scale factor 10 ve I/O dahil koşullarda yürütülmüştür
  • CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, başlıca veritabanları, S3 ve Azure depolamayı desteklediği için mevcut veri yığınına eklemek kolaydır

Polars'ın sunum biçimi

  • Polars, veri işleme için açık kaynaklı bir kütüphanedir ve tek bir makinedeki en hızlı veri işleme çözümlerinden biri olarak konumlanır
  • Yapılandırılmış ve tipli bir API sunar; aynı anda hem ifade gücünü hem de kullanım kolaylığını hedefler
  • Mevcut açık göstergeler şöyledir
    • 575M+ indirme
    • 38k+ GitHub yıldızı
  • Başlangıç dokümantasyonuna Get started sayfasından ulaşılabilir
  • Açık kaynak Polars

    • Polars, MIT lisansı altında ücretsiz kullanılabilen açık kaynaklı bir kütüphanedir
    • Yüksek performanslı bir DataFrame kütüphanesi olarak sunulur ve kurulumu da basittir
    • Kurulum örnekleri şöyledir
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');
  • Polars Cloud

    • Polars Cloud, notebook ortamındaki Polars sorgularını bulut veya on-prem production iş yüklerine genişleten yönetilen bir çözümdür
    • Aynı API kullanılarak kod değişikliği olmadan ölçeklenebilir
    • Dağıtım biçimi olarak Cloud veya On-Prem desteklenir
    • Ücretlendirme yalnızca sorgu çalıştırma için yapılır
    • Denemek için Polars Cloud kullanılabilir

Performans modeli ve veri entegrasyonu

  • Polars'ın performans temeli, Rust tabanlı çok iş parçacıklı sorgu motoru ve paralel işleme tasarımıdır
  • Vektörizasyon ve sütun odaklı işleme, modern işlemcilerde önbellekle uyumlu algoritmalar ve yüksek performans sağlar
  • Türetilmiş bağımsız TPC-H benchmark içinde çeşitli çözümlerle karşılaştırılmıştır ve amaç gerçek dünyadaki veri temizleme işlerini yeniden üretmektir
    • pandas ile karşılaştırıldığında 30 kattan fazla performans artışı mümkündür
    • Benchmark, c3-highmem-22 üzerinde scale factor 10 ve I/O dahil koşullarda yürütülmüştür
    • Sorgular open source olarak yayımlanmıştır
    • Ayrıntılar için Learn more sayfasına bakılabilir
  • Kullanılabilirlik ve yürütme optimizasyonu

    • Kullanıcılar sorguları istedikleri şekilde yazar ve Polars'ın sorgu optimize edicisi en verimli yürütme biçimini belirler
    • İşler, ek ayar veya serileştirme yükü olmadan kullanılabilir CPU çekirdeklerine dağıtılarak paralel yürütülür
    • Mevcut veri araçlarıyla entegre olabilmek için Apache Arrow bellek modelini kullanır
    • Zero-copy veri paylaşımı sayesinde araçlar arası iş birliği maliyeti azaltılabilir
    • Harici bağımlılıklar olmadan makineye yakın tasarlandığı için API, bellek ve yürütme üzerinde kontrol sağlar
    • Bellekten büyük veri kümeleri, tüm veriyi belleğe yüklemeye gerek kalmadan streaming API ile işlenebilir
  • Desteklenen veri biçimleri

    • Polars, yaygın veri biçimlerinde okuma ve yazmayı destekleyerek mevcut veri yığınıyla entegre olabilir
    • Destek kapsamı şöyledir
      • Text: CSV, JSON
      • Binary: Parquet, Delta Lake, AVRO, Excel
      • IPC: Feather, Arrow
      • Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Cloud storage: S3, Azure Blob, Azure File

1 yorum

 
GN⁺ 2024-01-09
Hacker News yorumları
  • Bu sayfanın, neye baktığını zaten bilen kişiler için yazıldığı çok belli. Daha ilk cümle, aracı açıklamak yerine “Polars is written from the ground up with performance in mind” gibi kalitesinden bahsederek başlıyor; geri kalanı da aynı çizgide
    Biri bunu 5 yaşındaki bir çocuğa anlatır gibi bunun ne olduğunu ve hangi ihtiyaç için iyi bir çözüm sunduğunu söyleyebilir mi?
    Düzenleme: Sonunda bunu Pandas DataFrame’in alternatif bir implementasyonu olarak anladım. Google’da bulduğum https://realpython.com/pandas-dataframe/ açıklamasına göre DataFrame, iki boyutlu verileri ve etiketleri tutan bir yapı; veri bilimi, makine öğrenimi, bilimsel hesaplama gibi veri yoğun alanlarda yaygın kullanılıyor ve SQL tablolarına ya da Excel/Calc elektronik tablolarına benziyor

    • Pek çok teknoloji ürününün sinir bozucu zayıf noktası tam da bu. Hedef kitleye, burada Pandas’ı sevip onu yavaş ve esnek olmayan bulan veri bilimcilere konuşmak istemek doğal; ama yeni başlayanlarda dışlanmışlık hissi yaratıyor
      Ben Polars’ın hedef kitlesindeyim ve aylardır denemek istiyorum ama sürekli erteliyorum. Pandas’ın yaratıcısı Wes McKinney’nin yaygın analiz araçlarını açıklayan faydalı bir kitap https://wesmckinney.com/book/ yazmış olmasından dolayı Pandas’a karşı hâlâ bir sadakatim var
    • Pandas’ın hızlı olanı. Pandas, orijinal açık kaynak veri çerçevesi kütüphanesi; sağlam ve yaygın kullanılıyor, ama kapsamı geniş ve bu yeni oyuncudan daha yavaş gibi görünüyor. “Veri çerçevesi” ifadesi, daha önce kullanmış olanlara hemen sinyal veriyor
    • Böyle sayfaları gördükçe insanın alçakgönüllü hissedesi geliyor. “Yeni çağın DataFrame’i” deniyor; ben DataFrame’i biliyor muyum acaba diye düşünüyorum, “çok iş parçacıklı sorgu motoru”nu görünce de bu bir veritabanı gibi bir şey mi diye düşünüyorum
      pandas, modin, vaex denen şeylerle karşılaştıran bir grafik çıkıyor; onları da hiç bilmediğim için sonunda bunun bana göre olmadığı hissine kapılıyorum. Yeni teknolojileri veya projeleri okuyup öğrenmeyi severim, ama burada tutunabileceğim bir şey yok
      Sıradan insanlara önemsiz web geliştirme konularından bahsettiğimde muhtemelen onların yaşadığı şey de böyle bir şeydir
    • Adil olmak gerekirse sayfanın başlığı “Dataframes for the new Era” ve başlığın altındaki Get Started bağlantısı GitHub sayfasına giden dokümantasyonu işaret ediyor. GitHub, veri analizi geçmişi olan kişilere bu kütüphanenin ne olduğunu açıklıyor: https://github.com/pola-rs/polars
    • Şu anda “veri” tarafındaki işlere çekiliyorum ve burası, kendine özgü arka planı ve kültürü olan paralel bir evren gibi. “Nincompoop’un kullanılabilirliği ve ARSE2’nin performansıyla Antelope ya da Meringue instance’larına bağlanın” tarzı ifadeler çok
      Polars’ta ilginç olan, Pandas’a benzemesi ama daha verimli bir Rust backend’i olan Arrow’u kullanması ve işlem bileşimlerini daha verimli hâle getiren sorgu planlayıcı gibi bir şeye sahip olması. Genelde Polars, Pandas’tan çok daha verimli; bu yüzden eskiden karmaşık altyapı gerektiren işler çoğu zaman tek bir makinede yapılabiliyor
      Pandas’ın çekirdek geliştiricilerinden birinin kurduğu çok dostane bir rekabet ortamı bu; görünüşe göre herkes memnun ve zamanla Pandas’ın yerini alma olasılığı yüksek görünüyor
  • İlgili yazılar:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - Ağustos 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - Ağustos 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - Ocak 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - Ocak 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - Ocak 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - Aralık 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - Aralık 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - Temmuz 2020

  • Pandas’ı birkaç yıl kullandım ama hep topu yokuş yukarı yuvarlıyormuşum gibi hissettirdi. Join gibi basit işlerde bile böyle; indeks sıfırlamayı da unutmamak gerekiyor
    Polars, neredeyse her açıdan Pandas’tan daha iyi hissettiriyor. Daha hızlı, çoklu çekirdek kullanıyor, daha az bellek tüketiyor ve API’si daha sezgisel. Hâlâ görece genç bir kütüphane olduğu için eksileri var ama yeni bir proje için en azından değerlendirmeye değer
    Rust ekosisteminden kolayca yararlanabilmek de harika. Kendi eklentimi yazarak bir fonksiyonu paralelleştirdim ve bazı jeo-uzamsal kodları 100 kat hızlandırdım

    • Join’i örnek vermen biraz ironik. Pandas’ın en büyük sorununun hep dokümantasyon olduğunu düşündüm. Örneğin indeks kullanmadan data frame’leri birleştirmenin bir yolu olduğunu biliyor muydun? Adı “join” değil, merge
      Pandas ilk dönemlerinde R’nin terimlerinden ve kullanım kalıplarından güçlü biçimde etkilenmişti; R’de de “merge”, “join” anlamında zaten yaygındı. Pandas öğrenmeye başladığım 2015 civarında R’yi önceden bilmiyor olsaydım hızlıca kavramam zor olurdu
    • PRQL’e (prql-lang.org) nasıl baktığını merak ediyorum. Kişisel olarak Polars veya Pandas’ın kullanım hissini ve geliştirici deneyimini SQL’in gücü ve evrenselliğiyle birleştirdiğini düşünüyorum
      Sorgular yalnızca Polars ve Pandas’ta değil; DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite gibi istediğiniz SQL uyumlu yürütme motorunda da çalıştırılabiliyor
      Join sözdizimi ve semantiği en çetrefilli kısımlardan biri, bu yüzden son zamanlarda yeniden tartışılıyor. İlişkisel cebirin özü ve PRQL’deki R’ye de karşılık geliyor. PRQL’in temel dönüşümlerinin çoğu map, filter, reduce gibi basit liste işlemleri; ancak monad bileşimini korumak için join’lerde dikkatli olmak gerekiyor. Düşüncelerimi buraya bıraktım: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      İlgili issue kapatıldı ama yeni bir issue açarsan ya da @snth ile etiketleyip görüşlerini paylaşırsan iyi olur. Bu arada ben PRQL katkıcısıyım
    • Pandas data frame birleştirmede neyin zor olduğunu merak ediyorum
  • Değerlendirdiğimde en büyük artısı, API’nin Pandas’a göre çok daha tutarlı ve anlaşılır olmasıydı. Pandas’ın 20 ana sürümünü görerek öğrenmiş olmalı; bu açıdan doğal
    Ancak çok daha az kullanıldığı için Copilot, Polars kodunu iyi yazamadı. Bu yüzden şimdilik Pandas ve Copilot kullanmaya devam ediyorum. Yeni kütüphaneler genelinde böyle bir bariyer olduğunu ilk kez bu sefer hissettim

    • Copilot desteği nedeniyle bir kütüphaneyi tercih ettiğini açıkça söyleyen birini ilk kez görüyorum. Yargılamak için söylemiyorum, ilginç geldi
      Yine de Copilot bir depo içinde çok hızlı öğreniyor. Ben, yazarı tarafından bile kullanılmayan ya da önerilmeyen bir TypeScript fork’u olan TS-Plus ile kurulmuş son derece özelleştirilmiş bir stack kullanıyorum; Copilot oldukça iyi TS-Plus kodu üretebiliyor
      Birkaç örnek gördükten sonra, tekrar eden kod aşamasında Copilot’ın epey iyi hale gelebileceğini hafife almamak gerek
    • Copilot desteği bir tavuk-yumurta problemi. Başkalarının kodlarından öğrenmesi gerekiyor; insanlar Copilot olmadan Polars kodu yazmazsa Copilot da Polars kodunu daha iyi yazamaz
    • JS’teki bir başka data frame kütüphanesi olan danfo.js’i kullanırken benzerdi. Copilot özellikleri ve metot adlarını düpedüz uyduruyordu
      Dokümanları okuyabildiğim için büyük sorun değildi ama Copilot’ın ihtiyacım olanı hemen çıkaramaması can sıkıcıydı
    • API’nin daha tutarlı ve anlaşılır olduğunu kabul ederken, sırf Copilot daha kolaylaştırıyor diye Pandas’ta kalacağını mı söylüyorsun? Hem senin için hem de açık kaynak inovasyonu için daha iyi olduğunu kabul ettiğin aracı kullanmak daha iyi
      Ben Pandas API’sini uzun süredir kullanıyorum ve sevmiyorum. Öğrenmeyi, araçları, düşünme biçimini ve teknikleri sürekli geliştirme konusunda epey istekliyim
    • Polars kütüphanesi hızla değişiyor. Copilot kullanmıyorum ama sistem talimatlarına örneğin with_column’ın with_columns olarak değiştiği gibi güncel bilgileri koyup doküman içeriği ekleyince ChatGPT ile oldukça iyi sonuçlar aldım
  • Deno, Jupyter desteğini yayımladığında nodejs-polars desteklenen temel veri bilimi kütüphanelerinden biriydi
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Kişisel olarak veri bilimi tarafında biri değilim ama JS/Jupyter ekosisteminin hâlâ erken aşamada olduğu düşünülürse TypeScript’te pola.rs tabanlı analizleri ayağa kaldırmak şaşırtıcı derecede hızlıydı
    JS binding’lerinin kesinlikle elden geçirilmesi gereken yerleri var, ama erişilebilirlik arttıkça yinelemeli iyileştirmeler olmasını umuyorum

    • JS’te hep Pandas benzeri bir şey istemiştim; bunu yeni öğrendim
  • Polars beni gerçekten heyecanlandırıyor ve hız performansı da etkileyici, ama vaex, modin ve dask’ı aynı benchmark’ta karşılaştırmak rahatsız edici
    Bu kütüphanelerin hepsi çekirdek dışı veri işleme, yani veri tek makineye sığmayacak kadar büyük olduğunda birden fazla makineye yayılarak hesaplama yapma amacıyla tasarlanmış. Tek makinelik data frame kütüphanesiyle karşılaştırmak garip; kaçınılmaz olarak ek yükleri büyük olduğu için daha yavaş olmaları doğal
    Polars’ı bu kütüphanelerle aynı bağlamda kullanmak pek olası değilken benchmark’ta eşdeğerlermiş gibi göstermek biraz komik. Üstelik Polars ile aynı bağlamda kullanılabilen ve birçok durumda daha hızlı olan DuckDB benchmark’ta yok
    Polars’ın yazılım mühendisliği harika bir iş; bu tür yanıltıcı benchmark’lara ihtiyacı yok

    • Diğerlerini bilmem ama Dask tek makinede de kullanılabilir; hatta Dask kullanmanın en kolay yolu da bu. Data frame’i partition’lara bölüp her çekirdekte işleyerek işlemleri paralelleştirir
      Ayar yapmadan Pandas’a kıyasla 2 kat performans artışı mümkün; belirli işlemlerde 5 kata kadar gördüm
    • Pandas’ın yaratıcısı tarafından yapılan Python data frame’i Ibis, DuckDB’yi varsayılan backend olarak kullanıyor ve bazı sorgu istisnaları dışında genelde bu tür benchmark’larda Polars’ı geçiyor
  • Polars’ı doğrudan kullanmıyorum; DuckDB iş akışında somutlaştırma biçimi olarak kullanıyorum
    duckdb.query(sql).pl(), duckdb.query(sql).df()’den çok daha hızlı. Polars tarafında sıfır kopya olduğu için anında bitiyor; Pandas’ta ise DataFrame büyükse epey uzun sürebiliyor. Ayrıca sözdizimi biraz farklı olsa da Pandas DataFrame gibi manipüle edilebiliyor
    Büyük veri kümeleriyle çalışmak için çok iyi

  • Greenspun’ın 10. yasasına (https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)) dair bir sonuç önerme var gibi. Yeterince karmaşık bir veri analizi kütüphanesi, SQL’in yarısını geçici, gayriresmî tanımlı, hatalı ve yavaş bir şekilde yeniden uygular gibi
    Pandas’ı ara sıra kullanıyorum, bunu da muhtemelen deneyeceğim; ama üzerinde çalıştığım veriyi en baştan doğrudan Postgres’e koymuş olsaydım diye hep düşünüyorum
    Veritabanı uzmanı değilim ve Python bana çok daha rahat geliyor; buna rağmen tablo biçimindeki verileri seçme, sıralama, filtreleme ve join etme konusunda SQL çok daha iyi

    • DuckDB ve duckdb-prql eklentisine bakmanızı öneririm
      DuckDB, veri kopyalamadan veya çoğaltmadan Polars, Pandas ve Arrow biçimindeki verileri SQL ile doğrudan işlemenizi sağlar
      duckdb-prql, PRQL (prql-lang.org) kullanmayı mümkün kılıyor; bana göre SQL’in gücü ve yaygınlığı ile Polars ya da Pandas’ın kullanım hissini ve geliştirici deneyimini birleştiriyor. Not: Ben PRQL katkıcısıyım
    • Öyle de yapılabilir, ama “analitik” sorgular söz konusuysa performansın çok daha kötü, esneklik ve ifade gücünün de daha düşük olma ihtimali büyük
      Bunun yerine DuckDB’ye bakmaya değer. SQL uygulaması geçici bir çözüm değil; hata dolu, yavaş ya da eksik de değil. Tanımının ne kadar biçimsel olduğunu bilmiyorum ama Polars ile uyumlu
    • Kişisel olarak lazy dataframe sözdiziminin bir sorgu motoru için çok daha iyi bir ön uç olduğunu düşünüyorum. Polars da SQL destekliyor, ancak hatalar genellikle ön uçtan değil sorgu motorundan çıkar
      Bu tür motorlarla yapılan sorgularda Postgres, OLAP sorgu motorlarından muhtemelen tek haneli katlar kadar daha yavaş olacaktır
    • Pandas’ın kurucusu bu nedenle Postgres arka ucuna sahip Ibis’i yaptı: https://ibis-project.org/backends/postgresql
      Python dataframe’leri ile SQL’i birlikte kullanmak için daha iyi bir yaklaşım
  • Birkaç ay önce büyük bir Pandas kod tabanını Polars’a taşımayı denedim. Python’da analiz veya veri pipeline’ı yapmayı pek sevmiyorum; karmaşık dönüşümler Pandas’ta Julia ya da R’ye (dataframes.jl, dplyr kullanarak) göre 2–5 kat daha uzun sürüyor
    Ne yazık ki Polars da cevap değildi. Standart işlemlerde çok fazla hata vardı ve Pandas ile birlikte çalışabilirliği istikrarsızdı. Birçok kütüphane girdi olarak Pandas DataFrame istediği için bu sorun. API’si de modern bir dataframe kütüphanesine göre çok laf kalabalığı içeriyor; yine de Pandas’tan daha iyi
    Zamanla çözülmesini umuyorum, ancak şu an en iyi seçenek Pandas üzerinde DuckDB kullanmak oldu. Polars kadar hızlı, daha kararlı ve birlikte çalışabilirliği de daha iyi
    Umarım bir gün Python dataframe ekosistemi de R’deki gibi, sezgisel API’ye sahip analiz odaklı bir dataframe kütüphanesini (dplyr) ve yüksek performanslı bir dataframe kütüphanesini (data.table) birlikte kolayca kullanabileceğimiz noktaya gelir

    • Ben de laf kalabalığından rahatsız oldum. Pandas da data.table gibi şeylerle karşılaştırıldığında oldukça ayrıntılı, ama Polars “veri manipülasyon aracı”ndan çok API kullanıyormuş hissi veriyor
      Keşifsel veri analizi ya da araştırma için muhtemelen kullanmam, ama daha iyi performansı nedeniyle bazı production script’lerinde kullanmaya başladım
      R’deki dplyr + data.table kombinasyonu hâlâ en sevdiğim veri manipülasyonu deneyimi. Yalnız R’de Matplotlib gibi bir şey olsaydı iyi olurdu. ggplot fazla yüksek seviyeli, temel grafikler ise fazla düşük seviyeli. Scikit-Learn de Caret’ten çok daha modüler olduğu için Caret’i özlemiyorum
    • PRQL’i (prql-lang.org) nasıl gördüğünüzü merak ediyorum. SQL’in kullanıldığı her yerde dplyr hissini vermeyi amaçlıyor ve SQL’e derleniyor
      Kişisel olarak dplyr, Polars ve Pandas’ın geliştirici deneyimi ile SQL’in gücünü ve yaygınlığını birleştirdiğini düşünüyorum. Sorgular yalnızca Polars ve Pandas’ta değil; DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite gibi istediğiniz SQL uyumlu çalıştırma motorunda da çalıştırılabilir
      Düşüncelerinizi GitHub tartışmalarında (https://github.com/PRQL/prql/discussions) veya Discord’da (https://discord.com/invite/XWxbCrWr) duymak isterim. Not: Ben PRQL katkıcısıyım
    • R, Python ve Julia’nın dataframe’lerini hepsini kullanmış olmanız güzel. Bunların arasında hangisini en çok beğendiğinizi merak ediyorum. Ekosistemler doğrudan karşılaştırılabilir olmayabilir, ama temel işlemler gibi işler açısından hangisi en iyiydi?
    • DuckDB arka uçlu Ibis’i de denemeye değer. Kişisel olarak Polars’ı da oldukça seviyorum. Geliştiriciler genel olarak sorunlara epey hızlı yanıt veriyor
  • Veri bilimi ekibimiz Polars’ı değerlendirdi ve sonuçlar karışıktı. Performansın kritik olduğu bölümler varsa kullanmayı değerlendirebiliriz, ama bunun dışında onlarca projede Pandas’ı değiştirmenin maliyeti nedeniyle biraz olumsuz yaklaştık

    • Bu değerlendirmenin doğru olduğunu düşünüyorum. Bence şu an, zaten iyi çalışan Pandas’ın yerini alma zamanından çok deneme zamanı
      API’de hâlâ beklenebilecek kırılma yaratan değişiklikler var ve birden fazla projeye yayıldığında bakım yükü oluşturabilir. Yine de API şimdiden daha tutarlı hissettiriyor ve genel olarak doğru yöne gidiyor gibi
    • Tüm kodu baştan yazmamak daha iyi. Ancak yeni kodda benimsemeye veya değerlendirmeye değer
      Özellikle Pandas birlikte çalışabilirlik maliyeti çok düşük ve Arrow arka ucunu kullanırsanız Pandas’a zero-copy geçiş yapmak da oldukça kolay
    • İlerisi için https://github.com/fugue-project/fugue var
    • Ekipte pandasql kullanıp kullanmadığınızı, yoksa ağırlıklı olarak doğrudan Pandas API’sini mi kullandığınızı merak ediyorum