Partilhar via

Kafka Streams para Hubs de Eventos do Azure

  • Artigo

Este artigo fornece detalhes sobre como usar a biblioteca de cliente do Kafka Streams com os Hubs de Eventos do Azure.

Nota

A funcionalidade Kafka Streams está disponível apenas na Pré-visualização Pública para os níveis Premium e Dedicado dos Hubs de Eventos .

Descrição geral

Apache Kafka Streams é uma biblioteca de cliente somente Java que fornece uma estrutura para processamento de dados de streaming e construção de aplicativos em tempo real contra os dados armazenados em tópicos Kafka. Todo o processamento tem como escopo o cliente, enquanto os tópicos Kafka atuam como o armazenamento de dados intermediários, antes que a saída seja gravada no tópico de destino.

Os Hubs de Eventos fornecem um ponto de extremidade Kafka para ser usado com seus aplicativos cliente Kafka existentes como uma alternativa para executar seu próprio cluster Kafka. Os Hubs de Eventos funcionam com muitos dos seus aplicativos Kafka existentes. Para obter mais informações, consulte Hubs de eventos para Apache Kafka.

Usando fluxos Kafka com Hubs de Eventos do Azure

Os Hubs de Eventos do Azure dão suporte nativo ao protocolo AMQP e Kafka. No entanto, para garantir o comportamento compatível do Kafka Streams, alguns dos parâmetros de configuração padrão precisam ser atualizados para clientes Kafka.

Property Comportamento padrão para Hubs de Eventos Comportamento modificado para fluxos Kafka Explicação
messageTimestampType definido como AppendTime deve ser definido como CreateTime O Kafka Streams depende do carimbo de data/hora de criação em vez do carimbo de data/hora de acréscimo
message.timestamp.difference.max.ms O valor máximo permitido é de 90 dias A propriedade é usada apenas para governar carimbos de data/hora passados. A hora futura está definida para 1 hora e não pode ser alterada. Isto está de acordo com a especificação do protocolo de Kafka
min.compaction.lag.ms O valor máximo permitido é de dois dias
Tópicos de retenção infinitos truncamento baseado em tamanho de 250 GB para cada partição de tópico
Excluir API de registro para tópicos de retenção infinitos Não implementado. Como solução alternativa, o tópico pode ser atualizado e um tempo de retenção finito pode ser definido. Isso será feito em GA

Outras considerações

Aqui estão algumas das outras considerações a ter em mente.

  • Os aplicativos cliente de fluxos Kafka devem receber permissões de gerenciamento, leitura e gravação para os namespaces inteiros para poder criar tópicos temporários para processamento de fluxo.
  • Tópicos temporários e partições contam para a cota do namespace fornecido. Eles devem ser mantidos em consideração ao provisionar o namespace ou cluster.
  • O tempo de retenção infinito para o armazenamento "Offset" é limitado pelo tempo máximo de retenção de mensagens do SKU. Verifique as Cotas de Hubs de Eventos para esses valores específicos da camada.

Isso inclui, atualizar a configuração do tópico no messageTimestampType para usar o (ou seja, o CreateTime tempo de criação do evento) em vez do (ou seja, o tempo de acréscimo do AppendTime log).

Para substituir o comportamento padrão (obrigatório), a configuração abaixo deve ser definida no Azure Resource Manager (ARM).

Nota

Apenas as partes específicas do modelo ARM são mostradas para destacar a configuração que precisa ser atualizada.

{
  "parameters": {
    "namespaceName": "contoso-test-namespace",
    "resourceGroupName": "contoso-resource-group",
    "eventHubName": "contoso-event-hub-kafka-streams-test",
    ...
    "parameters": {
      "properties": {
        ...
        "messageTimestampType": "CreateTime",
        "retentionDescription": {
          "cleanupPolicy": "Delete",
          "retentionTimeInHours": -1,
          "tombstoneRetentionTimeInHours": 1
        }
      }
    }
  }
}

Conceitos do Kafka Streams

Kafka streams fornece uma camada de abstração simples sobre as APIs de produtor e consumidor Kafka para ajudar os desenvolvedores a começar com cenários de streaming em tempo real mais rapidamente. A biblioteca leve depende de um agente compatível com Apache Kafka (como Hubs de Eventos do Azure) para a camada de mensagens interna e gerencia um armazenamento de estado local tolerante a falhas. Com a API transacional, a biblioteca de fluxos Kafka suporta recursos de processamento avançados, como processamento exatamente uma vez e um registro de cada vez.

Os registros que chegam fora de ordem se beneficiam de operações de janela baseadas em tempo de evento.

Nota

Recomendamos familiarizar-se com a documentação do Kafka Streams e os principais conceitos do Kafka Streams.

Fluxos

Um fluxo é a representação abstrata de um tópico de Kafka. Ele consiste em um conjunto de dados ilimitado e continuamente atualizado de registros de dados imutáveis, onde cada registro de dados é um par chave-valor.

Topologia de processamento de fluxo

