Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Commencer à ingérer du streaming à partir de sources Apache Kafka - Amazon Redshift

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Commencer à ingérer du streaming à partir de sources Apache Kafka

Cette rubrique explique comment utiliser des données de streaming depuis Amazon MSK, Apache Kafka ou Confluent Cloud à l'aide d'une vue matérialisée.

L’objectif de l’ingestion en streaming Amazon Redshift est de simplifier le processus afin d’ingérer directement des données de flux depuis un service de streaming vers Amazon Redshift ou Amazon Redshift sans serveur. Cela fonctionne avec Amazon MSK Provisioned et Amazon MSK Serverless, avec l'open source Apache Kafka et avec Confluent Cloud. L'ingestion du streaming par Amazon Redshift élimine le besoin de créer un sujet Apache Kafka dans Amazon S3 avant d'ingérer les données du flux dans Redshift.

Sur le plan technique, l'ingestion du streaming permet une ingestion rapide et à faible latence des données de flux ou de sujets dans une vue matérialisée Amazon Redshift. Après la configuration, l’actualisation de la vue matérialisée vous permet d’intégrer de gros volumes de données.

Vous devez disposer d'une source Apache Kafka avant de configurer l'ingestion du streaming par Amazon Redshift. Si vous n'avez pas de source, créez-en une en suivant les instructions suivantes :

Configuration de l'ingestion du streaming depuis Kafka

Utilisez les procédures suivantes pour configurer l'ingestion de flux vers Amazon Redshift à partir d'Amazon MSK ou de sources Apache Kafka non AWS gérées (Apache Kafka et Confluent Cloud).

Configurer l'authentification

Cette section décrit la configuration de l'authentification pour permettre à votre application Amazon Redshift d'accéder à une source Amazon MSK.

Après avoir créé le rôle de votre application, associez l'une des politiques suivantes pour autoriser l'accès à votre cluster Amazon MSK, Apache Kafka ou Confluent Cloud. Pour l'authentification mTLS, vous pouvez stocker les certificats utilisés par Amazon Redshift dans ACM ou Secrets Manager. Vous devez donc choisir la politique correspondant à l'endroit où le certificat est stocké.

AUTHENTIFICATION IAM (Amazon MSK uniquement) :

