Destino do Kafka

Este tópico explica como configurar a conectividade com um destino Kafka usando o conector de destino Kafka. O Kafka pode ser usado apenas em uma tarefa de replicação.

A configuração do Kafka como um destino envolve:

Atendendo aos pré-requisitos
Configurando uma conexão com o Kafka

Configurando propriedades de conexão

Para configurar o conector, faça o seguinte:

Em Conexões, clique em Criar conexão.
Selecione o conector de destino do Kafka e forneça as seguintes configurações:

Destino de dados

Gateway de dados

Este campo não está disponível com as assinaturas do Iniciante do Qlik Talend Cloud, pois o Gateway Data Movement não é compatível com esse nível de assinatura.

Ao mover dados para o Amazon MSK, um Gateway Data Movement só é necessário se o Amazon MSK não for acessível a partir do Qlik Cloud e só puder ser acessado por meio de um link privado (por exemplo, se estiver localizado em uma Nuvem Privada Virtual). Nesse caso, selecione o Gateway Data Movement através do qual você deseja acessar o banco de dados de destino. Dependendo do seu caso de uso, será o mesmo Gateway Data Movement implementado para mover dados da fonte de dados ou de uma fonte diferente.

Se você estiver movendo dados para uma instância do Amazon MSK que seja diretamente acessível do Qlik Cloud, selecione Nenhum.

Se estiver movendo dados para o Kafka local (consulte Provedor de nuvem abaixo), você deve selecionar um Gateway Data Movement, independentemente de o Kafka ser ou não diretamente acessível do Qlik Cloud.
Se você precisar usar o Gateway Data Movement, a versão 2025.5.40 ou posterior será necessária.

Para obter informações sobre casos de uso do Gateway Data Movement, consulte Quando o Gateway Data Movement é necessário? e Casos de uso comuns.

Provedor de nuvem

Escolha Nenhum para usar o Kafka local ou Amazon MSK para usar o Amazon MSK.

Servidores de broker

Especifique um ou mais servidores de broker usando o seguinte formato (para alta disponibilidade):

server1[:port1][,server2[:port2]]

Exemplo:

192.168.1.100:9092,192.168.1.101:9093

A tarefa de dados se conectará ao primeiro host disponível. Se um host for especificado sem uma porta, a porta 9092 será usada como padrão.

Ao usar autenticação SSL ou Kerberos, você deve especificar o FQDN do broker (ou seja, não o endereço IP).

Todos os servidores de broker em seu cluster precisam estar acessíveis a partir da máquina do Gateway Data Movement. No entanto, você não precisa especificar todos os servidores nos Servidores de broker Valores. Isso ocorre porque o Gateway Data Movement só precisa se conectar a um dos servidores para recuperar os detalhes de conexão dos outros servidores no cluster. Portanto, é recomendável especificar os servidores que têm maior probabilidade de estarem disponíveis quando a tarefa for executada. Os servidores para os quais a tarefa de dados produz mensagens são determinados pelo tópico e pelo tópico de particionamento, bem como pelas configurações de particionamento.

Propriedades da conta

Método de autenticação

Selecione uma das seguintes opções:

Nenhum: Sem autenticação.

Nota informativa
Não disponível quando o Provedor de nuvem selecionado é o Amazon MSK.
Certificado: Se você selecionar esta opção, também precisará fornecer as seguintes informações:

Observação Os arquivos de chave pública e privada devem estar no formato PEM.
- Arquivo de chave pública: Navegue até o arquivo de chave pública no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.
- Arquivo de chave privada: Navegue até o arquivo de chave privada no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.
- Senha de chave privada: A senha do arquivo de chave privada.
Kerberos (SASL/GSSAPI): Selecione para autenticar contra o cluster Kafka usando o Kerberos.

Nota informativa
Este método de autenticação não está disponível quando o Provedor de nuvem selecionado é Amazon MSK.
- Diretor: O diretor Kerberos usado para autenticar contra os servidores de broker.
- Arquivo keytab: Navegue até o arquivo keytab. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.
Nota informativa
Para usar a autenticação Kerberos no Linux, o pacote do cliente Kerberos (estação de trabalho) deve ser instalado.
Nome de usuário e senha (SASL/PLAIN): Você pode selecionar esta opção para se autenticar usando um nome de usuário e senha (SASL/PLAIN). Para evitar que a senha seja enviada em texto não criptografado, é altamente recomendável habilitar a opção Habilitar TLS também.

Nota informativa
Este método de autenticação não está disponível quando o Provedor de nuvem selecionado é Amazon MSK.
Nome de usuário e senha (SASL/SCRAM-SHA-256): Você pode selecionar esta opção para se autenticar usando um nome de usuário e senha (SASL/SCRAM-SHA-256).

