Properti langganan

Properti langganan Pub/Sub adalah karakteristik langganan. Anda dapat menyetel 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 akan dibahas di bagian berikutnya.

Durasi retensi pesan

Opsi Durasi retensi pesan menentukan berapa lama Pub/Sub mempertahankan pesan setelah dipublikasikan. Setelah durasi retensi pesan berlalu, Pub/Sub dapat menghapus pesan secara terpisah dari status konfirmasi pesan. Untuk mempertahankan pesan yang dikonfirmasi selama durasi retensi pesan, lihat Memutar ulang dan menghapus pesan.

Berikut adalah nilai untuk opsi Durasi retensi pesan:

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

Catatan: Mulai 30 Juni 2024, Anda akan dikenai biaya karena mempertahankan pesan yang tidak dikonfirmasi dengan langganan selama lebih dari 24 jam.

Pesan yang tidak dikonfirmasi dapat dihasilkan dari langganan yang tidak ada aktivitas, kebutuhan pencadangan, atau pemrosesan yang lambat. Jika Anda dapat memproses pesan dalam waktu 24 jam, biaya tambahan tidak akan dikenakan. Anda dapat menghindari tagihan baru dengan mengelola skenario berikut sebagai berikut:

• Langganan nonaktif. Hapus langganan saat tidak ada aktivitas untuk menghindari timbulnya biaya retensi pesan langganan.

• Penyimpanan cadangan. Jika menggunakan retensi langganan sebagai penyimpanan cadangan, Anda dapat beralih ke opsi penyimpanan lain seperti retensi pesan topik atau mempertahankan pesan yang dikonfirmasi. Retensi pesan topik menyimpan pesan hanya sekali di level topik, dan tetap tersedia untuk digunakan oleh semua langganan saat diperlukan.

• Pemrosesan tertunda. Tambahkan lebih banyak pelanggan (jika memungkinkan) untuk memproses pesan dalam satu hari.

Pertahankan pesan yang dikonfirmasi

Jika 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. Opsi ini meningkatkan biaya penyimpanan pesan. Untuk 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 habis masa berlakunya. Jika Pub/Sub mendeteksi aktivitas pelanggan atau jika Anda memperbarui properti langganan, jam penghapusan langganan akan dimulai ulang. Contoh aktivitas pelanggan mencakup koneksi terbuka, pull yang aktif, atau push yang berhasil.

Jika Anda menentukan periode habis masa berlaku, nilai harus lebih lama dari 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
• Nilai maksimum = 365 hari.

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

Batas waktu konfirmasi

Opsi Acknowledgment deadline menentukan batas waktu awal setelah pesan yang tidak terkonfirmasi akan dikirim lagi. Anda dapat memperpanjang batas waktu konfirmasi per pesan dengan mengirimkan permintaan ModifyAckDeadline berikutnya.

Berikut adalah nilai untuk opsi Acknowledgement deadline:

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

Dalam beberapa kasus, library klien Pub/Sub dapat mengontrol kecepatan pengiriman dan secara dinamis mengubah batas waktu konfirmasi. Dengan demikian, pesan mungkin akan dikirim ulang sebelum batas waktu konfirmasi 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.

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 berdasarkan atributnya, tetapi tidak menurut data dalam pesan.

• Jika tidak ditentukan, langganan tidak akan 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 traffic keluar untuk pesan yang dikonfirmasi Pub/Sub secara otomatis. Anda dikenai biaya pengiriman pesan dan biaya terkait penyimpanan pesan untuk pesan ini.

Untuk mengetahui informasi selengkapnya, lihat Memfilter pesan dari langganan.

Pengurutan pesan

Jika langganan mengaktifkan Pengurutan pesan, 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 yang dipesan, konfirmasi untuk pesan berikutnya tidak akan diproses hingga konfirmasi untuk pesan sebelumnya diproses.

Penerbit harus mengirim pesan dengan kunci pengurutan sehingga Pub/Sub dapat mengirimkan pesan secara berurutan.

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

Topik yang dihentikan pengirimannya

Jika pesan tidak dapat dikirimkan setelah sejumlah upaya pengiriman atau pelanggan tidak dapat mengonfirmasi pesan, Anda dapat mengonfigurasi topik yang dihentikan pengirimannya agar pesan-pesan ini dapat dipublikasikan ulang.

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

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

