Modèle Apache Kafka vers Cloud Storage

Le modèle Apache Kafka vers Cloud Storage est un pipeline de flux de données qui ingère les données textuelles de Google Cloud Managed Service pour Apache Kafka et génère les enregistrements dans Cloud Storage.

Vous pouvez également utiliser le modèle Apache Kafka vers BigQuery avec Kafka autogéré ou externe.

Conditions requises pour ce pipeline

  • Le bucket Cloud Storage de sortie doit exister.
  • Le serveur de courtiers Apache Kafka doit être en cours d'exécution et joignable depuis les machines de nœud de calcul Dataflow.
  • Les sujets Apache Kafka doivent exister.

Format de message Kafka

Ce modèle permet de lire des messages de Kafka aux formats suivants :

Format JSON

Pour lire les messages JSON, définissez le paramètre de modèle messageFormat sur "JSON".

Encodage binaire Avro

Pour lire les messages Avro binaires, définissez les paramètres de modèle suivants :

  • messageFormat : "AVRO_BINARY_ENCODING".
  • binaryAvroSchemaPath : emplacement d'un fichier de schéma Avro dans Cloud Storage. Exemple : gs://BUCKET_NAME/message-schema.avsc.

Pour en savoir plus sur le format binaire Avro, consultez Encodage binaire dans la documentation Apache Avro.

Avro encodé dans Confluent Schema Registry

Pour lire les messages au format Avro encodés dans Confluent Schema Registry, définissez les paramètres de modèle suivants :

  • messageFormat : "AVRO_CONFLUENT_WIRE_FORMAT".

  • schemaFormat : l'une des valeurs suivantes :
    • "SINGLE_SCHEMA_FILE" : le schéma du message est défini dans un fichier de schéma Avro. Spécifiez l'emplacement Cloud Storage du fichier de schéma dans le paramètre confluentAvroSchemaPath.
    • "SCHEMA_REGISTRY" : les messages sont encodés à l'aide de Confluent Schema Registry. Spécifiez l'URL de l'instance Confluent Schema Registry dans le paramètre schemaRegistryConnectionUrl et le mode d'authentification dans le paramètre schemaRegistryAuthenticationMode.

Pour en savoir plus sur ce format, consultez Format filaire dans la documentation Confluent.

Format du fichier de sortie

Le format du fichier de sortie est identique à celui du message Kafka d'entrée. Par exemple, si vous sélectionnez JSON pour le format de message Kafka, les fichiers JSON sont écrits dans le bucket Cloud Storage de sortie.

Authentification

Le modèle Apache Kafka vers Cloud Storage est compatible avec l'authentification SASL/PLAIN pour les courtiers Kafka.

Paramètres de modèle

Paramètres obligatoires

  • readBootstrapServerAndTopic : sujet Kafka à partir duquel lire l'entrée.
  • outputDirectory : chemin d'accès et préfixe du nom de fichier pour l'écriture des fichiers de sortie. Doit se terminer par une barre oblique. Exemple :gs://your-bucket/your-path/
  • kafkaReadAuthenticationMode : mode d'authentification à utiliser avec le cluster Kafka. Utilisez KafkaAuthenticationMethod.NONE pour désactiver l'authentification, KafkaAuthenticationMethod.SASL_PLAIN pour le nom d'utilisateur et le mot de passe SASL/PLAIN, KafkaAuthenticationMethod.SASL_SCRAM_512 pour l'authentification SASL_SCRAM_512 et KafkaAuthenticationMethod.TLS pour l'authentification basée sur un certificat. KafkaAuthenticationMethod.APPLICATION_DEFAULT_CREDENTIALS ne doit être utilisé que pour le cluster Google Cloud Apache Kafka pour BigQuery. Il permet de s'authentifier à l'aide des identifiants par défaut de l'application.
  • messageFormat : format des messages Kafka à lire. Les valeurs acceptées sont AVRO_CONFLUENT_WIRE_FORMAT (Avro encodé par Confluent Schema Registry), AVRO_BINARY_ENCODING (Avro binaire simple) et JSON. Valeur par défaut : AVRO_CONFLUENT_WIRE_FORMAT.
  • useBigQueryDLQ : si la valeur est "true", les messages ayant échoué sont écrits dans BigQuery avec des informations d'erreur supplémentaires. La valeur par défaut est "false".

