Visão geral dos conectores

Neste documento, apresentamos uma visão geral dos conectores do Kafka Connect noGoogle Cloud. Descubra quando usar cada tipo de conector para gerenciar e integrar seus fluxos de dados.

Esses conectores usam o framework Kafka Connect para integrar o Apache Kafka a outros aplicativos. Eles ingerem e replicam dados entre seus clusters e aplicativos do Kafka. Os tipos de conectores disponíveis incluem:

  • Conectores do MirrorMaker 2.0

    • Conector de origem

    • Conector de checkpoint

    • Conector de pulsação

  • Conector de coletor do BigQuery

  • Conector de coletor do Cloud Storage

  • Conector de origem do Pub/Sub

  • Conector de coletor do Pub/Sub

Os conectores do MirrorMaker 2.0 são projetados especificamente para replicação de dados e recuperação de desastres entre clusters do Kafka. Eles facilitam o espelhamento de dados de um cluster do Kafka para outro, permitindo alta disponibilidade e tolerância a falhas.

Os conectores do MirrorMaker 2.0 podem estabelecer conexões entre clusters do Serviço Gerenciado para Apache Kafka e outros clusters do Serviço Gerenciado para Apache Kafka ou clusters autogerenciados do Kafka.

Os outros conectores de coletor e origem servem para integrar o Kafka a vários serviços doGoogle Cloud . Esses conectores permitem a transferência de dados entre clusters do serviço gerenciado para Apache Kafka e serviços do Google Cloud , como BigQuery, Cloud Storage ou Pub/Sub.

Antes de começar

Antes de explorar e criar conectores, verifique se você tem o seguinte entendimento e pré-requisitos:

Quando usar o MirrorMaker 2.0

Use conectores do MirrorMaker 2.0 nos seguintes cenários:

  • Migrar dados: mova sua carga de trabalho do Kafka para um novo cluster do Serviço gerenciado para Apache Kafka.

  • Recuperação de desastres: crie um cluster de backup para garantir a continuidade dos negócios em caso de falhas.

  • Agregar dados: consolide dados de vários clusters do Kafka em um cluster central do Serviço Gerenciado para Apache Kafka para fins analíticos.

Principais recursos do MirrorMaker 2.0

  • Replica todos os componentes necessários, incluindo tópicos, dados, configurações, grupos de consumidores com offsets e ACLs.
  • Mantém o mesmo esquema de particionamento no cluster de destino, o que simplifica a transição para aplicativos.
  • Detecta e replica automaticamente novos tópicos e partições, minimizando a configuração manual.
  • Fornece métricas essenciais, como latência de replicação de ponta a ponta, que permitem monitorar a integridade e o desempenho do processo de replicação.
  • Garante uma operação confiável, mesmo com grandes volumes de dados, e pode ser escalonado horizontalmente para lidar com o aumento das cargas de trabalho.
  • Usa tópicos internos para sincronização de compensação, pontos de verificação e pulsações. Esses tópicos têm fatores de replicação configuráveis, como offset.syncs.topic.replication.factor, para garantir alta disponibilidade e tolerância a falhas.

Usar o conector de origem do MirrorMaker 2.0

O conector de origem do MirrorMaker 2.0 replica tópicos e dados de um cluster do Kafka (a origem) para outro (o destino).

Origem Destino
Cluster do Serviço gerenciado para Apache Kafka Cluster do Serviço gerenciado para Apache Kafka
Cluster do Serviço gerenciado para Apache Kafka Cluster do Kafka externo ou autogerenciado
Cluster do Kafka externo ou autogerenciado Cluster do Serviço gerenciado para Apache Kafka

O conector de origem do MirrorMaker 2.0 é compatível com estes cenários de migração:

  • Replique ou migre dados de um cluster do Kafka externo ou autogerenciado para um cluster do Serviço gerenciado para Apache Kafka.

  • Replique ou migre dados de um cluster do Serviço gerenciado para Apache Kafka para um cluster do Kafka externo ou autogerenciado.

  • Replique dados do Kafka entre regiões para atender aos requisitos de recuperação de desastres e alta disponibilidade.

Usar o conector de ponto de verificação do MirrorMaker 2.0

O uso do conector de ponto de verificação do MirrorMaker 2.0 é opcional. Ele copia os offsets do consumidor, que indicam a última mensagem consumida com sucesso. Esse processo garante que os consumidores no cluster de destino possam retomar o processamento do mesmo ponto que o cluster de origem.

Esse conector não é necessário para que o conector de origem do MirrorMaker 2.0 funcione. Esse conector só é necessário se você precisar sincronizar o estado ConsumerGroup para minimizar o tempo de inatividade durante uma troca do cluster de origem para o de destino. Se você só precisar de uma cópia dos dados de origem, esse conector não será necessário.

Use o conector de ponto de verificação do MirrorMaker 2.0 para os seguintes casos de uso:

  • Recuperação de desastres para manter um estado consistente do consumidor em todos os clusters e permitir failover sem problemas.

  • Preserve o progresso do consumidor em cenários críticos.

Usar o conector MirrorMaker 2.0 Heartbeat