Observe que a seleção desta opção também exige que o arquivo server.properties de cada broker seja configurado com o mecanismo SASL/SCRAM correspondente.

Nota informativa
Este método de autenticação não está disponível quando o Provedor de nuvem selecionado é Amazon MSK.
Nome de usuário e senha (SASL/SCRAM-SHA-512): Você pode selecionar esta opção para se autenticar usando um nome de usuário e senha (SASL/SCRAM-SHA-512).

Observe que a seleção desta opção também exige que o arquivo server.properties de cada broker seja configurado com o mecanismo SASL/SCRAM correspondente.

Opções de SSL

Habilitar TLS (suporta TLS 1.0, 1.1 e 1.2)

Selecione esta opção para criptografar a comunicação entre o Qlik Talend Cloud e os servidores do broker. Se os brokers estiverem configurados para exigir SSL, então você deve selecionar esta opção.

Arquivo CA: navegue até o certificado CA no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.

Nota informativa
Não é necessário quando o Provedor de nuvem selecionado é o Amazon MSK.

Publicação de mensagens de metadados

O Schema Registry estará disponível para publicação de mensagens de metadados

Na lista suspensa, selecione uma das seguintes opções:

Não

Quando esta opção for selecionada, apenas as mensagens de dados serão publicadas.

Confluent Schema Registry

Se você selecionar esta opção, também deverá configurar as Propriedades de conexão do Schema Registry descritas abaixo.

Nota de advertênciaQuando o Confluent Schema Registry é selecionado, você deve definir a seguinte propriedade interna: CsrSkipGlobalConfig=false

As opções do Confluent Schema Registry suportam apenas o formato de mensagem Avro.
É fortemente recomendado não publicar mensagens de esquema no mesmo tópico que as mensagens de dados.
Se os tópicos não existirem, configure os brokers com auto.create.topics.enable=true para permitir que a tarefa de dados crie os tópicos durante a execução. Caso contrário, a tarefa falhará.

Formato da mensagem

Escolha JSON ou Avro como o formato da mensagem. Avro será a única opção disponível se você selecionou Confluent Schema Registry.

Propriedades de conexão do Schema Registry

Servidores de Schema Registry

Especifique um ou mais servidores de Schema Registry usando o seguinte formato (para alta disponibilidade):

Ao publicar esquemas de dados no Confluent Schema Registry:

server1:port1[,server2[:port2]]

Exemplo:

192.168.1.100:8081,192.168.1.101:8081

A tarefa de dados se conectará ao primeiro host disponível.

Método de autenticação

Selecione uma das seguintes opções de autenticação do Schema Registry:

Nenhum: Sem autenticação.
Certificado: Selecione para autenticar usando um certificado.
Se você selecionar esta opção, também precisará fornecer as seguintes informações:

Arquivo de chave pública: Navegue até o arquivo de chave pública no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.
Arquivo de chave privada: Navegue até o arquivo de chave privada no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.
Senha de chave privada: A senha do arquivo de chave privada.

Nome de usuário e senha: Selecione para autenticar com um nome de usuário e senha. Em seguida, insira suas credenciais de login nos campos Nome de usuário e senha.
Certificado + Nome de usuário e senha: Selecione a opção para autenticar usando um certificado e um nome de usuário e senha.
Quando esta opção for selecionada, insira as informações necessárias nos campos Arquivo de chave pública, Arquivo de chave privada, Senha da chave privada, Nome de usuário e Senha descritos acima.
Habilitar TLS (compatível com TLS 1.0, 1.1 e 1.2): selecione esta opção para criptografar os dados entre a máquina do Gateway Data Movement e os servidores do Schema Registry. Se os servidores estiverem configurados para exigir SSL, então você deve selecionar esta opção.
- Arquivo de CA: Navegue até o certificado de CA no formato PEM. Ao clicar em Salvar, o arquivo será carregado para o Qlik Talend Cloud e implementado no Gateway Data Movement selecionado nas configurações do conector.

Propriedades internas

Propriedades internas são para casos de uso especiais e, portanto, não são expostas na caixa de diálogo. Você só deve usá-las se instruído pelo Suporte da Qlik.

Use os botões Criar novo e Cancelar à direita dos campos para adicionar ou remover propriedades conforme necessário.

Nome

O nome de exibição da conexão.

Pré-requisitos

Antes de usar o Kafka como destino, os seguintes pré-requisitos devem ser atendidos:

Abrir portas TCP para todos os brokers da máquina do Gateway Data Movement
Definir permissões que permitirão à tarefa de dados gravar nos tópicos de destino. Uma maneira de fazer isso é usar o script de ACLs do Kafka (kafka-acls).
Criar um tópico chamado attrep_apply_exceptions antes de iniciar a tarefa de dados ou configurar os brokers com auto.create.topics.enable=true.

Observe que, se este tópico não existir, a tarefa sempre falhará ao encontrar um erro de dados, independentemente da política de tratamento de erros.

