Questa pagina è stata tradotta dall'API Cloud Translation.

Proprietà delle sottoscrizioni

Le proprietà di sottoscrizione Pub/Sub sono le caratteristiche di una sottoscrizione. Puoi impostare le proprietà delle sottoscrizioni quando crei o aggiorni una sottoscrizione.

Questo documento descrive le diverse proprietà della sottoscrizione che puoi impostare per una sottoscrizione.

Prima di iniziare

Scopri di più sugli abbonamenti.
Scopri il flusso di lavoro per la sottoscrizione che stai per creare: Pull, Push o BigQuery.

Proprietà delle sottoscrizioni comuni

Quando crei una sottoscrizione, devi specificare una serie di opzioni per la sua configurazione. Alcune di queste proprietà sono comuni a tutti i tipi di abbonamento e verranno discusse nelle sezioni successive.

Tempo di conservazione dei messaggi

L'opzione Durata di conservazione dei messaggi specifica per quanto tempo Pub/Sub conserva i messaggi dopo la pubblicazione. Una volta trascorsa la durata di conservazione dei messaggi, Pub/Sub potrebbe ignorarlo indipendentemente dallo stato di conferma del messaggio. Per conservare i messaggi confermati per la durata di conservazione dei messaggi, consulta Riprodurre ed eliminare i messaggi.

Di seguito sono riportati i valori dell'opzione Durata di conservazione dei messaggi:

Valore predefinito = 7 giorni
Valore minimo = 10 minuti
Valore massimo = 7 giorni

I messaggi non confermati possono derivare da abbonamenti inattivi, esigenze di backup o elaborazione lenta. Se sei in grado di elaborare i messaggi entro 24 ore, non ti verranno addebitati costi aggiuntivi. Per evitare nuovi addebiti, gestisci questi scenari come segue:

Abbonamenti inattivi. Elimina gli abbonamenti inattivi per evitare costi di conservazione dei messaggi di abbonamento.
Spazio di archiviazione di backup. Se utilizzi la conservazione delle sottoscrizioni come archiviazione di backup, puoi passare a un'altra opzione di archiviazione, ad esempio la conservazione dei messaggi di argomento o la conservazione dei messaggi confermati. La conservazione dei messaggi di un argomento archivia i messaggi solo una volta a livello di argomento e li rimangono disponibili per consentire a tutte le sottoscrizioni di utilizzarli quando necessario.
Ritardi nell'elaborazione. Aggiungi altri sottoscrittori (se possibile) per elaborare i messaggi entro un giorno.

Conserva messaggi confermati

Se specifichi la Durata di conservazione dei messaggi, puoi anche indicare se vuoi conservare i messaggi confermati.

L'opzione Conserva i messaggi confermati consente di conservare i messaggi confermati per il periodo di conservazione dei messaggi specificato. Questa opzione aumenta le tariffe per l'archiviazione dei messaggi. Per ulteriori informazioni, vedi costi di archiviazione.

Periodo di scadenza

L'opzione Periodo di scadenza ti consente di estendere il periodo di scadenza dell'abbonamento.

Gli abbonamenti senza attività di abbonati o modifiche apportate alle proprietà degli abbonamenti scadono. Se Pub/Sub rileva l'attività dell'abbonato o se aggiorni una delle proprietà della sottoscrizione, l'orologio di eliminazione delle sottoscrizioni viene riavviato. Esempi di attività degli abbonati includono connessioni aperte, pull attivi o push riusciti.

Se specifichi il periodo di scadenza, il valore deve essere superiore alla durata di conservazione dei messaggi specificata nell'opzione Durata di conservazione dei messaggi.

Di seguito sono riportati i valori per l'opzione Periodo di scadenza:

Valore predefinito = 31 giorni
Valore minimo = 1 giorno
Valore massimo = 365 giorni.

Per evitare che un abbonamento scada, imposta il periodo di scadenza su never expire.

Scadenza conferma

L'opzione Scadenza conferma specifica la scadenza iniziale dopo la quale viene inviato di nuovo un messaggio non confermato. Puoi estendere la scadenza per la conferma in base al singolo messaggio inviando successivamente richieste ModifyAckDeadline.

Di seguito sono riportati i valori dell'opzione Scadenza di conferma:

Valore predefinito = 10 secondi
Valore minimo = 10 secondi
Valore massimo = 600 secondi

