Halaman ini diterjemahkan oleh Cloud Translation API.

Properti langganan

Properti langganan Pub/Sub adalah karakteristik langganan. Anda dapat menetapkan properti langganan saat membuat atau memperbarui langganan.

Dokumen ini menjelaskan berbagai properti langganan yang dapat Anda tetapkan untuk langganan.

Sebelum memulai

Pelajari langganan.
Pahami alur kerja untuk langganan yang akan Anda buat: Pull, Push, atau BigQuery.

Properti langganan umum

Saat membuat langganan, Anda harus menentukan sejumlah opsi untuk menyiapkan langganan. Beberapa properti ini umum untuk semua jenis langganan dan dibahas di bagian berikutnya.

Durasi retensi pesan

Opsi Durasi retensi pesan menentukan berapa lama Pub/Sub mempertahankan pesan setelah dipublikasikan. Setelah durasi retensi pesan berakhir, Pub/Sub dapat menghapus pesan terlepas dari status pengakuan pesan. Untuk mempertahankan pesan yang terkonfirmasi selama durasi retensi pesan, lihat Memutar ulang dan menghapus pesan.

Berikut adalah nilai untuk opsi Durasi penyimpanan pesan:

Nilai default = 7 hari
Nilai minimum = 10 menit
Nilai maksimum = 31 hari

Pesan yang belum dikonfirmasi dapat disebabkan oleh langganan yang tidak aktif, kebutuhan pencadangan, atau pemrosesan yang lambat. Jika Anda dapat memproses pesan dalam waktu 24 jam, Anda tidak akan dikenai biaya tambahan. Anda dapat menghindari tagihan baru dengan mengelola skenario ini sebagai berikut:

Langganan tidak aktif. Hapus langganan yang tidak aktif untuk menghindari biaya retensi pesan langganan.
Penyimpanan cadangan. Jika Anda menggunakan retensi langganan sebagai penyimpanan cadangan, Anda dapat beralih ke opsi penyimpanan lain seperti retensi pesan topik atau mempertahankan pesan yang telah dikonfirmasi. Penyimpanan retensi pesan topik menyimpan pesan hanya satu kali di tingkat topik dan pesan tersebut tetap tersedia untuk digunakan oleh semua langganan jika diperlukan.
Penundaan pemrosesan. Tambahkan lebih banyak pelanggan (jika memungkinkan) untuk memproses pesan dalam sehari.

Pertahankan pesan yang dikonfirmasi

Jika Anda menentukan Durasi retensi pesan, Anda juga dapat menentukan apakah Anda ingin mempertahankan pesan yang dikonfirmasi.

Opsi Pertahankan pesan yang dikonfirmasi memungkinkan Anda mempertahankan pesan yang dikonfirmasi selama durasi retensi pesan yang ditentukan. Akibatnya, biaya penyimpanan pesan akan naik. Untuk mengetahui informasi selengkapnya, lihat biaya penyimpanan.

Periode kedaluwarsa

Opsi Periode habis masa berlaku memungkinkan Anda memperpanjang periode habis masa berlaku langganan.

Langganan tanpa aktivitas pelanggan atau perubahan yang dilakukan pada properti langganan akan berakhir. Jika Pub/Sub mendeteksi aktivitas pelanggan atau jika Anda memperbarui salah satu properti langganan, timer penghapusan langganan akan dimulai ulang. Contoh aktivitas pelanggan mencakup koneksi terbuka, pull yang aktif, atau push yang berhasil dilakukan.

Jika Anda menentukan periode habis masa berlaku, nilai harus setidaknya selama durasi retensi pesan yang ditentukan dalam opsi Durasi retensi pesan.

Berikut adalah nilai untuk opsi Periode habis masa berlaku:

Nilai default = 31 hari
Nilai minimum = 1 hari

Untuk mencegah langganan berakhir, tetapkan periode masa berlaku ke never expire.

Batas waktu konfirmasi

