Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs à compter du 1er novembre 2025. Si vous souhaitez utiliser Python UDFs, créez la version UDFs antérieure à cette date. Le Python existant UDFs continuera à fonctionner normalement. Pour plus d’informations, consultez le billet de blog
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.
Ingestion en streaming vers une vue matérialisée
Cette rubrique explique comment utiliser les vues matérialisées pour accéder rapidement aux données en streaming.
L’ingestion en streaming garantit une ingestion à haute vitesse des données de flux provenant d’Amazon Kinesis Data Streams
Comment les données circulent d’un service de streaming vers Redshift
Cela permet de comprendre le fonctionnement de l’ingestion en 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 Amazon Redshift alloué ou vers un groupe de travail Amazon Redshift sans serveur. Il n’existe pas de zone d’atterrissage temporaire, telle qu’un compartiment Amazon S3. Le cluster ou groupe de travail alloué est le consommateur du flux. Dans la base de données Redshift, les données lues dans le flux atterrissent dans une vue matérialisée. Les données sont traitées dès leur arrivée. Par exemple, les valeurs JSON peuvent être consommées et mappées à des colonnes de données d’une vue matérialisée à l’aide d’instructions SQL. Lorsque la vue matérialisée est actualisée, Redshift consomme les données provenant des partitions de données Kinesis ou Kafka allouées jusqu’à ce que la vue soit mise à jour avec le flux.
Les cas d’utilisation pour l’ingestion en streaming Amazon Redshift impliquent des données générées de manière continue et devant être traitées dans un court délai (ou latence) après leur montage. C’est ce que l’on appelle généralement l’analytique en temps quasi réel. Les sources peuvent inclure des appareils informatiques, des appareils 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.
Bonnes pratiques d’analyse des données pour améliorer les performances
Lorsque vous configurez l’ingestion en 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 vous recommandons les bonnes pratiques suivantes pour éviter les erreurs ou les pertes de données. Elles sont issues 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 fonction JSON_EXTRACT_PATH_TEXT dans la définition de votre vue matérialisée pour analyser ou déchiqueter le JSON diffusé, 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, 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 données JSON, chaque enregistrement JSON est analysé 10 fois, ce qui inclut une logique supplémentaire. Cela entraîne 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 ont atterri dans la vue matérialisée, utilisez PartiQL pour extraire des chaînes individuelles de la représentation SUPER des données JSON. Pour de plus amples informations, consultez 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 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'une rubrique Amazon MSK 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 sujet. En effet, chaque vue matérialisée crée un consommateur pour chaque partition du flux Kinesis Data Streams ou de la partition de la rubrique Kafka. Cela peut entraîner une limitation ou un dépassement du débit du flux ou de la rubrique. 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 en streaming, nous vous recommandons de créer une vue matérialisée pour chaque flux ou rubrique.
Si votre cas d'utilisation nécessite que vous ingériez les données d'un flux KDS ou d'un sujet MSK dans plusieurs vues matérialisées, consultez le blog AWS Big Data
, en particulier les meilleures pratiques pour implémenter des analyses à l'aide d' near-real-timeAmazon Redshift Streaming Ingestion with Amazon MSK, avant de le faire.
Comportement de l’ingestion en streaming et types de données
La table suivante décrit les détails techniques du comportement et les limites de taille pour les 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 en 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 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. 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 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 |
| Valeurs dupliquées dans les en-têtes Kafka | Le client consommateur du streaming Amazon Redshift pour les rubriques Kafka provenant d’Amazon MSK, Confluent ou Apache Kafka ne prend pas en charge les valeurs dupliquées dans les en-têtes des rubriques Kafka. |
| Decompression (Décompression) |
|
| Maximum record size (Taille d’enregistrement maximale) | La taille maximale de tout enregistrement qu’Amazon Redshift peut ingérer à partir d’un service de streaming est de 16 777 216 octets (16 Mio), soit la taille maximale prise en charge par le type de données VARBYTE dans Amazon Redshift. Kinesis ne prend toutefois en charge qu’une taille d’enregistrement maximale de 1 048 576 octets (1 Mio). Amazon MSK prend en charge une taille d’enregistrement maximale de 16 777 216 octets (16 Mio). Par conséquent, par défaut, les vues matérialisées en streaming Amazon Redshift créées sur un flux de données Kinesis fixent la taille de la colonne de type de données VARBYTE à 1 048 576 octets (1 Mo), et les vues matérialisées en streaming Amazon Redshift créées sur une rubrique Amazon MSK fixent la taille de la colonne de données VARBYTE à 16 777 216 octets (16 Mio). Pour plus d’informations sur les limites de taille Kinesis, consultez Quotas et limites dans le Guide du développeur Amazon Kinesis Data Streams. |
| 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 de l’ajouter à la définition de votre vue matérialisée. |
| Connectivité privée multi-VPC Amazon MSK | La connectivité privée multi-VPC Amazon MSK n’est actuellement pas prise en charge pour l’ingestion en streaming Redshift. Vous pouvez également utiliser le peering VPC 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 cluster Amazon MSK ou avec Amazon MSK sans serveur 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 |
| Ingestion en streaming et Amazon Redshift sans serveur | Les instructions d’installation et de configuration qui s’appliquent à l’ingestion en streaming Amazon Redshift sur un cluster alloué s’appliquent également à l’ingestion en streaming sur Amazon Redshift sans serveur. 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 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 d’agent Amazon MSK dans la même zone de disponibilité que votre cluster ou groupe de travail Redshift alloué. |
| Emplacement de départ de l’actualisation | Après avoir créé une vue matérialisée, son actualisation initiale commence à partir du |
| Formats de données | Les formats de données pris en charge sont limités à ceux pouvant être convertis depuis |
| Ajouter des enregistrements à une table | Vous pouvez exécuter Les opérations
|
| Exécution de TRUNCATE ou DELETE | Vous pouvez supprimer des enregistrements d’une vue matérialisée utilisée pour l’ingestion en streaming à l’aide des méthodes suivantes :
Les opérations
|
| Identifiants non minuscules | Lorsque vous créez des vues matérialisées en streaming sur des rubriques Amazon Managed Streaming pour Apache Kafka ou Kinesis Data Streams contenant des identifiants autres que des minuscules, les actualisations automatiques peuvent échouer. Pour résoudre ce problème, procédez de l’une des manières suivantes :
NoteLa définition de Pour plus d’informations sur les identifiants sensibles à la casse, consultez enable_case_sensitive_identifier. |
| Idempotenciité |
Amazon Redshift garantit que chaque enregistrement est traité exactement une seule fois lors de l’ingestion de données provenant de sources de streaming. Cette garantie s’applique à deux types de sources : Amazon Kinesis (utilisant des identifiants de flux, de partition et de numéro de séquence) et Apache Kafka (utilisant des identifiants de rubrique, de partition et de décalage), y compris Amazon Managed Streaming pour Apache Kafka (Amazon MSK) et Confluent Cloud. |
