Ingestion en streaming

L’ingestion en streaming garantit une ingestion à faible latence et à haute vitesse des données de flux provenant d’Amazon Kinesis Data Streams et d’Amazon Managed Streaming for Apache Kafka dans une vue matérialisée Amazon Redshift sans serveur ou une vue Amazon Redshift provisionnée. Elle permet de réduire le temps nécessaire pour accéder aux données et les frais de stockage. Vous pouvez configurer l’ingestion en streaming de votre cluster Amazon Redshift ou pour Amazon Redshift sans serveur et créer une vue matérialisée au moyen d’instructions SQL, comme décrit dans Création de vues matérialisées dans Amazon Redshift. Ensuite, à l’aide de l’actualisation des vues matérialisées, vous pouvez ingérer des centaines de mégaoctets de données par seconde. Cela garantit un accès rapide aux données externes qui sont rapidement actualisées.

Flux de données

Un cluster Amazon Redshift provisionné ou un groupe de travail Amazon Redshift sans serveur est le consommateur de flux. Une vue matérialisée correspond à la zone d’arrivée des données lues à partir du flux, qui sont traitées au fur et à mesure de leur arrivée. Par exemple, les valeurs JSON peuvent être consommées et mappées à des colonnes de données de la vue matérialisée à l’aide d’instructions SQL familières. Lorsque la vue matérialisée est actualisée, Redshift consomme les données des partitions de données Kinesis ou des partitions Kafka allouées jusqu'à ce que la vue atteigne la parité avec le flux Kinesis ou la dernière pour SEQUENCE_NUMBER le sujet Kafka. Offset La vue matérialisée suivante actualise les données de lecture du dernier SEQUENCE_NUMBER de l’actualisation précédente, jusqu’à atteindre la parité avec les données du flux ou de la rubrique.

Cas d’utilisation d’ingestion en streaming

Les cas d’utilisation pour l’ingestion en streaming Amazon Redshift impliquent d’utiliser des données générées de manière continue (diffusées en continu) et devant être traitées dans un court délai (latence) après leur génération. C’est ce que l’on appelle l’analytique en temps quasi réel. Les sources de données peuvent varier et inclure des appareils IoT, des données télémétriques de système ou des données de flux de clics provenant d’un site web ou d’une application fréquentés.

Considérations de l’ingestion en streaming

Vous trouverez ci-dessous des considérations importantes et des bonnes pratiques en matière de performances et de facturation lors de la configuration de votre environnement d’ingestion en streaming.

• Utilisation et activation de l’actualisation automatique – Les requêtes d’actualisation automatique pour une ou plusieurs vues matérialisées sont traitées comme n’importe quelle autre charge de travail utilisateur. L’actualisation automatique charge les données du flux à mesure qu’elles arrivent.

  L’actualisation automatique peut être activée explicitement pour une vue matérialisée créée pour l’ingestion en streaming. Pour ce faire, spécifiez AUTO REFRESH dans la définition de la vue matérialisée. Par défaut, l’actualisation est manuelle. Pour spécifier l’actualisation automatique pour une vue matérialisée existante à des fins d’ingestion en streaming, vous pouvez exécuter ALTER MATERIALIZED VIEW pour l’activer. Pour en savoir plus, consultez CREATE MATERIALIZED VIEW ou ALTER MATERIALIZED VIEW.

• Ingestion en streaming et Amazon Redshift sans serveur : les mêmes instructions d’installation et de configuration qui s’appliquent à l’ingestion en streaming Amazon Redshift sur un cluster provisionné s’appliquent également à l’ingestion en streaming sur Amazon Redshift sans serveur. Il est important de dimensionner Amazon Redshift sans serveur avec le niveau de RPU nécessaire pour prendre en charge l’ingestion en streaming avec l’actualisation automatique et d’autres charges de travail. Pour obtenir plus d’informations, consultez Facturation d’Amazon Redshift sans serveur.