In alcuni casi, le librerie client di Pub/Sub possono controllare la frequenza di distribuzione e modificare dinamicamente la scadenza di conferma. In questo modo, il messaggio potrebbe essere recapitato prima della scadenza della conferma che hai impostato. Per eseguire l'override di questo comportamento, utilizza minDurationPerAckExtension e maxDurationPerAckExtension. Per ulteriori informazioni sull'utilizzo di questi valori, consulta Supporto della distribuzione "exactly-once" nelle librerie client.

Filtro sottoscrizioni

Utilizza l'opzione Filtro sottoscrizione per specificare una stringa con un'espressione di filtro. Se una sottoscrizione ha un filtro, la sottoscrizione recapita solo i messaggi che corrispondono al filtro. Il servizio Pub/Sub riconosce automaticamente i messaggi che non corrispondono al filtro.

Puoi filtrare i messaggi in base ai rispettivi attributi, ma non in base ai dati al loro interno.
Se non specificato, la sottoscrizione non filtra i messaggi e i sottoscrittori ricevono tutti i messaggi.
Non è possibile modificare o rimuovere i filtri una volta applicati.

Quando ricevi messaggi da una sottoscrizione con un filtro, non ti vengono addebitate tariffe di traffico in uscita per i messaggi che Pub/Sub riconosce automaticamente. Per questi messaggi sono previste tariffe di consegna dei messaggi e tariffe di archiviazione correlata alla ricerca.

Per ulteriori informazioni, vedi Filtrare i messaggi da una sottoscrizione.

Ordinamento messaggi

Se in una sottoscrizione è abilitato l'ordinamento dei messaggi, i client sottoscrittori ricevono i messaggi pubblicati nella stessa regione con la stessa chiave di ordinamento nell'ordine in cui sono stati ricevuti dal servizio.

Quando si utilizza la consegna ordinata, i riconoscimenti per i messaggi successivi non vengono elaborati fino a quando non vengono elaborati quelli per i messaggi precedenti.

Gli editori devono inviare messaggi con una chiave di ordinamento in modo che Pub/Sub possa recapitare i messaggi in ordine.

Se non viene configurato, Pub/Sub potrebbe non recapitare i messaggi in ordine, anche se ha una chiave di ordinamento.

Argomento messaggi non recapitabili

Quando un messaggio non può essere recapitato dopo un determinato numero di tentativi di recapito o un sottoscrittore non riesce a confermarlo, puoi configurare un argomento messaggi non recapitabili in cui questi messaggi possono essere ripubblicati.

Se imposti un argomento messaggi non recapitabili, puoi anche specificare il numero massimo di tentativi di recapito. Di seguito sono riportati i valori per il numero massimo di tentativi di consegna per l'argomento messaggi non recapitabili:

Valore predefinito = 5 tentativi di recapito
Valore minimo = 5 tentativi di recapito
Valore massimo = 100 tentativi di recapito

Se l'argomento messaggi non recapitabili si trova in un progetto diverso da quello della sottoscrizione, devi specificare anche l'ID progetto nell'argomento messaggi non recapitabili.

Per ulteriori informazioni, vedi Inoltro ad argomenti messaggi non recapitabili.

Criterio di ripetizione

Se la scadenza della conferma scade o se un sottoscrittore risponde con una conferma negativa, Pub/Sub può inviare di nuovo il messaggio. Questo tentativo di ripubblicazione è noto come criterio relativo ai nuovi tentativi dell'abbonamento.

Per impostazione predefinita, il criterio per i nuovi tentativi per una sottoscrizione è impostato in modo da utilizzare Riprova immediatamente. Con questa opzione, Pub/Sub invia nuovamente il messaggio quando la scadenza di conferma scade o un sottoscrittore risponde con un riconoscimento negativo.

Puoi anche impostare il valore su Riprova dopo un ritardo di backoff esponenziale. In questo caso, devi specificare i valori di backoff massimo e minimo.

Ecco alcune linee guida per impostare i valori dei valori di backoff massimo e minimo:

Se imposti il valore massimo per la durata del backoff, il valore predefinito per la durata minima del backoff è 10 secondi.
Se imposti il valore minimo per la durata del backoff, il valore predefinito per la durata massima del backoff è 600 secondi.
La durata di backoff più lunga che puoi specificare è 600 secondi.

Criterio di ripetizione e messaggi in batch

Se i messaggi sono in batch, Pub/Sub avvia il backoff esponenziale quando si verifica una delle seguenti condizioni:

Il sottoscrittore invia una conferma negativa per ogni messaggio nel batch.
La scadenza per la conferma scade.

