Halaman ini menguraikan praktik terbaik untuk mengoptimalkan pipeline Dataflow yang membaca dari Pub/Sub dan menulis ke BigQuery. Bergantung pada kasus penggunaan Anda, saran berikut dapat meningkatkan performa.
Solusi awal untuk backlog pipeline
Jika pipeline Pub/Sub ke BigQuery mengalami backlog yang terus bertambah dan tidak dapat mengikuti pesan masuk, Anda dapat mengambil langkah-langkah langsung berikut:
- Meningkatkan batas waktu konfirmasi Pub/Sub: Untuk langganan Pub/Sub terkait, tingkatkan 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 worker: Jika jumlah pesan yang belum dikonfirmasi dan backlog langganan meningkat dengan cepat, kapasitas pemrosesan pipeline kemungkinan tidak mencukupi. Tingkatkan jumlah worker Dataflow untuk menangani volume pesan.
- Mengaktifkan 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
getTableke BigQuery: Panggilan metodegetTableyang berlebihan dapat menyebabkan pembatasan frekuensi dan hambatan performa. Untuk mengatasinya:- Simpan informasi keberadaan tabel dalam cache di memori worker untuk menghindari panggilan berulang untuk tabel yang sama.
- Gabungkan panggilan
getTableberdasarkan per paket, bukan untuk setiap elemen. - Refaktorkan kode pipeline untuk menghilangkan kebutuhan memeriksa keberadaan tabel untuk setiap pesan.
- Menggunakan BigQuery Storage Write API (gRPC): Untuk pipeline streaming yang menulis ke BigQuery, migrasikan dari penyisipan streaming standar ke Storage Write API (gRPC). Storage Write API (gRPC) menawarkan performa yang lebih baik dan kuota yang jauh lebih tinggi.
- Menggunakan Streaming Java Runner standar (sebelumnya disebut Runner v1) untuk tugas dengan kardinalitas tinggi: Untuk tugas yang memproses sejumlah besar kunci unik (kardinalitas tinggi), Streaming Java Runner mungkin menawarkan performa yang lebih baik daripada Portable Runner, kecuali jika transformasi lintas bahasa diperlukan.
- 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 peningkatan untuk kuota apa pun yang mungkin tercapai selama peristiwa penskalaan. Misalnya, pertimbangkan peristiwa penskalaan berikut:
- Frekuensi panggilan yang tinggi ke metode
TableService.getTableatautabledata.insertAllmungkin melebihi kueri maksimum per detik (QPS). Untuk mengetahui informasi selengkapnya tentang batas dan cara meminta lebih banyak kuota, 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 lebih banyak kuota, lihat ringkasan kuota dan batas Compute Engine overview.
- Frekuensi panggilan yang tinggi ke metode
- Mengoptimalkan konfigurasi worker: Untuk mencegah error kehabisan memori (OOM) dan meningkatkan stabilitas:
- Gunakan jenis mesin worker dengan lebih banyak memori.
- Kurangi jumlah thread per worker.
- Tetapkan jumlah worker yang lebih tinggi untuk mendistribusikan beban kerja secara lebih merata dan mengurangi dampak performa dari peristiwa penskalaan otomatis yang sering terjadi.