• Amazon Redshift nodes in a different availability zone than the Amazon MSK cluster (Nœuds Amazon Redshift dans une zone de disponibilité différente de celle du cluster Amazon MSK) : lorsque vous configurez l’ingestion en streaming, Amazon Redshift tente de se connecter à un cluster Amazon MSK situé dans la même zone de disponibilité, si la prise en compte des racks est activée pour Amazon MSK. Si tous vos nœuds se trouvent dans des zones de disponibilité différentes de celles de votre cluster Amazon Redshift, vous pouvez encourir des frais de transfert de données entre zones de disponibilité. Pour éviter cela, conservez au moins un nœud de cluster de courtiers Amazon MSK dans la même zone que votre cluster ou groupe de travail provisionné par Redshift.

• Refresh start location (Emplacement de départ de l’actualisation) : après avoir créé une vue matérialisée, son actualisation initiale commence à partir du TRIM_HORIZON d’un flux Kinesis ou à partir du décalage 0 d’une rubrique Amazon MSK.

• Data formats (Formats de données) : les formats de données pris en charge sont limités à ceux pouvant être convertis depuis VARBYTE. Pour plus d’informations, consultez Type VARBYTE et Opérateurs VARBYTE.

• Ajouter des enregistrements à une table : vous pouvez exécuter ALTER TABLE APPEND pour ajouter des lignes à une table cible à partir d’une vue matérialisée source existante. Cela ne fonctionne que si la vue matérialisée est configurée pour l’ingestion en streaming. Pour plus d’informations, consultez ALTER TABLE APPEND.

• Exécution de TRUNCATE ou DELETE : vous pouvez supprimer des enregistrements d’une vue matérialisée utilisée pour l’ingestion en streaming en utilisant deux méthodes :

  • TRUNCATE : cette commande supprime toutes les lignes à partir d’une vue matérialisée configurée pour l’ingestion en streaming. Elle n’effectue pas d’analyse de la table. Pour plus d’informations, consultez TRUNCATE.

  • DELETE : cette commande supprime toutes les lignes à partir d’une vue matérialisée configurée pour l’ingestion en streaming. Pour plus d’informations, consultez DELETE.

Meilleures pratiques et recommandations en matière d'ingestion du streaming

Dans certains cas, des options vous sont proposées pour configurer l'ingestion du streaming. Nous recommandons les meilleures pratiques suivantes. Ils sont basés sur nos propres tests et visent à aider les clients à éviter les problèmes entraînant une perte de données.

• Extraction de valeurs à partir de données diffusées : si vous utilisez la fonction JSON_EXTRACT_PATH_TEXT dans la définition de votre vue matérialisée pour détruire le flux JSON entrant, cela peut avoir un impact significatif sur les performances et la latence. Pour expliquer, pour chaque colonne extraite à l'aide de JSON_EXTRACT_PATH_TEXT, le JSON entrant est réanalysé. Ensuite, toute conversion de type de données, tout filtrage et toute logique métier ont lieu. Cela signifie, par exemple, que si vous extrayez 10 colonnes de vos données JSON, chaque enregistrement JSON est analysé 10 fois, ce qui inclut les conversions de type et une logique supplémentaire. Cela se traduit par une latence d'ingestion plus élevée. Une autre approche que nous recommandons consiste à utiliser la fonction JSON_PARSE pour convertir les enregistrements JSON au type de données SUPER de Redshift. Une fois que les données diffusées sont arrivées dans la vue matérialisée, utilisez partiQL pour extraire des chaînes individuelles de la représentation des données JSON par SUPER. Pour plus d'informations, consultez la section Interrogation de données semi-structurées.

  Il est également important de noter que JSON_EXTRACT_PATH_TEXT a une taille de données maximale de 64 Ko. Ainsi, si un enregistrement JSON est supérieur à 64 Ko, son traitement avec JSON_EXTRACT_PATH_TEXT entraîne une erreur.