Criterio di ripetizione ed esecuzione push della sottoscrizione

Se ricevi messaggi da una sottoscrizione push, Pub/Sub potrebbe recapitare nuovamente i messaggi dopo il backoff del push anziché la durata del backoff esponenziale. Quando il backoff del push è superiore alla durata del backoff esponenziale, Pub/Sub recapita nuovamente i messaggi non confermati dopo il backoff del push.

Proprietà delle sottoscrizioni pull

Quando configuri una sottoscrizione pull, puoi specificare le seguenti proprietà.

Consegna "exactly-once"

Consegna "exactly-once". Se impostato, Pub/Sub soddisfa le garanzie di consegna exactly-once. Se non specificato, la sottoscrizione supporta la consegna at-least-once per ogni messaggio.

Proprietà delle sottoscrizioni push

Quando configuri una sottoscrizione push, puoi specificare le seguenti proprietà.

Endpoint

URL endpoint (obbligatorio). Un indirizzo HTTPS pubblicamente accessibile. Il server per l'endpoint push deve avere un certificato SSL valido firmato da un'autorità di certificazione. Il servizio Pub/Sub recapita i messaggi agli endpoint di push dalla stessa regione Google Cloud in cui il servizio Pub/Sub archivia i messaggi. Il servizio Pub/Sub recapita i messaggi dalla stessa regione Google Cloud secondo il criterio del "best effort".

Pub/Sub non richiede più la prova della proprietà per i domini URL con sottoscrizione push. Se il tuo dominio riceve richieste POST impreviste da Pub/Sub, puoi segnalare i sospetti comportamenti illeciti.

Autenticazione

Attiva autenticazione. Se questa opzione è abilitata, i messaggi consegnati da Pub/Sub all'endpoint push includono un'intestazione di autorizzazione per consentire all'endpoint di autenticare la richiesta. Sono disponibili meccanismi automatici di autenticazione e autorizzazione per gli endpoint App Engine Standard e Cloud Functions ospitati nello stesso progetto dell'abbonamento.

La configurazione di autenticazione per un abbonamento push autenticato è composta da un account di servizio gestito dall'utente e i parametri dei segmenti di pubblico specificati in una chiamata create, patch o ModifyPushConfig. Devi inoltre concedere un ruolo specifico a un agente di servizio, come discusso nella prossima sezione.

Account di servizio gestito dall'utente (obbligatorio). L'account di servizio associato alla sottoscrizione push. Questo account viene utilizzato come attestazione email del token JWT (JSON Web Token) generato. Di seguito è riportato un elenco dei requisiti per l'account di servizio:
- Questo account di servizio deve trovarsi nello stesso progetto della sottoscrizione push.
- L'entità che crea o modifica la sottoscrizione push deve avere l'autorizzazione iam.serviceAccounts.actAs per l'account di servizio. Puoi concedere un ruolo con questa autorizzazione nel progetto, nella cartella o nell'organizzazione per consentire al chiamante di impersonare più account di servizio oppure concedere un ruolo con questa autorizzazione nell'account di servizio per consentire al chiamante di impersonare solo questo account di servizio.
Pubblico. Una singola stringa, senza distinzione tra maiuscole e minuscole, utilizzata dal webhook per convalidare il pubblico previsto per questo particolare token.
Agente di servizio (obbligatorio).
- Pub/Sub crea automaticamente un account di servizio con il formato service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.
- A questo agente di servizio deve essere concessa l'autorizzazione iam.serviceAccounts.getOpenIdToken (inclusa nel ruolo di roles/iam.serviceAccountTokenCreator) per consentire a Pub/Sub di creare token JWT per le richieste push autenticate.

Annullamento del wrapping del payload

L'opzione Abilita l'annullamento del wrapping del payload rimuove i messaggi Pub/Sub di tutti i metadati dei messaggi, ad eccezione dei dati dei messaggi. Con l'annullamento del wrapping del payload, i dati dei messaggi vengono consegnati direttamente come il corpo HTTP.

Scrivi metadati. Aggiunge di nuovo i metadati del messaggio rimossi in precedenza nell'intestazione della richiesta.

Proprietà BigQuery

Quando selezioni il tipo di consegna delle sottoscrizioni come Scrivi in BigQuery, puoi specificare le seguenti proprietà aggiuntive.

Utilizza schema argomento