Opsi Batas waktu konfirmasi menentukan batas waktu awal setelah pesan yang tidak dikonfirmasi dikirim lagi. Anda dapat memperpanjang batas waktu konfirmasi per pesan dengan mengirimkan permintaan ModifyAckDeadline berikutnya.

Berikut adalah nilai untuk opsi Batas waktu konfirmasi:

Nilai default = 10 detik
Nilai minimum = 10 detik
Nilai maksimum = 600 detik

Dalam beberapa kasus, library klien Pub/Sub dapat mengontrol kecepatan pengiriman dan mengubah batas waktu konfirmasi secara dinamis. Dengan demikian, pesan mungkin dikirim ulang sebelum batas waktu pengakuan yang Anda tetapkan. Untuk mengganti perilaku ini, gunakan minDurationPerAckExtension dan maxDurationPerAckExtension. Untuk mengetahui informasi selengkapnya tentang penggunaan nilai ini, lihat Dukungan pengiriman tepat satu kali di library klien.

Transformasi Pesan Tunggal (SMT)

SMT memungkinkan modifikasi ringan pada atribut dan data pesan secara langsung dalam Pub/Sub. Fitur ini memungkinkan pembersihan, pemfilteran, atau konversi format data sebelum pesan dikirimkan ke klien subscriber.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan SMT dan Membuat langganan dengan SMT.

Filter langganan

Gunakan opsi Filter langganan untuk menentukan string dengan ekspresi pemfilteran. Jika langganan memiliki filter, langganan hanya akan mengirimkan pesan yang cocok dengan filter. Layanan Pub/Sub secara otomatis mengonfirmasi pesan yang tidak cocok dengan filter.

Anda dapat memfilter pesan menurut atributnya, tetapi tidak menurut data dalam pesan.
Jika tidak ditentukan, langganan tidak memfilter pesan dan pelanggan menerima semua pesan.
Filter tidak dapat diubah atau dihapus setelah Anda menerapkannya.

Saat menerima pesan dari langganan dengan filter, Anda tidak dikenai biaya keluar untuk pesan yang dikonfirmasi secara otomatis oleh Pub/Sub. Anda akan dikenai biaya pengiriman pesan dan biaya penyimpanan terkait penelusuran untuk pesan ini.

Untuk mengetahui informasi selengkapnya, lihat Memfilter pesan dari langganan.

Pengurutan pesan

Jika Pengurutan pesan diaktifkan untuk langganan, klien pelanggan akan menerima pesan yang dipublikasikan di region yang sama dengan kunci pengurutan yang sama sesuai urutan pesan diterima oleh layanan.

Saat menggunakan pengiriman berurutan, konfirmasi untuk pesan selanjutnya tidak diproses hingga konfirmasi untuk pesan sebelumnya diproses.

Penayang harus mengirim pesan dengan kunci pengurutan agar Pub/Sub dapat mengirimkan pesan secara berurutan.

Jika tidak disetel, Pub/Sub mungkin tidak mengirimkan pesan secara berurutan, meskipun pesan tersebut memiliki kunci pengurutan.

Topik yang dihentikan pengirimannya

Jika pesan tidak dapat dikirim setelah sejumlah upaya pengiriman yang ditetapkan atau pelanggan tidak dapat mengonfirmasi pesan, Anda dapat mengonfigurasi topik pesan yang tidak terkirim tempat pesan ini dapat dipublikasikan ulang.

Jika Anda menetapkan topik pesan yang tidak terkirim, Anda juga dapat menentukan jumlah maksimum upaya pengiriman. Berikut adalah nilai untuk jumlah maksimum upaya pengiriman untuk topik pesan yang pengirimannya dihentikan:

Nilai default = 5 upaya pengiriman
Nilai minimum = 5 upaya pengiriman
Nilai maksimum = 100 upaya pengiriman

Jika topik pesan yang tidak terkirim berada di project yang berbeda dengan langganan, Anda juga harus menentukan project ID dengan topik pesan yang tidak terkirim.

