Partager via

Kafka Streams pour Azure Event Hubs

  • Article

Cet article fournit des détails sur l’utilisation de la bibliothèque cliente Kafka Streams avec Azure Event Hubs.

Remarque

La fonctionnalité Kafka Streams est disponible en préversion publique pour les niveaux Event Hubs Premium et Dédié uniquement.

Vue d’ensemble

Apache Kafka Streams est une bibliothèque cliente Java uniquement qui fournit une infrastructure pour le traitement des données de diffusion en continu et la création d’applications en temps réel sur les données stockées dans les rubriques Kafka. Tout le traitement est délimité au client, tandis que les rubriques Kafka agissent comme magasin de données pour les données intermédiaires, avant que la sortie soit écrite dans la rubrique de destination.

Event Hubs fournit un point de terminaison Kafka à utiliser par vos applications clientes Kafka existantes pour éviter d’exécuter votre propre cluster Kafka. Event Hubs fonctionne avec un grand nombre de vos applications Kafka existantes. Pour plus d’informations, consultez Event Hubs pour Apache Kafka.

Utilisation de Kafka Streams avec Azure Event Hubs

Azure Event Hubs prend en charge en mode natif les protocoles AMQP et Kafka. Toutefois, pour garantir un comportement compatible de Kafka Streams, certains des paramètres de configuration par défaut doivent être mis à jour pour les clients Kafka.

Propriété Comportement par défaut pour Event Hubs Comportement modifié pour les flux Kafka Explication
messageTimestampType défini sur AppendTime doit être définie sur CreateTime Kafka Streams s’appuie sur le timestamp de création plutôt que sur le timestamp d’ajout
message.timestamp.difference.max.ms la valeur autorisée maximale est de 90 jours La propriété est utilisée pour régir les timestamps passés uniquement. L’heure à venir est définie sur 1 heure et ne peut pas être modifiée. Ceci est conforme à la spécification du protocole Kafka
min.compaction.lag.ms la valeur autorisée maximale est de deux jours
Rubriques à rétention infinie troncation basée sur la taille de 250 Go pour chaque rubrique-partition
API Supprimer l’enregistrement pour les rubriques à rétention infinie Non implémenté. Pour contourner ce problème, la rubrique peut être mise à jour et une durée de rétention finie peut être définie. Cette opération sera effectuée en disponibilité générale

Autres considérations

Voici quelques considérations spécifiques à prendre en compte.

  • Les applications clientes de flux Kafka doivent disposer d’autorisations de gestion, de lecture et d’écriture pour l’ensemble des espaces de noms afin de pouvoir créer des rubriques temporaires pour le traitement de flux.
  • Les rubriques et partitions temporaires comptent vers le quota de l’espace de noms donné. Celles-ci doivent être prises en compte lors de l’approvisionnement de l’espace de noms ou du cluster.
  • L’heure de rétention infinie pour le Magasin « Offset » est limitée par la durée maximale de rétention des messages de la référence SKU. Vérifiez les Quotas Event Hubs pour connaître ces valeurs spécifiques au niveau.

Il s’agit notamment de la mise à jour de la configuration de rubrique dans le messageTimestampType pour utiliser le CreateTime (autrement dit, l’heure de création de l’événement) au lieu du AppendTime (autrement dit, heure d’ajout du journal).

Pour remplacer le comportement par défaut (obligatoire), le paramètre ci-dessous doit être défini dans Azure Resource Manager (ARM).

Remarque

Seules les parties spécifiques du modèle ARM sont montrées pour mettre en évidence la configuration qui doit être mise à jour.

{
  "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
        }
      }
    }
  }
}

Concepts de Kafka Streams

Les flux Kafka fournissent une couche d’abstraction simple sur les API de producteur et de consommateur Kafka pour aider les développeurs à prendre en main les scénarios de diffusion en continu en temps réel plus rapidement. La bibliothèque légère dépend d’un répartiteur compatible Apache Kafka (comme Azure Event Hubs) pour la couche de messagerie interne et gère un magasin d’états local tolérant aux pannes. Avec l’API transactionnelle, la bibliothèque de flux Kafka prend en charge des fonctionnalités de traitement enrichies telles que le traitement exactement une fois et le traitement un enregistrement à la fois.

Les enregistrements arrivant dans le désordre bénéficient des opérations de fenêtrage basées sur les heures des événements.

Remarque

Nous vous recommandons de vous familiariser avec la documentation Kafka Streams et les concepts fondamentaux de Kafka Streams.

Flux

Un flux est la représentation abstraite d’une rubrique Kafka. Il se compose d’un jeu de données sans limite à mise à jour continue d’enregistrements de données immuables, où chaque enregistrement de données est une paire clé-valeur.

Topologie de traitement de flux

Une application de flux Kafka définit la logique de calcul par le biais d’un DAG représenté par une topologie de processeur. La topologie de processeur comprend des processeurs de flux (nœuds dans la topologie) qui représentent une étape de traitement, connectée par des flux (arêtes dans la topologie).