Questa opzione consente a Pub/Sub di utilizzare lo schema dell'argomento Pub/Sub a cui è collegata la sottoscrizione. Inoltre, Pub/Sub scrive i campi dei messaggi nelle colonne corrispondenti della tabella BigQuery.

Quando utilizzi questa opzione, ricordati di controllare i seguenti requisiti aggiuntivi:

I campi dello schema dell'argomento e dello schema BigQuery devono avere gli stessi nomi e i tipi devono essere compatibili tra loro.
Qualsiasi campo facoltativo nello schema dell'argomento deve essere facoltativo anche nello schema BigQuery.
I campi obbligatori nello schema dell'argomento non devono essere obbligatori nello schema BigQuery.
Se sono presenti campi BigQuery non presenti nello schema dell'argomento, questi campi BigQuery devono essere in modalità NULLABLE.
Se lo schema dell'argomento ha campi aggiuntivi che non sono presenti nello schema BigQuery e questi campi possono essere eliminati, seleziona l'opzione Trascina campi sconosciuti.
Puoi selezionare solo una delle proprietà della sottoscrizione, Utilizza schema argomento o Utilizza schema tabella.

Se non selezioni l'opzione Utilizza schema argomento o Utilizza schema della tabella, assicurati che la tabella BigQuery abbia una colonna denominata data di tipo BYTES, STRING o JSON. Pub/Sub scrive il messaggio in questa colonna BigQuery.

Potresti non vedere le modifiche allo schema degli argomenti Pub/Sub o allo schema della tabella BigQuery che vengono applicate immediatamente con i messaggi scritti nella tabella BigQuery. Ad esempio, se l'opzione Rilascia campi sconosciuti è abilitata ed è presente un campo nello schema Pub/Sub, ma non nello schema BigQuery, i messaggi scritti nella tabella BigQuery potrebbero comunque non contenere il campo dopo averlo aggiunto allo schema BigQuery. Alla fine, gli schemi si sincronizzano e i messaggi successivi includono il campo.

Quando utilizzi l'opzione Utilizza schema argomento per la tua sottoscrizione BigQuery, puoi anche sfruttare la tecnologia Change Data Capture (CDC) di BigQuery. CDC aggiorna le tabelle BigQuery elaborando e applicando le modifiche alle righe esistenti.

Per saperne di più su questa funzionalità, consulta Flusso di aggiornamenti delle tabelle con Change Data Capture (CDC).

Per informazioni su come utilizzare questa funzionalità con le sottoscrizioni BigQuery, consulta Change Data Capture (CDC) di BigQuery.

Utilizza schema tabella

Questa opzione consente a Pub/Sub di utilizzare lo schema della tabella BigQuery per scrivere i campi di un messaggio JSON nelle colonne corrispondenti. Quando utilizzi questa opzione, ricordati di controllare i seguenti requisiti aggiuntivi:

I messaggi pubblicati devono essere in formato JSON.
Se all'argomento della sottoscrizione è associato uno schema, la proprietà di codifica dei messaggi deve essere impostata su JSON.
Se non sono presenti campi BigQuery non presenti nei messaggi, questi campi BigQuery devono essere in modalità NULLABLE.
Se i messaggi hanno campi aggiuntivi che non sono presenti nello schema BigQuery e questi campi possono essere eliminati, seleziona l'opzione Trascina campi sconosciuti.
Nel messaggio JSON, i valori DATE, DATETIME, TIME e TIMESTAMP devono essere numeri interi che rispettano le rappresentazioni supportate.
Nel messaggio JSON, i valori NUMERIC e BIGNUMERIC devono essere codificati in byte utilizzando BigDecimalByteStringEncoder.
Puoi selezionare solo una delle proprietà della sottoscrizione, Utilizza schema argomento o Utilizza schema tabella.

Potresti non notare che le modifiche allo schema della tabella BigQuery vengono applicate immediatamente con i messaggi scritti nella tabella BigQuery. Ad esempio, se l'opzione Rilascia campi sconosciuti è abilitata e nei messaggi è presente un campo, ma non nello schema BigQuery, i messaggi scritti nella tabella BigQuery potrebbero comunque non contenere il campo dopo averlo aggiunto allo schema BigQuery. Alla fine, lo schema si sincronizza e i messaggi successivi includono il campo.

Quando utilizzi l'opzione Utilizza schema della tabella per la tua sottoscrizione BigQuery, puoi anche sfruttare la tecnologia Change Data Capture (CDC) di BigQuery. CDC aggiorna le tabelle BigQuery elaborando e applicando modifiche alle righe esistenti.

