Panoramica dei connettori

Questo documento fornisce una panoramica dei connettori Kafka Connect in Google Cloud. Scopri quando utilizzare ciascun tipo di connettore per gestire e integrare i tuoi stream di dati.

Questi connettori utilizzano il framework Kafka Connect per integrare Apache Kafka con altre applicazioni. Inseriscono e replicano i dati tra i cluster e le applicazioni Kafka. I tipi di connettore disponibili includono:

  • Connettori MirrorMaker 2.0

    • Connettore di origine

    • Connettore checkpoint

    • Connettore heartbeat

  • Connettore di sink BigQuery

  • Connettore di sink Cloud Storage

  • Connettore di origine Pub/Sub

  • Connettore di sink Pub/Sub

I connettori MirrorMaker 2.0 sono progettati specificamente per la replica dei dati e il ripristino di emergenza tra i cluster Kafka. Facilitano il mirroring dei dati da un cluster Kafka a un altro, consentendo alta disponibilità e tolleranza agli errori.

I connettori MirrorMaker 2.0 possono stabilire connessioni tra cluster Managed Service per Apache Kafka e altri cluster Managed Service per Apache Kafka o cluster Kafka autogestiti.

Gli altri connettori sink e di origine servono a integrare Kafka con vari serviziGoogle Cloud . Questi connettori consentono il trasferimento di dati tra cluster del servizio gestito per Apache Kafka e servizi Google Cloud , come BigQuery, Cloud Storage o Pub/Sub.

Prima di iniziare

Prima di esplorare e creare connettori, assicurati di disporre delle seguenti conoscenze e prerequisiti:

Quando utilizzare MirrorMaker 2.0

Utilizza i connettori MirrorMaker 2.0 nei seguenti scenari:

  • Migra i dati: sposta il tuo carico di lavoro Kafka in un nuovo cluster Managed Service per Apache Kafka.

  • Recupero in caso di emergenze: crea un cluster di backup per garantire la continuità aziendale in caso di guasti.

  • Aggrega i dati: consolida i dati di più cluster Kafka in un cluster Managed Service per Apache Kafka centrale a fini di analisi.

Funzionalità principali di MirrorMaker 2.0

  • Replica tutti i componenti necessari, inclusi argomenti, dati, configurazioni, gruppi di consumatori con offset e ACL.
  • Mantiene lo stesso schema di partizionamento nel cluster di destinazione, il che semplifica la transizione per le applicazioni.
  • Rileva e replica automaticamente nuovi argomenti e partizioni, riducendo al minimo la configurazione manuale.
  • Fornisce metriche essenziali, come la latenza di replica end-to-end, che ti consentono di monitorare l'integrità e le prestazioni del processo di replica.
  • Garantisce un funzionamento affidabile, anche con volumi di dati elevati, e può essere scalato orizzontalmente per gestire carichi di lavoro crescenti.
  • Utilizza argomenti interni per la sincronizzazione dell'offset, i checkpoint e i battiti. Questi argomenti hanno fattori di replica configurabili, come offset.syncs.topic.replication.factor, per garantire alta disponibilità e tolleranza di errore.

Utilizzare il connettore di origine MirrorMaker 2.0