Jika topik yang dihentikan pengirimannya berada di project yang berbeda dengan langganan, Anda juga harus menentukan project ID dengan topik yang dihentikan pengirimannya.

Untuk informasi selengkapnya, lihat Meneruskan ke topik yang dihentikan pengirimannya.

Kebijakan coba lagi

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

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

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

Berikut adalah beberapa panduan untuk menetapkan nilai bagi 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 backoff terpanjang yang dapat Anda tentukan adalah 600 detik.

Kebijakan percobaan ulang dan batch pesan

Jika pesan berada dalam batch, Pub/Sub akan memulai backoff eksponensial jika salah satu hal berikut terjadi:

• Pelanggan mengirim konfirmasi negatif untuk setiap pesan dalam batch.

• Batas waktu konfirmasi akan berakhir.

Kebijakan percobaan ulang dan langganan push

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

Catatan: Saat Anda mengubah kebijakan durasi retensi pesan atau akhir masa berlaku langganan, periode habis masa berlaku harus disetel ke nilai yang lebih besar dari durasi retensi pesan. Durasi retensi pesan default adalah 7 hari dan periode habis masa berlaku default adalah 31 hari.

Properti langganan pull

Saat mengonfigurasi langganan pull, Anda dapat menentukan properti berikut.

Pengiriman tepat satu kali

Pengiriman tepat satu kali. Jika ditetapkan, Pub/Sub akan memenuhi jaminan pengiriman tepat satu kali. Jika tidak ditentukan, langganan akan 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 valid yang 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 atas dasar upaya terbaik.

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.

Authentication

Aktifkan autentikasi. Jika diaktifkan, pesan yang dikirim oleh Pub/Sub ke endpoint push akan menyertakan header otorisasi agar endpoint dapat mengautentikasi permintaan. Mekanisme autentikasi dan otorisasi otomatis tersedia untuk endpoint App Engine Standar dan Cloud Functions 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 spesifik kepada akun layanan khusus yang dikelola Google - seperti yang dibahas di bagian berikutnya.

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

  • Akun layanan ini harus berada dalam project yang sama dengan langganan push.

  • Akun utama yang membuat atau mengubah langganan push harus memiliki izin iam.serviceAccounts.actAs di akun layanan. Anda dapat memberikan peran dengan izin ini di project, folder, atau organisasi agar pemanggil dapat meniru identitas beberapa akun layanan atau memberikan peran dengan izin ini di akun layanan agar pemanggil hanya meniru identitas akun layanan ini.

• Penonton. String tunggal yang tidak peka huruf besar/kecil yang digunakan webhook untuk memvalidasi audiens yang dituju dari token khusus ini.

• Akun layanan yang dikelola Google (wajib).

  • Pub/Sub secara otomatis membuat akun layanan untuk Anda dengan format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

  • Akun layanan ini harus diberi izin iam.serviceAccounts.getOpenIdToken (termasuk dalam peran roles/iam.serviceAccountTokenCreator) agar Pub/Sub dapat membuat token JWT untuk permintaan push yang diautentikasi.

Pembukaan payload

Opsi Enable payload unwrapping menghapus pesan Pub/Sub dari semua metadata pesan, kecuali data pesan. Dengan pembukaan payload, data pesan akan dikirim langsung sebagai isi HTTP.

• Menulis metadata. Menambahkan kembali metadata pesan yang telah dihapus sebelumnya ke header permintaan.

Properti BigQuery

Saat memilih jenis pengiriman langganan sebagai Write to BigQuery, Anda dapat menentukan properti tambahan berikut.

Gunakan skema topik

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

Perhatian: Penghapusan skema atau revisi skema bersifat permanen. Setiap pesan yang divalidasi terhadap revisi skema yang telah dihapus pada saat publikasi tidak dapat ditulis ke BigQuery menggunakan langganan BigQuery dengan Use topic schema diaktifkan. Pertimbangkan untuk melakukan roll back skema, bukan menghapus skema atau revisi.

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 dalam skema topik tidak perlu diwajibkan dalam 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 tersebut dapat dihapus, pilih opsi Hapus kolom yang tidak dikenal.