• Mappage d'un Amazon Kinesis Data Streams flux ou d'un sujet Amazon MSK avec une vue matérialisée d'ingestion de flux Amazon Redshift : nous ne recommandons pas de créer plusieurs vues matérialisées d'ingestion de flux pour ingérer les données d'un seul flux ou d'un seul sujet Amazon MSK. Amazon Kinesis Data Streams En effet, chaque vue matérialisée crée un consommateur pour chaque partition du flux ou de la partition Kinesis Data Streams de la rubrique Kafka. Cela peut entraîner une limitation ou un dépassement du débit du flux ou du sujet. Cela peut également entraîner des coûts plus élevés, car vous ingérez les mêmes données plusieurs fois. Nous vous recommandons de créer une vue matérialisée en streaming pour chaque flux ou sujet.

  Si votre cas d'utilisation nécessite de transférer les données d'un flux KDS ou d'un sujet MSK vers plusieurs vues matérialisées, consultez le blog AWS Big Data, en particulier les meilleures pratiques pour implémenter des near-real-time analyses à l'aide d'Amazon Redshift Streaming Ingestion with Amazon MSK, avant de le faire.

Utilisation de l’ingestion en streaming par rapport aux données intermédiaires dans Amazon S3

Il existe plusieurs options pour diffuser des données vers Amazon Redshift ou vers Amazon Redshift sans serveur. Deux options bien connues sont l'ingestion du streaming, comme décrit dans cette rubrique, ou la configuration d'un flux de diffusion vers Amazon S3 avec Firehose. La liste suivante décrit chaque méthode :

1. L’ingestion en streaming depuis Kinesis Data Streams ou Amazon Managed Streaming for Apache Kafka vers Amazon Redshift ou Amazon Redshift sans serveur implique la configuration d’une vue matérialisée pour recevoir les données.

2. La diffusion de données dans Amazon Redshift à l'aide de Kinesis Data Streams et du streaming via Firehose implique de connecter le flux source à Amazon Data Firehose et d'attendre que Firehose transfère les données dans Amazon S3. Ce procédé utilise des lots de tailles différentes avec des intervalles de mémoire tampon de longueur variable. Après le streaming vers Amazon S3, Firehose lance une commande COPY pour charger les données.

Avec l’ingestion en streaming, vous contournez plusieurs étapes requises pour le second processus :

• Il n'est pas nécessaire d'envoyer des données vers un flux de diffusion Amazon Data Firehose, car avec l'ingestion en streaming, les données peuvent être envoyées directement depuis Kinesis Data Streams vers une vue matérialisée dans une base de données Redshift.

• Il n’est pas nécessaire de transférer les données diffusées dans Amazon S3, car les données d’ingestion en streaming sont directement transférées vers la vue matérialisée Redshift.

• Il n’est pas nécessaire d’écrire et d’exécuter des commandes COPY car les données de la vue matérialisée sont actualisées directement à partir du flux. Le chargement de données depuis Amazon S3 vers Redshift ne fait pas partie du processus.

Notez que l’ingestion en streaming est limitée aux flux provenant d’Amazon Kinesis Data Streams et aux rubriques provenant d’Amazon MSK. Pour le streaming depuis Kinesis Data Streams vers des cibles autres qu'Amazon Redshift, il est probable que vous ayez besoin d'un flux de diffusion Firehose. Pour plus d'informations, consultez la section Envoi de données vers un flux de livraison Amazon Data Firehose.

Limites