{ "Version": "2012-10-17", "Statement": [ { "Sid": "MSKIAMpolicy", "Effect": "Allow", "Action": [ "kafka-cluster:ReadData", "kafka-cluster:DescribeTopic", "kafka-cluster:Connect" ], "Resource": [ "arn:aws:kafka:*:0123456789:cluster/MyTestCluster/*", "arn:aws:kafka:*:0123456789:topic/MyTestCluster/*" ] }, { "Effect": "Allow", "Action": [ "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": [ "arn:aws:kafka:*:0123456789:group/MyTestCluster/*" ] } ] }

AUTHENTIFICATION MTLS : à l'aide d'un certificat stocké dans AWS Certificate Manager

{ "Version": "2012-10-17", "Statement": [ { "Sid": "MSKmTLSACMpolicy", "Effect": "Allow", "Action": [ "acm:ExportCertificate" ], "Resource": [ "arn:aws:acm:us-east-1:444455556666:certificate/certificate_ID" ] } ] }

AUTHENTIFICATION MTLS : à l'aide d'un certificat stocké dans AWS Secrets Manager

{ "Version": "2012-10-17", "Statement": [ { "Sid": "MSKmTLSSecretsManagerpolicy", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:444455556666:secret:secret_ID" ] } ] }
Amazon MSK

Si vous utilisez AUTHENTICATION NONE pour vous connecter à une source Amazon MSK, aucun rôle IAM n'est requis. Toutefois, si vous utilisez AUTHENTICATION IAM ou MTLS pour vous authentifier auprès de votre cluster Amazon MSK, votre cluster Amazon Redshift ou votre espace de noms Amazon Redshift Serverless doit être associé à un rôle IAM avec les autorisations appropriées. Créez un rôle IAM avec une politique de confiance qui permet à votre cluster Amazon Redshift ou à votre espace de noms Amazon Redshift Serverless d'assumer ce rôle. Après avoir créé le rôle, ajoutez l'une des autorisations suivantes pour prendre en charge IAM ou MTLS. Pour l'authentification mTLS, les certificats utilisés par Amazon Redshift peuvent être stockés AWS Certificate Manager dans AWS Secrets Manager ou. Vous devez donc choisir la politique correspondant à l'endroit où le certificat est stocké. Associez le rôle à votre cluster provisionné Amazon Redshift ou à votre espace de noms Redshift Serverless. Pour plus d'informations sur la façon de configurer la politique de confiance pour le rôle IAM, consultez Autoriser Amazon Redshift à accéder à AWS d'autres services en votre nom.

Le tableau suivant montre les options de configuration complémentaires à définir pour l’ingestion en streaming depuis Amazon MSK :

Configuration Amazon Redshift Configuration d’Amazon MSK Port à ouvrir entre Redshift et Amazon MSK
AUTHENTICATION NONE Transport TLS désactivé 9092
AUTHENTICATION NONE Transport TLS activé 9094
AUTHENTICATION IAM IAM 9098/9198
AUTHENTIFICATION MTLS Transport TLS activé 9094

L’authentification Amazon Redshift est définie dans l’instruction CREATE EXTERNAL SCHEMA.

Note

Si l’authentification mTLS (Mutual Transport Layer Security) est activée sur le cluster Amazon MSK, la configuration d’Amazon Redshift pour utiliser AUTHENTICATION NONE lui indique d’utiliser le port 9094 pour un accès non authentifié. Toutefois, cela échouera, car le port est utilisé par l’authentification mTLS. Pour cette raison, nous vous recommandons de passer à AUTHENTIFICATION mtls lorsque vous utilisez mTLS.

Apache Kafka or Confluent Cloud

Pour Apache Kafka et Confluent Cloud, Amazon Redshift prend en charge les protocoles de connexion suivants :

  • Vous pouvez utiliser le protocole MTL ou le texte brut avec le transport TLS pour l'authentification lorsque vous vous connectez à Apache Kafka.

  • Vous ne pouvez utiliser mTLS que pour l'authentification lorsque vous vous connectez à Confluent Cloud.

Amazon Redshift prend en charge les protocoles de chiffrement suivants pour la connexion à Apache Kafka ou à Confluent Cloud :

Méthodes d'authentification prises en charge pour Apache Kafka et Confluent Cloud

Amazon Redshift Protocole de sécurité Kafka Support d'Apache Kafka Assistance Confluent Cloud
AUTHENTICATION NONE TEXTE EN CLAIR Non Non
AUTHENTICATION NONE SSL Oui Non
AUTHENTICATION IAM SASL_SSL Non Non
AUTHENTIFICATION MTLS SSL Oui (avec certificat) Oui (avec certificat)

Notez qu'Amazon Redshift n'est pas compatible. SASL/SCRAM or SASL/PLAINTEXT

Si vous utilisez AUTHENTICATION NONE pour vous connecter à une source Amazon MSK, aucun rôle IAM n'est requis. Toutefois, si vous utilisez AUTHENTICATION IAM ou MTLS pour vous authentifier auprès de votre cluster Amazon MSK, votre cluster Amazon Redshift ou votre espace de noms Amazon Redshift Serverless doit être associé à un rôle IAM avec les autorisations appropriées. Créez un rôle IAM avec une politique de confiance qui permet à votre cluster Amazon Redshift ou à votre espace de noms Amazon Redshift Serverless d'assumer ce rôle. Après avoir créé le rôle, ajoutez l'une des autorisations suivantes pour prendre en charge IAM ou MTLS. Pour l'authentification mTLS, les certificats utilisés par Amazon Redshift peuvent être stockés AWS Certificate Manager dans AWS Secrets Manager ou. Vous devez donc choisir la politique correspondant à l'endroit où le certificat est stocké. Associez le rôle à votre cluster provisionné Amazon Redshift ou à votre espace de noms Redshift Serverless. Pour plus d'informations sur la façon de configurer la politique de confiance pour le rôle IAM, consultez Autoriser Amazon Redshift à accéder à AWS d'autres services en votre nom.

Le tableau suivant montre les options de configuration complémentaires à définir pour l’ingestion en streaming depuis Amazon MSK :

Configuration Amazon Redshift Configuration d’Amazon MSK Port à ouvrir entre Redshift et Amazon MSK
AUTHENTICATION NONE Transport TLS désactivé 9092
AUTHENTICATION NONE Transport TLS activé 9094
AUTHENTICATION IAM IAM 9098/9198
AUTHENTIFICATION MTLS Transport TLS activé 9094

L’authentification Amazon Redshift est définie dans l’instruction CREATE EXTERNAL SCHEMA.

Note

Si l’authentification mTLS (Mutual Transport Layer Security) est activée sur le cluster Amazon MSK, la configuration d’Amazon Redshift pour utiliser AUTHENTICATION NONE lui indique d’utiliser le port 9094 pour un accès non authentifié. Toutefois, cela échouera, car le port est utilisé par l’authentification mTLS. Pour cette raison, nous vous recommandons de passer à AUTHENTIFICATION mtls lorsque vous utilisez mTLS.

Configuration de votre VPC

Après avoir créé vos ressources d'authentification, vérifiez votre VPC et vérifiez que votre cluster Amazon Redshift ou votre groupe de travail Amazon Redshift Serverless dispose d'un itinéraire pour accéder à votre source Apache Kafka.

Note

Pour Amazon MSK, les règles du groupe de sécurité entrant pour votre cluster Amazon MSK doivent autoriser le groupe de sécurité de votre cluster Amazon Redshift ou de votre groupe de travail Redshift Serverless. Les ports que vous spécifiez dépendent des méthodes d'authentification configurées sur votre cluster Amazon MSK. Pour plus d'informations, consultez les sections Informations sur les ports et Accès depuis le VPC AWS mais depuis l'extérieur.

Activez ensuite le routage VPC amélioré sur votre cluster Amazon Redshift ou votre groupe de travail Amazon Redshift Serverless. Pour plus d’informations, consultez Activation du routage VPC amélioré.

Création d'une vue matérialisée

Dans cette section, vous allez configurer la vue matérialisée qu'Amazon Redshift utilise pour accéder à vos données de streaming Apache Kafka.

En supposant qu'un cluster Apache Kafka soit disponible, la première étape consiste à définir un schéma dans Redshift CREATE EXTERNAL SCHEMA avec et à référencer le cluster comme source de données. Ensuite, pour accéder aux données dans la rubrique, définissez le STREAM dans une vue matérialisée. Vous pouvez stocker les enregistrements de votre rubrique en utilisant le type de données Amazon Redshift VARBYTE par défaut, ou définir un schéma qui convertit les données au format semi-structuré. SUPER Lorsque vous interrogez la vue matérialisée, les enregistrements renvoyés sont une point-in-time vue du sujet.

  1. Dans Amazon Redshift, créez un schéma externe à mapper au cluster Apacke Kafka. La syntaxe est la suivante :

    CREATE EXTERNAL SCHEMA MySchema FROM KAFKA [ IAM_ROLE [ default | 'iam-role-arn' ] ] AUTHENTICATION [ none | iam | mtls ] [AUTHENTICATION_ARN 'acm-certificate-arn' | SECRET_ARN 'ssm-secret-arn' ];

    Dans la FROM clause, KAFKA indique que le schéma mappe les données d'une source Apache Kafka.

    AUTHENTICATIONindique le type d'authentification pour l'ingestion du streaming. Trois types sont disponibles :

    • none — Spécifie qu'aucune authentification n'est requise. Cela correspond à un accès non authentifié sur MSK. Cela correspond à l'authentification SSL dans Apache Kafka. Cette méthode d'authentification n'est pas prise en charge pour Confluent Cloud.

    • iam – Indique une authentification IAM. Vous ne pouvez utiliser l'authentification IAM qu'avec Amazon MSK. Lorsque vous choisissez cette option, vérifiez que le rôle IAM dispose des autorisations nécessaires à l’authentification IAM. Pour plus d'informations sur la configuration des politiques IAM requises, consultezConfiguration de l'ingestion du streaming depuis Kafka.

    • mtls — Spécifie que la sécurité mutuelle de la couche de transport assure une communication sécurisée en facilitant l'authentification entre un client et un serveur. Dans ce cas, le client est Redshift et le serveur est Apache Kafka. Pour plus d'informations sur la configuration de l'ingestion du streaming avec les mTLS, consultezAuthentification avec MTL pour l'ingestion de flux Redshift à partir de sources Apache Kafka.

    Notez que l'authentification Amazon MSK avec un nom d'utilisateur et un mot de passe n'est pas prise en charge pour l'ingestion du streaming.

    Le AUTHENTICATION_ARN paramètre spécifie l'ARN du certificat mTLS (ACM Mutual Transport Layer Security) que vous utilisez pour établir une connexion cryptée.

    Le SECRET_ARN paramètre spécifie l'ARN du AWS Secrets Manager secret contenant le certificat à utiliser par Amazon Redshift pour les MTL.

    Les exemples suivants montrent comment définir l'URI du courtier pour le cluster Amazon MSK lorsque vous créez le schéma externe :

    Utilisation de l'authentification IAM :

    CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION IAM URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098'

    Sans authentification :

    CREATE EXTERNAL SCHEMA my_schema FROM KAFKA AUTHENTICATION none URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9092,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9092'

    À l'aide de MTL :

    CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION MTLS URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094,b- 2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094' AUTHENTICATION_ARN 'acm-certificate-arn' | [ SECRET_ARN 'ssm-secret-arn' ];

    Pour plus d'informations sur la création d'un schéma externe, voir CRÉER UN SCHÉMA EXTERNE.

  2. Créez une vue matérialisée pour consommer les données de la rubrique. Utilisez une commande SQL telle que l'exemple suivant.

    CREATE MATERIALIZED VIEW MyView AUTO REFRESH YES AS SELECT * FROM MySchema."mytopic";

    Les noms de rubrique Kafka sont sensibles à la casse et peuvent contenir des lettres majuscules et minuscules. Pour effectuer une ingestion à partir de rubriques dont les noms sont en majuscules, vous pouvez définir la configuration enable_case_sensitive_identifier true au niveau de la session ou de la base de données. Pour plus d’informations, consultez Noms et identificateurs et enable_case_sensitive_identifier.

    Pour activer l’actualisation automatique, utilisez AUTO REFRESH YES. L’actualisation manuelle est le comportement par défaut.

  3. Les colonnes de métadonnées incluent ce qui suit :

    Colonne de métadonnées Type de données Description
    kafka_partition bigint ID de partition de l’enregistrement issu de la rubrique Kafka
    kafka_offset bigint Décalage de l’enregistrement dans la rubrique Kafka pour une partition donnée
    kafka_timestamp_type char(1)

    Type d’horodatage utilisé dans l’enregistrement Kafka :

    • C – Enregistrer l’heure de création (CREATE_TIME) côté client

    • L – Enregistrer l’heure d’ajout (LOG_APPEND_TIME) côté serveur Kafka

    • U – Enregistrer l’heure de création indisponible (NO_TIMESTAMP_TYPE)

    kafka_timestamp horodatage sans fuseau horaire Valeur timestamp de l’enregistrement
    kafka_key varbyte La clé de l’enregistrement de Kafka
    kafka_value varbyte L’enregistrement reçu de Kafka
    kafka_headers super L’en-tête de l’enregistrement reçu de Kafka
    refresh_time horodatage sans fuseau horaire L’heure de début de l’actualisation

    Il est important de noter que si la définition de votre vue matérialisée comporte une logique métier qui entraîne des erreurs de logique métier, cela peut entraîner des échecs d'ingestion lors de l'ingestion du streaming dans certains cas. Cela peut vous obliger à supprimer et à recréer la vue matérialisée. Pour éviter cela, nous vous recommandons de conserver une logique métier simple et d'exécuter une logique supplémentaire sur les données après les avoir ingérées.

  4. Actualisez la vue, ce qui appelle Amazon Redshift à lire à partir de la rubrique et à charger des données dans la vue matérialisée.

    REFRESH MATERIALIZED VIEW MyView;
  5. Interrogez les données dans la vue matérialisée.

    select * from MyView;

    La vue matérialisée est mise à jour directement à partir de la rubrique lorsque REFRESH est exécuté. Vous créez une vue matérialisée qui se mappe à la source de données de la rubrique Kafka. Vous pouvez effectuer des filtrages et des agrégations sur les données dans le cadre de la définition de la vue matérialisée. Votre vue matérialisée de l’ingestion en streaming (la vue matérialisée de base) ne peut référencer qu’une seule rubrique Kafka. Toutefois, vous pouvez créer des vues matérialisées supplémentaires qui se joignent à la vue matérialisée de base et à d’autres vues ou tables matérialisées.

Pour plus d’informations sur les limites relatives à l’ingestion en streaming, consultez Comportement d'ingestion du streaming et types de données.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.