KAL
Menu

Spark Connect

Pemisahan client-server dan DataFrame jarak jauh pada era Spark 4.x.

Daftar isi

Spark Connect adalah arsitektur klien-server yang memisahkan kode aplikasi dari sesi Spark yang menjalankannya, dan sejak Spark 4 posisinya menjadi jalur koneksi baku untuk aplikasi jarak jauh. Topik ini membahas cara kerjanya, apa yang berubah pada pola pemakaian DataFrame, dan batas-batas yang menyertainya. Setelah membacanya, perbedaan sesi lokal dengan sesi jarak jauh dapat dijelaskan, dan keputusan kapan memakai masing-masing dapat diambil dengan dasar yang jelas.

Masalah yang diselesaikan Spark Connect#

Pada arsitektur klasik, aplikasi Python membangun sesi Spark di dalam prosesnya sendiri, sehingga seluruh pustaka Python yang dipakai program harus dipasang di tempat yang sama dengan runtime Spark, dan driver menanggung beban perhitungan analitik maupun memori bagi data yang dibawa ke Python. Keterikatan ini membuat aplikasi analitik sulit dilekatkan pada alat modern seperti server web, IDE, atau layanan penjadwal, karena semuanya harus hidup di satu proses JVM yang sama.

Spark Connect memecahnya menjadi dua sisi yang berkomunikasi melalui gRPC. Sisi server menjalankan Spark sesungguhnya, sedangkan sisi klien hanya mengirim rencana DataFrame yang belum dieksekusi ke server. Karena rencanalah yang dikirim, bukan data maupun fungsi, aplikasi klien bebas berjalan di mana saja dengan pustaka Python apa pun, dan driver tidak lagi menanggung proses Python pengguna. Satu server juga dapat melayani banyak klien sekaligus dengan isolasi sesi per koneksi.

Model inilah yang dipakai lingkungan interaktif modern seperti notebook cloud dan IDE yang terhubung ke cluster, dan inilah alasan posisinya dinaikkan menjadi jalur baku pada era Spark 4. Kode DataFrame yang ditulis pembaca pada seluruh jalur ini tidak berubah antara mode lokal dan mode Connect, karena API-nya sama, sehingga keterampilan yang dibangun di sini berlaku pada kedua bentuk sesi.

Cara kerja rencana yang dikirim#

Ketika klien merakit transformasi, setiap pemanggilan metode menambah bagian pada pohon rencana yang belum dieksekusi, yang direpresentasikan sebagai protocol buffer. Baris df.filter(...).select(...) pada klien tidak menyentuh data sama sekali, dan begitu sebuah action dipanggil, seluruh pohon rencana dikirim ke server untuk dianalisis, dioptimalkan, dan dieksekusi. Hasil yang berupa data lalu disalurkan kembali ke klien secara aliran, sedangkan operasi yang hanya menghasilkan DataFrame baru tidak mengirim apa pun, karena rencananya tetap dirakit di sisi klien untuk dilanjutkan.

Pola ini menjelaskan dua sifat yang akan sering ditemui. Pertama, latency per interaksi lebih terasa karena setiap action melewati jaringan, sehingga kebiasaan menutup rantai dengan satu action yang matang lebih bernilai daripada banyak action kecil. Kedua, error analisis muncul dari server setelah action, sehingga umpan baliknya menempuh perjalanan yang sama. Kedua sifat ini konsisten dengan disiplin lazy yang telah dibangun sejak topik evaluasi lazy.

Skrip klien berikut adalah bentuk paling kecil pemakaian Spark Connect. Skrip ini tidak dijalankan pada verifikasi otomatis karena menuntut server Connect yang hidup sebagai proses jangka panjang, dan bentuk keluarannya sama dengan sesi lokal untuk data yang sama.

python klien_connect.py 
# tidak-dijalankan
from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .remote("sc://localhost:15002")
    .appName("klien-connect")
    .getOrCreate()
)

