Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menguraikan praktik terbaik untuk mengoptimalkan pipeline Dataflow yang membaca dari
Pub/Sub dan
menulis ke BigQuery.
Bergantung pada kasus penggunaan, saran berikut dapat menghasilkan performa yang lebih baik.
Solusi awal untuk backlog pipeline
Jika pipeline Pub/Sub ke BigQuery mengalami backlog yang terus bertambah dan tidak dapat menangani pesan yang masuk, Anda dapat melakukan langkah-langkah langsung berikut:
Perpanjang batas waktu konfirmasi Pub/Sub: Untuk langganan Pub/Sub terkait, perpanjang batas waktu konfirmasi ke nilai yang sedikit lebih lama dari
waktu pemrosesan pesan maksimum yang diharapkan. Hal ini mencegah pesan dikirim ulang sebelum waktunya saat masih diproses.
Menskalakan pekerja: Jika jumlah pesan yang belum dikonfirmasi dan backlog langganan meningkat dengan cepat, kapasitas pemrosesan pipeline kemungkinan tidak memadai. Tingkatkan jumlah worker Dataflow untuk menangani volume pesan.
Aktifkan backoff eksponensial: Aktifkan backoff eksponensial
untuk meningkatkan cara pipeline menangani percobaan ulang untuk masalah sementara, sehingga
lebih tangguh.
Pengoptimalan kode dan pipeline jangka panjang
Untuk performa dan stabilitas yang berkelanjutan, sebaiknya lakukan perubahan arsitektur dan kode berikut:
Mengurangi panggilan getTable ke BigQuery: Panggilan metode getTable yang berlebihan dapat menyebabkan pembatasan kecepatan dan bottleneck performa. Untuk
memitigasi hal ini:
Simpan informasi keberadaan tabel dalam memori pekerja untuk menghindari panggilan berulang untuk tabel yang sama.
Panggilan batch getTable berdasarkan per paket, bukan untuk setiap elemen individual.
Refaktorkan kode pipeline untuk menghilangkan kebutuhan memeriksa keberadaan tabel untuk setiap pesan.
Gunakan BigQuery Storage Write API: Untuk pipeline streaming yang menulis ke
BigQuery, lakukan migrasi dari penyisipan streaming standar ke
Storage Write API. Storage Write API menawarkan performa yang lebih baik dan kuota yang jauh lebih tinggi.
Gunakan runner Dataflow lama untuk tugas dengan kardinalitas tinggi:
Untuk tugas yang memproses sejumlah besar kunci unik
(kardinalitas tinggi), runner Dataflow lama mungkin menawarkan
performa yang lebih baik daripada Runner v2, kecuali jika diperlukan transformasi lintas bahasa.
Mengoptimalkan ruang kunci: Performa dapat menurun saat pipeline beroperasi pada jutaan kunci aktif. Sesuaikan logika pipeline untuk melakukan pekerjaan pada ruang kunci yang lebih kecil dan lebih mudah dikelola.
Pengelolaan resource, kuota, dan konfigurasi
Alokasi dan konfigurasi resource yang tepat sangat penting untuk kesehatan pipeline:
Mengelola kuota secara proaktif: Pantau kuota dan minta penambahan untuk kuota apa pun yang mungkin tercapai selama peristiwa penskalaan. Misalnya, pertimbangkan peristiwa penskalaan berikut:
Tingkat panggilan yang tinggi ke metode TableService.getTable atau
tabledata.insertAll dapat melebihi kueri maksimum per
detik (QPS). Untuk mengetahui informasi selengkapnya tentang batas dan cara meminta kuota yang lebih besar, lihat Kuota dan batas BigQuery.
Kuota Compute Engine untuk alamat IP dan CPU yang sedang digunakan mungkin melebihi batas maksimum. Untuk mengetahui informasi selengkapnya tentang batas dan cara meminta kuota tambahan, lihat ringkasan kuota dan batas Compute Engine.
Mengoptimalkan konfigurasi pekerja: Untuk mencegah error kehabisan memori (OOM) dan meningkatkan stabilitas:
Gunakan jenis mesin pekerja dengan memori yang lebih besar.
Tetapkan jumlah pekerja yang lebih tinggi untuk mendistribusikan workload secara lebih merata dan mengurangi dampak performa dari peristiwa penskalaan otomatis yang sering terjadi.
[[["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-09-04 UTC."],[],[],null,["# Pub/Sub to BigQuery best practices\n\nThis page outlines best practices for optimizing a Dataflow\npipeline that [reads from\nPub/Sub](/dataflow/docs/concepts/streaming-with-cloud-pubsub) and\n[writes to BigQuery](/dataflow/docs/guides/write-to-bigquery).\nDepending on your use case, the following suggestions might lead to better\nperformance.\n\nInitial solutions for pipeline backlogs\n---------------------------------------\n\nWhen a Pub/Sub to BigQuery pipeline experiences a\ngrowing backlog and can't keep up with incoming messages, you can take the\nfollowing immediate steps:\n\n- **Increase Pub/Sub acknowledgment deadline:** For the associated Pub/Sub subscription, [increase the acknowledgment\n deadline](/pubsub/docs/lease-management) to a value slightly longer than the maximum expected message processing time. This prevents messages from being redelivered prematurely while they are still being processed.\n- **Scale out workers:** If the unacknowledged message count and subscription backlog are growing rapidly, the pipeline's processing capacity is likely insufficient. Increase the [number of Dataflow\n workers](/dataflow/docs/reference/pipeline-options) to handle the message volume.\n- **Enable exponential backoff:** Enable [exponential backoff](/pubsub/docs/handling-failures#exponential_backoff) to improve how the pipeline handles retries for transient issues, making it more resilient.\n\nLong-term code and pipeline optimizations\n-----------------------------------------\n\nFor sustained performance and stability, the following architectural and code\nchanges are recommended:\n\n- **Reduce `getTable` calls to BigQuery:** Excessive `getTable` method calls can lead to rate-limiting and performance bottlenecks. To mitigate this:\n - Cache table existence information in worker memory to avoid repeated calls for the same table.\n - Batch `getTable` calls on a per-bundle basis instead of for each individual element.\n - Refactor the pipeline code to eliminate the need to check for table existence for every message.\n- **Use the BigQuery Storage Write API:** For streaming pipelines writing to BigQuery, migrate from standard streaming inserts to the [Storage Write API](/bigquery/docs/write-api). The Storage Write API offers better performance and significantly higher quotas.\n- **Use the legacy Dataflow runner for high-cardinality jobs:** For jobs that process a very large number of unique keys (*high-cardinality*), the legacy Dataflow runner might offer better performance than Runner v2, unless cross-language transforms are required.\n- **Optimize the key space:** Performance can degrade when pipelines operate on millions of active keys. Adjust the pipeline's logic to perform work on a smaller, more manageable key space.\n\nResource, quota, and configuration management\n---------------------------------------------\n\nProper resource allocation and configuration are critical for pipeline health:\n\n- **Proactively manage quotas:** Monitor quotas and request increases for any quotas that might be reached during scaling events. For example, consider the following scaling events:\n - A high rate of calls to the `TableService.getTable` or `tabledata.insertAll` methods might exceed the maximum queries per second (QPS). For more information on limits and how to request more quota, see [BigQuery quotas and\n limits](/bigquery/quotas).\n - Compute Engine quotas for in-use IP addresses and CPUs might exceed maximum limits. For more information on limits and how to request more quota, see the [Compute Engine quota and limits\n overview](/compute/quotas-limits).\n- **Optimize worker configuration:** To prevent out-of-memory (OOM) errors and improve stability:\n - Use worker [machine\n types](/dataflow/docs/guides/configure-worker-vm#machine-type) with more memory.\n - Reduce the [number of\n threads](/dataflow/docs/reference/pipeline-options#resource_utilization) per worker.\n - Set a higher [number of\n workers](/dataflow/docs/reference/pipeline-options#resource_utilization) to distribute the workload more evenly and reduce the performance impact of frequent autoscaling events.\n\nWhat's next\n-----------\n\n- [Develop and test Dataflow pipelines](/dataflow/docs/guides/develop-and-test-pipelines)\n- [Dataflow pipeline best practices](/dataflow/docs/guides/pipeline-best-practices)\n- [Dataflow job metrics](/dataflow/docs/guides/using-monitoring-intf)"]]