• Anda hanya dapat memilih salah satu properti langganan, yaitu Use topic schema atau Use table schema.

Jika Anda tidak memilih opsi Use topic schema atau Use table schema, pastikan tabel BigQuery memiliki kolom bernama data dari 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 Drop unknown fields diaktifkan dan sebuah kolom ada dalam skema Pub/Sub, tapi bukan dalam skema BigQuery, pesan yang ditulis ke tabel BigQuery mungkin masih belum berisi kolom tersebut setelah menambahkannya ke skema BigQuery. Akhirnya, skema akan disinkronkan dan pesan berikutnya menyertakan kolom tersebut.

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

Untuk mempelajari fitur ini lebih lanjut, lihat Lakukan pembaruan tabel streaming dengan pengambilan data perubahan.

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

Gunakan skema tabel

Dengan opsi ini, Pub/Sub dapat 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:

• Pesan yang dipublikasikan harus dalam format JSON.

• Jika topik langganan memiliki skema yang terkait dengannya, properti encoding pesan harus ditetapkan ke JSON.

• Jika ada kolom BigQuery yang tidak ada dalam pesan, kolom BigQuery ini harus berada dalam mode NULLABLE.

• Jika pesan memiliki kolom tambahan yang tidak ada dalam skema BigQuery dan kolom ini dapat dihapus, pilih opsi Hapus kolom yang tidak dikenal.

• Dalam pesan JSON, nilai DATE, DATETIME, TIME, dan TIMESTAMP harus berupa bilangan bulat yang mematuhi representasi yang didukung.

• Dalam pesan JSON, nilai NUMERIC dan BIGNUMERIC harus dienkode byte menggunakan BigDecimalByteStringEncoder.

• Anda hanya dapat memilih salah satu properti langganan, yaitu Use topic schema atau Use table schema.

Jika Anda tidak memilih opsi Use topic schema atau Use table schema, pastikan tabel BigQuery memiliki kolom bernama data dari jenis BYTES, STRING, atau JSON. Pub/Sub menulis pesan ke kolom BigQuery ini.

Anda mungkin tidak melihat perubahan pada skema tabel BigQuery yang langsung diterapkan pada pesan yang ditulis ke tabel BigQuery. Misalnya, jika opsi Hapus kolom yang tidak dikenal diaktifkan dan sebuah kolom ada dalam pesan, tetapi tidak ada dalam skema BigQuery, pesan yang ditulis ke tabel BigQuery mungkin masih belum berisi kolom tersebut setelah menambahkannya ke skema BigQuery. Akhirnya, skema akan disinkronkan dan pesan berikutnya menyertakan kolom tersebut.

Saat 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 Lakukan pembaruan tabel streaming dengan pengambilan data perubahan.

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

Menghapus kolom yang tidak dikenal

Opsi ini digunakan dengan opsi Gunakan skema topik atau Gunakan skema tabel. Dengan opsi ini, Pub/Sub dapat menghapus kolom apa pun yang ada dalam skema atau pesan topik, tetapi tidak ada dalam skema BigQuery. Tanpa menetapkan Drop knowns fields, pesan dengan kolom tambahan tidak akan ditulis ke BigQuery dan tetap berada dalam backlog langganan. Langganan akan berakhir dalam status error.

Menulis metadata

Dengan opsi ini, Pub/Sub dapat menulis metadata setiap pesan ke kolom tambahan di tabel BigQuery. Selain itu, {i>metadata <i}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 Write metadata, tabel BigQuery tujuan hanya memerlukan kolom data kecuali jika use_topic_schema bernilai benar (true). Jika Anda memilih opsi Write metadata dan Use topic schema, skema topik tidak boleh berisi kolom apa pun dengan nama yang cocok dengan parameter metadata. Batasan ini mencakup versi camelcase dari parameter snake case ini.

Parameter
subscription_name	STRING Nama langganan.
message_id	STRING ID pesan
publish_time	TIMESTAMP Waktu publikasi pesan.
data	myactivity, STRING, atau JSON Isi pesan. Kolom data wajib ada untuk semua tabel BigQuery tujuan yang tidak memilih Use topic schema. Jika kolom berjenis JSON, 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 Write to 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 di 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 menyertakan 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 dihasilkan secara otomatis dan dapat disesuaikan berdasarkan waktu pembuatan objek.