Per saperne di più su questa funzionalità, consulta Flusso di aggiornamenti delle tabelle con Change Data Capture (CDC).

Per informazioni su come utilizzare questa funzionalità con le sottoscrizioni BigQuery, consulta Acquisizione dei dati sulle modifiche a BigQuery.

Rilascia campi sconosciuti

Questa opzione viene utilizzata con l'opzione Utilizza schema argomento o Utilizza schema della tabella. Questa opzione consente a Pub/Sub di eliminare qualsiasi campo presente nello schema o nel messaggio dell'argomento, ma non nello schema BigQuery. Se non è impostata l'opzione Rilascia campi sconosciuti, i messaggi con campi aggiuntivi non vengono scritti in BigQuery e rimangono nel backlog della sottoscrizione. L'abbonamento viene visualizzato in uno stato di errore.

Scrivi metadati

Questa opzione consente a Pub/Sub di scrivere i metadati di ciascun messaggio in colonne aggiuntive della tabella BigQuery. In caso contrario, i metadati non vengono scritti nella tabella BigQuery.

Se selezioni l'opzione Scrivi metadati, assicurati che la tabella BigQuery contenga i campi descritti nella seguente tabella.

Se non selezioni l'opzione Scrivi metadati, la tabella BigQuery di destinazione richiede solo il campo data, a meno che use_topic_schema non sia true. Se selezioni entrambe le opzioni Scrivi metadati e Utilizza schema argomento, lo schema dell'argomento non deve contenere campi con nomi corrispondenti a quelli dei parametri dei metadati. Questa limitazione include le versioni camelcase di questi parametri snake case.

Parametri
`subscription_name`	STRING Nome di una sottoscrizione.
`message_id`	STRING ID di un messaggio
`publish_time`	TIMESTAMP L'ora di pubblicazione di un messaggio.
`data`	BYTES, STRING o JSON Il corpo del messaggio. Il campo `data` è obbligatorio per tutte le tabelle BigQuery di destinazione che non selezionano Utilizza schema argomento o Utilizza schema tabella. Se il campo è di tipo JSON, il corpo del messaggio deve essere in formato JSON valido.
`attributes`	STRING o JSON Un oggetto JSON contenente tutti gli attributi dei messaggi. Contiene anche altri campi che fanno parte del messaggio Pub/Sub, inclusa la chiave di ordinamento, se presente.

Proprietà di Cloud Storage

Quando selezioni il tipo di consegna delle sottoscrizioni come Scrittura in Cloud Storage, puoi specificare le seguenti proprietà aggiuntive.

Nome bucket

Prima della creazione di un abbonamento a Cloud Storage deve esistere già un bucket Cloud Storage.

I messaggi vengono inviati in batch e archiviati nel bucket Cloud Storage. Un singolo batch o file viene archiviato come oggetto nel bucket.

Nel bucket Cloud Storage deve essere disabilitata l'opzione Pagamenti a carico del richiedente.

Per creare un bucket Cloud Storage, consulta Creare bucket.

Prefisso, suffisso e data/ora del nome file

I file Cloud Storage di output generati dalla sottoscrizione Cloud Storage vengono archiviati come oggetti nel bucket Cloud Storage. Il nome dell'oggetto archiviato nel bucket Cloud Storage ha il seguente formato: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

Il seguente elenco include i dettagli del formato file e i campi che puoi personalizzare:

