Alat baris perintah bisa 235x lebih cepat daripada klaster Hadoop (2014)

• Hasil pemrosesan sekitar 1,75GB data pertandingan catur dengan alat baris perintah alih-alih Hadoop selesai hanya dalam 12 detik, menunjukkan kinerja lebih dari 235x lebih cepat dibanding 26 menit di Hadoop
• Dengan menggabungkan perintah shell dasar seperti grep, sort, uniq, awk, xargs, mawk, dibangun pipeline pemrosesan streaming dengan penggunaan memori nyaris 0
• Melalui pemrosesan paralel xargs dan optimasi mawk, pemanfaatan inti CPU ditingkatkan dan bottleneck IO diminimalkan
• Dibanding memproses dataset yang sama di klaster Hadoop (7 instance c1.medium), biaya dan beban pemeliharaan jauh lebih rendah
• Ini menunjukkan bahwa analisis data yang efisien juga mungkin dilakukan di satu mesin, sekaligus menjadi peringatan terhadap penggunaan alat Big Data yang tidak perlu

---

Pendahuluan: pemrosesan baris perintah yang lebih cepat daripada Hadoop

• Setelah melihat contoh analisis sekitar 2 juta pertandingan catur dengan Amazon EMR dan mrjob, eksperimen yang sama direproduksi dengan pemrosesan streaming berbasis baris perintah
  • Di klaster Hadoop (7 c1.medium), memakan waktu 26 menit, dengan throughput 1,14MB/sec
  • Di laptop lokal, selesai dalam 12 detik, dengan throughput 270MB/sec
• Ini membuktikan bahwa pekerjaan agregasi hasil yang sederhana jauh lebih efisien dengan pipeline shell daripada Hadoop
• Dengan menggabungkan perintah shell, struktur pemrosesan stream paralel mirip Storm dapat diimplementasikan di satu mesin

Struktur data dan persiapan

• Data berbentuk catatan pertandingan catur format PGN (Portable Game Notation), dan hasil tiap pertandingan ditampilkan pada baris "Result"
  • "1-0" berarti putih menang, "0-1" berarti hitam menang, "1/2-1/2" berarti remis
• Sekitar dataset 3,46GB diperoleh dari repositori GitHub rozim/ChessData
  • Sekitar dua kali lebih besar daripada data eksperimen Tom Hayden (1,75GB)

Membangun pipeline dasar

• Untuk mengukur batas IO, menjalankan cat *.pgn > /dev/null memakan waktu sekitar 13 detik (272MB/sec)
• Pipeline analisis dasar:

  cat *.pgn | grep "Result" | sort | uniq -c
  

  • Waktu eksekusi sekitar 70 detik, sekitar 47x lebih cepat daripada Hadoop
• Menggunakan AWK untuk langsung mengagregasi hasil alih-alih sort | uniq
  • Waktu eksekusi 65 detik, penggunaan memori nyaris nol
  • grep memonopoli satu inti CPU dan menjadi bottleneck

Paralelisasi dan optimasi

• Memparalelkan grep dengan xargs

  find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
  

  • Waktu eksekusi 38 detik, sekitar peningkatan kecepatan 77x
• Menghapus grep dan menyederhanakan tahap dengan pemfilteran AWK saja
  • Dibangun pipeline AWK ganda untuk menggabungkan hasil tiap file
  • Waktu eksekusi 18 detik, sekitar 174x lebih cepat
• Optimasi tambahan dengan mengganti ke mawk

  find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
  

  • Waktu eksekusi 12 detik, 235x lebih cepat daripada Hadoop, dengan throughput 270MB/sec

Kesimpulan: efisiensi dari kesederhanaan

• Kecuali untuk kasus yang memang membutuhkan pemrosesan terdistribusi skala besar, kombinasi alat shell di satu mesin lebih cepat dan lebih ekonomis
• Hadoop sering dipakai secara berlebihan bahkan untuk pekerjaan yang sebenarnya cukup ditangani DB relasional atau skrip sederhana
• Analisis streaming berbasis baris perintah adalah alternatif unggul dari sisi kinerja, biaya implementasi, dan kemudahan pemeliharaan

[dongho42]

Dulu pernah ada istilah pemrograman Taco Bell, rasanya filosofinya mirip.

[GN⁺]

Komentar Hacker News