Fonction ou comportement	Description
Kafka topic length limit (Limite de longueur des rubriques Kafka)	Il n’est pas possible d’utiliser une rubrique Kafka dont le nom comporte plus de 128 caractères (guillemets non compris). Pour plus d’informations, consultez Noms et identificateurs.
Incremental refreshes and JOINs on a materialized view (Actualisations et JOIN incrémentiels sur une vue matérialisée)	La vue matérialisée doit être gérable de manière progressive. Le recalcul complet est impossible pour Kinesis ou Amazon MSK, car ils ne conservent pas l’historique des flux ou des rubriques après 24 heures ou 7 jours, par défaut. Vous pouvez définir des périodes de conservation des données plus longues dans Kinesis ou Amazon MSK. Cependant, cela peut entraîner une maintenance et des frais supplémentaires. De plus, les JOIN ne sont actuellement pas pris en charge sur les vues matérialisées créées sur un flux Kinesis ou sur une rubrique Amazon MSK. Après avoir créé une vue matérialisée sur votre flux ou rubrique, vous pouvez créer une autre vue matérialisée pour joindre votre vue matérialisée de streaming à d’autres vues matérialisées, tables ou vues. Pour plus d’informations, consultez REFRESH MATERIALIZED VIEW.
Record parsing (Analyse des enregistrements)	L’ingestion en streaming Amazon Redshift ne prend pas en charge l’analyse des enregistrements agrégés par la Kinesis Producer Library (KPL Key Concepts - Aggregation (Concepts clés KPL – Agrégation)). Les registres agrégés sont ingérés, mais sont stockés sous forme de données de tampon de protocole binaire. (Consultez Protocol Buffers pour plus d’informations.) Selon la manière dont vous transmettez les données à Kinesis, vous devrez peut-être désactiver cette fonction.
Decompression (Décompression)	VARBYTE ne prend en charge aucune méthode de décompression actuellement. De ce fait, les enregistrements contenant des données compressées ne peuvent pas être interrogés dans Redshift. Décompressez vos données avant de les envoyer dans le flux Kinesis ou dans la rubrique Amazon MSK.
Maximum record size (Taille d’enregistrement maximale)	La taille maximale de tout champ d’enregistrement qu’Amazon Redshift peut ingérer depuis Kinesis ou Amazon MSK est légèrement inférieure à 1 Mo. Les points suivants détaillent le comportement : Maximum VARBYTE length (Longueur VARBYTE maximale) : le type VARBYTE prend en charge les données d’une longueur maximale de 1 024 000 octets. Comme Kinesis limite les charges utiles à 1 Mo, après l’encodage Base64, toutes les données Kinesis peuvent être ingérées par Amazon Redshift. Message limits (Limites de messages) : la configuration Amazon MSK par défaut limite les messages à 1 Mo. De plus, si un message inclut des en-têtes, la quantité de données est limitée à 1 048 470 octets. Avec les paramètres par défaut, il n’y a aucun problème d’ingestion. Vous pouvez toutefois modifier la taille maximale des messages pour Kafka, et donc Amazon MSK, en leur attribuant une valeur plus élevée. Dans ce cas, il est possible que le champ clé/valeur d’un enregistrement Kafka, ou l’en-tête, dépasse la limite de taille. Ces enregistrements peuvent provoquer une erreur et ne sont pas ingérés.
Enregistrements d’erreurs	Chaque fois qu’un enregistrement ne peut pas être ingéré dans Redshift parce que la taille des données dépasse la taille maximale, cet enregistrement est ignoré. L’actualisation de la vue matérialisée réussit toujours, dans ce cas, et un segment de chaque enregistrement d’erreur est écrit dans la table système SYS_STREAM_SCAN_ERRORS. Les erreurs résultant de la logique métier, telles qu’une erreur de calcul ou une erreur résultant d’une conversion de type, ne sont pas ignorées. Testez soigneusement la logique avant d’ajouter une logique à la définition de votre vue matérialisée, afin d’éviter ces problèmes.
Connectivité privée multi-VPC Amazon MSK	La connectivité privée multi-VPC d'Amazon MSK n'est actuellement pas prise en charge pour l'ingestion du streaming Redshift. Vous pouvez également utiliser le peering VPC pour connecter des VPC ou pour connecter des VPC AWS Transit Gatewayà des réseaux sur site via un hub central. L'une ou l'autre de ces options peut permettre à Redshift de communiquer avec un cluster Amazon MSK ou avec Amazon MSK Serverless dans un autre VPC.