Les processeurs de flux peuvent être chaînés vers des processeurs en amont ou des processeurs en aval, à l’exception de certains cas spéciaux :

  • Processeurs sources : ces processeurs n’ont pas de processeurs en amont et lisent directement à partir d’un ou plusieurs flux. Ils peuvent ensuite être chaînés à des processeurs en aval.
  • Processeurs récepteurs : ces processeurs n’ont pas de processeurs en aval et doivent écrire directement dans un flux.

La topologie de traitement de flux peut être définie avec le DSL Kafka Streams ou avec l’API Processor de niveau inférieur.

Dualité de flux et de table

Les flux et les tables sont 2 abstractions différentes mais utiles fournies par le DSL Kafka Streams, qui modélisent les formats de séries chronologiques et de données relationnelles qui doivent coexister pour les cas d’usage de traitement de flux.

Kafka étend cela plus loin et introduit une dualité entre les flux et les tables, où

  • Un flux peut être considéré comme un journal des modifications d’une table et
  • Une table peut être considérée comme un instantané de la dernière valeur de chaque clé d’un flux.

Cette dualité permet aux tables et aux flux d’être utilisés de façon interchangeable selon le cas d’usage.

Par exemple

  • La jointure de données client statiques (modélisées sous forme de table) avec des transactions dynamiques (modélisées en tant que flux) et
  • La jointure de positions de portefeuille changeantes dans un portefeuille de traders journaliers (modélisés en tant que flux) avec le dernier flux de données de marché (modélisé en tant que flux).

Temps

Kafka Streams permet les fonctions de fenêtrage et de grâce pour permettre l’ingestion d’enregistrements de données dans le désordre et leur inclusion dans le traitement. Pour s’assurer que ce comportement est déterministe, il existe des notions supplémentaires de temps dans les flux Kafka. Il s’agit notamment des paramètres suivants :

  • Heure de création (également appelée « Heure de l’événement ») : il s’agit de l’heure à laquelle l’événement s’est produit et l’enregistrement de données a été créé.
  • Heure de traitement : il s’agit de l’heure à laquelle l’enregistrement de données est traité par l’application de traitement de flux (ou consommé).
  • Heure d’ajout (également appelée « Heure de création ») : il s’agit de l’heure à laquelle les données sont stockées et validées dans le stockage du répartiteur Kafka. Cela diffère de l’heure de création en raison de la différence de temps entre la création de l’événement et l’ingestion réelle par le répartiteur.

Opérations avec état

La gestion de l’état permet des applications de traitement des flux sophistiquées, comme la jointure et l’agrégation de données à partir de différents flux. Pour ce faire, les magasins d’état fournis par Kafka Streams sont accessibles à l’aide d’opérateurs avec état dans le DSL Kafka Streams.

Les transformations avec état dans le DSL comprennent :

Fenêtre et grâce

Les opérations de fenêtrage dans le DSL Kafka Streams permettent aux développeurs de contrôler comment les enregistrements sont regroupés pour une clé donnée pour les opérations avec état telles que les agrégations et les jointures.

Les opérations de fenêtrage permettent également la spécification d’une période de grâce pour fournir une certaine flexibilité pour les enregistrements dans le désordre d’une fenêtre donnée. Un enregistrement destiné à une fenêtre donnée qui arrive après la fenêtre donnée, mais dans la période de grâce acceptée. Les enregistrements arrivant après la période de grâce sont ignorés.

Les applications doivent utiliser les contrôles de fenêtrage et de période de grâce pour améliorer la tolérance de panne pour les enregistrements dans le désordre. Les valeurs appropriées varient en fonction de la charge de travail et doivent être identifiées empiriquement.

Garanties de traitement

Les utilisateurs professionnels et techniques cherchent à extraire des perspectives clés à partir de la sortie des charges de travail de traitement de flux, ce qui se traduit par des exigences de garantie transactionnelle élevées. Les flux Kafka fonctionnent avec les transactions Kafka pour appliquer des garanties de traitement transactionnel en intégrant le système de stockage sous-jacent des répartiteurs compatibles Kafka (tels qu’Azure Event Hubs) pour s’assurer que les validations de décalage et les mises à jour du magasin d’états sont écrites atomiquement.

Pour appliquer les garanties de traitement transactionnel, le paramètre processing.guarantee dans les configurations Kafka Streams doit être mis à jour de la valeur par défaut de at_least_once à exactly_once_v2 (pour les versions clientes à ou après Apache Kafka 2.5) ou à exactly_once (pour les versions clientes avant Apache Kafka 2.5.x).

Étapes suivantes

Cet article a présenté une introduction à Event Hubs pour Kafka. Pour en savoir plus, consultez Guide du développeur Apache Kafka pour Azure Event Hubs.

Pour consulter un tutoriel avec des instructions pas à pas afin de créer un Event Hub et y accéder à l’aide d’une signature d’accès partagé ou OAuth, consultez Démarrage rapide : Streaming de données avec Event Hubs en utilisant le protocole Kafka.

Consultez également les exemples OAuth sur GitHub.