O conector de sinal de funcionamento do MirrorMaker 2.0 é um componente opcional que gera mensagens periódicas de sinal de funcionamento no cluster de origem do Kafka. O conector grava essas mensagens em um tópico dedicado, normalmente chamado de heartbeats.

É possível configurar um conector de origem do MirrorMaker 2.0 para replicar o tópico heartbeats no cluster de destino. Ao observar esse tópico replicado no cluster de destino, é possível monitorar o status e o desempenho do fluxo de replicação de tópicos. Isso oferece uma maneira de verificar a conexão e o fluxo de dados entre clusters, mesmo quando nenhum outro dado está sendo produzido ou replicado.

A implantação apenas do conector Heartbeat não monitora automaticamente a integridade da replicação. Para usar no monitoramento, replique o tópico heartbeats e observe a presença e a pontualidade dele no cluster de destino ou use ferramentas de monitoramento que consomem esses heartbeats.

O conector Heartbeat não é necessário para que o conector de origem do MirrorMaker 2.0 funcione. Use o conector de pulsação do MirrorMaker 2.0 para os seguintes casos de uso:

  • Monitore a integridade e o status da replicação do MirrorMaker 2.

  • Configure alertas no Cloud Monitoring usando os heartbeats gerados e as métricas disponíveis para receber notificações quando a replicação ou o heartbeat parar.

Usar conectores de coletor

Os conectores de coletor exportam dados de tópicos do Kafka para outros sistemas.

Usar o conector de coletor do BigQuery

O conector de coletor do BigQuery transmite dados de tópicos do Kafka para tabelas do BigQuery.

Use o conector de coletor do BigQuery para os seguintes casos de uso:

  • Armazenamento de dados para carregar dados de streaming no BigQuery para análises e relatórios.

  • Preencher tabelas do BigQuery que alimentam painéis em tempo real.

Usar o conector de coletor do Cloud Storage

O conector de coletor do Cloud Storage transmite dados de tópicos do Kafka para buckets do Cloud Storage.

Use o conector de gravador do Cloud Storage para os seguintes casos de uso:

  • Ingestão de data lake para armazenar dados do Kafka em um data lake para arquivamento de longo prazo e processamento em lote.

  • Arquivar dados para atender a requisitos regulamentares.

Usar o conector de coletor do Pub/Sub

O conector de coletor do Pub/Sub transmite mensagens de tópicos do Kafka para um tópico do Pub/Sub.

Use o conector de coletor do Pub/Sub para os seguintes casos de uso:

  • Integração de serviços para enviar dados do Kafka a outros serviços ou aplicativos Google Cloud que consomem do Pub/Sub.

  • Acionar notificações ou ações em tempo real com base nos dados processados.

Usar conectores de origem

Os conectores de origem importam dados de outros sistemas para tópicos do Kafka.

Usar o conector de origem do Pub/Sub

O conector de origem do Pub/Sub transmite mensagens de uma assinatura do Pub/Sub para um tópico do Kafka.

Use o conector de origem do Pub/Sub para os seguintes casos de uso:

  • Ingestão de dados em tempo real, trazendo dados de serviços de nuvem ou outros aplicativos e publicando no Pub/Sub no Kafka para processamento de stream.

  • Arquiteturas orientadas a eventos, acionando o processamento baseado no Kafka com base em eventos publicados no Pub/Sub.

Política de reinicialização da tarefa

É possível definir uma política de reinicialização de tarefas de um conector, que determina o comportamento quando ocorre uma falha. Os conectores são compatíveis com as seguintes políticas:

  • Nunca reiniciar. O conector não reinicia tarefas com falha. Essa política é o comportamento padrão. Isso é útil para depuração ou em situações em que é necessária intervenção manual após um erro.

  • Reinicie com espera exponencial. O conector reinicia uma tarefa com falha após um atraso (chamado de período de backoff). O atraso aumenta exponencialmente a cada falha subsequente. Essa política é recomendada para a maioria das cargas de trabalho de produção.

    Se você usar a política de espera exponencial, defina também valores para a espera mínima e máxima. A espera mínima precisa ser maior que 60 segundos, e a espera máxima precisa ser menor que 7.200 segundos.

Transformações e predicados

O Kafka Connect é compatível com as transformações e os predicados padrão do Kafka.

Você especifica a configuração como parte da configuração do conector. Por exemplo, para configurar um conector de gravador para ignorar mensagens que contêm uma chave de cabeçalho DoNotProcess, adicione a seguinte configuração ao conector:

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

Essa configuração faz o seguinte:

  1. Configura um predicado chamado hasKey do tipo org.apache.kafka.connect.transforms.predicates.HasHeaderKey. Esse predicado corresponde a todas as mensagens que contêm um cabeçalho com a chave DoNotProcess.

  2. Configura uma transformação chamada dropMessage do tipo org.apache.kafka.connect.transforms.Filter. Essa transformação descarta todas as mensagens que correspondem ao predicado configurado.

  3. Vincula a transformação ao predicado hasKey. Isso garante que apenas mensagens com a chave de cabeçalho DoNotProcess presente sejam descartadas pela transformação.

Para mais informações, consulte a documentação do Kafka sobre transformações e predicados.

A seguir

Apache Kafka® é uma marca registrada da The Apache Software Foundation ou afiliadas nos Estados Unidos e/ou em outros países.