- 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
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
- 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
Belum ada komentar.