Untuk mengetahui informasi selengkapnya, lihat Meneruskan ke topik pesan yang tidak terkirim.

Kebijakan coba lagi

Jika batas waktu konfirmasi berakhir atau pelanggan merespons dengan konfirmasi negatif, Pub/Sub dapat mengirim pesan lagi. Upaya pengiriman ulang ini dikenal sebagai Kebijakan percobaan ulang langganan.

Secara default, kebijakan percobaan ulang untuk langganan ditetapkan untuk menggunakan Coba lagi segera. Dengan opsi ini, Pub/Sub mengirim ulang pesan saat batas waktu konfirmasi berakhir atau pelanggan merespons dengan konfirmasi negatif.

Anda juga dapat menyetel nilai ke Coba lagi setelah penundaan backoff eksponensial. Dalam hal ini, Anda harus menentukan nilai backoff maksimum dan minimum.

Berikut beberapa panduan untuk menetapkan nilai backoff maksimum dan minimum:

Jika Anda menetapkan nilai maksimum untuk durasi backoff, nilai default untuk durasi backoff minimum adalah 10 detik.
Jika Anda menetapkan nilai minimum untuk durasi backoff, nilai default untuk durasi backoff maksimum adalah 600 detik.
Durasi penundaan terlama yang dapat Anda tentukan adalah 600 detik.

Kebijakan percobaan ulang dan pesan batch

Jika pesan berada dalam batch, Pub/Sub memulai penundaan eksponensial saat salah satu hal berikut terjadi:

Pelanggan mengirimkan konfirmasi negatif untuk setiap pesan dalam batch.
Batas waktu konfirmasi berakhir.

Kebijakan coba lagi dan langganan push

Jika Anda menerima pesan dari langganan push, Pub/Sub mungkin mengirim ulang pesan setelah penundaan push bukan durasi penundaan eksponensial. Jika backoff push lebih lama daripada durasi backoff eksponensial, Pub/Sub akan mengirim ulang pesan yang belum dikonfirmasi setelah backoff push.

Properti langganan pull

Saat mengonfigurasi langganan pull, Anda dapat menentukan properti berikut.

Pengiriman tepat satu kali

Pengiriman tepat satu kali. Jika disetel, Pub/Sub memenuhi jaminan pengiriman tepat satu kali. Jika tidak ditentukan, langganan mendukung pengiriman minimal satu kali untuk setiap pesan.

Properti langganan push

Saat mengonfigurasi langganan push, Anda dapat menentukan properti berikut.

Endpoint

URL Endpoint (wajib). Alamat HTTPS yang dapat diakses secara publik. Server untuk endpoint push harus memiliki sertifikat SSL yang valid dan ditandatangani oleh certificate authority. Layanan Pub/Sub mengirimkan pesan ke endpoint push dari region Google Cloud yang sama dengan tempat layanan Pub/Sub menyimpan pesan. Layanan Pub/Sub mengirimkan pesan dari region Google Cloud yang sama berdasarkan upaya terbaik.

Jika pelanggan menggunakan firewall, mereka tidak dapat menerima permintaan push. Untuk menerima permintaan push, Anda harus menonaktifkan firewall dan memverifikasi Token Web JSON (JWT) yang digunakan dalam permintaan. Jika pelanggan memiliki firewall, Anda mungkin menerima error 403 permission denied.
Pub/Sub tidak lagi memerlukan bukti kepemilikan untuk domain URL langganan push. Jika domain Anda menerima permintaan POST yang tidak terduga dari Pub/Sub, Anda dapat melaporkan dugaan penyalahgunaan.

Autentikasi

Aktifkan autentikasi. Jika diaktifkan, pesan yang dikirim oleh Pub/Sub ke endpoint push akan menyertakan header otorisasi untuk mengizinkan endpoint mengautentikasi permintaan. Mekanisme autentikasi dan otorisasi otomatis tersedia untuk endpoint fungsi App Engine Standard dan Cloud Run yang dihosting di project yang sama dengan langganan.