Il connettore di origine MirrorMaker 2.0 replica gli argomenti e i dati da un cluster Kafka (l'origine) a un altro cluster Kafka (la destinazione).

Origine Target
Cluster Managed Service per Apache Kafka Cluster Managed Service per Apache Kafka
Cluster Managed Service per Apache Kafka Cluster Kafka esterno o autogestito
Cluster Kafka esterno o autogestito Cluster Managed Service per Apache Kafka

Il connettore di origine MirrorMaker 2.0 supporta i seguenti scenari di migrazione:

  • Replica o esegui la migrazione dei dati da un cluster Kafka esterno o autogestito a un cluster Managed Service per Apache Kafka

  • Replica o esegui la migrazione dei dati da un cluster Managed Service per Apache Kafka a un cluster Kafka esterno o autogestito.

  • Replica i dati Kafka tra le regioni per soddisfare i requisiti di ripristino di emergenza e alta disponibilità.

Utilizzare il connettore di checkpoint MirrorMaker 2.0

L'utilizzo del connettore di checkpoint MirrorMaker 2.0 è facoltativo. Copia gli offset dei consumer, che indicano l'ultimo messaggio utilizzato correttamente. Questo processo garantisce che i consumatori del cluster di destinazione possano riprendere l'elaborazione dallo stesso punto del cluster di origine.

Questo connettore non è necessario per il funzionamento del connettore di origine MirrorMaker 2.0. Questo connettore è necessario solo se devi sincronizzare lo stato di ConsumerGroup per tempi di inattività minimi durante il passaggio dal cluster di origine a quello di destinazione. Se ti serve solo una copia dei dati di origine, questo connettore non è necessario.

Utilizza il connettore di checkpoint MirrorMaker 2.0 per i seguenti casi d'uso:

  • Ripristino di emergenza per mantenere uno stato del consumatore coerente nei cluster e consentire il failover senza interruzioni.

  • Conserva i progressi dei consumatori negli scenari in cui è fondamentale.

Utilizzare il connettore Heartbeat MirrorMaker 2.0

Il connettore di heartbeat MirrorMaker 2.0 è un componente facoltativo che genera messaggi heartbeat periodici sul cluster Kafka di origine. Il connettore scrive questi messaggi in un argomento dedicato, in genere denominato heartbeats.

Puoi configurare un connettore di origine MirrorMaker 2.0 per replicare l'argomento heartbeats nel cluster di destinazione. Osservando questo argomento replicato nel cluster di destinazione, puoi monitorare lo stato e il rendimento del flusso di replica dell'argomento. In questo modo è possibile verificare la connessione e il flusso di dati tra i cluster, anche quando non vengono prodotti o replicati altri dati.

Il deployment del connettore Heartbeat da solo non monitora automaticamente l'integrità della replica. Per utilizzarlo per il monitoraggio, devi replicare l'argomento heartbeats e poi osservarne la presenza e la tempestività nel cluster di destinazione oppure utilizzare strumenti di monitoraggio che utilizzano questi heartbeat.

Il connettore heartbeat non è necessario per il funzionamento del connettore di origine MirrorMaker 2.0. Utilizza il connettore Heartbeat MirrorMaker 2.0 per i seguenti casi d'uso:

  • Monitora l'integrità e lo stato della replica di MirrorMaker 2.

  • Configura gli avvisi in Cloud Monitoring utilizzando i heartbeat generati e le metriche disponibili per ricevere una notifica quando la replica o l'heartbeat si interrompe.

Utilizzare i connettori sink

I connettori di sink esportano i dati dagli argomenti Kafka ad altri sistemi.

Utilizza il connettore di sink BigQuery

Il connettore di sink BigQuery trasmette i dati dagli argomenti Kafka alle tabelle BigQuery.

Utilizza il connettore di sink BigQuery per i seguenti casi d'uso:

  • Data warehousing, per caricare i dati di streaming in BigQuery per analisi e report.

  • Compilazione delle tabelle BigQuery che alimentano le dashboard in tempo reale.

Utilizzare il connettore di sink Cloud Storage

Il connettore di sink Cloud Storage trasmette i dati dagli argomenti Kafka ai bucket Cloud Storage.

Utilizza il connettore di sink Cloud Storage per i seguenti casi d'uso:

  • Importazione del data lake, per archiviare i dati Kafka in un data lake per l'archiviazione a lungo termine e l'elaborazione batch.

  • Archiviazione dei dati per soddisfare i requisiti normativi.

Utilizza il connettore di sink Pub/Sub

Il connettore di sink Pub/Sub trasmette i messaggi dagli argomenti Kafka a un argomento Pub/Sub.

Utilizza il connettore di sink Pub/Sub per i seguenti casi d'uso:

  • Integrazione del servizio, per inviare dati da Kafka ad altri Google Cloud servizi o applicazioni che utilizzano Pub/Sub.

  • Attivazione di notifiche o azioni in tempo reale in base ai dati elaborati.

Utilizzare i connettori di origine

I connettori di origine importano i dati da altri sistemi negli argomenti Kafka.

Utilizza il connettore di origine Pub/Sub

Il connettore di origine Pub/Sub trasmette i messaggi da una sottoscrizione Pub/Sub a un argomento Kafka.

Utilizza il connettore di origine Pub/Sub per i seguenti casi d'uso:

  • Importazione dati in tempo reale, che porta i dati da servizi cloud o altre applicazioni e li pubblica in Pub/Sub in Kafka per l'elaborazione dei flussi.

  • Architetture basate su eventi, che attivano l'elaborazione basata su Kafka in base agli eventi pubblicati su Pub/Sub.

Policy di riavvio attività

Puoi impostare la policy di riavvio delle attività di un connettore, che determina il comportamento quando si verifica un errore. I connettori supportano le seguenti norme:

  • Non riavviare mai. Il connettore non riavvia le attività non riuscite. Questo criterio è il comportamento predefinito. È utile per il debug o in situazioni in cui è necessario un intervento manuale dopo un errore.

  • Riavvia con backoff esponenziale. Il connettore riavvia un'attività non riuscita dopo un ritardo (chiamato periodo di backoff). Il ritardo aumenta in modo esponenziale a ogni errore successivo. Questo criterio è consigliato per la maggior parte dei carichi di lavoro di produzione.

    Se utilizzi il criterio di backoff esponenziale, imposta anche i valori per il backoff minimo e massimo. Il backoff minimo deve essere maggiore di 60 secondi e il backoff massimo deve essere inferiore a 7200 secondi.

Trasformazioni e predicati

Kafka Connect supporta le trasformazioni e i predicati Kafka predefiniti.

Specifichi la configurazione nell'ambito della configurazione del connettore. Ad esempio, per configurare un connettore sink in modo che ignori i messaggi che contengono una chiave di intestazione DoNotProcess, aggiungi la seguente configurazione al connettore:

transforms=dropMessage
transforms.dropMessage.type=org.apache.kafka.connect.transforms.Filter
transforms.dropMessage.predicate=hasKey
predicates=hasKey
predicates.hasKey.type=org.apache.kafka.connect.transforms.predicates.HasHeaderKey
predicates.hasKey.name=DoNotProcess

Questa configurazione esegue le seguenti operazioni:

  1. Configura un predicato denominato hasKey di tipo org.apache.kafka.connect.transforms.predicates.HasHeaderKey. Questo predicato corrisponde a tutti i messaggi che contengono un'intestazione con la chiave DoNotProcess.

  2. Configura una trasformazione denominata dropMessage di tipo org.apache.kafka.connect.transforms.Filter. Questa trasformazione elimina tutti i messaggi che corrispondono al predicato configurato.

  3. Collega la trasformazione al predicato hasKey. In questo modo, solo i messaggi con la chiave di intestazione DoNotProcess presente vengono eliminati dalla trasformazione.

Per saperne di più, consulta la documentazione di Kafka su trasformazioni e predicati.

Passaggi successivi

Apache Kafka® è un marchio registrato di Apache Software Foundation o delle sue affiliate negli Stati Uniti e/o in altri paesi.