• Hal yang paling menyedihkan adalah tulisan ini berasal dari 2014
  Sekarang bahkan ada lebih banyak lapisan abstraksi seperti Airflow, dbt, Snowflake, jadi hal seperti ini dipasang bahkan pada dataset yang sebenarnya muat seluruhnya di RAM
  Startup membakar $5.000 per bulan untuk klaster terdistribusi hanya untuk memproses log kurang dari 10GB per hari. Alasannya, memakai ‘Modern Data Stack’ bisa membantu dapat promosi, sedangkan menyelesaikannya dengan skrip bash diabaikan sebagai ‘tidak bisa diskalakan’. Efisiensi dan insentif benar-benar tidak selaras

  • Dalam wawancara belakangan ini, mereka membicarakannya sebagai ‘masalah scaling’, tetapi pada kenyataannya sering kali semuanya cukup masuk ke satu mesin
    Ada juga kasus yang meng-ingest 1GB JSON per hari, dan ketika saya menjelaskan bahwa “satu mesin sudah cukup”, saya ditolak dengan alasan “secara teknis benar, tapi itu bukan jawaban yang kami inginkan”
    Mesin zaman sekarang punya RAM skala TB dan ratusan core. Satu mesin saja sudah sangat besar
  • Ini bukan cuma soal promosi, tapi juga masalah struktur perekrutan
    Saat merekrut orang berpengalaman DevOps, mereka menekankan pengalaman dengan framework yang mencolok, jadi ketika orang-orang itu masuk ke perusahaan, mereka mengulang hal yang sama
    Karena tidak ada yang menentang, pekerjaan yang sebenarnya cukup dijalankan di satu desktop akhirnya dibuat jadi rumit
  • Selama 20 tahun terakhir saya memakai ‘teknologi yang tepat’ alih-alih ‘teknologi yang terlihat keren’, dan akhirnya saya tetap di-PHK
    Dengan CV yang hampir tidak punya framework terbaru, saya sudah mencari kerja lebih dari setahun dan mulai merasa diri saya bodoh
  • Saya juga melihat hal serupa di perusahaan. Untuk memutar beberapa GB data per hari lewat berbagai sistem, pekerjaan yang dulu selesai dalam seminggu dengan skrip Python sekarang butuh berbulan-bulan dan sering rusak
  • Sekarang laptop RAM 128GB pun sudah umum, dan server jauh lebih besar lagi
    Pada 2014, 4GB itu umum, tetapi sekarang kecepatan streaming SSD juga jauh lebih cepat, jadi membaca dari SSD lokal kadang lebih baik daripada klaster

• Saya penulisnya!
  Senang rasanya tulisan lama ini masih bermanfaat
  Saya setuju dengan pendapat bahwa situasinya makin memburuk, tetapi di sisi lain saya juga senang melihat ada gerakan menjauh dari pemujaan microservices
  Saya mendukung semua orang yang berusaha meningkatkan performa. Masih ada harapan

  • Adam, terima kasih!
    Saya sudah membaca ulang tulisan ini berkali-kali, lalu terinspirasi untuk mem-port Waters-Series ke JavaScript dan membangun stream pipelining

• Di industri saat ini, persepsi bahwa Spark atau alat terdistribusi adalah jawaban untuk data engineering terlalu kuat
  Ini mirip dengan kecenderungan berlebihan memakai framework SPA di web development
  Saran saya seperti ini:

  • Manajer jangan meminta teknologi tertentu (Spark, React), tapi serahkan pada engineer yang punya kemampuan memecahkan masalah
  • Tech lead harus jujur mengatakan, “pipeline kami bisa menangani sampai 20GB, dan kalau lebih besar kami berencana memperluasnya dengan X/Y/Z”
    Yang ingin didengar manajer bukanlah ‘semuanya bisa diskalakan tanpa batas’, tetapi keyakinan bahwa ‘ini berjalan dengan stabil’
  • Sebagian besar perusahaan menangani data skala kecil
    Ukuran data mengikuti hukum pangkat, jadi engineer yang benar-benar menangani data skala petabyte itu sangat sedikit
    Tetapi karena orang ingin memasukkan pengalaman seperti itu ke CV demi kenaikan gaji, muncullah overengineering
  • Dulu saat bekerja di unicorn terkenal, manajer saya berkata, “kuartal depan kita harus memakai Spark”
    Ketika saya tanya alasannya, jawabannya “pokoknya harus”. Mungkin untuk CV atau alasan politis seseorang

