Memigrasikan Tugas Apache Spark ke Dataproc

Dokumen ini menjelaskan cara memindahkan tugas Apache Spark ke Dataproc. Dokumen ini ditujukan untuk engineer dan arsitek big data. Panduan ini mencakup topik seperti pertimbangan untuk migrasi, persiapan, migrasi pekerjaan, dan manajemen.

Ringkasan

Jika Anda ingin memindahkan beban kerja Apache Spark dari lingkungan lokal ke Google Cloud, sebaiknya gunakan Dataproc untuk menjalankan cluster Apache Spark/Apache Hadoop. Dataproc adalah layanan yang dikelola sepenuhnya dan didukung sepenuhnya yang ditawarkan oleh Google Cloud. Dengan layanan ini, Anda dapat memisahkan penyimpanan dan komputasi, sehingga Anda dapat mengelola biaya dan menjadi lebih fleksibel dalam menskalakan workload.

Jika lingkungan Hadoop terkelola tidak sesuai dengan kebutuhan Anda, Anda juga dapat menggunakan penyiapan lain, seperti menjalankan Spark di Google Kubernetes Engine (GKE), atau menyewa virtual machine di Compute Engine dan menyiapkan sendiri cluster Hadoop atau Spark. Namun, pertimbangkan bahwa opsi selain menggunakan Dataproc dikelola sendiri dan hanya memiliki dukungan komunitas.

Merencanakan migrasi Anda

Ada banyak perbedaan antara menjalankan tugas Spark di infrastruktur lokal dan menjalankan tugas Spark di cluster Dataproc atau Hadoop di Compute Engine. Penting untuk memperhatikan beban kerja Anda dan mempersiapkan migrasi. Di bagian ini, kami menjelaskan pertimbangan yang perlu dipertimbangkan, dan persiapan yang harus dilakukan sebelum Anda memigrasikan tugas Spark.

Mengidentifikasi jenis pekerjaan dan cluster rencana

Ada tiga jenis beban kerja Spark, sebagaimana dijelaskan di bagian ini.

Tugas batch yang dijadwalkan secara teratur

Tugas batch yang dijadwalkan secara rutin mencakup kasus penggunaan seperti ETL harian atau per jam, atau pipeline untuk melatih model machine learning dengan Spark ML. Untuk kasus ini, sebaiknya buat cluster untuk setiap beban kerja batch, lalu hapus cluster setelah tugas Anda selesai. Anda memiliki fleksibilitas untuk mengonfigurasi cluster, karena Anda dapat menyesuaikan konfigurasi untuk setiap beban kerja secara terpisah. Cluster Dataproc ditagih dalam kelipatan satu detik blok setelah satu menit pertama, sehingga pendekatan ini juga hemat biaya karena Anda dapat memberi label pada cluster. Untuk mengetahui informasi selengkapnya, lihat halaman harga Dataproc.

Anda dapat menerapkan tugas batch dengan template alur kerja atau dengan mengikuti langkah-langkah berikut:

Buat cluster dan tunggu hingga cluster dibuat. (Anda dapat memantau apakah cluster telah dibuat menggunakan panggilan API atau perintah gcloud.) Jika Anda menjalankan tugas pada cluster Dataproc khusus, mungkin akan ada gunanya untuk menonaktifkan alokasi dinamis dan layanan acak eksternal. Perintah gcloud berikut menunjukkan properti konfigurasi Spark yang disediakan saat Anda membuat cluster Dataproc:
```
dataproc clusters create ... \
    --properties 'spark:spark.dynamicAllocation.enabled=false,spark:spark.shuffle.service.enabled=false,spark.executor.instances=10000'
```

Kirim tugas Anda ke cluster. (Anda dapat memantau status tugas menggunakan panggilan API atau perintah gcloud.) Contoh:

