Considérations relatives au moment d’utiliser les intégrations zéro ETL avec Amazon Redshift

Votre entrepôt des données Amazon Redshift cible doit répondre aux conditions préalables suivantes :

Si vous supprimez une source d’intégration autorisée pour un entrepôt des données Amazon Redshift, toutes les intégrations associées passeront à l’état FAILED. Toutes les données précédemment répliquées restent dans votre base de données Amazon Redshift et peuvent être consultées.

La base de données de destination est en lecture seule. Vous ne pouvez pas créer de tables, de vues ni de vues matérialisées dans la base de données de destination. Toutefois, vous pouvez utiliser des vues matérialisées sur d’autres tables dans l’entrepôt des données cible.

Les vues matérialisées sont prises en charge lorsqu’elles sont utilisées dans des requêtes entre bases de données. Pour en savoir plus sur la création de vues matérialisées avec des données répliquées via des intégrations zéro ETL, consultez Interrogation de données répliquées avec des vues matérialisées.

Par défaut, vous pouvez interroger les tables uniquement dans l’entrepôt des données cible qui se trouvent dans l’état Synced. Pour interroger des tables dans un autre état, définissez le paramètre de base de données QUERY_ALL_STATES sur TRUE. Pour plus d’informations sur la définition de QUERY_ALL_STATES, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur Amazon Redshift. Pour plus d’informations sur l’état de votre base de données, consultez SVV_INTEGRATION_TABLE_STATE dans le Guide du développeur de base de données Amazon Redshift.

Amazon Redshift n’acceptant que les caractères UTF-8, il est possible qu’il ne respecte pas le classement défini dans votre source. Les règles de tri et de comparaison peuvent être différentes, ce qui peut finalement modifier les résultats de la requête.

Les intégrations zéro ETL sont limitées à 50 intégrations par entrepôt de données Amazon Redshift cible.

Les tables de la source d’intégration doivent posséder une clé primaire. Sinon, vos tables ne peuvent pas être répliquées vers l’entrepôt de données cible dans Amazon Redshift.

Pour plus d’informations sur la façon d’ajouter une clé primaire à Amazon Aurora PostgreSQL, consultez Gestion des tables sans clés primaires lors de la création d’intégrations zéro ETL Amazon Aurora PostgreSQL avec Amazon Redshift sur le Blog de base de données AWS. Pour plus d’informations sur la façon d’ajouter une clé primaire à Amazon Aurora MySQL ou RDS for MySQL, consultez Gestion des tables sans clés primaires lors de la création d’intégrations zéro ETL Amazon Aurora MySQL ou Amazon RDS for MySQL avec Amazon Redshift sur le Blog de base de données AWS.

Vous pouvez utiliser le filtrage des données pour les intégrations zéro ETL Aurora afin de définir l’étendue de la réplication entre le cluster de base de données Aurora source et l’entrepôt de données Amazon Redshift cible. Plutôt que de répliquer toutes les données vers la cible, vous pouvez définir un ou plusieurs filtres qui incluent ou excluent de manière sélective certaines tables de la réplication. Pour plus d’informations, consultez Filtrage des données pour les intégrations zéro ETL Aurora avec Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.

Pour les intégrations zéro ETL Aurora PostgreSQL avec Amazon Redshift, Amazon Redshift prend en charge un maximum de 100 bases de données Aurora PostgreSQL. Chaque base de données se réplique de la source vers la cible indépendamment.

L’intégration zéro ETL ne prend pas en charge les transformations lors de la réplication des données des magasins de données transactionnels vers Amazon Redshift. Les données sont répliquées telles quelles à partir de la base de données source. Vous pouvez toutefois appliquer des transformations aux données répliquées dans Amazon Redshift.