Konfigurasi autentikasi untuk langganan push yang diautentikasi terdiri dari akun layanan yang dikelola pengguna, dan parameter audiens yang ditentukan dalam panggilan create, patch, atau ModifyPushConfig. Anda juga harus memberikan peran tertentu ke akun layanan, seperti yang dibahas di bagian berikutnya.

Audiens. Satu string yang tidak peka huruf besar/kecil yang digunakan webhook untuk memvalidasi target audiens yang dimaksud dari token tertentu ini.
Akun layanan. Pub/Sub otomatis membuat akun layanan untuk Anda dengan format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

Prasyarat untuk mengaktifkan autentikasi

Akun layanan yang dikelola pengguna adalah akun layanan yang terkait dengan langganan push. Akun ini digunakan sebagai klaim email dari Token Web JSON (JWT) yang dibuat. Berikut adalah daftar persyaratan untuk akun layanan:

Akun layanan yang dikelola pengguna ini harus berada dalam project yang sama dengan langganan push.
Akun utama yang membuat atau mengubah langganan push harus memiliki izin iam.serviceAccounts.actAs pada akun layanan yang dikelola penggunauntuk melampirkan akun layanan ke langganan push. Untuk mengetahui informasi selengkapnya, lihat Melampirkan akun layanan ke resource.
Izin yang diperlukan: Akun layanan ini harus diberi izin iam.serviceAccounts.getOpenIdToken (termasuk dalam peran roles/iam.serviceAccountTokenCreator) agar Pub/Sub dapat membuat token JWT untuk akun layanan yang ditentukan guna mengautentikasi permintaan push.

Pembukaan payload

Opsi Aktifkan pembukaan payload menghapus semua metadata pesan Pub/Sub, kecuali data pesan. Dengan pembukaan payload, data pesan dikirimkan langsung sebagai isi HTTP.

Anda juga dapat Mengaktifkan opsi Tulis metadata. Opsi Tulis metadata menambahkan kembali metadata pesan yang sebelumnya dihapus ke header permintaan.

Properti BigQuery

Saat memilih jenis pengiriman langganan sebagai Tulis ke BigQuery, Anda dapat menentukan properti tambahan berikut.

Menggunakan skema topik

Opsi ini memungkinkan Pub/Sub menggunakan skema topik Pub/Sub yang menjadi tujuan langganan. Selain itu, Pub/Sub menulis kolom dalam pesan ke kolom yang sesuai di tabel BigQuery.

Saat Anda menggunakan opsi ini, jangan lupa untuk memeriksa persyaratan tambahan berikut:

Kolom dalam skema topik dan skema BigQuery harus memiliki nama yang sama dan jenisnya harus kompatibel satu sama lain.
Setiap kolom opsional dalam skema topik juga harus bersifat opsional dalam skema BigQuery.
Kolom wajib di skema topik tidak harus wajib di skema BigQuery.
Jika ada kolom BigQuery yang tidak ada dalam skema topik, kolom BigQuery ini harus dalam mode NULLABLE.
Jika skema topik memiliki kolom tambahan yang tidak ada dalam skema BigQuery dan kolom ini dapat dihapus, pilih opsi Hapus kolom tidak dikenal.
Anda hanya dapat memilih salah satu properti langganan, Gunakan skema topik atau Gunakan skema tabel.

Jika Anda tidak memilih opsi Gunakan skema topik atau Gunakan skema tabel, pastikan tabel BigQuery memiliki kolom bernama data dengan jenis BYTES, STRING, atau JSON. Pub/Sub menulis pesan ke kolom BigQuery ini.

Anda mungkin tidak melihat perubahan pada skema topik Pub/Sub atau skema tabel BigQuery langsung diterapkan dengan pesan yang ditulis ke tabel BigQuery. Misalnya, jika opsi Hapus kolom tidak dikenal diaktifkan dan kolom ada dalam skema Pub/Sub, tetapi tidak ada dalam skema BigQuery, pesan yang ditulis ke tabel BigQuery mungkin masih tidak berisi kolom tersebut setelah ditambahkan ke skema BigQuery. Pada akhirnya, skema akan disinkronkan dan pesan berikutnya akan menyertakan kolom tersebut.