• <uuid> adalah string acak yang dibuat secara otomatis untuk objek.

• <file-suffix> adalah akhiran nama file kustom. Kolom ini bersifat opsional. Akhiran 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 tampilan tanggal dan waktu dalam nama file:

  • Pencocok tanggal dan waktu yang diperlukan yang hanya dapat Anda gunakan sekali: tahun (YYYY atau YY), bulan (MM), hari (DD), jam (hh), menit (mm), detik (ss). Misalnya, YY-YYYY atau MMM tidak valid.

  • Pencocok opsional yang hanya dapat Anda gunakan satu kali: pemisah tanggal dan waktu (T) serta offset 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 dan waktu nama file adalah YYYY-MM-DD/hh_mm_ssZ, nama objek contoh adalah prod_2023-09-25/04_10_00Z_uNiQuE_archive.

  • Jika format tanggal dan nama nama file berakhiran karakter yang bukan pencocok, karakter tersebut akan menggantikan pemisah antara <UTC-date-time> dan <uuid>. Misalnya, jika nilai format tanggal dan waktu nama file adalah YYYY-MM-DDThh_mm_ss-, nama objek contoh adalah prod_2023-09-25T04_10_00-uNiQuE_archive.

Pengelompokan file

Dengan langganan Cloud Storage, Anda dapat memutuskan kapan akan membuat file output baru yang disimpan sebagai objek di bucket Cloud Storage. Pub/Sub menulis file output ketika salah satu kondisi pengelompokan yang ditentukan terpenuhi. Berikut adalah kondisi pengelompokan Cloud Storage:

• Durasi maksimum batch penyimpanan. Setelan ini wajib diisi. Langganan Cloud Storage akan menulis file output baru jika nilai durasi maksimum yang ditentukan terlampaui. Jika Anda tidak menentukan nilainya, nilai default 5 menit akan diterapkan. Berikut adalah nilai yang berlaku untuk durasi maksimum:

  • Nilai minimum = 1 menit
  • Nilai default = 5 menit
  • Nilai maksimum = 10 menit

• Byte maksimum batch penyimpanan. Ini adalah setelan opsional. Langganan Cloud Storage akan menulis file output baru jika nilai byte maksimum yang ditentukan terlampaui. Berikut adalah nilai yang berlaku untuk byte maksimal:

  • Nilai minimum = 1 KB
  • Nilai maksimum = 10 GiB

Misalnya, Anda dapat mengonfigurasi durasi maksimum 6 menit dan byte maksimum sebesar 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 Anda telah mengonfigurasi langganan untuk membuat file baru setiap menit ke-6, Anda mungkin mengamati beberapa file Cloud Storage dibuat setiap 6 menit.

Dalam beberapa situasi, Pub/Sub dapat mulai menulis ke file baru lebih awal dari waktu yang dikonfigurasi oleh kondisi pengelompokan file. File juga dapat melebihi nilai Max Byte 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 Text 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 juga dapat mengaktifkan opsi tulis metadata. Dengan opsi ini, Anda dapat menyimpan metadata pesan beserta pesan.

  Metadata seperti subscription_name, message_id, publish_time, dan kolom atribut ditulis ke kolom level teratas dalam objek Avro output, sementara semua properti pesan lainnya selain data (misalnya, order_key, jika ada) ditambahkan sebagai entri dalam peta atribut.

  Jika tulis metadata dinonaktifkan, hanya payload pesan yang akan ditulis ke objek Avro output.

  Berikut adalah skema Avro untuk pesan output tanpa mengaktifkan write metadata:

  {
    "type": "record",
    "namespace": "com.google.pubsub",
    "name": "PubsubMessage",
    "fields": [
      { "name": "data", "type": "bytes" }
    ]
  }
  

  Berikut adalah skema Avro untuk pesan output dengan write metadata aktif:

  {
    "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" }
    ]
  }
  

Langkah selanjutnya

• Buat langganan pull.
• Buat langganan push.
• Buat langganan BigQuery.
• Membuat langganan Cloud Storage.