Diffusion de l'ingestion vers une vue matérialisée - 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.

Diffusion de l'ingestion vers une vue matérialisée

L'ingestion de streaming permet une ingestion de données à faible latence et à haut débit depuis Amazon Kinesis Data Streams ou Amazon Managed Streaming for Apache Kafka vers une base de données Amazon Redshift provisionnée ou Amazon Redshift Serverless. Les données arrivent dans une vue matérialisée Redshift configurée à cet effet. Cela se traduit par un accès rapide aux données externes. L'ingestion du streaming réduit le temps d'accès aux données et réduit les coûts de stockage. Vous pouvez le configurer pour votre cluster Amazon Redshift ou pour votre groupe de travail Amazon Redshift Serverless à l'aide d'un petit ensemble de commandes. SQL Une fois configurée, chaque actualisation d'une vue matérialisée peut ingérer des centaines de mégaoctets de données par seconde.

Comment les données circulent d'un service de streaming vers Redshift

Cela permet de comprendre le fonctionnement de l'ingestion du streaming et les objets de base de données utilisés au cours du processus. Les données circulent directement d'un fournisseur de flux de données vers un cluster provisionné par Amazon Redshift ou vers un groupe de travail Amazon Redshift Serverless. Il n'existe pas de zone d'atterrissage temporaire, telle qu'un compartiment Amazon S3. Le cluster ou le groupe de travail provisionné est le consommateur du flux. Dans la base de données Redshift, les données lues dans le flux apparaissent dans une vue matérialisée. Les données sont traitées au fur et à mesure de leur arrivée. Par exemple, JSON les valeurs peuvent être consommées et mappées aux colonnes de données d'une vue matérialisée à l'aide de. SQL Lorsque la vue matérialisée est actualisée, Redshift consomme les données provenant des fragments de données Kinesis ou des partitions Kafka alloués jusqu'à ce que la vue soit mise à jour avec le flux.

Les cas d'utilisation de l'ingestion du streaming par Amazon Redshift impliquent des données générées en continu et devant être traitées dans un court laps de temps (latence) à compter de leur origine. C'est ce que l'on appelle communément l'analyse en temps quasi réel. Les sources peuvent inclure des appareils informatiques, des dispositifs de télémétrie du système et des données de flux de clics provenant d'un site Web ou d'une application très fréquenté.

Meilleures pratiques d'analyse des données pour améliorer les performances

Lorsque vous configurez l'ingestion du streaming, il existe des options permettant d'analyser les données entrantes. Les pratiques peuvent inclure l'exécution de la logique métier ou le formatage au fur et à mesure que les données arrivent. Nous recommandons les meilleures pratiques suivantes pour éviter les erreurs ou les pertes de données. Ils sont issus de tests internes et ont aidé les clients à résoudre les problèmes de configuration et d'analyse.

  • Extraction de valeurs à partir de données diffusées — Si vous utilisez la TEXT fonction JSON_ _ EXTRACT PATH _ dans la définition de votre vue matérialisée pour analyser ou détruire les données diffuséesJSON, 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, l'entrée JSON est réanalysée. Ensuite, la conversion des types de données, le filtrage et les calculs de logique métier ont lieu. Cela signifie, par exemple, que si vous extrayez 10 colonnes à partir de JSON données, chaque JSON enregistrement est analysé 10 fois, ce qui inclut une logique supplémentaire. Cela se traduit par une latence d'ingestion plus élevée. Une autre approche que nous recommandons consiste à utiliser la PARSEfonction JSON _ pour convertir JSON les enregistrements au type de SUPER données 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 SUPER représentation des données. JSON Pour plus d'informations, consultez la section Interrogation de données semi-structurées.

    Notez également que JSON _ _ EXTRACT PATH _ TEXT a une taille de données maximale de 64 Ko. Ainsi, si JSON un enregistrement 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'une MSK rubrique Amazon sur plusieurs vues matérialisées : nous vous déconseillons de créer plusieurs vues matérialisées pour ingérer les données d'un seul flux ou d'un seul sujet. 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. Lorsque vous configurez l'ingestion de flux, nous vous recommandons de créer une vue matérialisée pour chaque flux ou sujet.

    Si votre cas d'utilisation nécessite que vous ingériez les données d'un KDS flux ou d'un MSK sujet dans 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 MSK Amazon, avant de le faire.

Comportement d'ingestion du streaming et types de données