L’intégration zéro ETL s’exécute dans Amazon Redshift à l’aide de connexions parallèles. Elle s’exécute en utilisant les informations d’identification de l’utilisateur qui a créé la base de données à partir de l’intégration. Lorsque la requête est exécutée, la mise à l’échelle de la simultanéité n’intervient pas pour ces connexions lors de la synchronisation (écritures). Les lectures de mise à l’échelle de la simultanéité (provenant de clients Amazon Redshift) fonctionnent pour les objets synchronisés.

Vous pouvez définir une intégration zéro ETL afin de contrôler la fréquence de réplication des données dans Amazon Redshift REFRESH_INTERVAL. Pour plus d’informations, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur de base de données Amazon Redshift.

Après avoir créé une base de données Amazon Redshift à partir d’une intégration zéro ETL avec Amazon DynamoDB, l’état de la base de données doit passer de Création à Active. Cela démarre la réplication des données dans les tables DynamoDB source vers les tables Redshift cibles, qui sont créées selon le schéma public de la base de données de destination (ddb_rs_customerprofiles_zetl_db).

Lorsque vous déposez une table sur une source, la table sur la cible n’est pas supprimée, mais son état est changé pour DroppedSource. Vous pouvez supprimer ou renommer la table depuis la base de données Amazon Redshift.

Lorsque vous tronquez une table sur une source, des suppressions sont effectuées sur la table cible. Par exemple, si tous les enregistrements sont tronqués sur la source, les enregistrements correspondants de la colonne cible _record_is_active sont remplacés par false.

Lorsque vous exécutez la commande SQL TRUNCATE sur la table cible, les lignes d’historique actives sont marquées comme inactives avec l’horodatage correspondant.

Lorsqu’une ligne d’un tableau est définie comme inactive, elle peut être supprimée après un court délai (environ 10 minutes). Pour supprimer les lignes inactives, connectez-vous à votre base de données zéro ETL à l’aide de l’éditeur de requête v2 ou d’un autre client SQL.

Vous ne pouvez supprimer des lignes inactives d’un tableau que lorsque le mode historique est activé. Par exemple, une commande SQL similaire à la suivante supprime uniquement les lignes inactives.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

Cela équivaut à une commande SQL similaire à celle-ci.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

Lorsque le mode historique est désactivé pour une table, toutes les données historiques sont enregistrées dans la table nommée avec <schema>.<table-name>_historical_<timestamp> tandis que la table d’origine nommée <schema>.<table-name> est actualisée.

Lorsqu’une table dont le mode historique est activé est exclue de la réplication à l’aide d’un filtre de table, toutes les lignes sont définies comme inactives et leur état est changé pour DroppedSource. Pour plus d’informations sur les filtres de table, consultez Filtrage des données pour les intégrations zéro ETL Aurora avec Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.

Le mode historique ne peut être défini que sur true ou false pour les tables en état Synced.

Les vues matérialisées pour les tables dont le mode historique est activé sont créées sous forme de recalcul complet.

Vous pouvez utiliser le filtrage des données pour les intégrations zéro ETL Aurora et RDSL for MySQL afin de définir l’étendue de la réplication entre le cluster de base de données source et l’entrepôt de données Amazon Redshift cible. Plutôt que de répliquer toutes les données vers la cible, vous pouvez définir un ou plusieurs filtres qui incluent ou excluent de manière sélective certaines tables de la réplication. Pour plus d’informations, consultez Filtrage des données pour les intégrations zéro ETL Aurora avec Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.

Les tables de la source d’intégration doivent posséder une clé primaire. Sinon, vos tables ne peuvent pas être répliquées vers l’entrepôt de données cible dans Amazon Redshift.

Pour plus d’informations sur la façon d’ajouter une clé primaire à Amazon Aurora PostgreSQL, consultez Gestion des tables sans clés primaires lors de la création d’intégrations zéro ETL Amazon Aurora PostgreSQL avec Amazon Redshift sur le Blog de base de données AWS. Pour plus d’informations sur la façon d’ajouter une clé primaire à Amazon Aurora MySQL ou RDS for MySQL, consultez Gestion des tables sans clés primaires lors de la création d’intégrations zéro ETL Amazon Aurora MySQL ou Amazon RDS for MySQL avec Amazon Redshift sur le Blog de base de données AWS.