df = spark.read.parquet("/tmp/lokasi/parquet_ujian")
df.groupBy("kelas").count().orderBy("kelas").show()

spark.stop()

Perbedaannya dengan sesi lokal hanya ada pada .remote("sc://localhost:15002") yang menggantikan .master("local[2]"), dengan alamat server Connect yang melayani koneksi. Servernya sendiri dinyalakan sebagai proses terpisah yang terus hidup, dan beberapa klien dapat memakainya bersamaan. Seluruh bagian lain skrip, mulai dari spark.read sampai show, identik dengan yang dipraktikkan sepanjang jalur ini.

Batas dan hal yang perlu diperhatikan#

Tidak semua API hadir dengan cara yang sama pada sesi jarak jauh. Fitur yang menuntut akses langsung ke driver atau pustaka yang dieksekusi bersama JVM, misalnya sebagian penggunaan RDD tingkat rendah dan beberapa bentuk pemetaan Python yang berat, tidak tersedia atau berperilaku berbeda karena klien tidak hidup di dalam proses Spark. UDF tetap didukung, tetapi isinya dikirim ke server pada saat eksekusi, sehingga pustaka yang diimpor oleh fungsi tersebut wajib tersedia di sisi server.

Pemantauan juga bergeser. Job yang dilihat pada Spark UI milik server, bukan milik klien, dan aplikasi yang muncul di UI dikelompokkan per sesi koneksi. Kebiasaan menyertakan appName yang bermakna menjadi lebih penting karena itulah jejak yang membedakan klien satu dengan lainnya pada UI server.

Pemilihan sesi pada akhirnya mengikuti tempat data dan pemakainya berada. Mode lokal tetap pilihan tepat untuk belajar, eksperimen kecil, dan pengujian, sebagaimana dipakai sepanjang jalur ini, sedangkan Spark Connect dipakai ketika cluster diakses dari aplikasi, layanan, atau lingkungan interaktif yang tidak boleh menyatu dengan JVM Spark. Karena API-nya sama, perpindahan di antara keduanya adalah perubahan satu baris builder, dan sisanya adalah kebiasaan yang telah dilatih.

Kesalahan umum#

Kesalahan pertama adalah menganggap sesi Connect identik sepenuhnya dengan sesi lokal, lalu memakai fitur yang menuntut kesatuan proses. Error yang muncul menyebut fitur tidak didukung pada sesi jarak jauh, dan perbaikannya adalah memindahkan bagian tersebut ke sisi server atau merancang ulang dengan API DataFrame yang didukung.

Kesalahan kedua adalah lupa menyalakan server sebelum klien. Klien yang gagal tersambung memunculkan error koneksi dengan alamat yang dicoba, dan perbaikannya ada di sisi server, bukan pada kode DataFrame. Cocokkan alamat dan port pada builder dengan yang benar-benar dilayani server.

Kesalahan ketiga adalah mengira pustaka Python klien otomatis tersedia di server. UDF yang mengimpor pustaka tertentu memerlukan pustaka itu pada sisi server, sehingga daftar dependensi kedua sisi perlu dipelihara secara sadar, terutama pada pipeline yang memakai pandas UDF.

Ringkasan#

  • Spark Connect memisahkan klien dari server Spark melalui gRPC, dengan rencana DataFrame tak beroperasi sebagai muatan yang dikirim.
  • API DataFrame tidak berubah antara mode lokal dan Connect, dan perbedaannya pada builder adalah .remote("sc://...") menggantikan .master(...).
  • Latency per action bergeser ke jaringan, job tercatat pada UI server, dan fitur yang menuntut kesatuan proses dengan JVM tidak tersedia atau berbeda.
  • Mode lokal tetap cocok untuk belajar dan eksperimen, sedangkan Connect dipakai saat cluster diakses dari aplikasi dan lingkungan interaktif yang terpisah.

Referensi#