Le tableau suivant décrit les détails techniques du comportement et les limites de taille pour différents types de données. Nous vous recommandons de vous familiariser avec celles-ci avant de configurer une vue matérialisée pour l'ingestion du streaming.

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.

Actualisations incrémentielles et JOINs sur une vue matérialisée

La vue matérialisée doit être gérable de manière progressive. Le recalcul complet n'est pas possible pour Kinesis ou MSK Amazon car, par défaut, ils ne conservent pas l'historique des diffusions ou des sujets après 24 heures ou 7 jours. 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. En outre, JOINs ils ne sont actuellement pas pris en charge sur les vues matérialisées créées sur un flux Kinesis ou sur une rubrique AmazonMSK. 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 REFRESHMATERIALIZEDVIEW.

Record parsing (Analyse des enregistrements)

L'ingestion du streaming par Amazon Redshift ne prend pas en charge l'analyse des enregistrements agrégés par la bibliothèque Kinesis Producer (concepts KPLclés - 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)

VARBYTEne prend pas en charge la décompression. 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 ajouter au flux Kinesis ou à la rubrique AmazonMSK.

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 :

  • VARBYTELongueur maximale : pour l'ingestion en streaming, le VARBYTE type prend en charge les données jusqu'à une longueur maximale de 1 024 000 octets. Kinesis limite les charges utiles à 1 Mo.

  • Limites de messages — La MSK configuration par défaut d'Amazon 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. Cependant, vous pouvez modifier la taille maximale des messages pour Kafka, et donc AmazonMSK, par 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.

Note

Amazon Redshift prend en charge une taille maximale de 1 024 000 octets pour l'ingestion de flux depuis Kinesis ou Amazon, MSK même si Amazon Redshift prend en charge une taille maximale de 16 Mo pour le type de données. VARBYTE

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 le maximum, 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 de l'ajouter à la définition de votre vue matérialisée.

Connectivité Amazon MSK Multi- VPC privée

La connectivité MSK VPC multi-privée d'Amazon n'est actuellement pas prise en charge pour l'ingestion du streaming Redshift. Vous pouvez également utiliser le VPCpeering pour connecter VPCs ou AWS Transit Gatewayconnecter VPCs des réseaux sur site via un hub central. L'une ou l'autre de ces options peut permettre à Redshift de communiquer avec un MSK cluster Amazon ou avec Amazon MSK Serverless dans un autre. VPC

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 toute 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 plus d'informations, consultez CREATEMATERIALIZEDVIEWou ALTERMATERIALIZEDVIEW.

Ingestion du streaming et Amazon Redshift Serverless

Les instructions d'installation et de configuration qui s'appliquent à l'ingestion du streaming par Amazon Redshift sur un cluster provisionné s'appliquent également à l'ingestion du streaming sur Amazon Redshift Serverless. Il est important de spécifier le niveau nécessaire pour RPUs prendre en charge l'ingestion du streaming avec l'actualisation automatique et d'autres charges de travail. Pour obtenir plus d’informations, consultez Facturation d’Amazon Redshift sans serveur.

Nœuds Amazon Redshift situés dans une zone de disponibilité différente de celle du cluster Amazon MSK

Lorsque vous configurez l'ingestion du streaming, Amazon Redshift tente de se connecter à un MSK cluster Amazon présentant le même niveau de disponibilité, si la reconnaissance du rack 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 avoir à payer des frais de transfert de données entre zones de disponibilité. Pour éviter cela, conservez au moins un nœud de cluster Amazon MSK Broker dans la même zone que votre cluster ou groupe de travail provisionné par Redshift.

Actualiser l'emplacement de départ

Après avoir créé une vue matérialisée, son actualisation initiale commence à partir TRIM_HORIZON d'un flux Kinesis ou à partir du décalage 0 d'une rubrique AmazonMSK.

Formats de données

Les formats de données pris en charge sont limités à ceux à partir desquels il est possible de convertirVARBYTE. Pour plus d’informations, consultez VARBYTEtype 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 ALTERTABLEAPPEND.

Courir TRUNCATE ou DELETE

Vous pouvez supprimer des enregistrements d'une vue matérialisée utilisée pour l'ingestion de flux en continu, en procédant comme suit :

  • TRUNCATE— Cela supprime toutes les lignes d'une vue matérialisée configurée pour l'ingestion du streaming. Elle n’effectue pas d’analyse de la table. Pour plus d'informations, consultez TRUNCATE.

  • DELETE— Cela supprime toutes les lignes d'une vue matérialisée configurée pour l'ingestion du streaming. Pour plus d'informations, consultez DELETE.