Halaman ini menjelaskan penyesuaian performa untuk operasi JOIN
di Cloud Data Fusion.
Operasi JOIN
dapat menjadi bagian pipeline yang paling mahal. Seperti halnya semua
yang lain dalam pipeline, operasi dijalankan secara paralel. Langkah pertama
JOIN
adalah mengacak data sehingga setiap kumpulan data dengan kunci JOIN
yang sama dikirim
ke eksekutor yang sama. Setelah semua data diacak, data tersebut akan digabungkan, dan
output akan berlanjut melalui pipeline.
Contoh pemrosesan paralel dalam operasi JOIN
Misalnya, Anda melakukan operasi JOIN
pada set data yang disebut
Purchases
dan Items
. Setiap catatan pembelian berisi nama dan nomor item
yang dibeli. Setiap catatan item berisi nama item dan harga item tersebut. JOIN
dijalankan pada nama item untuk menghitung total harga setiap
pembelian. Saat data digabungkan, data akan diacak ke seluruh cluster sehingga
record dengan ID yang sama berakhir di eksekutor yang sama.
Jika kunci JOIN
didistribusikan secara merata, operasi JOIN
akan berperforma
baik karena dapat dijalankan secara paralel.
Seperti pengacakan lainnya, data yang terdistorsi akan berdampak negatif pada performa. Dalam contoh
sebelumnya, telur jauh lebih sering dibeli daripada ayam atau susu, yang
berarti eksekutor yang bergabung dalam pembelian telur melakukan lebih banyak pekerjaan daripada eksekutor
lainnya. Jika Anda melihat bahwa JOIN
condong, ada dua cara untuk meningkatkan
performa.
Pisahkan partisi yang miring secara otomatis
Dengan eksekusi kueri adaptif, distorsi yang sangat berat akan ditangani secara otomatis.
Segera setelah JOIN
menghasilkan beberapa partisi yang jauh lebih besar daripada partisi lainnya, partisi tersebut akan dibagi menjadi partisi yang lebih kecil. Untuk mengonfirmasi bahwa Anda telah mengaktifkan eksekusi kueri adaptif,
lihat Penyesuaian otomatis.
Gunakan JOIN
dalam memori
JOIN
dalam memori dapat dilakukan jika satu sisi JOIN
cukup kecil
untuk muat dalam memori. Dalam situasi ini, set data kecil dimuat ke dalam memori,
lalu disiarkan ke setiap eksekutor. Set data besar tidak diacak sama sekali, untuk menghapus partisi tidak merata yang dihasilkan saat mengacak
kunci JOIN
.
Pada contoh sebelumnya, set data item pertama kali dimuat ke dalam memori driver Spark. Data tersebut kemudian disiarkan ke setiap eksekutor. Eksekutor kini dapat menggabungkan data tanpa mengacak set data pembelian.
Pendekatan ini mengharuskan Anda memberikan memori yang cukup bagi driver dan
eksekutor Spark agar dapat menyimpan set data siaran di memori. Secara default, Spark mencadangkan kurang dari 30% memorinya untuk menyimpan jenis data ini. Saat menggunakan JOIN
dalam memori, kalikan ukuran set data dengan empat dan
tetapkan sebagai eksekutor dan memori driver. Misalnya, jika set data item
berukuran 1 GB, kita harus menetapkan memori eksekutor dan driver ke
setidaknya 4 GB. Set data yang lebih besar dari 8 GB tidak dapat dimuat ke dalam memori.
Distribusi kunci
Jika kedua sisi JOIN
terlalu besar untuk dimuat dalam memori, teknik
yang berbeda dapat digunakan untuk membagi setiap kunci JOIN
menjadi beberapa kunci untuk meningkatkan
tingkat paralelisme. Teknik ini dapat diterapkan ke operasi INNER JOIN
dan
LEFT OUTER JOIN
. Class ini tidak dapat digunakan untuk operasi FULL OUTER JOIN
.
Dalam pendekatan ini, sisi yang miring diberi salt dengan kolom bilangan bulat baru dengan
angka acak dari 1 hingga N. Sisi yang tidak miring akan meledak, dengan setiap baris yang ada
menghasilkan N
baris baru. Kolom baru ditambahkan ke sisi yang meledak, diisi
dengan setiap angka dari 1 hingga N. JOIN
normal kemudian dijalankan, kecuali kolom
baru ditambahkan sebagai bagian dari kunci JOIN
. Dengan cara ini, semua data yang sebelumnya
diarahkan ke satu partisi kini tersebar hingga N
partisi yang berbeda.
Pada contoh sebelumnya, faktor distribusi N
ditetapkan ke 3
. Set data asli
ditampilkan di sebelah kiri. Versi {i>salt<i} dan {i>exploide<i} dari {i>dataset<i}
ditampilkan di tengah. Data yang diacak ditampilkan di sebelah kanan, dengan
tiga eksekutor berbeda bergabung dengan pembelian telur, bukan satu.
Paralelisme yang lebih baik dicapai dengan meningkatkan distribusi. Namun, hal ini mengakibatkan ledakan di satu sisi JOIN
, sehingga lebih banyak data yang diacak di seluruh cluster. Oleh karena itu, manfaatnya akan berkurang seiring meningkatnya
distribusi. Biasanya, tetapkan nilainya ke 20 atau kurang.
Langkah selanjutnya
- Pelajari pemrosesan paralel di Cloud Data Fusion lebih lanjut.