La longueur maximale d’un type de données Amazon Redshift VARCHAR est de 65 535 octets. Lorsque le contenu de la source ne correspond pas à cette limite, la réplication ne se poursuit pas et la table est mise en état d’échec. Vous pouvez définir le paramètre de base de données TRUNCATECOLUMNS sur TRUE pour tronquer le contenu afin qu’il tienne dans la colonne. Pour plus d’informations sur la définition de TRUNCATECOLUMNS, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur de base de données Amazon Redshift.

Pour plus d’informations sur les différences de type de données entre les sources d’intégration zéro ETL et les bases de données Amazon Redshift, consultez Différences de type de données entre Aurora et Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.

Les noms de table de DynamoDB supérieurs à 127 caractères ne sont pas pris en charge.

Les données issues d’une intégration zéro ETL DynamoDB correspondent à une colonne de type de données SUPER dans Amazon Redshift.

Les noms de colonne de plus de 127 caractères pour la clé de partition ou la clé de tri ne sont pas pris en charge.

Une intégration zéro ETL provenant de DynamoDB ne peut être mappée qu’à une seule base de données Amazon Redshift.

Pour les clés de partition et de tri, la précision et l’échelle maximales sont de (38,18). Les types de données numériques sur DynamoDB offrent une précision maximale allant jusqu’à 38. Amazon Redshift prend également en charge une précision maximale de 38, mais la précision/échelle décimale par défaut sur Amazon Redshift est (38,10). Cela signifie que les valeurs d’échelle peuvent être tronquées.

Pour que l’intégration zéro ETL soit réussie, un attribut individuel (composé du nom+de la valeur) d’un élément DynamoDB ne doit pas dépasser 64 Ko.

Lors de l’activation, l’intégration zéro ETL exporte la table DynamoDB complète pour alimenter la base de données Amazon Redshift. La durée nécessaire à ce processus initial dépend de la taille de la table DynamoDB. L’intégration zéro ETL réplique ensuite de manière incrémentielle les mises à jour de DynamoDB vers Amazon Redshift à l’aide des exportations incrémentielles DynamoDB. Cela signifie que les données DynamoDB répliquées dans Amazon Redshift sont automatiquement mises à jour.

Actuellement, la latence minimale pour l’intégration zéro ETL DynamoDB est de 15 minutes. Vous pouvez l’augmenter encore en définissant un REFRESH_INTERVAL différent de zéro pour une intégration zéro ETL. Pour plus d’informations, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur de base de données Amazon Redshift.

Les noms de table et de colonne provenant de sources d’application de plus de 127 caractères ne sont pas pris en charge.

La longueur maximale d’un type de données Amazon Redshift VARCHAR est de 65 535 octets. Lorsque le contenu de la source ne correspond pas à cette limite, la réplication ne se poursuit pas et la table est mise en état d’échec. Vous pouvez définir le paramètre de base de données TRUNCATECOLUMNS sur TRUE pour tronquer le contenu afin qu’il tienne dans la colonne. Pour plus d’informations sur la définition de TRUNCATECOLUMNS, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur de base de données Amazon Redshift.

Pour plus d’informations sur les différences de type de données entre les sources d’applications d’intégration zéro ETL et les bases de données Amazon Redshift, consultez Intégrations zéro ETL dans le Guide du développeur AWS Glue.

La latence minimale pour une intégration zéro ETL avec les applications est d’une heure. Vous pouvez l’augmenter encore en définissant un REFRESH_INTERVAL différent de zéro pour une intégration zéro ETL. Pour plus d’informations, consultez CREATE DATABASE et ALTER DATABASE dans le Guide du développeur de base de données Amazon Redshift.