Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Tugas batch menggunakan shuffle Dataflow secara default.
Shuffle Dataflow memindahkan operasi shuffle dari VM pekerja ke backend layanan Dataflow.
Informasi di halaman ini berlaku untuk tugas batch. Tugas streaming menggunakan mekanisme shuffle yang berbeda, yang disebut streaming shuffle.
Tentang shuffle Dataflow
Shuffle Dataflow adalah operasi dasar di balik transformasi Dataflow seperti GroupByKey, CoGroupByKey, dan Combine.
Operasi shuffle Dataflow membuat partisi dan mengelompokkan data berdasarkan kunci dengan cara yang skalabel, efisien, dan fault-tolerant.
Manfaat shuffle Dataflow
Pengacakan Dataflow berbasis layanan memiliki manfaat berikut:
Waktu eksekusi pipeline batch yang lebih cepat untuk sebagian besar jenis tugas pipeline.
Pengurangan resource penyimpanan CPU, memori, dan Persistent Disk yang digunakan di VM pekerja.
Penskalaan Otomatis Horizontal yang lebih baik, karena
VM tidak menyimpan data pengacakan apa pun sehingga dapat diturunkan skalanya lebih awal.
Toleransi kesalahan yang lebih baik, karena VM yang tidak sehat yang menyimpan data pengacakan Dataflow tidak menyebabkan seluruh tugas gagal.
Dukungan dan batasan
Fitur ini tersedia di semua wilayah tempat Dataflow didukung. Untuk melihat lokasi yang tersedia, baca Lokasi Dataflow. Mungkin ada perbedaan performa antar-wilayah.
Worker harus di-deploy di region yang sama dengan tugas Dataflow.
Jangan tentukan opsi pipeline zone. Sebagai gantinya, tentukan region, dan
tetapkan nilai ke salah satu region yang tersedia. Dataflow
akan otomatis memilih zona di region yang Anda tentukan.
Jika Anda menentukan opsi pipeline zone dan menyetelnya ke zona di luar region yang tersedia, tugas Dataflow akan menampilkan error. Jika Anda menetapkan kombinasi region dan zone yang tidak kompatibel, tugas Anda tidak dapat menggunakan pengacakan Dataflow.
Untuk Python, pengacakan Dataflow memerlukan Apache Beam SDK untuk Python versi 2.1.0 atau yang lebih baru.
Pertimbangan ukuran disk
Ukuran boot disk default untuk setiap tugas batch adalah 25 GB. Untuk beberapa tugas batch,
Anda mungkin perlu mengubah ukuran disk. Pertimbangkan hal berikut:
VM pekerja menggunakan sebagian ruang disk sebesar 25 GB untuk sistem operasi, biner, log, dan container. Tugas yang menggunakan disk dalam jumlah besar dan melampaui kapasitas disk yang tersisa dapat gagal saat Anda menggunakan shuffle Dataflow.
Tugas yang menggunakan banyak I/O disk mungkin lambat karena performa disk kecil. Untuk mengetahui informasi selengkapnya tentang perbedaan performa antar-ukuran disk, lihat Performa Persistent Disk Compute Engine.
Untuk menentukan ukuran disk yang lebih besar untuk tugas shuffle Dataflow, Anda dapat menggunakan parameter --disk_size_gb.
Harga
Sebagian besar pengurangan resource worker berasal dari memindahkan tugas shuffle
ke layanan Dataflow. Oleh karena itu, ada
biaya yang terkait dengan penggunaan pengacakan Dataflow. Waktu eksekusi dapat bervariasi dari satu eksekusi ke eksekusi lainnya. Jika Anda menjalankan
pipeline yang memiliki batas waktu penting, sebaiknya alokasikan
waktu jeda yang cukup sebelum batas waktu.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-18 UTC."],[[["\u003cp\u003eDataflow shuffle, which is used by default for batch jobs, moves shuffle operations to the Dataflow service backend, improving efficiency.\u003c/p\u003e\n"],["\u003cp\u003eDataflow shuffle is the foundational operation for Dataflow transforms like \u003ccode\u003eGroupByKey\u003c/code\u003e, \u003ccode\u003eCoGroupByKey\u003c/code\u003e, and \u003ccode\u003eCombine\u003c/code\u003e, enabling scalable and fault-tolerant data partitioning and grouping.\u003c/p\u003e\n"],["\u003cp\u003eBenefits of Dataflow shuffle include faster batch pipeline execution, reduced worker VM resource consumption, improved horizontal autoscaling, and better fault tolerance.\u003c/p\u003e\n"],["\u003cp\u003eDataflow shuffle is not available for streaming jobs and requires worker VMs to be deployed in the same region as the Dataflow job, avoiding the specification of a \u003ccode\u003ezone\u003c/code\u003e pipeline option.\u003c/p\u003e\n"],["\u003cp\u003eDataflow shuffle charges apply, and the default 25 GB boot disk size may need to be increased for jobs with heavy disk I/O to ensure optimal performance.\u003c/p\u003e\n"]]],[],null,["# Dataflow shuffle for batch jobs\n\nBatch jobs use Dataflow shuffle by default.\nDataflow shuffle\nmoves the shuffle operation out of the worker VMs and into the\nDataflow service backend.\n\nThe information on this page applies to batch jobs. Streaming jobs use a\ndifferent shuffle mechanism, called\n[streaming shuffle](/dataflow/docs/concepts/exactly-once#streaming-shuffle).\n\nAbout Dataflow shuffle\n----------------------\n\n- Dataflow shuffle is the base operation behind Dataflow transforms such as `GroupByKey`, `CoGroupByKey`, and `Combine`.\n- The Dataflow shuffle operation partitions and groups data by key in a scalable, efficient, fault-tolerant manner.\n\nBenefits of Dataflow shuffle\n----------------------------\n\nThe service-based Dataflow shuffle has the following benefits:\n\n- Faster execution time of batch pipelines for the majority of pipeline job types.\n- A reduction in consumed CPU, memory, and Persistent Disk storage resources on the worker VMs.\n- Better [Horizontal Autoscaling](/dataflow/docs/horizontal-autoscaling), because VMs don't hold any shuffle data and can therefore be scaled down earlier.\n- Better fault tolerance, because an unhealthy VM holding Dataflow shuffle data doesn't cause the entire job to fail.\n\nSupport and limitations\n-----------------------\n\n- This feature is available in all regions where Dataflow is supported. To see available locations, read [Dataflow locations](/dataflow/docs/resources/locations). There might be performance differences between regions.\n- Workers must be deployed in the same region as the Dataflow job.\n- Don't specify the `zone` pipeline option. Instead, specify the `region`, and\n set the value to one of the available regions. Dataflow\n automatically selects the zone in the region you specified.\n\n If you specify the `zone`\n pipeline option and set it to a zone outside of the available regions, the\n Dataflow job returns an error. If you set an incompatible combination\n of `region` and `zone`, your job can't use Dataflow shuffle.\n- For Python, Dataflow shuffle requires Apache Beam SDK\n for Python version 2.1.0 or later.\n\nDisk size considerations\n------------------------\n\nThe default boot disk size for each batch job is 25 GB. For some batch jobs,\nyou might be required to modify the size of the disk. Consider the following:\n\n- A worker VM uses part of the 25 GB of disk space for the operating system, binaries, logs, and containers. Jobs that use a significant amount of disk and exceed the remaining disk capacity may fail when you use Dataflow shuffle.\n- Jobs that use a lot of disk I/O may be slow due to the performance of the small disk. For more information about performance differences between disk sizes, see [Compute Engine Persistent Disk Performance](/compute/docs/disks/performance).\n\nTo specify a larger disk size for a Dataflow shuffle job, you can\nuse the [`--disk_size_gb`](/dataflow/pipelines/specifying-exec-params#setting-other-cloud-pipeline-options)\nparameter.\n\nPricing\n-------\n\nMost of the reduction in worker resources comes from offloading the shuffle work\nto the Dataflow service. For that reason, there is a\n[charge](/dataflow/pricing) associated with the use of Dataflow\nshuffle. The execution times might vary from run to run. If you are running\na pipeline that has important deadlines, we recommend allocating sufficient\nbuffer time before the deadline."]]