Para uma descrição da tabela de controle attrep_apply_exceptions, consulte Exceções de aplicação.

Limitações e considerações

Ao definir uma tarefa com Kafka como conector de destino, aplicam-se as seguintes limitações:

Configurações de tarefa não suportadas:
- O conector de destino Kafka não suporta tamanho LOB ilimitado. Nas configurações de tarefas, a opção Incluir colunas LOB e limitar o tamanho da coluna a (KB) será ativada e será somente leitura.
- O modo Armazenar alterações não é compatível.
- O modo Aplicar otimizado em lote não é suportado. O Kafka sempre funciona no modo Aplicação transacional.
- A configuração Ignorar ALTER Aplicar alterações não é compatível com alterações em tipos de dados de origem e renomeação de tabelas.
- A opção Descartar e criar tabela do campo Preparação da tabela de destino não é compatível.
- A opção Truncar antes de carregar do campo Preparação da Tabela de Destino não é compatível.
- A tabela de controle de Particionamento de dados de alteração não é compatível.
Limitações gerais:
- Nomes de tópicos Kafka não podem conter espaços ou exceder 255 caracteres (249 a partir do Kafka 0.10) e só podem conter os seguintes caracteres:
  a-z|A-Z|0-9|. (ponto)|_(sublinhado)|-(hífen)
  Se os nomes das tabelas de origem excederem o comprimento máximo permitido ou contiverem caracteres não suportados, você precisa modificar os nomes antes de iniciar a tarefa ou definir uma transformação global.
- Nomes de colunas devem começar com [A-Za-z_] (letras ou um sublinhado) seguido por [A-Za-z0-9_] (letras, dígitos ou um sublinhado). Por exemplo, _Test_ é um nome de coluna válido, enquanto &Test não é.
  Se um nome de coluna de origem não aderir a esta regra, então uma transformação deve ser usada para renomear a coluna.
- Não há suporte para a exclusão ou renomeação de uma tabela de origem.

Tipos de dados

A tabela a seguir mostra os tipos de dados Kafka que são suportados durante o uso do Qlik Cloud e o mapeamento padrão dos tipos de dados do Qlik Cloud.

Ao usar o formato de mensagem JSON, os valores binários são representados como dígitos hexadecimais.

Mapeamento de dados Kafka
Tipos de dados do Qlik Cloud	Tipos de dados de destino Kafka em mensagens de esquema
DATE	DATE
TIME	TIME
DATETIME	DATETIME
BYTES	BYTES (comprimento)
BLOB	BLOB
REAL4	REAL4 (7)
REAL8	REAL8 (14)
INT1	INT1 (3)
INT2	INT2 (5)
INT4	INT4 (10)
INT8	INT8 (19)
UINT1	UINT1 (3)
UINT2	UINT2 (5)
UINT4 Nota informativa Valores maiores que 2^31-1 não são compatíveis.	UINT4 (10)
UINT8 Nota informativa Valores maiores que 2^63-1 não são compatíveis.	UINT8 (20)
NUMERIC	NUMERIC (p,s)
STRING	STRING (comprimento)
WSTRING	STRING (comprimento)
CLOB	CLOB
NCLOB	NCLOB
BOOLEAN	BOOLEAN (1)

Mapeamento para JSON e Avro

O formato de mensagem Avro usa tipos lógicos para uma representação mais precisa do tipo de dados.

Os tipos de dados do Qlik Cloud serão mapeados apenas para tipos de dados lógicos Avro compatíveis se a caixa de seleção Usar tipos de dados lógicos para tipos de dados específicos estiver marcada.

Mapeamentos de tipo de dados
Tipos de dados do Qlik Cloud	JSON	Tipos de dados lógicos Avro
DATE	STRING	DATE Anota um Avro INT.
TIME	STRING	TIME-MILLIS Anota um Avro INT.
TIMESTAMP	STRING	TIMESTAMP-MICROS Anota um Avro LONG.
STRING	STRING	-
WSTRING	STRING	-
CLOB	STRING	-
NCLOB	STRING	-
NUMERIC	STRING	DECIMAL (p,s) Anota um Avro BYTES.
BYTES	BYTES	-
BLOB	BYTES	-
REAL4	FLOAT	-
REAL8	DOUBLE	-
INT1	INT	-
INT2	INT	-
INT4	INT	-
UINT1	INT	-
UINT2	INT	-
UINT4	LONG	-
INT8	LONG	-
UINT8	STRING	DECIMAL (20,0) Anota um Avro BYTES.
BOOLEAN	BOOLEAN	-

Esta página ajudou?

Se você encontrar algum problema com esta página ou seu conteúdo – um erro de digitação, uma etapa ausente ou um erro técnico – avise-nos!

Deixe seu feedback aqui