• Ini cerita sejarah yang terkait dengan tulisan itu
  Alat bernama mrjob bisa dijalankan dalam mode lokal tanpa Hadoop
  Pada dataset kecil, ini jauh lebih cepat daripada klaster. Bahkan bisa selesai lebih cepat daripada klaster sementara seperti AWS EMR
  Tapi pendekatan penulis tampaknya akan lebih efisien lagi
  MapReduce memudahkan scaling besar, tetapi untuk data kecil ia membawa banyak batasan yang tidak efisien
  Pada awal 2010-an, mrjob dipakai untuk memproses data skala petabyte, tetapi sekarang hampir tidak dipakai lagi

• Saat bekerja sebagai data engineer, saya pernah menulis ulang skrip Bash/Python ke C# dan menaikkan kecepatan pemrosesan JSON sampai 1GB/s
  Hanya dengan optimasi sederhana seperti streaming parsing saja perbedaannya sudah besar
  Jadi saya penasaran — sebenarnya mulai dari ukuran data seperti apa clustering benar-benar masuk akal?

  • Sebaliknya, 15 tahun lalu saya juga pernah mengganti sistem C# yang rumit dengan bash + Python dan hasilnya jauh lebih cepat
    Menurut saya, kalau sebuah pekerjaan butuh lebih dari sehari, itu sudah layak dipertimbangkan untuk pemrosesan terdistribusi
  • Dulu di panel PyCon, seorang data scientist terkenal berkata bahwa “Excel lebih baik daripada Pandas”
    Katanya, kalau datanya besar, dia melakukan sampling lalu menganalisisnya di Excel. Sekarang berkat LLM, skrip Python/Bash sederhana pun mudah dibuat
  • Selain waktu pemrosesan, data yang tidak muat di disk lokal juga jadi kriteria lain
    Sekarang kita bisa membaca dan menulis langsung dari object storage seperti S3, dan saat ini kecepatan 100GB/s juga dimungkinkan
  • Dataset catur yang disebut di komentar ini berukuran sekitar 14TB
    Itu muat di disk, tetapi terlalu besar untuk laptop biasa
  • Saya penasaran bagaimana cara melakukan streaming parse pada JSON. Kebanyakan parser harus membaca semuanya dulu untuk memvalidasi sintaks, jadi saya ingin tahu bagaimana itu diatasi

• ‘Besar’-nya data bergantung pada apa yang ingin dilakukan
  Misalnya, untuk statistik sederhana pada data operasi, bash saja cukup, tetapi jika ingin menghitung korelasi antara pengalaman dokter dan tingkat keberhasilan, kompleksitasnya naik tajam
  Jadi dari sudut pandang perusahaan, jauh lebih mudah mengatakan “kami memakai Spark” daripada mengatakan “kami membuat engine khusus untuk tiap pertanyaan”

  • Tetapi bahkan dengan SQLite saja, kita bisa menangani 50GB sampai 2TB data
    Semua masalah yang disebutkan bisa diselesaikan di satu server dengan alat sederhana

• Tulisan ini sudah beberapa kali muncul di HN
  Versi 2018, versi 2022, dan versi 2024 semuanya diposting oleh pengirim yang sama

• Ini mengingatkan saya pada kalimat pengantar di situs web Shakti dulu
  “1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
  Sumber

• Banyak developer belajar di lingkungan Windows sehingga tidak terbiasa dengan alat CLI
  Tapi CLI menawarkan fitur-fitur kuat seperti loop implisit, pemisahan field otomatis, penerapan regex secara paralel, dan lain-lain
  Karena itu kita bisa cepat membuat solusi ad-hoc, dan ini jadi titik awal yang baik sebelum memakai sistem berskala besar

• Saya jadi penasaran bagaimana kalau benchmark-nya diulang dengan data catur yang diperbesar lagi
  Saat ini dataset Lichess sekitar 7B game, 2,34TB terkompresi (14TB tidak terkompresi)
  Saya penasaran apakah pada skala seperti ini Hadoop bisa menang

  • Jika beberapa SSD cepat dipasang di satu server, sepertinya itu masih akan lebih cepat daripada EMR+S3
    Hanya saja itu berarti perlu mengelola server khusus
    EMR adalah model yang dirancang untuk pemrosesan paralel saat frekuensi akses datanya rendah (1–10 kali per hari)
  • Data yang terkompresi cukup muat di SSD lokal, dan dekompresi streaming juga memungkinkan
  • Saya penasaran apa yang akan dihitung dengan data seperti ini. Menarik juga kalau diuji di NVL72