Saat menggunakan opsi Gunakan skema topik untuk langganan BigQuery, Anda juga dapat memanfaatkan pengambilan data perubahan (CDC) BigQuery. CDC memperbarui tabel BigQuery Anda dengan memproses dan menerapkan perubahan pada baris yang ada.

Untuk mempelajari fitur ini lebih lanjut, lihat Streaming update tabel dengan pengambilan data perubahan.

Untuk mempelajari cara menggunakan fitur ini dengan langganan BigQuery, lihat Pengambilan data perubahan BigQuery.

Menggunakan skema tabel

Opsi ini memungkinkan Pub/Sub menggunakan skema tabel BigQuery untuk menulis kolom pesan JSON ke kolom yang sesuai. Saat Anda menggunakan opsi ini, jangan lupa untuk memeriksa persyaratan tambahan berikut:

Nama setiap kolom dalam tabel BigQuery hanya boleh berisi huruf (a-z, A-Z), angka (0-9), atau garis bawah (_).
Pesan yang dipublikasikan harus dalam format JSON.

Konversi JSON berikut didukung:

Jenis JSON	Jenis Data BigQuery
`string`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME`, atau `TIMESTAMP`
`number`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME`, atau `TIMESTAMP`

Saat menggunakan number untuk DATE, DATETIME, TIME, atau TIMESTAMP konversi, angka harus mematuhi representasi yang didukung.
Saat menggunakan konversi number ke NUMERIC atau BIGNUMERIC, presisi dan rentang nilai dibatasi pada nilai yang diterima oleh standar IEEE 754 untuk aritmatika floating point. Jika Anda memerlukan presisi tinggi atau rentang nilai yang lebih luas, gunakan konversi string ke NUMERIC atau BIGNUMERIC.
Saat menggunakan konversi string ke NUMERIC atau BIGNUMERIC, Pub/Sub mengasumsikan string adalah angka yang dapat dibaca manusia (misalnya, "123.124"). Jika pemrosesan string sebagai angka yang dapat dibaca manusia gagal, Pub/Sub akan memperlakukan string sebagai byte yang dienkode dengan BigDecimalByteStringEncoder.

Jika topik langganan memiliki skema yang terkait dengannya, maka properti encoding pesan harus disetel ke JSON.
Jika ada kolom BigQuery yang tidak ada dalam pesan, kolom BigQuery ini harus dalam mode NULLABLE.
Jika pesan memiliki kolom tambahan yang tidak ada dalam skema BigQuery dan kolom ini dapat dihapus, pilih opsi Hapus kolom tidak dikenal.
Anda hanya dapat memilih salah satu properti langganan, Gunakan skema topik atau Gunakan skema tabel.

Anda mungkin tidak melihat perubahan pada skema tabel BigQuery langsung diterapkan dengan pesan yang ditulis ke tabel BigQuery. Misalnya, jika opsi Hapus kolom yang tidak diketahui diaktifkan dan kolom ada dalam pesan, tetapi tidak ada dalam skema BigQuery, pesan yang ditulis ke tabel BigQuery mungkin masih tidak berisi kolom tersebut setelah ditambahkan ke skema BigQuery. Pada akhirnya, skema akan disinkronkan dan pesan berikutnya akan menyertakan kolom tersebut.

Jika menggunakan opsi Gunakan skema tabel untuk langganan BigQuery, Anda juga dapat memanfaatkan pengambilan data perubahan (CDC) BigQuery. CDC memperbarui tabel BigQuery Anda dengan memproses dan menerapkan perubahan pada baris yang ada.

Untuk mempelajari fitur ini lebih lanjut, lihat Streaming update tabel dengan pengambilan data perubahan.

Untuk mempelajari cara menggunakan fitur ini dengan langganan BigQuery, lihat Pengambilan data perubahan BigQuery.