Paramètres facultatifs

  • windowDuration : durée/taille de la fenêtre dans laquelle les données seront écrites dans Cloud Storage. Les formats autorisés sont les suivants : Ns (pour les secondes, exemple : 5s), Nm (pour les minutes, exemple : 12m), Nh (pour les heures, exemple : 2h). Exemple :5m La valeur par défaut est "5m".
  • outputFilenamePrefix : préfixe à placer sur chaque fichier ciblé sur une fenêtre. Exemple :output- La valeur par défaut est : "output".
  • numShards : nombre maximal de partitions de sortie générées lors de l'écriture. Un nombre plus élevé de segments entraîne un débit plus élevé pour l'écriture dans Cloud Storage, mais potentiellement un coût d'agrégation de données plus élevé entre les partitions lors du traitement des fichiers Cloud Storage de sortie. La valeur par défaut est déterminée par Dataflow.
  • enableCommitOffsets : commit des décalages des messages traités vers Kafka. Si cette option est activée, les écarts ou le traitement en double des messages seront minimisés lors du redémarrage du pipeline. L'ID du groupe de consommateurs doit être spécifié. La valeur par défaut est "false".
  • consumerGroupId : identifiant unique du groupe de consommateurs auquel ce pipeline appartient. Obligatoire si l'option "Commit Offsets to Kafka" (Enregistrer les décalages dans Kafka) est activée. La valeur par défaut est vide.
  • kafkaReadOffset : point de départ de la lecture des messages lorsqu'il n'existe aucun décalage validé. Le premier commence au début, le dernier à partir du message le plus récent. Valeur par défaut : le plus récent.
  • kafkaReadUsernameSecretId : ID du secret Google Cloud Secret Manager contenant le nom d'utilisateur Kafka à utiliser avec l'authentification SASL_PLAIN. Par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>. La valeur par défaut est vide.
  • kafkaReadPasswordSecretId : ID du secret Secret Manager de Google Cloud contenant le mot de passe Kafka à utiliser avec l'authentification SASL_PLAIN. Par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>. La valeur par défaut est vide.
  • kafkaReadKeystoreLocation : chemin d'accès Google Cloud Storage au fichier Java KeyStore (JKS) contenant le certificat TLS et la clé privée à utiliser lors de l'authentification avec le cluster Kafka. Exemple :gs://your-bucket/keystore.jks
  • kafkaReadTruststoreLocation : chemin d'accès Google Cloud Storage au fichier Java TrustStore (JKS) contenant les certificats approuvés à utiliser pour vérifier l'identité du courtier Kafka.
  • kafkaReadTruststorePasswordSecretId : ID de secret Google Cloud Secret Manager contenant le mot de passe à utiliser pour accéder au fichier Java TrustStore (JKS) pour l'authentification TLS Kafka (par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>).
  • kafkaReadKeystorePasswordSecretId : ID de secret Google Cloud Secret Manager contenant le mot de passe à utiliser pour accéder au fichier Java KeyStore (JKS) pour l'authentification TLS Kafka. Exemple :projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>
  • kafkaReadKeyPasswordSecretId : ID de secret Google Cloud Secret Manager contenant le mot de passe à utiliser pour accéder à la clé privée dans le fichier Java KeyStore (JKS) pour l'authentification TLS Kafka. Exemple :projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>
  • kafkaReadSaslScramUsernameSecretId : ID du secret Google Cloud Secret Manager contenant le nom d'utilisateur Kafka à utiliser avec l'authentification SASL_SCRAM. Par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>.
  • kafkaReadSaslScramPasswordSecretId : ID du secret Google Cloud Secret Manager contenant le mot de passe Kafka à utiliser avec l'authentification SASL_SCRAM. Par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>.
  • kafkaReadSaslScramTruststoreLocation : chemin d'accès Google Cloud Storage au fichier Java TrustStore (JKS) contenant les certificats de confiance à utiliser pour vérifier l'identité du courtier Kafka.
  • kafkaReadSaslScramTruststorePasswordSecretId : ID de secret Google Cloud Secret Manager contenant le mot de passe à utiliser pour accéder au fichier Java TrustStore (JKS) pour l'authentification Kafka SASL_SCRAM. Par exemple, projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>.
  • schemaFormat : format de schéma Kafka. Peut être fourni sous la forme SINGLE_SCHEMA_FILE ou SCHEMA_REGISTRY. Si SINGLE_SCHEMA_FILE est spécifié, utilisez le schéma mentionné dans le fichier de schéma Avro pour tous les messages. Si SCHEMA_REGISTRY est spécifié, les messages peuvent avoir un seul schéma ou plusieurs. La valeur par défaut est SINGLE_schema_FILE.
  • confluentAvroSchemaPath : chemin d'accès Google Cloud Storage au fichier de schéma Avro unique utilisé pour décoder tous les messages d'un sujet. La valeur par défaut est vide.
  • schemaRegistryConnectionUrl : URL de l'instance Confluent Schema Registry utilisée pour gérer les schémas Avro pour le décodage des messages. La valeur par défaut est vide.
  • binaryAvroSchemaPath : chemin d'accès Google Cloud Storage au fichier de schéma Avro utilisé pour décoder les messages Avro encodés en binaire. La valeur par défaut est vide.
  • schemaRegistryAuthenticationMode : mode d'authentification du registre de schémas. Peut être défini sur NONE, TLS ou OAUTH. La valeur par défaut est "NONE".
  • schemaRegistryTruststoreLocation : emplacement du certificat SSL où le truststore pour l'authentification auprès du registre de schémas est stocké. Exemple :/your-bucket/truststore.jks
  • schemaRegistryTruststorePasswordSecretId : SecretId dans Secret Manager où est stocké le mot de passe permettant d'accéder au secret dans le truststore. Exemple :projects/your-project-number/secrets/your-secret-name/versions/your-secret-version
  • schemaRegistryKeystoreLocation : emplacement du keystore contenant le certificat SSL et la clé privée. Exemple :/your-bucket/keystore.jks
  • schemaRegistryKeystorePasswordSecretId : SecretId dans Secret Manager où se trouve le mot de passe permettant d'accéder au fichier keystore. Par exemple, projects/your-project-number/secrets/your-secret-name/versions/your-secret-version.
  • schemaRegistryKeyPasswordSecretId : SecretId du mot de passe requis pour accéder à la clé privée du client stockée dans le keystore. Par exemple, projects/your-project-number/secrets/your-secret-name/versions/your-secret-version.
  • schemaRegistryOauthClientId : ID client utilisé pour authentifier le client Schema Registry en mode OAUTH. Obligatoire pour le format de message AVRO_CONFLUENT_WIRE_FORMAT.
  • schemaRegistryOauthClientSecretId : ID du secret Google Cloud Secret Manager contenant le code secret client à utiliser pour authentifier le client Schema Registry en mode OAUTH. Obligatoire pour le format de message AVRO_CONFLUENT_WIRE_FORMAT. Exemple :projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<SECRET_VERSION>
  • schemaRegistryOauthScope : portée du jeton d'accès utilisé pour authentifier le client Schema Registry en mode OAUTH. Ce champ est facultatif, car la demande peut être effectuée sans paramètre d'étendue. Exemple :openid
  • schemaRegistryOauthTokenEndpointUrl : URL basée sur HTTP(S) pour le fournisseur d'identité OAuth/OIDC utilisé pour authentifier le client Schema Registry en mode OAUTH. Obligatoire pour le format de message AVRO_CONFLUENT_WIRE_FORMAT.
  • outputDeadletterTable : nom complet de la table BigQuery pour les messages ayant échoué. Les messages n'ayant pas pu atteindre la table de sortie pour différentes raisons (par exemple, schéma non concordant ou format JSON non valide) sont écrits dans cette table. La table sera créée par le modèle. Exemple :your-project-id:your-dataset.your-table-name

