Data 650GB (Delta Lake di S3). Polars vs. DuckDB vs. Daft vs. Spark

 (dataengineeringcentral.substack.com)
8 poin oleh GN⁺ 2025-11-16 | 1 komentar | Bagikan ke WhatsApp
  • Eksperimen perbandingan performa untuk memproses data Delta Lake berukuran 650GB yang disimpan di S3 menggunakan Polars, DuckDB, Daft, dan Spark dalam lingkungan single-node
  • Memverifikasi apakah tiap engine dapat menangani data berukuran besar pada instance EC2 dengan memori 32GB, sambil mengeksplorasi kemungkinan single-node dibanding Spark berbasis klaster
  • DuckDB membutuhkan 16 menit, Polars 12 menit, Daft 50 menit, dan PySpark lebih dari 1 jam, yang menunjukkan kelayakan pemrosesan nyata bahkan di single-node
  • Polars tidak mendukung Deletion Vector, sementara hanya DuckDB yang mendukung fitur tersebut, sehingga ada perbedaan dalam kompatibilitas Lake House
  • Secara keseluruhan, eksperimen ini membuktikan bahwa framework single-node mampu memproses data skala besar bahkan pada hardware berbiaya rendah, dan memunculkan kebutuhan untuk meninjau kembali ketergantungan pada komputasi terdistribusi

Kelelahan terhadap klaster dan alternatif single-node

  • Disebutkan fenomena "cluster fatigue" seiring meningkatnya biaya dan kompleksitas operasional klaster Lake House berbasis SaaS
  • Dulu Spark digunakan karena tidak ada alternatif selain Pandas, tetapi kemunculan DuckDB, Polars, dan Daft (D.P.D.) memperluas kemungkinan pemrosesan single-node
  • D.P.D. memungkinkan pemrosesan dataset yang lebih besar dari memori (LTM) dan komputasi berkecepatan tinggi
  • Tulisan ini menawarkan dua pilihan, terdistribusi dan non-terdistribusi, sambil menekankan konsep "Single Node Rebellion"

Susunan lingkungan eksperimen

  • Membuat tabel Delta Lake di S3 dan menyimpan sekitar 650GB data (target awal 1TB, tetapi dihentikan)
  • Menjalankan DuckDB, Polars, dan Daft pada instance EC2 (32GB RAM, 16 CPU) lalu membandingkannya dengan Spark
  • Data berupa data simulasi berbentuk posting media sosial; dibuat sebagai Python dict, diubah menjadi Daft DataFrame, lalu disimpan sebagai file Parquet
  • Setelah itu, file Parquet dikonversi menjadi tabel Delta Lake di Databricks, dengan partisi per tahun dan bulan
  • Jika log Delta dikecualikan, terkonfirmasi ada sekitar 650GB data
Iklan

Batasan memori dan kebutuhan streaming

  • Karena 650GB data harus diproses pada single-node dengan memori 32GB, muncul kebutuhan untuk menjalankan query dengan metode streaming
  • Dengan mengutip issue di GitHub Polars, disebutkan contoh kebutuhan akan fitur penulisan streaming ke Iceberg
  • Ditekankan bahwa framework baru seperti Polars dan DuckDB memerlukan dukungan bawaan untuk membaca dan menulis format Lake House secara streaming

Hasil pengujian tiap engine

  • DuckDB
    • Satu-satunya yang mendukung Deletion Vector
    • Berhasil memproses 650GB data di mesin Linux 32GB hanya dalam 16 menit
    • Kodenya sederhana dan file hasil berhasil dibuat dengan normal
  • Polars
    • Karena tidak mendukung Deletion Vector, ada keterbatasan di lingkungan Lake House
    • Perlu menggunakan Lazy API (Scan/Sink)
    • Selesai diproses dalam 12 menit, lebih cepat daripada DuckDB
  • Daft
    • Berbasis Rust, nyaman digunakan, tetapi waktu proses 50 menit sehingga menjadi yang paling lambat
    • Dipastikan berjalan stabil dalam pekerjaan terkait Iceberg
    Iklan
  • PySpark (Databricks Single Node)
    • Memerlukan lebih dari 1 jam, dijalankan tanpa tuning
    • Efisiensinya lebih rendah dibanding engine single-node
    • Tujuan eksperimen ini bukan semata kecepatan, melainkan memverifikasi kelayakan single-node