Uma aplicação Kafka streams define a lógica computacional através de um DAG (gráfico acíclico dirigido) representado por uma topologia de processador. A topologia do processador compreende processadores de fluxo (nós na topologia) que representam uma etapa de processamento, conectada por fluxos (bordas na topologia).

Os processadores de fluxo podem ser encadeados a processadores upstream ou downstream, exceto em certos casos especiais:

  • Processadores de origem - Esses processadores não têm processadores upstream e leem diretamente de um ou mais fluxos. Eles podem então ser encadeados a processadores a jusante.
  • Processadores de coletor - Esses processadores não têm processadores downstream e devem gravar diretamente em um fluxo.

A topologia de processamento de fluxo pode ser definida com a DSL do Kafka Streams ou com a API do processador de nível inferior.

Dualidade de fluxo e tabela

Fluxos e tabelas são 2 abstrações diferentes, mas úteis, fornecidas pelo Kafka Streams DSL, modelando séries temporais e formatos de dados relacionais que devem coexistir para casos de uso de processamento de fluxo.

Kafka estende isso ainda mais e introduz uma dualidade entre fluxos e tabelas, onde um

  • Um fluxo pode ser considerado como um changelog de uma tabela, e
  • Uma tabela pode ser considerada como um instantâneo do valor mais recente de cada chave em um fluxo.

Essa dualidade permite que tabelas e fluxos sejam usados de forma intercambiável, conforme exigido pelo caso de uso.

Por exemplo

  • Unir dados estáticos do cliente (modelados como uma tabela) com transações dinâmicas (modeladas como um fluxo) e
  • Juntar posições de carteira variáveis em uma carteira de day traders (modelada como um fluxo) com o feed de dados de mercado mais recente (modelado como um fluxo).

Hora

O Kafka Streams permite que as funções de janela e graça permitam que registros de dados fora de ordem sejam ingeridos e ainda sejam incluídos no processamento. Para garantir que esse comportamento seja determinista, há noções adicionais de tempo nos fluxos de Kafka. Estes são, entre outros:

  • Tempo de criação (também conhecido como 'Hora do evento') - Este é o momento em que o evento ocorreu e o registro de dados foi criado.
  • Tempo de processamento - Este é o momento em que o registro de dados é processado pelo aplicativo de processamento de fluxo (ou quando é consumido).
  • Tempo de anexação (também conhecido como 'Tempo de criação') - Este é o momento em que os dados são armazenados e comprometidos com o armazenamento do corretor Kafka. Isso difere do tempo de criação devido à diferença de tempo entre a criação do evento e a ingestão real pelo corretor.

Operações com estado

O gerenciamento de estado permite aplicativos sofisticados de processamento de fluxo, como unir e agregar dados de diferentes fluxos. Isso é conseguido com lojas estatais fornecidas pela Kafka Streams e acessadas usando operadores stateful na DSL Kafka Streams.

As transformações com estado na DSL incluem:

Janela e graça

As operações de janelas na DSL do Kafka Streams permitem que os desenvolvedores controlem como os registros são agrupados para uma determinada chave para operações com monitoração de estado, como agregações e junções.

As operações de janelamento também permitem a especificação de um período de carência para fornecer alguma flexibilidade para registros fora de ordem para uma determinada janela. Um registro que é destinado a uma determinada janela e chega depois da janela dada, mas dentro do período de carência é aceito. Os registros que chegam após o término do período de carência são descartados.

Os aplicativos devem utilizar os controles de janela e período de carência para melhorar a tolerância a falhas para registros fora de ordem. Os valores apropriados variam com base na carga de trabalho e devem ser identificados empiricamente.

Garantias de processamento

Os usuários técnicos e de negócios procuram extrair os principais insights de negócios da saída de cargas de trabalho de processamento de fluxo, que se traduzem em altos requisitos de garantia transacional. Os fluxos Kafka trabalham em conjunto com as transações Kafka para garantir garantias de processamento transacional integrando-se com o sistema de armazenamento subjacente dos corretores compatíveis com Kafka (como os Hubs de Eventos do Azure) para garantir que as confirmações de compensação e as atualizações de armazenamento de estado sejam gravadas atomicamente.

Para garantir garantias de processamento transacional, a processing.guarantee configuração nas configurações do Kafka Streams deve ser atualizada do valor padrão de para exactly_once_v2 (para versões de cliente no Apache Kafka 2.5 ou após ele) ou exactly_once (para versões de cliente antes do at_least_once Apache Kafka 2.5.x).

Próximos passos

Este artigo forneceu uma introdução aos Hubs de Eventos para Kafka. Para saber mais, consulte Guia do desenvolvedor do Apache Kafka para Hubs de Eventos do Azure.

Para obter um tutorial com instruções passo a passo para criar um hub de eventos e acessá-lo usando SAS ou OAuth, consulte Guia de início rápido: streaming de dados com Hubs de Eventos usando o protocolo Kafka.

Além disso, consulte os exemplos OAuth no GitHub.