Exécuter le modèle

Console

  1. Accédez à la page Dataflow Créer un job à partir d'un modèle.
  2. Accéder à la page Créer un job à partir d'un modèle
  3. Dans le champ Nom du job, saisissez un nom de job unique.
  4. Facultatif : pour Point de terminaison régional, sélectionnez une valeur dans le menu déroulant. La région par défaut est us-central1.

    Pour obtenir la liste des régions dans lesquelles vous pouvez exécuter un job Dataflow, consultez la page Emplacements Dataflow.

  5. Dans le menu déroulant Modèle Dataflow, sélectionnez the Kafka to Cloud Storage template.
  6. Dans les champs fournis, saisissez vos valeurs de paramètres.
  7. Facultatif : Pour passer du traitement de type "exactement une fois" au mode de traitement en flux continu de type "au moins une fois", sélectionnez Au moins une fois.
  8. Cliquez sur Run Job (Exécuter la tâche).

gcloud

Dans le shell ou le terminal, exécutez le modèle :

gcloud dataflow flex-template run JOB_NAME \
    --project=PROJECT_ID \
    --region=REGION_NAME \
    --template-file-gcs-location=gs://dataflow-templates-REGION_NAME/VERSION/flex/Kafka_to_Gcs_Flex \
    --parameters \