Menghapus kolom yang tidak diketahui

Opsi ini digunakan dengan opsi Gunakan skema topik atau Gunakan skema tabel. Jika diaktifkan, opsi ini memungkinkan Pub/Sub menghapus kolom apa pun yang ada dalam skema topik atau pesan, tetapi tidak ada dalam skema BigQuery. Kolom yang bukan bagian dari skema BigQuery akan dihapus saat menulis pesan ke tabel BigQuery.

Jika Hapus kolom yang tidak diketahui tidak disetel, pesan dengan kolom tambahan tidak akan ditulis ke BigQuery dan tetap berada dalam backlog langganan kecuali Anda mengonfigurasi topik pesan yang tidak terkirim.

Setelan Hapus kolom yang tidak diketahui tidak memengaruhi kolom yang tidak ditentukan dalam skema topik Pub/Sub atau skema tabel BigQuery. Dalam hal ini, pesan Pub/Sub yang valid dikirimkan ke langganan. Namun, karena BigQuery tidak memiliki kolom yang ditentukan untuk kolom tambahan ini, kolom tersebut akan dihilangkan selama proses penulisan BigQuery. Untuk mencegah perilaku ini, pastikan bahwa setiap kolom yang ada dalam pesan Pub/Sub juga ada dalam skema tabel BigQuery.

Perilaku terkait kolom tambahan juga dapat bergantung pada jenis skema tertentu (Avro, Protocol Buffer) dan encoding (JSON, Biner) yang digunakan. Untuk mengetahui informasi tentang cara faktor-faktor ini memengaruhi penanganan kolom tambahan, lihat dokumentasi untuk jenis dan encoding skema tertentu Anda.

Menulis metadata

Opsi ini memungkinkan Pub/Sub menulis metadata setiap pesan ke kolom tambahan dalam tabel BigQuery. Jika tidak, metadata tidak ditulis ke tabel BigQuery.

Jika Anda memilih opsi Tulis metadata, pastikan tabel BigQuery memiliki kolom yang dijelaskan dalam tabel berikut.

Jika Anda tidak memilih opsi Tulis metadata, tabel BigQuery tujuan hanya memerlukan kolom data kecuali jika use_topic_schema benar (true). Jika Anda memilih opsi Tulis metadata dan Gunakan skema topik, maka skema topik tidak boleh berisi kolom dengan nama yang cocok dengan nama parameter metadata. Batasan ini mencakup versi camel case dari parameter snake case ini.

Parameter
`subscription_name`	STRING Nama langganan.
`message_id`	STRING ID pesan
`publish_time`	TIMESTAMP Waktu memublikasikan pesan.
`data`	BYTES, STRING, atau JSON Isi pesan. Kolom `data` diperlukan untuk semua tabel BigQuery tujuan yang tidak memilih Gunakan skema topik atau Gunakan skema tabel. Jika kolom berjenis JSON, maka isi pesan harus berupa JSON yang valid.
`attributes`	STRING atau JSON Objek JSON yang berisi semua atribut pesan. Objek ini juga berisi kolom tambahan yang merupakan bagian dari pesan Pub/Sub, termasuk kunci pengurutan, jika ada.

Properti Cloud Storage

Saat memilih jenis pengiriman langganan sebagai Tulis ke Cloud Storage, Anda dapat menentukan properti tambahan berikut.

Nama bucket

Bucket Cloud Storage harus sudah ada sebelum Anda membuat langganan Cloud Storage.

Pesan dikirim sebagai batch dan disimpan di bucket Cloud Storage. Satu batch atau file disimpan sebagai objek dalam bucket.

Bucket Cloud Storage harus menonaktifkan Requester Pays.

Untuk membuat bucket Cloud Storage, lihat Membuat bucket.

Awalan, akhiran, dan tanggal waktu nama file

File Cloud Storage output yang dihasilkan oleh langganan Cloud Storage disimpan sebagai objek di bucket Cloud Storage. Nama objek yang disimpan di bucket Cloud Storage memiliki format berikut: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