jobId=$(gcloud --quiet dataproc jobs submit pyspark \
    --async \
    --format='value(reference.jobId)' \
    --cluster $clusterName \
    --region global \
    gs://dataproc-examples-2f10d78d114f6aaec76462e3c310f31f/src/pyspark/hello-world/hello-world.py)

gcloud dataproc jobs describe $jobId \
    --region=global \
    --format='value(status.state)'

Hapus cluster setelah tugas dijalankan menggunakan panggilan API atau perintah gcloud.

Tugas streaming

Untuk tugas streaming, Anda harus membuat cluster Dataproc yang berjalan lama dan mengonfigurasi cluster tersebut agar berjalan dalam mode ketersediaan tinggi. Sebaiknya jangan gunakan preemptible VM untuk kasus ini.

Workload ad hoc atau interaktif yang dikirimkan oleh pengguna

Contoh beban kerja ad hoc dapat mencakup pengguna yang menulis kueri atau menjalankan tugas analisis pada siang hari.

Untuk kasus ini, Anda harus memutuskan apakah cluster perlu dijalankan dalam mode ketersediaan tinggi, ingin menggunakan preemptible VM, dan cara mengelola akses ke cluster. Anda dapat menjadwalkan pembuatan dan penghentian cluster (misalnya, jika Anda tidak memerlukan cluster di malam hari atau akhir pekan), dan Anda dapat mengimplementasikan penskalaan naik dan turun sesuai jadwal.

Mengidentifikasi sumber dan ketergantungan data

Setiap tugas memiliki dependensinya sendiri (misalnya, sumber data yang dibutuhkan), dan tim lain di perusahaan Anda mungkin bergantung pada hasil pekerjaan Anda. Oleh karena itu, Anda harus mengidentifikasi semua dependensi, lalu membuat rencana migrasi yang menyertakan prosedur untuk hal berikut:

Migrasi langkah demi langkah semua sumber data Anda ke Google Cloud. Pada awalnya, sebaiknya cerminkan sumber data di Google Cloud sehingga Anda memilikinya di dua tempat.
Migrasi tugas demi tugas dari workload Spark Anda ke Google Cloud segera setelah sumber data yang sesuai telah dimigrasikan. Seperti halnya data, pada waktu tertentu Anda mungkin memiliki dua workload yang berjalan secara paralel, baik di lingkungan lama maupun di Google Cloud.
Migrasi workload lain yang bergantung pada output workload Spark Anda. Atau, Anda dapat mereplikasi outputnya kembali ke lingkungan awal.
Penonaktifan tugas Spark di lingkungan lama setelah semua tim dependen mengonfirmasi bahwa mereka tidak lagi memerlukan tugas tersebut.

Pilih opsi penyimpanan

Ada dua opsi penyimpanan yang dapat digunakan dengan cluster Dataproc: Anda dapat menyimpan semua data di Cloud Storage, atau menggunakan disk lokal atau persistent disk dengan pekerja cluster. Pilihan yang benar tergantung pada karakter pekerjaan Anda.

Membandingkan Cloud Storage dan HDFS

Setiap node cluster Dataproc memiliki konektor Cloud Storage yang terinstal di dalamnya. Secara default, konektor diinstal di /usr/lib/hadoop/lib. Konektor ini menerapkan antarmuka FileSystem Hadoop dan membuat Cloud Storage kompatibel dengan HDFS.

Karena Cloud Storage adalah sistem penyimpanan objek besar (BLOB) biner, konektor mengemulasi direktori sesuai dengan nama objek. Anda dapat mengakses data dengan menggunakan awalan gs://, bukan awalan hdfs://.

Konektor Cloud Storage biasanya tidak memerlukan penyesuaian apa pun. Namun, jika perlu melakukan perubahan, Anda dapat mengikuti petunjuk untuk mengonfigurasi konektor. Daftar lengkap kunci konfigurasi juga tersedia.

Cloud Storage adalah opsi yang bagus jika:

Data Anda dalam ORC, Parquet, Avro, atau format lainnya akan digunakan oleh berbagai cluster atau tugas, dan Anda memerlukan persistensi data jika cluster dihentikan.
Anda memerlukan throughput yang tinggi dan data akan disimpan dalam file yang berukuran lebih dari 128 MB.
Anda memerlukan ketahanan lintas zona untuk data Anda.
Anda memerlukan data yang memiliki ketersediaan tinggi. Misalnya, Anda ingin menghapus NameNode HDFS sebagai titik tunggal kegagalan.

Penyimpanan HDFS lokal adalah opsi yang baik jika:

Tugas Anda memerlukan banyak operasi metadata—misalnya, Anda memiliki ribuan partisi dan direktori, dan setiap ukuran file relatif kecil.
Anda sering mengubah data HDFS atau mengganti nama direktori. (Objek Cloud Storage tidak dapat diubah, sehingga mengganti nama direktori adalah operasi yang mahal karena terdiri dari penyalinan semua objek ke kunci baru dan menghapusnya setelahnya.)
Anda akan sering menggunakan operasi append pada file HDFS.
Anda memiliki beban kerja yang melibatkan I/O yang berat. Misalnya, Anda memiliki banyak penulisan yang dipartisi, seperti berikut:
```
spark.read().write.partitionBy(...).parquet("gs://")
```
Anda memiliki beban kerja I/O yang sangat sensitif terhadap latensi. Misalnya, Anda memerlukan latensi milidetik satu digit per operasi penyimpanan.

Secara umum, kami merekomendasikan penggunaan Cloud Storage sebagai sumber data awal dan akhir di pipeline big data. Misalnya, jika alur kerja berisi lima tugas Spark secara seri, tugas pertama akan mengambil data awal dari Cloud Storage, lalu menulis data acak dan output tugas menengah ke HDFS. Tugas Spark terakhir akan menulis hasilnya ke Cloud Storage.

Menyesuaikan ukuran penyimpanan

Dengan menggunakan Dataproc dengan Cloud Storage, Anda dapat mengurangi persyaratan disk dan menghemat biaya dengan menempatkan data Anda di sana, bukan di HDFS. Jika Anda menyimpan data di Cloud Storage dan tidak menyimpannya di HDFS lokal, Anda dapat menggunakan disk yang lebih kecil untuk cluster Anda. Dengan menjadikan cluster Anda benar-benar sesuai permintaan, Anda juga dapat memisahkan penyimpanan dan komputasi, seperti yang disebutkan sebelumnya, yang membantu Anda mengurangi biaya secara signifikan.

Meskipun Anda menyimpan semua data di Cloud Storage, cluster Dataproc Anda memerlukan HDFS untuk operasi tertentu seperti menyimpan file kontrol dan pemulihan, atau menggabungkan log. Alat ini juga memerlukan ruang disk lokal non-HDFS untuk shuffling. Anda dapat mengurangi ukuran disk per pekerja jika tidak banyak menggunakan HDFS lokal.

Berikut beberapa opsi untuk menyesuaikan ukuran HDFS lokal:

Kurangi ukuran total HDFS lokal dengan mengurangi ukuran persistent disk utama untuk master dan pekerja. Persistent disk utama juga berisi volume booting dan library sistem, jadi alokasikan minimal 100 GB.
Tingkatkan ukuran total HDFS lokal dengan menambah ukuran persistent disk utama untuk pekerja. Pertimbangkan opsi ini dengan cermat. Penggunaan HDFS dengan persistent disk standar jarang terjadi pada workload yang mendapatkan performa lebih baik dibandingkan dengan menggunakan Cloud Storage atau HDFS lokal dengan SSD.
Pasang hingga delapan SSD (masing-masing 375 GB) ke setiap pekerja dan gunakan disk ini untuk HDFS. Ini adalah opsi yang bagus jika Anda perlu menggunakan HDFS untuk beban kerja I/O yang intensif dan Anda memerlukan latensi milidetik satu digit. Pastikan Anda menggunakan jenis mesin yang memiliki cukup CPU dan memori pada pekerja untuk mendukung disk ini.
Gunakan persistent-disk SSD (PD-SSD) untuk master atau worker Anda sebagai disk utama.

Mengakses Dataproc

Mengakses Dataproc atau Hadoop di Compute Engine berbeda dengan mengakses cluster lokal. Anda perlu menentukan setelan keamanan dan opsi akses jaringan.

Networking

Semua instance VM dari cluster Dataproc memerlukan jaringan internal satu sama lain, dan memerlukan port UDP, TCP, dan ICMP terbuka. Anda dapat mengizinkan akses ke cluster Dataproc dari alamat IP eksternal dengan menggunakan konfigurasi jaringan default atau menggunakan jaringan VPC. Cluster Dataproc Anda akan memiliki akses jaringan ke semua layanan Google Cloud (bucket Cloud Storage, API, dan sebagainya) dalam opsi jaringan apa pun yang Anda gunakan. Untuk mengizinkan akses jaringan ke atau dari resource lokal, pilih konfigurasi jaringan VPC dan siapkan aturan firewall yang sesuai. Untuk mengetahui detailnya, lihat panduan Konfigurasi Jaringan Cluster Dataproc dan bagian Akses YARN di bawah.

Pengelolaan akses dan identitas

Selain akses jaringan, cluster Dataproc Anda memerlukan izin untuk mengakses resource. Misalnya, untuk menulis data ke bucket Cloud Storage, cluster Dataproc Anda harus memiliki akses tulis ke bucket tersebut. Anda membuat akses menggunakan peran. Periksa kode Spark Anda dan temukan semua resource non-Dataproc yang diperlukan kode dan berikan peran yang benar ke akun layanan cluster. Selain itu, pastikan pengguna yang akan membuat cluster, tugas, operasi, dan template alur kerja memiliki izin yang tepat.

Untuk mengetahui detail lebih lanjut dan praktik terbaik, baca dokumentasi IAM.

Memverifikasi Spark dan dependensi library lainnya

Bandingkan versi Spark dan versi library lain dengan daftar versi Dataproc resmi, lalu cari library yang belum tersedia. Sebaiknya gunakan versi Spark yang didukung secara resmi oleh Dataproc.

Jika perlu menambahkan library, Anda dapat melakukan hal berikut:

Buat gambar kustom cluster Dataproc.
Buat skrip inisialisasi di Cloud Storage untuk cluster Anda. Anda dapat menggunakan skrip inisialisasi untuk menginstal dependensi tambahan, menyalin biner, dan sebagainya.
Kompilasi ulang kode Java atau Scala dan kemas semua dependensi tambahan yang bukan bagian dari distribusi dasar sebagai "fat jar" menggunakan Gradle, Maven, Sbt, atau alat lainnya.

Menyesuaikan ukuran cluster Dataproc

Dalam setiap konfigurasi cluster, baik di infrastruktur lokal maupun di cloud, ukuran cluster sangat penting bagi performa tugas Spark. Tugas Spark tanpa resource yang cukup akan menjadi lambat atau akan gagal, terutama jika tidak memiliki memori eksekutor yang cukup. Untuk mendapatkan saran tentang hal-hal yang perlu dipertimbangkan saat menentukan ukuran cluster Hadoop, lihat bagian mengubah ukuran cluster Anda di panduan migrasi Hadoop.

Bagian berikut menjelaskan beberapa opsi terkait cara mengukur cluster Anda.

Mendapatkan konfigurasi tugas Spark Anda saat ini

Lihat konfigurasi tugas Spark Anda saat ini dan pastikan cluster Dataproc cukup besar. Jika Anda berpindah dari cluster bersama ke beberapa cluster Dataproc (satu untuk setiap beban kerja batch), lihat konfigurasi YARN untuk setiap aplikasi agar Anda dapat memahami jumlah eksekutor yang dibutuhkan, jumlah CPU per eksekutor, dan total memori eksekutor. Jika cluster lokal Anda telah menyiapkan antrean YARN, lihat tugas mana yang berbagi resource setiap antrean dan identifikasi bottleneck. Migrasi ini merupakan peluang untuk menghapus pembatasan resource yang mungkin Anda miliki di cluster lokal.

Memilih jenis mesin dan opsi disk

Pilih jumlah dan jenis VM agar sesuai dengan kebutuhan workload Anda. Jika Anda memutuskan untuk menggunakan HDFS lokal untuk penyimpanan, pastikan VM memiliki jenis dan ukuran disk yang tepat. Jangan lupa untuk menyertakan kebutuhan resource program driver dalam kalkulasi Anda.

Setiap VM memiliki batas traffic keluar jaringan sebesar 2 Gbps per vCPU. Penulisan ke persistent disk atau SSD persisten diperhitungkan dalam batas ini, sehingga VM dengan jumlah vCPU yang sangat rendah dapat tertahan oleh batas tersebut saat menulis ke disk ini. Hal ini kemungkinan terjadi pada fase acak, saat Spark menulis data acak ke disk dan memindahkan data acak melalui jaringan di antara eksekutor. Persistent disk memerlukan setidaknya 2 vCPU untuk mencapai performa tulis maksimum, dan SSD persisten memerlukan 4 vCPU. Perlu diperhatikan bahwa nilai minimum ini tidak memperhitungkan traffic seperti komunikasi antar-VM. Selain itu, ukuran setiap disk memengaruhi performa puncak.

Konfigurasi yang Anda pilih akan memengaruhi biaya cluster Dataproc Anda. Harga Dataproc merupakan tambahan untuk harga per instance Compute Engine untuk setiap VM dan resource Google Cloud lainnya. Untuk mengetahui informasi lebih lanjut, dan untuk menggunakan kalkulator harga Google Cloud guna mengetahui perkiraan biaya Anda, lihat halaman harga Dataproc.

Membuat tolok ukur performa dan pengoptimalan

Setelah Anda menyelesaikan fase migrasi tugas, tetapi sebelum berhenti menjalankan workload Spark di cluster lokal, lakukan benchmark tugas Spark dan pertimbangkan pengoptimalan apa pun. Ingatlah bahwa Anda dapat resize cluster jika konfigurasi Anda tidak optimal.

Dataproc Serverless untuk penskalaan otomatis Spark

Gunakan Dataproc Serverless untuk menjalankan beban kerja Spark tanpa menyediakan dan mengelola cluster Anda sendiri. Tentukan parameter beban kerja, lalu kirimkan beban kerja ke layanan Dataproc Serverless. Layanan akan menjalankan beban kerja pada infrastruktur komputasi terkelola, melakukan penskalaan otomatis resource sesuai kebutuhan. Biaya Dataproc Serverless hanya berlaku pada saat beban kerja dieksekusi.

Melakukan migrasi

Bagian ini membahas cara memigrasikan data, mengubah kode tugas, dan mengubah cara tugas dijalankan.

Migrasikan data

Sebelum menjalankan tugas Spark apa pun di cluster Dataproc, Anda harus memigrasikan data ke Google Cloud. Untuk informasi lebih lanjut, lihat Panduan Migrasi Data.

Memigrasikan kode Spark

Setelah merencanakan migrasi ke Dataproc dan memindahkan sumber data yang diperlukan, Anda dapat memigrasikan kode tugas. Jika tidak ada perbedaan pada versi Spark antara kedua cluster, dan jika ingin menyimpan data di Cloud Storage, bukan HDFS lokal, Anda hanya perlu mengubah awalan semua jalur file HDFS dari hdfs:// menjadi gs://.

Jika Anda menggunakan versi Spark yang berbeda, lihat catatan rilis Spark, bandingkan kedua versi tersebut, dan sesuaikan kode Spark Anda dengan semestinya.

Anda dapat menyalin file jar untuk aplikasi Spark ke bucket Cloud Storage yang terkait dengan cluster Dataproc Anda atau ke folder HDFS. Bagian berikutnya menjelaskan opsi yang tersedia untuk menjalankan tugas Spark.

Jika memutuskan untuk menggunakan template alur kerja, sebaiknya uji setiap tugas Spark yang ingin ditambahkan secara terpisah. Kemudian, Anda dapat menjalankan pengujian akhir template untuk memastikan alur kerja template sudah benar (tidak ada tugas upstream yang hilang, output disimpan di lokasi yang tepat, dan seterusnya).

Menjalankan tugas

Anda dapat menjalankan tugas Spark dengan cara berikut:

Dengan menggunakan perintah gcloud berikut:
```
gcloud dataproc jobs submit [COMMAND]
```
dengan:

[COMMAND] adalah spark, pyspark, atau spark-sql

Anda dapat menetapkan properti Spark dengan opsi --properties. Untuk mengetahui informasi selengkapnya, lihat dokumentasi untuk perintah ini.
Dengan menggunakan proses yang sama seperti yang Anda gunakan sebelum memigrasikan tugas ke Dataproc. Cluster Dataproc harus dapat diakses dari infrastruktur lokal, dan Anda harus menggunakan konfigurasi yang sama.
Menggunakan Cloud Composer. Anda dapat membuat lingkungan (server Apache Airflow yang terkelola), menentukan beberapa tugas Spark sebagai alur kerja DAG, lalu menjalankan seluruh alur kerja.

Untuk detail selengkapnya, lihat panduan Mengirim Tugas.

Mengelola tugas setelah migrasi

Setelah memindahkan tugas Spark ke Google Cloud, penting untuk mengelola tugas ini menggunakan alat dan mekanisme yang disediakan oleh Google Cloud. Pada bagian ini, kami membahas logging, pemantauan, akses cluster, penskalaan cluster, dan pengoptimalan tugas.

Menggunakan logging dan pemantauan performa

Di Google Cloud, Anda dapat menggunakan Cloud Logging dan Cloud Monitoring untuk melihat dan menyesuaikan log, serta untuk memantau tugas dan resource.

Cara terbaik untuk menemukan error yang menyebabkan kegagalan tugas Spark adalah dengan melihat output driver dan log yang dihasilkan oleh eksekutor Spark.

Anda dapat mengambil output program driver dengan menggunakan Google Cloud Console atau menggunakan perintah gcloud. Outputnya juga disimpan di bucket Cloud Storage cluster Dataproc. Untuk detail lebih lanjut, lihat bagian output driver tugas dalam dokumentasi Dataproc.

Semua log lainnya berada di file berbeda di dalam mesin cluster. Anda dapat melihat log untuk setiap penampung dari UI web aplikasi Spark (atau dari Server Histori setelah program berakhir) di tab eksekutor. Anda harus menjelajahi setiap container Spark untuk melihat setiap log. Jika Anda menulis log atau mencetak ke stdout atau stderr dalam kode aplikasi, log tersebut akan disimpan dalam pengalihan stdout atau stderr.

Dalam cluster Dataproc, YARN dikonfigurasi untuk mengumpulkan semua log ini secara default, dan log tersebut tersedia di Cloud Logging. Cloud Logging memberikan tampilan semua log yang terkonsolidasi dan ringkas, sehingga Anda tidak perlu menghabiskan waktu untuk menjelajahi log container untuk menemukan error.

Gambar berikut menunjukkan halaman Cloud Logging di Konsol Google Cloud. Anda dapat melihat semua log dari cluster Dataproc dengan memilih nama cluster di menu pemilih. Jangan lupa untuk memperluas durasi waktu di pemilih rentang waktu.

Halaman Cloud Logging di konsol Google Cloud

Anda bisa mendapatkan log dari aplikasi Spark dengan memfilter menurut ID-nya. Anda bisa mendapatkan ID aplikasi dari output driver.

Membuat dan menggunakan label

Untuk menemukan log lebih cepat, Anda dapat membuat dan menggunakan label Anda sendiri untuk setiap cluster atau untuk setiap tugas Dataproc. Misalnya, Anda dapat membuat label dengan kunci env dan nilai exploration, lalu menggunakannya untuk tugas eksplorasi data. Anda kemudian bisa mendapatkan log untuk semua pembuatan tugas eksplorasi dengan memfilter menggunakan label:env:exploration di Cloud Logging. Perhatikan bahwa filter ini tidak akan menampilkan semua log untuk tugas ini, hanya log pembuatan resource.

Menetapkan level log

Anda dapat menetapkan level log driver menggunakan perintah gcloud berikut:

gcloud dataproc jobs submit hadoop --driver-log-levels

Anda dapat menetapkan level log untuk aplikasi lainnya dari konteks Spark. Contoh:

spark.sparkContext.setLogLevel("DEBUG")

Memantau tugas

Cloud Monitoring dapat memantau CPU, disk, penggunaan jaringan, dan resource YARN cluster. Anda dapat membuat dasbor kustom untuk mendapatkan diagram terbaru untuk metrik tersebut dan metrik lainnya. Dataproc berjalan di atas Compute Engine. Jika ingin memvisualisasikan penggunaan CPU, I/O disk, atau metrik jaringan dalam diagram, Anda harus memilih instance VM Compute Engine sebagai jenis resource, lalu memfilter berdasarkan nama cluster. Diagram berikut menunjukkan contoh output.

Halaman Monitoring di konsol Google Cloud

Untuk melihat metrik untuk kueri, tugas, tahapan, atau tugas Spark, hubungkan ke UI web aplikasi Spark. Bagian berikutnya menjelaskan cara melakukannya. Untuk mengetahui detail cara membuat metrik kustom, lihat panduan Metrik Kustom dari Agen.

Mengakses YARN

Anda dapat mengakses antarmuka web pengelola resource YARN dari luar cluster Dataproc dengan menyiapkan tunnel SSH. Sebaiknya gunakan proxy SOCKS yang ringan daripada penerusan port lokal, karena penjelajahan melalui antarmuka web lebih mudah dengan cara tersebut.

URL berikut berguna untuk akses YARN:

Pengelola resource YARN: http://[MASTER_HOST_NAME]:8088
Server histori Spark: http://[MASTER_HOST_NAME]:18080

Jika cluster Dataproc hanya memiliki alamat IP internal, Anda dapat menghubungkannya melalui koneksi VPN atau melalui bastion host. Untuk mengetahui informasi lebih lanjut, baca artikel Memilih opsi koneksi untuk VM khusus internal.

Menskalakan dan mengubah ukuran cluster Dataproc

Cluster Dataproc dapat diskalakan dengan menambah atau mengurangi jumlah pekerja utama atau sekunder (preemptible). Dataproc juga mendukung penghentian yang halus.

Penurunan skala di Spark dipengaruhi oleh sejumlah faktor. Pertimbangkan hal berikut:

Sebaiknya gunakan ExternalShuffleService, terutama jika Anda menurunkan skala cluster secara berkala. Pengacakan menggunakan hasil yang telah ditulis ke disk lokal pekerja setelah fase komputasi dijalankan, sehingga node tidak dapat dihapus meskipun resource komputasi tidak digunakan lagi.
Spark caches data di memori (baik RDD maupun set data), dan eksekutor yang digunakan untuk menyimpan data ke dalam cache tidak akan pernah keluar. Akibatnya, jika digunakan untuk meng-cache, pekerja tidak akan pernah dinonaktifkan dengan baik. Menghapus pekerja secara paksa akan memengaruhi performa keseluruhan, karena data yang di-cache akan hilang.
Streaming Spark memiliki alokasi dinamis yang dinonaktifkan secara default, dan kunci konfigurasi yang menetapkan perilaku ini tidak didokumentasikan. (Anda dapat mengikuti diskusi tentang perilaku alokasi dinamis di thread masalah Spark.) Jika menggunakan Spark Streaming atau Spark Structured Streaming, Anda juga harus secara eksplisit menonaktifkan alokasi dinamis seperti yang dibahas sebelumnya di bagian Mengidentifikasi jenis tugas dan merencanakan cluster.

Secara umum, sebaiknya hindari menurunkan skala cluster Dataproc jika Anda menjalankan beban kerja batch atau streaming.

Mengoptimalkan performa

Bagian ini membahas cara untuk mendapatkan performa yang lebih baik dan mengurangi biaya saat menjalankan tugas Spark.

Mengelola ukuran file Cloud Storage

Untuk mendapatkan performa yang optimal, bagi data Anda di Cloud Storage menjadi beberapa file dengan ukuran dari 128 MB hingga 1 GB. Menggunakan banyak file kecil dapat menimbulkan kerusakan. Jika Anda memiliki banyak file kecil, pertimbangkan untuk menyalin file untuk diproses ke HDFS lokal, lalu menyalin kembali hasilnya.

Beralih ke disk SSD

Jika Anda melakukan banyak operasi pengacakan atau penulisan yang dipartisi, beralihlah ke SSD untuk meningkatkan performa.

Menempatkan VM di zona yang sama

Untuk mengurangi biaya jaringan dan meningkatkan performa, gunakan lokasi regional yang sama untuk bucket Cloud Storage yang Anda gunakan untuk cluster Dataproc.

Secara default, ketika Anda menggunakan endpoint Dataproc global atau regional, VM cluster akan ditempatkan ke zona yang sama (atau zona lain di region yang sama yang memiliki kapasitas cukup) saat cluster dibuat. Anda juga dapat menentukan zona saat cluster dibuat.

Menggunakan preemptible VM

Cluster Dataproc dapat menggunakan instance preemptible VM sebagai pekerja. Hal ini menyebabkan biaya komputasi per jam yang lebih rendah untuk workload non-kritis Anda dibandingkan dengan menggunakan instance normal. Namun, ada beberapa faktor yang perlu dipertimbangkan saat Anda menggunakan preemptible VM:

Preemptible VM tidak dapat digunakan untuk penyimpanan HDFS.
Secara default, preemptible VM dibuat dengan ukuran boot disk yang lebih kecil, dan Anda dapat mengganti konfigurasi ini jika menjalankan beban kerja yang berat secara acak. Untuk mengetahui detailnya, lihat halaman tentang preemptible VM di dokumentasi Dataproc.
Sebaiknya tidak membuat lebih dari setengah total pekerja Anda dapat dihentikan penggunaannya.
Saat Anda menggunakan preemptible VM, sebaiknya sesuaikan konfigurasi cluster agar lebih toleran terhadap kegagalan tugas, karena VM mungkin kurang tersedia. Misalnya, buat setelan seperti berikut dalam konfigurasi YARN:
```
yarn.resourcemanager.am.max-attempts
mapreduce.map.maxattempts
mapreduce.reduce.maxattempts
spark.task.maxFailures
spark.stage.maxConsecutiveAttempts
```
Anda dapat menambahkan atau menghapus preemptible VM dari cluster dengan mudah. Untuk mengetahui detail selengkapnya, baca Preemptible VM.

Langkah selanjutnya

Lihat panduan tentang cara memigrasikan infrastruktur Hadoop lokal ke Google Cloud.
Lihat deskripsi kami tentang Masa Pakai Tugas Dataproc.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.