readBootstrapServerAndTopic=BOOTSTRAP_SERVER_AND_TOPIC,\
kafkaReadAuthenticationMode=APPLICATION_DEFAULT_CREDENTIALS,\
messageFormat=JSON,\
outputDirectory=gs://STORAGE_BUCKET_NAME,\
useBigQueryDLQ=false
  

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet Google Cloud dans lequel vous souhaitez exécuter le job Dataflow
  • JOB_NAME : nom de job unique de votre choix
  • REGION_NAME : région dans laquelle vous souhaitez déployer votre job Dataflow, par exemple us-central1
  • VERSION : version du modèle que vous souhaitez utiliser

    Vous pouvez utiliser les valeurs suivantes :

  • BOOTSTRAP_SERVER_AND_TOPIC : adresse et sujet du serveur d'amorçage Apache Kafka

    Le format de l'adresse et du thème du serveur d'amorçage dépend du type de cluster :

    • Cluster Managed Service pour Apache Kafka : projects/PROJECT_ID/locations/REGION_NAME/clusters/CLUSTER_NAME/topics/TOPIC_NAME
    • Cluster Kafka externe : BOOTSTRAP_SERVER_ADDRESS;TOPIC_NAME
  • STORAGE_BUCKET_NAME : bucket Cloud Storage dans lequel la sortie est écrite.

API

Pour exécuter le modèle à l'aide de l'API REST, envoyez une requête HTTP POST. Pour en savoir plus sur l'API, ses autorisations et leurs champs d'application, consultez la section projects.templates.launch.

POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/LOCATION/flexTemplates:launch
{
   "launch_parameter": {
      "jobName": "JOB_NAME",
      "parameters": {
          "readBootstrapServerAndTopic": "BOOTSTRAP_SERVER_AND_TOPIC",
          "kafkaReadAuthenticationMode": "APPLICATION_DEFAULT_CREDENTIALS",
          "messageFormat": "JSON",
          "outputDirectory": "gs://STORAGE_BUCKET_NAME",
          "useBigQueryDLQ": "false"
      },
      "containerSpecGcsPath": "gs://dataflow-templates-LOCATION/VERSION/flex/Kafka_to_Gcs_Flex",
   }
}
  

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet Google Cloud dans lequel vous souhaitez exécuter le job Dataflow
  • JOB_NAME : nom de job unique de votre choix
  • LOCATION : région dans laquelle vous souhaitez déployer votre job Dataflow, par exemple us-central1
  • VERSION : version du modèle que vous souhaitez utiliser

    Vous pouvez utiliser les valeurs suivantes :

  • BOOTSTRAP_SERVER_AND_TOPIC : adresse et sujet du serveur d'amorçage Apache Kafka

    Le format de l'adresse et du thème du serveur d'amorçage dépend du type de cluster :

    • Cluster Managed Service pour Apache Kafka : projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/topics/TOPIC_NAME
    • Cluster Kafka externe : BOOTSTRAP_SERVER_ADDRESS;TOPIC_NAME
  • STORAGE_BUCKET_NAME : bucket Cloud Storage dans lequel la sortie est écrite.

Étapes suivantes