Daftar berikut mencakup detail format file dan kolom yang dapat Anda sesuaikan:

<file-prefix> adalah awalan nama file kustom. Kolom ini bersifat opsional.
<UTC-date-time> adalah string yang dibuat otomatis dan dapat disesuaikan berdasarkan waktu saat objek dibuat.
<uuid> adalah string acak yang dibuat otomatis untuk objek.
<file-suffix> adalah sufiks nama file kustom. Kolom ini bersifat opsional. Sufiks nama file tidak boleh diakhiri dengan "/".
Anda dapat mengubah awalan dan akhiran nama file:
- Misalnya, jika nilai awalan nama file adalah prod_ dan nilai akhiran nama file adalah _archive, contoh nama objek adalah prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.
- Jika Anda tidak menentukan awalan dan akhiran nama file, nama objek yang disimpan di bucket Cloud Storage akan memiliki format: <UTC-date-time>_<uuid>.
- Persyaratan penamaan objek Cloud Storage juga berlaku untuk awalan dan akhiran nama file. Untuk mengetahui informasi selengkapnya, lihat Tentang objek Cloud Storage.
Anda dapat mengubah cara tanggal dan waktu ditampilkan dalam nama file:
- Pencocokan tanggal dan waktu wajib yang hanya dapat Anda gunakan satu kali: tahun (YYYY atau YY), bulan (MM), hari (DD), jam (hh), menit (mm), detik (ss). Misalnya, YY-YYYY atau MMM tidak valid.
- Pencocok opsional yang dapat Anda gunakan hanya sekali: pemisah tanggal dan waktu (T) dan dan selisih zona waktu (Z atau +00:00).
- Elemen opsional yang dapat Anda gunakan beberapa kali: tanda hubung (-), garis bawah (_), titik dua (:), dan garis miring (/).
- Misalnya, jika nilai format tanggal waktu nama file adalah YYYY-MM-DD/hh_mm_ssZ, contoh nama objek adalah prod_2023-09-25/04_10_00Z_uNiQuE_archive.
- Jika format tanggal dan waktu nama file diakhiri dengan karakter yang bukan pencocok, karakter tersebut akan menggantikan pemisah antara <UTC-date-time> dan <uuid>. Misalnya, jika nilai format tanggal waktu nama file adalah YYYY-MM-DDThh_mm_ss-, contoh nama objek adalah prod_2023-09-25T04_10_00-uNiQuE_archive.

Pengelompokan file dalam batch

Langganan Cloud Storage memungkinkan Anda memutuskan kapan Anda ingin membuat file output baru yang disimpan sebagai objek di bucket Cloud Storage. Pub/Sub menulis file output saat salah satu kondisi pengelompokan yang ditentukan terpenuhi. Berikut adalah kondisi batching Cloud Storage:

Durasi maksimum batch penyimpanan. Ini adalah setelan yang wajib diisi. Langganan Cloud Storage menulis file output baru jika nilai durasi maksimum yang ditentukan terlampaui. Jika Anda tidak menentukan nilai, nilai default 5 menit akan diterapkan. Berikut adalah nilai yang berlaku untuk durasi maks:
- Nilai minimum = 1 menit
- Nilai default = 5 menit
- Nilai maksimum = 10 menit
Byte maksimum batch penyimpanan. Setelan ini bersifat opsional. Langganan Cloud Storage menulis file output baru jika nilai maksimum byte yang ditentukan terlampaui. Berikut adalah nilai yang berlaku untuk byte maks:
- Nilai minimum = 1 KB
- Nilai maksimum = 10 GiB
Pesan maksimum batch penyimpanan. Setelan ini bersifat opsional. Langganan Cloud Storage menulis file output baru jika jumlah maksimum pesan yang ditentukan terlampaui. Berikut adalah nilai yang berlaku untuk pesan maks:
- Nilai minimum = 1000