<file-prefix> è il prefisso del nome file personalizzato. Questo campo è facoltativo.
<UTC-date-time> è una stringa personalizzabile generata automaticamente in base al momento di creazione dell'oggetto.
<uuid> è una stringa casuale generata automaticamente per l'oggetto.
<file-suffix> è il suffisso del nome file personalizzato. Questo campo è facoltativo. Il suffisso del file non può terminare con "/".
Puoi modificare il prefisso e il suffisso del nome file:
- Ad esempio, se il valore del prefisso del nome file è prod_ e il valore del suffisso del nome file è _archive, il nome di un oggetto di esempio è prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.
- Se non specifichi il prefisso e il suffisso del nome file, il nome dell'oggetto archiviato nel bucket Cloud Storage sarà nel formato: <UTC-date-time>_<uuid>.
- I requisiti di denominazione degli oggetti di Cloud Storage si applicano anche al prefisso e al suffisso dei nomi file. Per ulteriori informazioni, consulta Informazioni sugli oggetti Cloud Storage.
È possibile modificare la modalità di visualizzazione di data e ora nel nome file:
- Corrispondenza data e ora obbligatorie che puoi utilizzare una sola volta: anno (YYYY o YY), mese (MM), giorno (DD), ora (hh), minuto (mm), secondo (ss). Ad esempio, YY-YYYY o MMM non sono validi.
- Corrispondenza facoltativi che puoi utilizzare una sola volta: separatore data/ora (T) e sfasamento del fuso orario (Z o +00:00).
- Elementi facoltativi che puoi utilizzare più volte: trattino (-), trattino basso (_), due punti (:) e barra (/).
- Ad esempio, se il valore del formato data/ora del nome file è YYYY-MM-DD/hh_mm_ssZ, un nome oggetto di esempio è prod_2023-09-25/04_10_00Z_uNiQuE_archive.
- Se il formato data/ora del nome file termina con un carattere che non è un matcher, questo carattere sostituirà il separatore tra <UTC-date-time> e <uuid>. Ad esempio, se il valore del formato data/ora del nome file è YYYY-MM-DDThh_mm_ss-, un nome oggetto di esempio è prod_2023-09-25T04_10_00-uNiQuE_archive.

Batch di file

Gli abbonamenti a Cloud Storage ti consentono di decidere quando creare un nuovo file di output da archiviare come oggetto nel bucket Cloud Storage. Pub/Sub scrive un file di output quando viene soddisfatta una delle condizioni di batch specificate. Di seguito sono riportate le condizioni di raggruppamento in batch di Cloud Storage:

Durata massima batch di archiviazione. Questa impostazione è obbligatoria. L'abbonamento a Cloud Storage scrive un nuovo file di output se viene superato il valore specificato di durata massima. Se non specifichi il valore, viene applicato un valore predefinito di 5 minuti. Di seguito sono riportati i valori applicabili per la durata massima:
- Valore minimo = 1 minuto
- Valore predefinito = 5 minuti
- Valore massimo = 10 minuti
Byte massimi batch di archiviazione. Questa impostazione è facoltativa. La sottoscrizione Cloud Storage scrive un nuovo file di output se viene superato il valore massimo di byte specificato. Di seguito sono riportati i valori applicabili per i byte massimi:
- Valore minimo = 1 kB
- Valore massimo = 10 GiB

Ad esempio, puoi configurare una durata massima di 6 minuti e di 2 GB. Se al quarto minuto il file di output raggiunge una dimensione file di 2 GB, Pub/Sub finalizza il file precedente e inizia a scrivere in un nuovo file.

Un abbonamento a Cloud Storage potrebbe scrivere su più file contemporaneamente in un bucket Cloud Storage. Se hai configurato la tua sottoscrizione in modo da creare un nuovo file ogni 6 minuti, potresti osservare la creazione di più file di Cloud Storage ogni 6 minuti.

In alcune situazioni, Pub/Sub potrebbe iniziare a scrivere su un nuovo file prima dell'orario configurato dalle condizioni di batch dei file. Un file può anche superare il valore Max byte se la sottoscrizione riceve messaggi di dimensioni superiori al valore Max byte.

Formato file

Quando crei un abbonamento a Cloud Storage, puoi specificare il formato dei file di output da archiviare in un bucket Cloud Storage come Text o Avro.

Testo: i messaggi vengono archiviati come testo normale. Un carattere di nuova riga separa un messaggio dal messaggio precedente nel file. Vengono archiviati solo i payload dei messaggi, non gli attributi o altri metadati.
Avro: i messaggi vengono archiviati in formato binario Apache Avro.

Quando selezioni Avro, puoi abilitare ulteriormente l'opzione Scrivi metadati. Questa opzione ti consente di archiviare i metadati del messaggio insieme al messaggio.

I metadati come subscription_name, message_id, publish_time e i campi degli attributi vengono scritti nei campi di primo livello dell'oggetto Avro di output, mentre tutte le altre proprietà dei messaggi diverse dai dati (ad esempio, una Order_key, se presente) vengono aggiunte come voci nella mappa degli attributi.

Se la funzionalità di scrittura dei metadati è disabilitata, solo il payload del messaggio viene scritto nell'oggetto Avro di output.

Ecco lo schema Avro per i messaggi di output senza metadati di scrittura abilitati:
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}
```
Ecco lo schema Avro per i messaggi di output con i metadati di scrittura abilitati:
```
{
  "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" }
  ]
}
```