Kesimpulan dan implikasi

  • Eksperimen ini membuktikan bahwa framework single-node dapat memproses data Lake House berukuran besar
  • Bahkan pada hardware berbiaya rendah, diperoleh waktu eksekusi yang masuk akal dan struktur kode yang sederhana
  • DuckDB, Polars, dan Daft semuanya memberikan performa yang praktis tanpa klaster terdistribusi
  • Ini menunjukkan bahwa komputasi terdistribusi bukan satu-satunya solusi, dan mendorong peninjauan ulang arsitektur Lake House modern
  • Melalui konsep "Single Node Rebellion", artikel ini menyoroti kemungkinan pendekatan data engineering yang lebih efisien dari sisi biaya

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-16
Opini Hacker News
  • Saya adalah software engineer yang bekerja di Eventual, dan ingin mengucapkan terima kasih karena telah membagikan benchmark untuk Daft yang dibuat tim kami
    Daft adalah mesin pemrosesan data berkinerja tinggi untuk workload AI, dan berjalan baik di lingkungan single-node maupun terdistribusi
    Melalui benchmark kali ini, kami menemukan banyak ruang untuk peningkatan pada paralelisme dan pipelining. Terutama pada pembaca deltalake dan operator groupby, masih banyak bagian yang bisa dioptimalkan
    Kami berencana memasukkan perbaikan ini pada rilis mendatang, dan detail lebih lanjut dapat dilihat di GitHub, Twitter, LinkedIn
    Jika Daft terdengar menarik, Anda bisa langsung mencobanya dengan pip install daft
    • Saya penasaran apakah ada rencana untuk mengekspos Daft sebagai backend ibis. Kalau begitu, akan lebih mudah untuk berpindah mulus dari engine lain sambil melakukan pengujian
    • Ini terlihat seperti akun yang dibuat untuk promosi perusahaan
  • Awk? Ada tulisan menarik terkait hal ini — Command-line tools can be 235x faster than your Hadoop cluster
  • 650GB? Itu data yang cukup kecil sampai-sampai bisa masuk ke ponsel saya
    Daripada tooling berlebihan, pakai saja tool GNU
    Sebagai referensi, ini tulisan lama tapi masih menarik — command-line tools can be 235x faster than your Hadoop cluster
    • Sekarang sudah berbeda dengan era Hadoop 2014 yang dibahas artikel itu
      Kalau Anda mencoba mengagregasi 650GB data JSON dengan tool CLI, akan sulit menyaingi kinerja pemrosesan paralel DuckDB atau ClickHouse. Saya juga pernah mencoba dengan GNU Parallel, tetapi ada batasannya
    • Kalau 650TB, ceritanya akan sepenuhnya berbeda. Artikel itu hanyalah microbenchmark
      Dalam praktik nyata, Anda akan memerlukan katalog data dan pekerjaan berbasis klaster
    • Membagikan video ini sambil bercanda, “Saya sudah lupa cara menghitung angka sekecil itu”
  • Saya cukup sering memproses ‘biggish data’ di single node dengan DuckDB
    Saya men-query dengan menelusuri file Parquet secara langsung alih-alih memakai Delta atau Iceberg
    Saya mengunduh hasil query dari BigQuery ke file Parquet lokal (sekitar 1GB per file) lalu menganalisisnya dengan DuckDB. Datanya jauh lebih besar daripada RAM, tetapi tetap berjalan baik
    Saya juga membandingkan perbedaan kinerja agregasi antara BigQuery dan DuckDB, lalu membagi pekerjaan agar dijalankan di dua engine itu. Kombinasi seperti ini adalah bagian menarik dari data engineering
    • Untuk sekitar 650GB, pemrosesan di filesystem lokal pun sudah sangat memungkinkan. Tidak perlu tool yang rumit
  • Benchmark kali ini tampak seperti eksperimen yang sepenuhnya didominasi oleh bandwidth NIC
    Dengan bandwidth maksimum 10Gbps pada instance c5.4xlarge, membaca 650GB dari S3 akan memakan waktu minimal 9 menit
    Perbedaan kecil dalam cara penjadwalan I/O kemungkinan besar memberi pengaruh besar pada hasil
    Bahkan, bisa jadi lebih ekonomis memakai instance yang lebih besar agar selesai lebih cepat
    • Akan menarik juga kalau diuji di desktop biasa atau laptop yang lumayan
      Penyimpanan NVMe jauh lebih cepat daripada S3, dan CPU lokal 8–16 core bisa jadi lebih baik daripada cloud
      S3 adalah produk yang hebat, tetapi tidak bisa menandingi kinerja storage lokal
    • Kemungkinan besar query sebenarnya tidak memindai seluruh file, melainkan memanfaatkan pembacaan byte-range S3 untuk hanya memproses sebagian kolom
      Distribusi ukuran file atau skew pada panggilan API mungkin justru menjadi variabel yang lebih besar
      Saya sepenuhnya setuju dengan pernyataan bahwa “instance yang lebih besar bisa jadi selesai lebih murah”
    • Nilai eksperimen ini tidak begitu jelas
      Spark cocok untuk dataset besar multi-tahap, dan ketika memakai S3 sebagai backend, bottleneck jaringan akan terlihat langsung sebagai biaya
      Kinerja single-node DuckDB/Polars memang mengesankan, tetapi ini seperti memperlombakan pesawat di landasan dengan sepeda motor
    • 10Gbps itu terlalu rendah. Di Google mereka memakai NIC 400Gbps dan kontrol kemacetan TCP yang ditingkatkan
      Perbedaan seperti ini adalah salah satu alasan banyak orang merasa lelah dengan komputasi terdistribusi
    • Saya setuju dengan poin ini. Ada pelajaran yang saya dapat 30 tahun lalu di Wall Street — sebelum menguji kinerja sistem, pahami dulu batas maksimum teoretisnya
      Jika Anda memahami batas sumber daya dan mengekspresikan kinerja aktual sebagai rasio terhadap batas itu, hasilnya akan jauh lebih jelas
  • Tulisan ini adalah artikel yang menyesatkan dalam dua hal
    1. Kemungkinan besar sebenarnya diterapkan column pruning, sehingga hanya 2 kolom + metadata yang diakses
    2. Sebagian besar waktu kemungkinan habis pada S3 I/O, dan batas koneksi simultan memberi pengaruh lebih besar
      Bagus bahwa mereka mencoba berbagai sistem, tetapi saya berharap mereka benar-benar membahas query yang lebih besar daripada memori
    • Penting bahwa query ini merupakan projection yang hanya mengembalikan sebagian dari total 650GB
      DuckDB kuat dalam streaming yang melebihi memori, tetapi Polars masih belum matang
      Konfigurasi default S3 tidak menghalangi pembacaan paralel, jadi kemungkinan besar bandwidth jaringan VM-lah bottleneck utamanya
  • Baru-baru ini saya harus memproses beberapa TB data JSON, dan masalah utamanya adalah banyak sekali file kecil berukuran 10–20MB
    ClickHouse adalah yang tercepat, sementara DuckDB adalah yang terbaik dari sisi kesederhanaan dan stabilitas
    Flink dan PySpark 3–5 kali lebih lambat, dan Dask serta Ray juga terlalu lambat
    Sekarang saya biasanya menyarankan memulai dengan DuckDB atau ClickHouse untuk sebagian besar workload. Mengganti Pandas dengan DuckDB saat Pandas terasa lambat adalah strategi default saya
    • Saya penasaran apakah data JSON itu lebih dulu dikonversi ke format lain, atau Anda langsung bekerja di atas JSON
  • Polars bergantung pada delta-rs untuk dukungan Delta Lake, dan implementasi ini tidak mendukung Deletion vectors
    Bahkan dengan library single-node, sekitar 1TB masih sangat bisa ditangani, dan barulah di atas 10TB masuk akal beralih ke Spark
    Isu terkait
    • Banyak orang terlalu cepat beralih ke Spark dengan alasan “Spark mudah diparalelkan”
      Padahal sering kali masalahnya bisa diselesaikan dengan tool yang lebih baik
      Dulu ada engineer junior yang butuh 18 jam untuk memproses ratusan file JSON berukuran 5GB dengan penggabungan string Python,
      tetapi setelah diganti dengan tool konsol sederhana dan multiprocessing, waktunya turun menjadi 35 menit
      Memilih tool yang tepat adalah kuncinya
  • Presto (AWS Athena) mungkin merupakan alternatif yang lebih cepat dan lebih baik. Saya juga ingin menguji 650GB data secara lokal
    • Presto sekarang sudah berganti nama menjadi Trino
      Biaya maintenance dan operasionalnya sangat rendah, dan ini adalah tool dengan value-for-money yang baik
  • Format katalog DuckLake yang baru dari DuckDB juga tampak layak menjadi kandidat pengujian — ducklake.select
    • Fitur data inlining flush di DuckLake masih berada pada tahap alpha
      Untuk mengatasi masalah terlalu banyak file Parquet saat menulis batch kecil, DuckLake menyimpan data itu secara inline di DBMS (seperti Postgres)
      Fitur untuk menuliskannya kembali ke Parquet baru ditambahkan belakangan ini, jadi masih perlu distabilkan
      Dokumentasi terkait
    • Format DuckLake memiliki masalah ayam-dan-telur berupa ketergantungan SQL
      Katalognya harus direpresentasikan sebagai SQL DB, padahal salah satu kelebihan Parquet justru adalah menghindari kompleksitas itu
      Jika katalognya juga dibuat berbasis Parquet, sepertinya itu bisa menjadi format yang self-bootstrapping