Misalnya, Anda dapat mengonfigurasi durasi maks. sebagai 6 menit dan byte maks. sebagai 2 GB. Jika pada menit ke-4, file output mencapai ukuran file 2 GB, Pub/Sub akan menyelesaikan file sebelumnya dan mulai menulis ke file baru.

Langganan Cloud Storage dapat menulis ke beberapa file di bucket Cloud Storage secara bersamaan. Jika telah mengonfigurasi langganan untuk membuat file baru setiap 6 menit, Anda mungkin melihat beberapa file Cloud Storage dibuat setiap 6 menit.

Dalam beberapa situasi, Pub/Sub mungkin mulai menulis ke file baru lebih awal dari waktu yang dikonfigurasi oleh kondisi pengelompokan file. File juga dapat melebihi nilai Byte maks jika langganan menerima pesan yang lebih besar dari nilai Byte maks.

Format file

Saat membuat langganan Cloud Storage, Anda dapat menentukan format file output yang akan disimpan di bucket Cloud Storage sebagai Teks atau Avro.

Teks: Pesan disimpan sebagai teks biasa. Karakter baris baru memisahkan pesan dari pesan sebelumnya dalam file. Hanya payload pesan yang disimpan, bukan atribut atau metadata lainnya.
Avro: Pesan disimpan dalam format biner Apache Avro. Saat memilih Avro, Anda dapat mengaktifkan properti tambahan berikut:
- Tulis metadata: Opsi ini memungkinkan Anda menyimpan metadata pesan bersama dengan pesan. Metadata seperti kolom subscription_name, message_id, publish_time, dan attributes ditulis ke kolom tingkat teratas dalam objek Avro output, sementara semua properti pesan lainnya selain data (misalnya, ordering_key, jika ada) ditambahkan sebagai entri dalam peta attributes.
  
  Jika write metadata dinonaktifkan, hanya payload pesan yang ditulis ke objek Avro output. Berikut adalah skema Avro untuk pesan output dengan tulis metadata dinonaktifkan:
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}
```
  Berikut adalah skema Avro untuk pesan output dengan tulis metadata yang diaktifkan:
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessageWithMetadata",
  "fields": [
    { "name": "subscription_name", "type": "string" },
    { "name": "message_id", "type": "string"  },
    { "name": "publish_time", "type": {
        "type": "long",
        "logicalType": "timestamp-micros"
      }
    },
    { "name": "attributes", "type": { "type": "map", "values": "string" } },
    { "name": "data", "type": "bytes" }
  ]
}
```
- Gunakan skema topik: Opsi ini memungkinkan Pub/Sub menggunakan skema topik Pub/Sub yang menjadi tujuan langganan saat menulis file Avro.
  
  Saat Anda menggunakan opsi ini, jangan lupa untuk memeriksa persyaratan tambahan berikut:
  - Skema topik harus dalam format Apache Avro.
  - Jika gunakan skema topik dan tulis metadata diaktifkan, skema topik harus memiliki objek Record di root-nya. Pub/Sub akan memperluas daftar kolom Record untuk menyertakan kolom metadata. Akibatnya, Rekaman tidak boleh berisi kolom dengan nama yang sama dengan kolom metadata (subscription_name, message_id, publish_time, atau attributes).

Akun layanan

Anda memiliki opsi berikut untuk menulis pesan ke tabel BigQuery atau bucket Cloud Storage:

Konfigurasi akun layanan kustom sehingga hanya pengguna yang memiliki izin iam.serviceAccounts.actAs di akun layanan yang dapat membuat langganan yang menulis ke tabel atau bucket. Contoh peran yang menyertakan izin iam.serviceAccounts.actAs adalah peran Service Account User (roles/iam.serviceAccountUser).
Gunakan agen layanan Pub/Sub default yang memungkinkan pengguna mana pun dengan kemampuan untuk membuat langganan di project guna membuat langganan yang menulis ke tabel atau bucket. Agen layanan Pub/Sub adalah setelan default jika Anda tidak menentukan akun layanan kustom.