Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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. # Chargement de données dans Amazon Redshift Il existe plusieurs méthodes pour charger des données dans une base de données Amazon Redshift. Les fichiers Amazon S3 sont l’une des sources de données les plus populaires à charger. Le tableau suivant rassemble certaines des méthodes à utiliser pour démarrer à partir d’une source Amazon S3. | Méthode à utiliser | Description | Quand une méthode est nécessaire | | --- | --- | --- | | COPY command (Commande COPY) | Exécute une ingestion de fichiers par lots pour charger des données à partir de vos fichiers Amazon S3. Cette méthode tire parti des capacités de traitement parallèle d’Amazon Redshift. Pour plus d’informations, consultez [Chargement de tables à l’aide de la commande COPY](t_Loading_tables_with_the_COPY_command.md). | Doit être utilisé lorsque les exigences de base en matière de chargement de données pour initier manuellement l’ingestion de fichiers par lots sont nécessaires. Cette méthode est principalement utilisée avec des pipelines d’ingestion de fichiers personnalisés et tiers ou des charges de travail d’ingestion de fichiers ponctuelles ou ad hoc. | | COPY... Commande CREATE JOB (copie automatique) | Exécute automatiquement vos commandes COPY lorsqu’un nouveau fichier est créé sur des chemins Amazon S3 suivis. Pour plus d’informations, consultez [Créer une intégration d’événements S3 pour copier automatiquement des fichiers à partir de compartiments Amazon S3](loading-data-copy-job.md). | Doit être utilisé lorsqu’un pipeline d’ingestion de fichiers doit ingérer automatiquement des données lorsqu’un nouveau fichier est créé sur Amazon S3. Amazon Redshift suit les fichiers ingérés pour empêcher la duplication des données. Cette méthode nécessite une configuration par les propriétaires de compartiments Amazon S3. | | Charger des requêtes à partir d’un lac de données | Créez des tables externes pour exécuter des requêtes de lac de données sur vos fichiers Amazon S3, puis exécutez la commande INSERT INTO pour charger les résultats de vos requêtes de lac de données dans des tables locales. Pour plus d’informations, consultez [Tables externes pour Redshift Spectrum](c-spectrum-external-tables.md). | Le changement de mot de passe exécute l’un des scénarios suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/t_Loading_data.html) | | Autres méthodes que vous pouvez envisager | | 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 Redshift sans serveur ou une vue Amazon Redshift allouée. Pour plus d’informations, consultez [Mise en route de l’ingestion en streaming à partir d’Amazon Kinesis Data Streams](materialized-view-streaming-ingestion-getting-started.md) et [Mise en route de l’ingestion en streaming à partir de sources Apache Kafka](materialized-view-streaming-ingestion-getting-started-MSK.md). | À prendre en compte pour les cas d’utilisation où les données sont d’abord diffusées dans des fichiers sur Amazon S3, puis chargées depuis Amazon S3. S’il n’est pas nécessaire de conserver des données sur Amazon S3, vous pouvez souvent envisager de les diffuser directement dans Amazon Redshift. | | Interroger un lac de données | Exécution de requêtes directement à partir d’une table de lac de données au lieu d’ingérer le contenu de la table dans une table locale. Pour plus d’informations, consultez [Amazon Redshift Spectrum](c-using-spectrum.md). | À utiliser lorsque le cas d’utilisation ne nécessite pas les performances des requêtes de table locales dans Amazon Redshift. | | Chargement par lots à l’aide d’Amazon Redshift Query Editor V2 | Vous pouvez préparer et exécuter visuellement vos charges de travail d’ingestion de fichiers par lots à l’aide d’Amazon Redshift Query Editor V2. Pour plus d’informations, consultez [Chargement de données S3](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data) dans le *Guide de gestion Amazon Redshift*. | À utiliser lorsque vous souhaitez que l’éditeur de requêtes v2 prépare des instructions COPY et que vous souhaitez un outil visuel pour simplifier le processus de préparation des instructions COPY. | | Charger des données à partir d’un fichier local à l’aide de Amazon Redshift Query Editor v2 | Vous pouvez charger des fichiers directement depuis votre bureau vers les tables Amazon Redshift sans avoir à les télécharger manuellement dans Amazon S3. Pour plus d’informations, consultez [Chargement de données à partir d’un fichier local : configuration et flux de travail](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data-local) dans le *Guide de gestion Amazon Redshift*. | À utiliser lorsque vous devez charger rapidement des fichiers depuis votre ordinateur local à des fins de requêtes ponctuelles. Avec cette méthode, Amazon Redshift Query Editor V2 stocke temporairement le fichier dans un compartiment Amazon S3 appartenant au client et exécute une commande de copie en utilisant ce chemin Amazon S3. | Une commande COPY est le moyen le plus efficace de charger une table. Vous pouvez également ajouter des données à vos tables à l’aide des commandes INSERT, même si c’est beaucoup moins efficace que l’utilisation de la commande COPY. La commande COPY est capable de lire simultanément plusieurs fichiers de données ou plusieurs flux de données. Amazon Redshift alloue la charge de travail aux nœuds Amazon Redshift et effectue les opérations de chargement en parallèle, y compris le tri des lignes et la distribution des données entre les tranches de nœud. **Note** Les tables externes d’Amazon Redshift Spectrum sont en lecture seule. Vous ne pouvez pas copier (COPY) ni insérer (INSERT) dans une table externe. Pour accéder aux données d'autres AWS ressources, Amazon Redshift doit être autorisé à accéder à ces ressources et à effectuer les actions nécessaires pour accéder aux données. Vous pouvez utiliser Gestion des identités et des accès AWS (IAM) pour limiter l'accès des utilisateurs aux ressources et aux données Amazon Redshift. Une fois vos données initiales chargées, si vous ajoutez, modifiez ou supprimez une quantité importante de données, vous devez poursuivre en exécutant une commande VACUUM pour réorganiser vos données et récupérer de l’espace après les suppressions. Vous devez également exécuter une commande ANALYZE pour mettre à jour les statistiques des tables. **Topics** + [Chargement de tables à l’aide de la commande COPY](t_Loading_tables_with_the_COPY_command.md) + [Créer une intégration d’événements S3 pour copier automatiquement des fichiers à partir de compartiments Amazon S3](loading-data-copy-job.md) + [Chargement de tables avec les commandes DML](t_Updating_tables_with_DML_commands.md) + [Exécution d’une copie complète](performing-a-deep-copy.md) + [Analyse des tables](t_Analyzing_tables.md) + [Exécution de l’opération VACUUM sur les tables](t_Reclaiming_storage_space202.md) + [Gestion des opérations d’écriture simultanées](c_Concurrent_writes.md) + [Didacticiel : chargement des données à partir d’Amazon S3](tutorial-loading-data.md) # Chargement de tables à l’aide de la commande COPY La commande COPY s’appuie sur l’architecture Amazon Redshift du traitement hautement parallèle (MPP) pour lire et charger les données en parallèle à partir de fichiers sur Amazon S3, d’une table DynamoDB ou de la sortie de texte d’un ou de plusieurs hôtes distants. Avant de connaître toutes les options de la commande COPY, nous vous recommandons de connaître les options de base pour charger les données Amazon S3. Le *Guide de démarrage Amazon Redshift* montre une utilisation simple de la commande COPY pour charger des données Amazon S3 à l’aide d’un rôle IAM par défaut. Consultez [Étape 4 : Charger les données d’Amazon S3 vers Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) pour plus de détails. **Note** Nous vous recommandons vivement d’utiliser la commande COPY pour charger de grandes quantités de données. La lenteur liée à l’utilisation d’instructions INSERT pour remplir une table peut être prohibitive. Sinon, si vos données existent déjà dans d’autres tables de bases de données Amazon Redshift, utilisez INSERT INTO ... SELECT ou CREATE TABLE AS pour améliorer les performances. Pour plus d’informations, consultez [INSERT](r_INSERT_30.md) ou [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Pour charger des données depuis une autre AWS ressource, Amazon Redshift doit être autorisé à accéder à la ressource et à effectuer les actions nécessaires. Pour accorder ou révoquer le privilège de charger les données dans une table à l’aide d’une commande COPY, accordez ou révoquez le privilège INSERT. Vos données doivent être au format approprié pour le chargement dans votre table Amazon Redshift. Cette section présente les directives de préparation et de vérification de vos données avant le chargement, et de validation d’une instruction COPY avant son exécution. Pour protéger les informations contenues dans vos fichiers, vous pouvez chiffrer les fichiers de données avant de les charger sur votre compartiment Amazon S3 ; la commande COPY déchiffre les données pendant le chargement. Vous pouvez aussi limiter l’accès à vos données de chargement en fournissant des informations d’identification de sécurité temporaires aux utilisateurs. Les informations d’identification de sécurité temporaires offrent une sécurité améliorée parce qu’elles sont de courte durée et ne peuvent pas être réutilisées après leur expiration. Amazon Redshift dispose de fonctions intégrées à COPY pour charger rapidement des données délimitées et non compressées. Vous pouvez toutefois compresser vos fichiers à l’aide de gzip, lzop ou bzip2 pour gagner du temps lors du téléchargement des fichiers. Si les mots clés suivants figurent dans la requête COPY, le fractionnement automatique des données non compressées n’est pas pris en charge : ESCAPE, REMOVEQUOTES et FIXEDWIDTH. Mais le mot-clé CSV est pris en charge. Pour garantir la sécurité de vos données en transit dans le AWS cloud, Amazon Redshift utilise le protocole SSL à accélération matérielle pour communiquer avec Amazon S3 ou Amazon DynamoDB pour les opérations de copie, de déchargement, de sauvegarde et de restauration. Lorsque vous chargez directement votre table depuis une table Amazon DynamoDB, vous avez la possibilité de contrôler la quantité de débit alloué Amazon DynamoDB que vous consommez. Vous pouvez, le cas échéant, laisser la commande COPY analyser vos données d’entrée et appliquer automatiquement les encodages de compression optimale à votre table dans le cadre du processus de chargement. **Topics** + [Informations d’identification et autorisations d’accès](loading-data-access-permissions.md) + [Préparation de vos données d’entrée](t_preparing-input-data.md) + [Chargement des données à partir d’Amazon S3](t_Loading-data-from-S3.md) + [Chargement de données à partir d’Amazon EMR](loading-data-from-emr.md) + [Chargement des données à partir des hôtes distants](loading-data-from-remote-hosts.md) + [Chargement de données à partir d’une table Amazon DynamoDB](t_Loading-data-from-dynamodb.md) + [Vérification que les données ont été chargées correctement](verifying-that-data-loaded-correctly.md) + [Validation des données d’entrée](t_Validating_input_files.md) + [Chargement des tables avec compression automatique](c_Loading_tables_auto_compress.md) + [Optimisation de stockage pour les tables étroites](c_load_compression_hidden_cols.md) + [Chargement des valeurs par défaut des colonnes](c_loading_default_values.md) + [Résolution des problèmes de chargement de données](t_Troubleshooting_load_errors.md) # Informations d’identification et autorisations d’accès Pour charger ou décharger des données à l'aide d'une autre AWS ressource, telle qu'Amazon S3, Amazon DynamoDB, Amazon EMR ou Amazon EC2, Amazon Redshift doit être autorisé à accéder à la ressource et à effectuer les actions nécessaires pour accéder aux données. Par exemple, pour charger des données depuis Amazon S3, la commande COPY doit disposer de l’accès LIST au compartiment et de l’accès GET pour les objets du compartiment. Pour obtenir l’autorisation d’accéder à une ressource, Amazon Redshift doit être authentifié. Vous pouvez choisir le contrôle d’accès basé sur les rôles ou le contrôle d’accès basé sur les clés. Cette section présente une vue d’ensemble des deux méthodes. Pour obtenir des détails et des exemples, consultez [Autorisations d'accès à d'autres AWS ressources](copy-usage_notes-access-permissions.md). ## Contrôle d’accès basé sur les rôles Avec un contrôle d’accès basé sur les rôles, Amazon Redshift assume temporairement un rôle Gestion des identités et des accès AWS (IAM) en votre nom. Ensuite, en fonction des autorisations accordées au rôle, Amazon Redshift peut accéder aux AWS ressources requises. Nous vous recommandons d'utiliser le contrôle d'accès basé sur les rôles, car il permet un contrôle plus sûr et plus précis de l'accès aux AWS ressources et aux données utilisateur sensibles, en plus de protéger vos informations d'identification. AWS Pour utiliser le contrôle d’accès basé sur les rôles, vous devez d’abord créer un rôle IAM à l’aide du type de rôle de service Amazon Redshift, puis attacher le rôle à votre entrepôt de données. Le rôle doit avoir, au minimum, les autorisations répertoriées dans [Autorisations IAM pour les commandes COPY, UNLOAD et CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Pour savoir comment créer un rôle IAM et l'associer à votre cluster, consultez la section [Création d'un rôle IAM pour autoriser votre cluster Amazon Redshift à AWS accéder aux](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html#authorizing-redshift-service-creating-an-iam-role) services dans le guide de gestion Amazon *Redshift*. Vous pouvez ajouter un rôle à un cluster ou afficher les rôles associés à un cluster à l’aide de la console de gestion, de la CLI ou de l’API Amazon Redshift. Pour plus d’informations, consultez [Authorizing COPY and UNLOAD Operations Using IAM Roles](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role.html) dans le *Guide de gestion Amazon Redshift*. Lorsque vous créez un rôle IAM, IAM renvoie un Amazon Resource Name (ARN) pour le rôle. Pour exécuter une commande COPY à l’aide d’un rôle IAM, fournissez le rôle ARN à l’aide des paramètres IAM\$1ROLE ou CREDENTIALS. L’exemple suivant de commande COPY utilise le paramètre IAM\$1ROLE avec le rôle `MyRedshiftRole` pour l’authentification. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::12345678901:role/MyRedshiftRole'; ``` L' AWS utilisateur doit disposer, au minimum, des autorisations répertoriées dans[Autorisations IAM pour les commandes COPY, UNLOAD et CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). ## Contrôle d’accès basé sur les clés Avec le contrôle d'accès basé sur les clés, vous fournissez l'ID de clé d'accès et la clé d'accès secrète à un utilisateur autorisé à accéder aux AWS ressources contenant les données.  **Note** Nous vous recommandons vivement d’utiliser un rôle IAM pour l’authentification au lieu de fournir une clé d’accès secrète et un ID de clé d’accès en texte brut. Si vous optez pour le contrôle d'accès par clé, n'utilisez jamais les informations d'identification de votre AWS compte (root). Créez toujours un utilisateur IAM et fournissez l’ID de clé d’accès et la clé d’accès secrète de cet utilisateur. Pour connaître les étapes à suivre pour créer un utilisateur IAM, consultez [Création d’un utilisateur IAM dans votre compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). # Préparation de vos données d’entrée Si vos données d’entrée ne sont pas compatibles avec les Colonnes de la table qui les recevront, la commande COPY échoue. Utilisez les instructions suivantes pour vous assurer que vos données d’entrée sont valides : + Vos données peuvent contenir uniquement des caractères UTF-8 de quatre octets au plus. + Vérifiez que les chaînes CHAR et VARCHAR ne sont pas plus longues que les colonnes correspondantes. Comme les chaînes VARCHAR sont mesurées en octets, pas en caractères, une chaîne de quatre caractères chinois qui occupent quatre octets chacun nécessite une colonne VARCHAR(16), par exemple. + Les caractères multioctets ne peuvent être utilisés qu’avec les colonnes VARCHAR. Vérifiez que les caractères multioctets ne dépassent pas quatre octets. + Vérifiez que les données des colonnes CHAR ne contiennent que des caractères codés sur un octet. + N’incluez pas de caractères spéciaux ou de syntaxe particulière pour indiquer le dernier champ d’un enregistrement. Ce champ peut être un délimiteur. + Si vos données incluent des terminaisons null, également appelées NUL (UTF-8 0000) ou zéro binaire (0x000), vous pouvez charger ces caractères en tant que valeurs NULL dans des colonnes CHAR ou VARCHAR en utilisant l’option NULL AS dans la commande COPY : `null as '\0'` ou `null as '\000'`. Si vous n’utilisez pas NULL AS, les terminaisons null entraînent l’échec de la commande COPY. + Si vos chaînes contiennent des caractères spéciaux, tels que des délimiteurs et des sauts de ligne imbriqués, utilisez l’option ESCAPE avec la commande [COPY](r_COPY.md). + Vérifiez que tous les guillemets simples et doubles correspondent de manière appropriée. + Vérifiez que les chaînes à virgule flottante sont dans un format à virgule flottante standard, tel que 12,123, ou dans un format d’élévation à la puissance, tel que 1,0E4. + Vérifiez que toutes les chaînes de type timestamp et date suivent les spécifications de [Chaînes DATEFORMAT et TIMEFORMATExemple](r_DATEFORMAT_and_TIMEFORMAT_strings.md). Le format d'horodatage par défaut est YYYY-MM-DD hh:mm:ss, et le format de date par défaut est. YYYY-MM-DD + Pour plus d’informations sur les limites et limitations des types de données individuels, consultez [Types de données](c_Supported_data_types.md). Pour plus d’informations sur les erreurs de caractères multioctets, consultez [Erreurs de chargement de caractères multioctets](multi-byte-character-load-errors.md) # Chargement des données à partir d’Amazon S3 La commande COPY s’appuie sur l’architecture Amazon Redshift du traitement hautement parallèle (MPP) pour lire et charger les données en parallèle à partir d’un ou de plusieurs fichiers d’un compartiment Amazon S3. Vous pouvez tirer le meilleur parti du traitement parallèle en fractionnant vos données en plusieurs fichiers, dans les cas où les fichiers sont compressés. (Il existe des exceptions à cette règle, qui sont détaillées dans la section [Chargement de fichiers de données](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-use-multiple-files.html).) Vous pouvez aussi profiter au maximum du traitement parallèle en définissant les clés de distribution de vos tables. Pour plus d’informations sur les clés de distribution, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md). Les données sont chargées dans la table cible, une ligne par ligne. Les champs du fichier de données sont mis en correspondance avec les colonnes de la table dans l’ordre, de gauche à droite. Les champs des fichiers de données peuvent être à largeur fixe ou délimités par un caractère ; le délimiteur par défaut est une barre verticale (\$1). Par défaut, toutes les colonnes de la table sont chargées, mais vous pouvez, le cas échéant, définir une liste de colonnes séparées par des virgules. Si une colonne de table n’est pas incluse dans la liste des colonnes spécifiée dans la commande COPY, elle est chargée avec une valeur par défaut. Pour plus d'informations, consultez [Chargement des valeurs par défaut des colonnes](c_loading_default_values.md). **Topics** + [Chargement de données à partir de fichiers compressés et non compressés](t_splitting-data-files.md) + [Chargement de fichiers sur Amazon S3 à utiliser avec COPY](t_uploading-data-to-S3.md) + [Utilisation de la commande COPY pour charger à partir d’Amazon S3](t_loading-tables-from-s3.md) # Chargement de données à partir de fichiers compressés et non compressés Lorsque vous chargez des données compressées, nous vous recommandons de fractionner les données de chaque table en plusieurs fichiers. Lorsque vous chargez des données délimitées et non compressées, la commande COPY utilise des plages de traitement massivement parallèle (MPP) et d’analyse pour charger des données à partir de fichiers volumineux dans un compartiment Amazon S3. ## Chargement de données à partir de plusieurs fichiers compressés Dans les cas où vous avez des données compressées, nous vous recommandons de fractionner les données de chaque table en plusieurs fichiers. La commande COPY peut charger les données à partir de plusieurs fichiers en parallèle. Vous pouvez charger plusieurs fichiers en spécifiant un préfixe commun, ou *clé de préfixe*, pour l’ensemble, ou en indiquant explicitement les fichiers dans un fichier manifeste. Scindez vos données en fichiers de telle sorte que le nombre de fichiers soit un multiple du nombre de tranches de votre cluster. De cette façon, Amazon Redshift peut diviser également les données entre les tranches. Le nombre de tranches par nœud dépend de la taille de nœud du cluster. Par exemple, chaque nœud de calcul dc2.large a deux tranches, tandis que chaque nœud de calcul dc2.8xlarge a 16 tranches. Pour plus d’informations sur le nombre de tranches pour chaque taille de nœud, consultez la rubrique [À propos des clusters et nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) dans le *Guide de gestion Amazon Redshift*. Les nœuds participent tous à l’exécution de requêtes parallèles, en travaillant sur des données réparties aussi uniformément que possible sur les tranches. Si vous avez un cluster avec deux nœuds dc2.large, vous pouvez scinder vos données en quatre fichiers (ou un multiple de quatre). Amazon Redshift ne prend pas en compte la taille des fichiers lors de la répartition de la charge de travail. Par conséquent, vous devez vous assurer que les fichiers ont à peu près la même taille, de 1 Mo à 1 Go après compression. Pour utiliser des préfixes d’objet pour identifier les fichiers du chargement, nommez chaque fichier avec un préfixe commun. Par exemple, le fichier `venue.txt` peut être fractionné en quatre fichiers, comme suit : ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` Si vous placez plusieurs fichiers dans un dossier de votre compartiment et spécifiez le nom du dossier comme préfixe, la commande COPY charge tous les fichiers dans le dossier. Si vous listez explicitement les fichiers à charger à l’aide d’un fichier manifeste, les fichiers peuvent résider dans différents compartiments ou dossiers. Pour plus d’informations sur les fichiers manifeste, consultez [Utilisation d’un manifeste pour spécifier les fichiers de données](r_COPY_command_examples.md#copy-command-examples-manifest). ## Chargement de données à partir de fichiers délimités non compressés Lorsque vous chargez des données non compressées et délimitées, la commande COPY utilise l’architecture de traitement massivement parallèle (MPP) dans Amazon Redshift. Amazon Redshift utilise automatiquement des tranches fonctionnant en parallèle avec des plages de chargement de données provenant d’un fichier volumineux dans un compartiment Amazon S3. Le fichier doit être délimité pour que le chargement en parallèle ait lieu. Par exemple, délimitation de canaux. Le chargement automatique et parallèle des données avec la commande COPY est également disponible pour les fichiers CSV. Vous pouvez également profiter du traitement parallèle en définissant les clés de distribution de vos tables. Pour plus d’informations sur les clés de distribution, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md). Le chargement parallèle des données n’est pas pris en charge lorsque la requête COPY inclut l’un des mots clés suivants : ESCAPE, REMOVEQUOTES et FIXEDWIDTH. Les données du ou des fichiers sont chargées dans la table cible, une ligne par ligne. Les champs du fichier de données sont mis en correspondance avec les colonnes de la table dans l’ordre, de gauche à droite. Les champs des fichiers de données peuvent être à largeur fixe ou délimités par un caractère ; le délimiteur par défaut est une barre verticale (\$1). Par défaut, toutes les colonnes de la table sont chargées, mais vous pouvez, le cas échéant, définir une liste de colonnes séparées par des virgules. Si une colonne de table n’est pas incluse dans la liste des colonnes spécifiée dans la commande COPY, elle est chargée avec une valeur par défaut. Pour plus d'informations, consultez [Chargement des valeurs par défaut des colonnes](c_loading_default_values.md). Suivez ce processus général pour charger les données depuis Amazon S3, lorsque vos données sont décompressées et délimitées : 1. Chargez vos fichiers sur Amazon S3. 1. Exécutez une commande COPY pour charger la table. 1. Vérifiez que les données ont été chargées correctement. Pour obtenir des exemples de commandes COPY, consultez [Exemples de commandes COPY](r_COPY_command_examples.md). Pour plus d’informations sur les données chargées dans Amazon Redshift, consultez les tables système [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) et [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md). Pour plus d’informations sur les nœuds et les tranches qu’ils contiennent, consultez [À propos des clusters et nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) dans le *Guide de gestion Amazon Redshift*. # Chargement de fichiers sur Amazon S3 à utiliser avec COPY Il existe quelques approches à adopter lors du chargement de fichiers texte sur Amazon S3 : + Si vous avez des fichiers compressés, nous vous recommandons de fractionner les fichiers volumineux pour tirer parti du traitement parallèle dans Amazon Redshift. + D’autre part, COPY divise automatiquement les données de fichiers volumineux, non compressés et délimités par des textes, afin de faciliter le parallélisme et de distribuer efficacement les données de fichiers volumineux. Créez un compartiment Amazon S3 pour contenir vos fichiers de données, puis chargez les fichiers de données dans le compartiment. Pour plus d’informations sur la création de compartiments et le chargement de fichiers, consultez [Working with Amazon S3 Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. **Important** Le compartiment Amazon S3 qui contient les fichiers de données doit être créé dans la même région AWS que votre cluster, sauf si vous utilisez l’option [REGION](copy-parameters-data-source-s3.md#copy-region) pour spécifier la région dans laquelle se trouve le compartiment Amazon S3. Vérifiez que les plages d’adresses IP S3 sont ajoutées à votre liste d’autorisations. Pour plus d’informations sur les plages d’adresses IP S3 requises, consultez [Isolement de réseau](https://docs.aws.amazon.com//redshift/latest/mgmt/security-network-isolation.html#network-isolation). Vous pouvez créer un compartiment Amazon S3 dans une région spécifique en sélectionnant la région lorsque vous créez le compartiment à l’aide de la console Amazon S3 ou en spécifiant un point de terminaison lorsque vous créez le compartiment à l’aide de l’API ou de la CLI Amazon S3. Après le chargement des données, vérifiez que les fichiers appropriés sont présents sur Amazon S3. **Topics** + [Gestion de la cohérence des données](managing-data-consistency.md) + [Chargement de données chiffrées sur Amazon S3](t_uploading-encrypted-data.md) + [Vérification de la présence des fichiers corrects dans votre compartiment](verifying-that-correct-files-are-present.md) # Gestion de la cohérence des données Amazon S3 assure une forte read-after-write cohérence pour les opérations COPY, UNLOAD, INSERT (table externe), CREATE EXTERNAL TABLE AS et Amazon Redshift Spectrum sur les compartiments Amazon S3 dans toutes les régions. AWS En outre, les opérations de lecture sur Amazon S3 Select, les listes de contrôle d’accès Amazon S3, les balises d’objet Amazon S3 et les métadonnées d’objet (par exemple, l’objet HEAD) sont fortement cohérentes. Pour plus d’informations sur la cohérence des données, consultez [Modèle de cohérence des données Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Introduction.html#ConsistencyModel) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. # Chargement de données chiffrées sur Amazon S3 Amazon S3 prend en charge le chiffrement côté serveur et le chiffrement côté client. Cette rubrique présente les différences entre le chiffrement côté serveur et le chiffrement côté client, et décrit les étapes pour utiliser le chiffrement côté client avec Amazon Redshift. Le chiffrement côté serveur est transparent à Amazon Redshift. ## Chiffrement côté serveur Le chiffrement côté serveur est le chiffrement des données au repos : autrement dit, Amazon S3 chiffre vos données au fur et à mesure qu’il les charge et les déchiffre automatiquement lorsque vous y accédez. Lorsque vous chargez les tables à l’aide d’une commande COPY, il n’existe aucune différence dans la façon dont vous chargez à partir d’objets non chiffrés ou d’objets chiffrés côté serveur sur Amazon S3. Pour plus d’informations sur le chiffrement côté serveur, consultez [Using Server-Side Encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. ## Chiffrement côté client Dans le chiffrement côté client, votre application cliente gère le chiffrement de vos données, les clés de chiffrement et les outils associés. Vous pouvez charger les données sur un compartiment Amazon S3 à l’aide d’un chiffrement côté client, puis chargez les données à l’aide de la commande COPY avec l’option ENCRYPTED et une clé de chiffrement privée pour renforcer la sécurité. Vous chiffrez vos données à l’aide du chiffrement d’enveloppe. Avec le *chiffrement d’enveloppe*, votre application gère tout le chiffrement exclusivement. Vos clés de chiffrement privées et vos données non chiffrées ne sont jamais envoyées à AWS. Il est donc très important que vous gériez vos clés de chiffrement en toute sécurité. Si vous perdez vos clés de chiffrement, vous ne pourrez pas déchiffrer vos données et vous ne pourrez pas récupérer vos clés de chiffrement. AWS Le chiffrement d’enveloppe combine les performances du chiffrement symétrique rapide tout en assurant la plus grande sécurité que la gestion des clés avec des clés asymétriques fournit. Une clé one-time-use symétrique (la clé symétrique d'enveloppe) est générée par votre client de chiffrement Amazon S3 pour chiffrer vos données, puis cette clé est chiffrée par votre clé racine et stockée avec vos données dans Amazon S3. Quand Amazon Redshift accède à vos données pendant un chargement, la clé symétrique chiffrée est récupérée et déchiffrée avec votre clé réelle, puis les données sont déchiffrées. Pour utiliser les données chiffrées côté client Amazon S3 dans Amazon Redshift, suivez les étapes présentées dans la section [Protection des données à l’aide du chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service* avec les conditions requises supplémentaires que vous utilisez : + **Chiffrement symétrique** : le kit SDK AWS pour la classe Java `AmazonS3EncryptionClient` utilise le chiffrement d’enveloppe, décrit précédemment, qui repose sur le chiffrement à clé symétrique. Utilisez cette classe pour créer un client Amazon S3 et charger les données chiffrées côté client. + **Clé symétrique racine AES 256 bits :** une clé racine chiffre la clé d’enveloppe. Vous passez la clé racine à votre instance de la classe `AmazonS3EncryptionClient`. Enregistrez cette clé, car vous en aurez besoin pour copier les données dans Amazon Redshift. + **Métadonnées objet pour stocker la clé d’enveloppe chiffrée :** par défaut, Amazon S3 stocke la clé d’enveloppe comme métadonnées objet pour la classe `AmazonS3EncryptionClient`. La clé d’enveloppe chiffrée qui est stockée sous forme de métadonnées objet est utilisée pendant le processus de déchiffrement. **Note** Si vous recevez un message d’erreur de chiffrement lorsque vous utilisez l’API de chiffrement pour la première fois, il se peut que votre version JDK possède un fichier de politique de juridiction Java Cryptography Extension (JCE) qui limite la longueur maximale de la clé pour les transformations de chiffrement et de déchiffrement vers 128 bits. Pour plus d'informations sur la résolution de ce problème, consultez la section [Spécification du chiffrement côté client à l'aide du AWS SDK pour Java dans le guide de l'utilisateur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryptionUpload.html) d'*Amazon Simple Storage Service*. Pour plus d’informations sur le chargement de fichiers chiffrés côté client dans vos tables Amazon Redshift à l’aide de la commande COPY, consultez [Chargement de fichiers de données chiffrés à partir d’Amazon S3](c_loading-encrypted-files.md). ## Exemple : Chargement des données chiffrées côté client Pour un exemple d'utilisation du AWS SDK pour Java afin de télécharger des données chiffrées côté client, consultez la section [Protection des données à l'aide du chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/encrypt-client-side-symmetric-master-key.html) dans *le guide de l'utilisateur d'Amazon* Simple Storage Service. La seconde option montre les choix que vous devez faire pendant le chiffrement côté client afin que les données puissent être chargées dans Amazon Redshift. Plus précisément, l’exemple montre l’utilisation de métadonnées objet pour stocker la clé enveloppe chiffrée et l’utilisation d’une clé symétrique racine AES 256 bits. Cet exemple fournit un exemple de code utilisant le AWS SDK for Java pour créer une clé racine symétrique AES 256 bits et l'enregistrer dans un fichier. L’exemple charge ensuite un objet sur Amazon S3 à l’aide du client de chiffrement S3 qui chiffre d’abord des exemples de données côté client. Cet exemple télécharge également l’objet et vérifie que les données sont identiques. # Vérification de la présence des fichiers corrects dans votre compartiment Une fois que vous avez chargé vos fichiers sur votre compartiment Amazon S3, nous vous recommandons d’afficher le contenu du compartiment pour vérifier que tous les fichiers appropriés sont présents et qu’aucun fichier indésirable ne s’y trouve. Par exemple, si le compartiment `amzn-s3-demo-bucket` contient un fichier nommé `venue.txt.back`, ce fichier est chargé, peut-être involontairement, par la commande suivante : ``` COPY venue FROM 's3://amzn-s3-demo-bucket/venue' … ; ``` Si vous souhaitez contrôler plus précisément quels fichiers sont chargés, vous pouvez utiliser un fichier manifeste pour répertorier explicitement les fichiers de données. Pour plus d’informations sur l’utilisation d’un fichier manifeste, consultez l’option [copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file) de la commande COPY et [Utilisation d’un manifeste pour spécifier les fichiers de données](r_COPY_command_examples.md#copy-command-examples-manifest) dans les exemples de COPY. Pour plus d’informations sur l’affichage du contenu du compartiment, consultez [Affichage des clés d’objet](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ListingKeysUsingAPIs.html) dans le *Guide du développeur Amazon S3*. # Utilisation de la commande COPY pour charger à partir d’Amazon S3 Utilisez la commande [COPY](r_COPY.md) pour charger une table en parallèle à partir de fichiers de données sur Amazon S3. Vous pouvez spécifier les fichiers à charger en utilisant un préfixe d’objet Amazon S3 ou un fichier manifeste. La syntaxe pour spécifier les fichiers à charger en utilisant un préfixe est la suivante : ``` COPY FROM 's3:///' authorization; ``` Le fichier manifeste est un fichier au format JSON qui répertorie les fichiers de données à charger. La syntaxe pour spécifier les fichiers à charger en utilisant un fichier manifeste est la suivante : ``` COPY FROM 's3:///' authorization MANIFEST; ``` La table à charger doit déjà exister dans la base de données. Pour plus d’informations sur la création d’une table, consultez [CREATE TABLE](r_CREATE_TABLE_NEW.md) dans la référence SQL. Les valeurs d'*autorisation* fournissent l' AWS autorisation dont Amazon Redshift a besoin pour accéder aux objets Amazon S3. Pour plus d’informations sur les autorisations requises, consultez [Autorisations IAM pour les commandes COPY, UNLOAD et CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). La méthode d’authentification recommandée est celle qui consiste à spécifier le paramètre IAM\$1ROLE et à fournir l’Amazon Resource Name (ARN) d’un rôle IAM avec les autorisations nécessaires. Pour plus d’informations, consultez [Contrôle d’accès basé sur les rôles](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based). Pour vous authentifier à l'aide du paramètre IAM\$1ROLE, remplacez ** et ** comme indiqué dans la syntaxe suivante. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` L’authentification à l’aide d’un rôle IAM est présentée dans l’exemple suivant. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Pour plus d’informations sur d’autres options d’autorisation, consultez [Paramètres d’autorisation](copy-parameters-authorization.md) Si vous voulez valider vos données sans charger le tableau, utilisez l’option NOLOAD avec la commande [COPY](r_COPY.md). L’exemple suivant montre les toutes premières lignes des données, délimitées par une barre verticale, d’un fichier nommé `venue.txt`. ``` 1|Toyota Park|Bridgeview|IL|0 2|Columbus Crew Stadium|Columbus|OH|0 3|RFK Stadium|Washington|DC|0 ``` Avant le chargement du fichier sur Amazon S3, fractionnez le fichier en plusieurs fichiers, afin que la commande COPY puisse le charger à l’aide du traitement parallèle. Le nombre de fichiers doit être un multiple du nombre de tranches de votre cluster. Fractionnez vos fichiers de données de chargement de telle sorte que les fichiers soient à peu près de taille égale, entre 1 Mo et 1 Go après compression. Pour plus d'informations, consultez [Chargement de données à partir de fichiers compressés et non compressés](t_splitting-data-files.md). Par exemple, le fichier `venue.txt` peut être fractionné en quatre fichiers, comme suit : ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` La commande COPY suivante charge la table VENUE à l’aide des données délimitées par une barre verticale des fichiers de données avec le préfixe ’venue’ dans le compartiment Amazon S3 `amzn-s3-demo-bucket`. **Note** Le compartiment Amazon S3 `amzn-s3-demo-bucket` des exemples suivants n’existe pas. Pour des exemples de commandes COPY qui utilisent les données réelles d’un compartiment Amazon S3 existant, consultez [Chargement des exemples de données](https://docs.aws.amazon.com/redshift/latest/gsg/cm-dev-t-load-sample-data.html). ``` COPY venue FROM 's3://amzn-s3-demo-bucket/venue' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|'; ``` Si aucun objet Amazon S3 avec le préfixe de clé ’venue’ n’existe, le chargement échoue. **Topics** + [Utilisation d’un manifeste pour spécifier les fichiers de données](loading-data-files-using-manifest.md) + [Chargement des fichiers de données compressés à partir d’Amazon S3](t_loading-gzip-compressed-data-files-from-S3.md) + [Chargement de données de largeur fixe à partir d’Amazon S3](t_loading_fixed_width_data.md) + [Chargement de données multioctets à partir d'Amazon S3](t_loading_unicode_data.md) + [Chargement de fichiers de données chiffrés à partir d’Amazon S3](c_loading-encrypted-files.md) # Utilisation d’un manifeste pour spécifier les fichiers de données Vous pouvez utiliser un manifeste pour faire en sorte que la commande COPY charge tous les fichiers nécessaires, et seulement ceux-là, lors d’un chargement de données. Vous pouvez utiliser un manifeste pour charger les fichiers de différents compartiments ou les fichiers qui ne partagent pas le même préfixe. Au lieu de fournir un chemin d’objet pour la commande COPY, vous fournissez le nom d’un fichier texte au format JSON qui répertorie explicitement les fichiers à charger. L’URL du manifeste doit spécifier le nom de compartiment et le chemin d’objet complet du fichier, pas simplement un préfixe. Pour plus d’informations sur les fichiers manifestes, consultez l’exemple de COPY [Utilisation d’un manifeste pour spécifier des fichiers de données](r_COPY_command_examples.md#copy-command-examples-manifest). L’exemple suivant illustre le format JSON pour charger les fichiers de différents compartiments et avec des noms de fichiers commençant par des horodatages. ``` { "entries": [ {"url":"s3://amzn-s3-demo-bucket1/2013-10-04-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket1/2013-10-05-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket2/2013-10-04-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket2/2013-10-05-custdata", "mandatory":true} ] } ``` L’indicateur facultatif `mandatory` spécifie si la commande COPY doit renvoyer une erreur si le fichier est introuvable. La valeur par défaut de `mandatory` est `false`. Quels que soient les paramètres obligatoires, la commande COPY s’arrête si aucun fichier n’est trouvé. L’exemple suivant exécute la commande COPY avec le manifeste de l’exemple précédent, qui s’appelle `cust.manifest`. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/cust.manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MANIFEST; ``` ## Utilisation d’un manifeste créé par une commande UNLOAD Il se peut qu’un manifeste créé par une opération [UNLOAD](r_UNLOAD.md) utilisant le paramètre MANIFEST contienne des clés non nécessaires à l’opération COPY. Par exemple, le manifeste `UNLOAD` suivant comprend une clé `meta` qui est requise pour une table externe Amazon Redshift Spectrum et pour charger des fichiers de données au format `ORC` ou `Parquet`. La clé `meta` contient une clé `content_length` avec une valeur correspondant à la taille réelle du fichier en octets. L’opération COPY nécessite uniquement la clé `url` et une clé `mandatory` facultative. ``` { "entries": [ {"url":"s3://amzn-s3-demo-bucket/unload/manifest_0000_part_00", "meta": { "content_length": 5956875 }}, {"url":"s3://amzn-s3-demo-bucket/unload/unload/manifest_0001_part_00", "meta": { "content_length": 5997091 }} ] } ``` Pour plus d’informations sur les fichiers manifeste, consultez [Utilisation d’un manifeste pour spécifier les fichiers de données](r_COPY_command_examples.md#copy-command-examples-manifest). # Chargement des fichiers de données compressés à partir d’Amazon S3 Pour charger des fichiers de données compressés à l'aide de gzip, lzop ou bzip2, incluez l'option correspondante : GZIP, LZOP ou. BZIP2 Par exemple, la commande suivante charge des fichiers compressés à l’aide de lzop. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/customer.lzo' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' LZOP; ``` **Note** Si vous compressez un fichier de données avec la compression lzop et que vous utilisez l’option *--filter*, la commande COPY ne la prend pas en charge. # Chargement de données de largeur fixe à partir d’Amazon S3 Les fichiers de données de largeur fixe ont des longueurs uniformes pour chaque colonne de données. Chaque champ d’un fichier de données de largeur fixe possède exactement les mêmes longueur et position. Pour les données de type character (CHAR et VARCHAR) d’un fichier de données de largeur fixe, vous devez inclure les espaces de début ou de fin comme espaces réservés afin que la largeur demeure uniforme. Pour les entiers, vous devez utiliser des zéros comme espaces réservés. Un fichier de données de largeur fixe n’a pas de délimiteur pour séparer les colonnes. Pour charger un fichier de données de largeur fixe dans une table existante, utilisez le paramètre FIXEDWIDTH de la commande COPY. Vos spécifications de table doivent correspondre à la valeur de fixedwidth\$1spec pour que les données se chargent correctement. Pour charger les données de largeur fixe depuis un fichier vers une table, émettez la commande suivante : ``` COPY table_name FROM 's3://amzn-s3-demo-bucket/prefix' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' FIXEDWIDTH 'fixedwidth_spec'; ``` Le paramètre *fixedwidth\$1spec* est une chaîne qui contient un identificateur pour chaque colonne et la largeur de chaque colonne, avec le caractère deux-points comme séparateur. Les paires **column:width** sont délimitées par des virgules. L’identificateur peut être l’un de vos choix : chiffres, lettres ou une combinaison des deux. L’identificateur n’ayant aucune relation avec la table elle-même, les spécifications doivent contenir les colonnes dans le même ordre que la table. Les deux exemples suivants présentent les mêmes spécifications, avec la première utilisant des identificateurs de type numérique (numeric) et la seconde des identificateurs de type chaîne (string) : ``` '0:3,1:25,2:12,3:2,4:6' ``` ``` 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6' ``` L’exemple suivant montre un exemple de données de largeur fixe qui pourraient être chargées dans la table VENUE selon les spécifications précédentes : ``` 1 Toyota Park Bridgeview IL0 2 Columbus Crew Stadium Columbus OH0 3 RFK Stadium Washington DC0 4 CommunityAmerica Ballpark Kansas City KS0 5 Gillette Stadium Foxborough MA68756 ``` La commande COPY suivante charge cet ensemble de données dans la table VENUE : ``` COPY venue FROM 's3://amzn-s3-demo-bucket/data/venue_fw.txt' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' FIXEDWIDTH 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6'; ``` # Chargement de données multioctets à partir d'Amazon S3 Si vos données incluent des caractères non-ASCII codés sur plusieurs octets (par exemple, les caractères chinois ou cyrilliques), vous devez charger les données dans des colonnes VARCHAR. Le type de données VARCHAR prend en charge les caractères UTF-8 codés sur quatre octets, mais le type de données CHAR n’accepte que les caractères ASCII codés sur un octet. Vous ne pouvez pas charger de caractères codés sur cinq octets ou plus dans des tables Amazon Redshift. Pour plus d’informations sur CHAR et VARCHAR, consultez [Types de données](c_Supported_data_types.md). Pour vérifier l’encodage utilisé par un fichier d’entrée, choisissez la commande Linux * `file` *: ``` $ file ordersdata.txt ordersdata.txt: ASCII English text $ file uni_ordersdata.dat uni_ordersdata.dat: UTF-8 Unicode text ``` # Chargement de fichiers de données chiffrés à partir d’Amazon S3 Vous pouvez utiliser la commande COPY pour charger les fichiers de données qui ont été chargées sur Amazon S3 à l’aide d’un chiffrement côté serveur, d’un chiffrement côté client ou des deux. La commande COPY prend en charge les types de chiffrement Amazon S3 suivants : + Chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3) + Chiffrement côté serveur avec AWS KMS keys (SSE-KMS) + Chiffrement côté client via une clé racine symétrique côté client La commande COPY ne prend pas en charge les types de chiffrement Amazon S3 suivants : + Chiffrement côté serveur avec clés fournies par le client (SSE-C) + Chiffrement côté client à l'aide d'un AWS KMS key + Chiffrement côté client via une clé racine asymétrique fournie par le client Pour plus d’informations sur le chiffrement Amazon S3, consultez [Protection des données à l’aide d’un chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) et [Protection des données via le chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) dans le Guide de l’utilisateur Amazon Simple Storage Service. La commande [UNLOAD](r_UNLOAD.md) chiffre automatiquement les fichiers à l’aide de SSE-S3. Vous pouvez également effectuer un déchargement avec un chiffrement côté client ou SSE-KMS avec une clé symétrique gérée par le client. Pour plus d’informations, consultez [Déchargement de fichiers de données chiffrés](t_unloading_encrypted_files.md) La commande COPY reconnaît et charge automatiquement les fichiers chiffrés avec SSE-S3 et SSE-KMS. Vous pouvez charger des fichiers chiffrés à l’aide d’une clé racine symétrique côté client en spécifiant l’option ENCRYPTED et en fournissant la valeur de la clé. Pour plus d'informations, consultez [Chargement de données chiffrées sur Amazon S3](t_uploading-encrypted-data.md). Pour charger des fichiers de données chiffrés côté client, indiquez la valeur de la clé racine à l’aide du paramètre MASTER\$1SYMMETRIC\$1KEY et ajoutez l’option ENCRYPTED. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MASTER_SYMMETRIC_KEY '' ENCRYPTED DELIMITER '|'; ``` Pour charger des fichiers de données chiffrés compressés au format gzip, lzop ou bzip2, incluez l'option GZIP, LZOP ou ainsi que la valeur de la clé racine et l' BZIP2 option ENCRYPTED. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MASTER_SYMMETRIC_KEY '' ENCRYPTED DELIMITER '|' GZIP; ``` # Chargement de données à partir d’Amazon EMR Vous pouvez utiliser la commande COPY pour charger des données en parallèle à partir d’un cluster Amazon EMR configuré pour écrire les fichiers texte dans le système de fichiers distribué Hadoop (HDFS) du cluster sous la forme de fichiers à largeur fixe, de fichiers délimités par des caractères, de fichiers CSV ou de fichiers au format JSON. ## Processus de chargement des données à partir d’Amazon EMR Cette section vous guide à travers le processus de chargement des données à partir d’un cluster Amazon EMR. Les sections suivantes fournissent les informations détaillées dont vous avez besoin pour effectuer chaque étape. + **[Étape 1 : Configurer des autorisations IAM](#load-from-emr-steps-configure-iam)** Les utilisateurs qui créent le cluster Amazon EMR et exécutent la command’Amazon Redshift COPY doivent avoir les autorisations nécessaires. + **[Étape 2 : Créer un cluster Amazon EMR](#load-from-emr-steps-create-cluster)** Configurez le cluster pour produire les fichiers texte sur le système de fichiers DFS Hadoop (HDFS). Vous avez besoin de l’ID de cluster Amazon EMR et du DNS public principal du cluster (point de terminaison de l’instance Amazon EC2 qui héberge le cluster). + **[Étape 3 : Récupérer la clé publique de cluster Amazon Redshift et les adresses IP de nœud de cluster](#load-from-emr-steps-retrieve-key-and-ips)** La clé publique permet aux nœuds de cluster Amazon Redshift d’établir des connexions SSH aux hôtes. Vous allez utiliser l’adresse IP de chaque nœud de cluster pour configurer les groupes de sécurité hôte et permettre l’accès à partir de votre cluster Amazon Redshift à l’aide de ces adresses IP. + **[Étape 4 : Ajouter la clé publique de cluster Amazon Redshift à chacun des fichiers de clés autorisées de l’hôte Amazon EC2](#load-from-emr-steps-add-key-to-host)** Vous ajoutez la clé publique de cluster Amazon Redshift au fichier des clés autorisées de l’hôte de telle sorte que l’hôte reconnaisse le cluster Amazon Redshift et accepte la connexion SSH. + **[Étape 5 : Configurer les hôtes pour accepter toutes les adresses IP du cluster Amazon Redshift](#load-from-emr-steps-configure-security-groups)** Modifiez les groupes de sécurité de l’instance Amazon EMR pour ajouter des règles de trafic entrant et accepter les adresses IP Amazon Redshift. + **[Étape 6 : Exécuter la commande COPY pour charger les données](#load-from-emr-steps-run-copy)** Depuis une base de données Amazon Redshift, exécutez la commande COPY pour charger les données dans une table Amazon Redshift. ## Étape 1 : Configurer des autorisations IAM Les utilisateurs qui créent le cluster Amazon EMR et exécutent la commande Amazon Redshift COPY doivent avoir les autorisations nécessaires. **Pour configurer les autorisations IAM** 1. Ajoutez les autorisations suivantes pour l’utilisateur qui créera le cluster Amazon EMR. ``` ec2:DescribeSecurityGroups ec2:RevokeSecurityGroupIngress ec2:AuthorizeSecurityGroupIngress redshift:DescribeClusters ``` 1. Ajoutez l’autorisation suivante pour le rôle IAM ou l’utilisateur qui exécutera la commande COPY. ``` elasticmapreduce:ListInstances ``` 1. Ajoutez l’autorisation suivante au rôle IAM du cluster Amazon EMR. ``` redshift:DescribeClusters ``` ## Étape 2 : Créer un cluster Amazon EMR La commande COPY charge les données à partir des fichiers du système de fichiers distribué Hadoop (HDFS) Amazon EMR. Lorsque vous créez le cluster Amazon EMR, configurez le cluster pour générer les fichiers de données sur le système de fichiers distribué Hadoop (HDFS) du cluster. **Pour créer un cluster Amazon EMR** 1. Créez un cluster Amazon EMR dans la même AWS région que le cluster Amazon Redshift. Si le cluster Amazon Redshift est un VPC, le cluster Amazon EMR doit être dans le même groupe VPC. Si le cluster Amazon Redshift utilise le mode EC2-Classic (à savoir, qu’il n’est pas dans un VPC), le cluster Amazon EMR doit également utiliser le mode EC2-Classic. Pour plus d’informations, consultez [Gestion des clusters dans un cloud privé virtuel (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) dans le *Guide de gestion Amazon Redshift*. 1. Configurez le cluster pour générer les fichiers de données sur le système de fichiers distribué Hadoop (HDFS) du cluster. Les noms de fichiers HDFS ne doivent pas comporter d’astérisque (\$1) ou de point d’interrogation (?). **Important** Les noms de fichiers ne doivent pas comporter d’astérisque (\$1) ou de point d’interrogation ( ? ). 1. Spécifiez **No (Non)** pour l’option **Auto-terminate (Arrêt automatique)** de la configuration du cluster Amazon EMR de telle sorte que le cluster demeure disponible pendant que la commande COPY s’exécute. **Important** Si l’un des fichiers de données est modifié ou supprimé avant la fin de la commande COPY, vous pouvez avoir des résultats inattendus ou l’opération COPY peut échouer. 1. Notez l’ID de cluster et le DNS public principal (point de terminaison de l’instance Amazon EC2 qui héberge le cluster). Vous allez utiliser ces informations dans les étapes ultérieures. ## Étape 3 : Récupérer la clé publique de cluster Amazon Redshift et les adresses IP de nœud de cluster Vous allez utiliser l’adresse IP de chaque nœud de cluster pour configurer les groupes de sécurité hôte et permettre l’accès à partir de votre cluster Amazon Redshift à l’aide de ces adresses IP. **Pour récupérer la clé publique de cluster et les adresses IP de nœud de cluster Amazon Redshift pour votre cluster à l’aide de la console** 1. Accédez à la console de gestion Amazon Redshift. 1. Choisissez le lien **Clusters** dans le volet de navigation. 1. Sélectionnez votre cluster dans la liste. 1. Recherchez le groupe **Paramètres d’ingestion SSH**. Notez la **Clé publique du cluster** et les **Adresses IP du nœud**. Vous allez les utiliser dans les étapes ultérieures. ![\[Capture d’écran du groupe de paramètres d’ingestion SSH montrant la clé publique du cluster et les adresses IP des nœuds.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/copy-from-ssh-console-2.png) Vous allez utiliser les adresses IP privées de l’étape 3 pour configurer l’hôte Amazon EC2 de sorte qu’il accepte la connexion à partir d’Amazon Redshift. Pour récupérer la clé publique de cluster et les adresses IP de nœud de cluster pour votre cluster à l’aide de la CLI Amazon Redshift, exécutez la commande describe-clusters. Par exemple : ``` aws redshift describe-clusters --cluster-identifier ``` La réponse inclura une ClusterPublicKey valeur et la liste des adresses IP privées et publiques, similaires à ce qui suit : ``` { "Clusters": [ { "VpcSecurityGroups": [], "ClusterStatus": "available", "ClusterNodes": [ { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "LEADER", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-0", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-1", "PublicIPAddress": "10.nnn.nnn.nnn" } ], "AutomatedSnapshotRetentionPeriod": 1, "PreferredMaintenanceWindow": "wed:05:30-wed:06:00", "AvailabilityZone": "us-east-1a", "NodeType": "dc2.large", "ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift", ... ... } ``` Pour extraire la clé publique de cluster et les adresses IP de nœud de cluster de votre cluster à l’aide de l’API Amazon Redshift, utilisez l’action `DescribeClusters`. Pour plus d'informations, consultez la section [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) dans le guide de la *CLI Amazon Redshift [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)*ou dans le guide de l'API Amazon Redshift. ## Étape 4 : Ajouter la clé publique de cluster Amazon Redshift à chacun des fichiers de clés autorisées de l’hôte Amazon EC2 Vous ajoutez la clé publique de cluster à chaque fichier de clés autorisées de l’hôte pour tous les nœuds de cluster Amazon EMR de telle sorte que les hôtes reconnaissent Amazon Redshift et acceptent la connexion SSH. **Pour ajouter la clé publique de cluster Amazon Redshift au fichier de clés autorisées de l’hôte** 1. Accédez à l’hôte à l’aide d’une connexion SSH. Pour plus d’informations sur la connexion à une instance à l’aide de SSH, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) dans le *Guide de l’utilisateur Amazon EC2*. 1. Copiez la clé publique Amazon Redshift à partir de la console ou du texte de réponse de la CLI. 1. Copiez et collez le contenu de la clé publique dans le fichier `/home//.ssh/authorized_keys` de l’hôte. Incluez la chaîne complète, y compris le préfixe « `ssh-rsa` » et le suffixe « `Amazon-Redshift` ». Par exemple : ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Étape 5 : Configurer les hôtes pour accepter toutes les adresses IP du cluster Amazon Redshift Pour autoriser le trafic entrant des instances de l’hôte, modifiez le groupe de sécurité et ajoutez une règle de trafic entrant pour chacun nœud de cluster Amazon Redshift. Pour **Type**, sélectionnez SSH avec le protocole TCP sur le port 22. Pour **Source**, saisissez les adresses IP privées du nœud de cluster Amazon Redshift que vous avez récupérées dans [Étape 3 : Récupérer la clé publique de cluster Amazon Redshift et les adresses IP de nœud de cluster](#load-from-emr-steps-retrieve-key-and-ips). Pour plus d’informations sur l’ajout de règles à un groupe de sécurité Amazon EC2, consultez [Autorisation du trafic entrant pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) dans le *Guide de l’utilisateur Amazon EC2*. ## Étape 6 : Exécuter la commande COPY pour charger les données Exécutez une commande [COPY](r_COPY.md) pour vous connecter au cluster Amazon EMR et charger les données dans une table Amazon Redshift. Le cluster Amazon EMR doit continuer à s’exécuter jusqu’à la fin de la commande COPY. Par exemple, ne configurez pas le cluster pour qu’il se termine automatiquement. **Important** Si l’un des fichiers de données est modifié ou supprimé avant la fin de la commande COPY, vous pouvez avoir des résultats inattendus ou l’opération COPY peut échouer. Dans la commande COPY, spécifiez l’ID de cluster Amazon EMR, ainsi que le nom et le chemin d’accès du fichier HDFS. ``` COPY sales FROM 'emr://myemrclusterid/myoutput/part*' CREDENTIALS IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Vous pouvez utiliser l’astérisque comme caractère générique (`*`) et le point d’interrogation (`?`) dans le cadre de l’argument de nom de fichier. Par exemple, `part*` charge les fichiers `part-0000`, `part-0001`, et ainsi de suite. Si vous spécifiez uniquement un nom de dossier, COPY tente de charger tous les fichiers dans le dossier. **Important** Si vous utilisez des caractères génériques ou utilisez uniquement le nom de dossier, vérifiez qu’aucun fichier indésirable n’est chargées, sinon la commande COPY échoue. Par exemple, certains processus peuvent écrire un fichier journal sur le dossier de sortie. # Chargement des données à partir des hôtes distants Vous pouvez utiliser la commande COPY pour charger les données en parallèle à partir d’un ou de plusieurs hôtes distants, comme les instances Amazon EC2 ou autres ordinateurs. COPY se connecte aux hôtes distants à l’aide de SSH et exécute les commandes sur les hôtes distants pour générer la sortie texte. L’hôte distant peut être une instance Linux Amazon EC2 ou un autre ordinateur Unix ou Linux configuré pour accepter les connexions SSH. Ce guide suppose que votre hôte à distance est une instance Amazon EC2. Lorsque la procédure est différente pour un autre ordinateur, le guide signale la différence. Amazon Redshift peut se connecter à plusieurs hôtes et ouvrir plusieurs connexions SSH à chaque hôte. Amazon Redshift envoie une commande unique via chaque connexion pour générer la sortie texte sur la sortie standard de l’hôte, qu’Amazon Redshift lit ensuite comme un fichier texte. ## Avant de commencer Avant de commencer, vous devez avoir les éléments suivants en place : + Un ou plusieurs ordinateurs hôtes, comme les instances Amazon EC2 auxquelles vous pouvez vous connecter à l’aide de SSH. + Sources de données sur les hôtes. Vous devez fournir les commandes que le cluster Amazon Redshift exécutera sur les hôtes pour générer la sortie texte. Une fois que le cluster s’est connecté à un hôte, la commande COPY exécute les commandes, lit le texte depuis la sortie standard des hôtes et charge les données en parallèle dans une table Amazon Redshift. La sortie texte doit être sous une forme que la commande COPY peut assimiler. Pour plus d'informations, consultez [Préparation de vos données d’entrée](t_preparing-input-data.md) + Accédez aux hôtes à partir de votre ordinateur. Pour une instance Amazon EC2, vous allez utiliser une connexion SSH pour accéder à l’hôte. Vous devez accéder à l’hôte pour ajouter la clé publique du cluster Amazon Redshift au fichier de clés autorisées de l’hôte. + Un cluster Amazon Redshift en cours d’exécution. Pour plus d’informations sur le lancement d’un cluster, consultez [Guide de démarrage d’Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/). ## Processus de chargement de données Cette section vous guide à travers le processus de chargement de données à partir d’hôtes distants. Les sections suivantes fournissent les informations détaillées dont vous avez besoin pour effectuer chaque étape. + **[Étape 1 : Récupérer la clé publique de cluster et les adresses IP de nœud de cluster](#load-from-host-steps-retrieve-key-and-ips)** La clé publique permet aux nœuds de cluster Amazon Redshift d’établir des connexions SSH aux hôtes distants. Vous allez utiliser l’adresse IP de chaque nœud de cluster pour configurer les groupes de sécurité hôte ou le pare-feu, et permettre l’accès à partir de votre cluster Amazon Redshift à l’aide de ces adresses IP. + **[Étape 2 : Ajouter la clé publique de cluster Amazon Redshift au fichier de clés autorisées de l’hôte](#load-from-host-steps-add-key-to-host)** Vous ajoutez la clé publique de cluster Amazon Redshift au fichier des clés autorisées de l’hôte de telle sorte que l’hôte reconnaisse le cluster Amazon Redshift et accepte la connexion SSH. + **[Étape 3 : Configurer l’hôte pour accepter toutes les adresses IP du cluster Amazon Redshift](#load-from-host-steps-configure-security-groups)** Pour Amazon EC2, modifiez les groupes de sécurité de l’instance pour ajouter des règles de trafic entrant et accepter les adresses IP Amazon Redshift. Pour les autres hôtes, modifiez le pare-feu de telle sorte que vos nœuds Amazon Redshift puissent établir des connexions SSH à l’hôte distant. + **[Étape 4 : Obtenir la clé publique de l’hôte](#load-from-host-steps-get-the-host-key)** Vous pouvez spécifier le cas échéant qu’Amazon Redshift doit utiliser la clé publique pour identifier l’hôte. Vous devez trouver la clé publique et copier le texte dans votre fichier manifeste. + **[Étape 5 : Créer un fichier manifeste](#load-from-host-steps-create-manifest)** Le manifeste est un fichier texte au format JSON avec les détails dont Amazon Redshift a besoin pour se connecter aux hôtes et récupérer les données. + **[Étape 6 : charger le fichier manifeste sur un compartiment Amazon S3](#load-from-host-steps-upload-manifest)** Amazon Redshift lit le manifeste et utilise ces informations pour se connecter à l’hôte distant. Si le compartiment Amazon S3 ne réside pas dans la même région que votre cluster Amazon Redshift, vous devez utiliser l’option [REGION](copy-parameters-data-source-s3.md#copy-region) pour spécifier la région dans laquelle les données se trouvent. + **[Étape 7 : Exécuter la commande COPY pour charger les données](#load-from-host-steps-run-copy)** Depuis une base de données Amazon Redshift, exécutez la commande COPY pour charger les données dans une table Amazon Redshift. ## Étape 1 : Récupérer la clé publique de cluster et les adresses IP de nœud de cluster Vous allez utiliser l’adresse IP de chaque nœud de cluster pour configurer les groupes de sécurité hôte et permettre l’accès à partir de votre cluster Amazon Redshift à l’aide de ces adresses IP. **Pour récupérer la clé publique de cluster et les adresses IP de nœud de cluster pour votre cluster à l’aide de la console** 1. Accédez à la console de gestion Amazon Redshift. 1. Choisissez le lien **Clusters** dans le volet de navigation. 1. Sélectionnez votre cluster dans la liste. 1. Recherchez le groupe **Paramètres d’ingestion SSH**. Notez la **Clé publique du cluster** et les **Adresses IP du nœud**. Vous allez les utiliser dans les étapes ultérieures. ![\[Capture d’écran du groupe de paramètres d’ingestion SSH montrant la clé publique du cluster et les adresses IP des nœuds.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/copy-from-ssh-console-2.png) Vous allez utiliser les adresses IP privées de l’étape 3 pour configurer l’hôte et accepter la connexion à partir d’Amazon Redshift. Selon le type d’hôte auquel vous vous connectez à et qu’il figure ou pas dans un VPC, vous allez utiliser les adresses IP publiques ou les adresses IP privées. Pour récupérer la clé publique de cluster et les adresses IP de nœud de cluster pour votre cluster à l’aide de la CLI Amazon Redshift, exécutez la commande describe-clusters. Par exemple : ``` aws redshift describe-clusters --cluster-identifier ``` La réponse inclura ClusterPublicKey la liste des adresses IP privées et publiques, comme suit : ``` { "Clusters": [ { "VpcSecurityGroups": [], "ClusterStatus": "available", "ClusterNodes": [ { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "LEADER", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-0", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-1", "PublicIPAddress": "10.nnn.nnn.nnn" } ], "AutomatedSnapshotRetentionPeriod": 1, "PreferredMaintenanceWindow": "wed:05:30-wed:06:00", "AvailabilityZone": "us-east-1a", "NodeType": "dc2.large", "ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift", ... ... } ``` Pour récupérer la clé publique du cluster et les adresses IP des nœuds de cluster de votre cluster à l'aide de l'API Amazon Redshift, utilisez l' DescribeClusters action. Pour plus d'informations, consultez la section [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) dans le guide de la *CLI Amazon Redshift [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)*ou dans le guide de l'API Amazon Redshift. ## Étape 2 : Ajouter la clé publique de cluster Amazon Redshift au fichier de clés autorisées de l’hôte Vous ajoutez la clé publique de cluster à chaque fichier de clés autorisées de l’hôte de telle sorte que l’hôte reconnaisse Amazon Redshift et accepte la connexion SSH. **Pour ajouter la clé publique de cluster Amazon Redshift au fichier de clés autorisées de l’hôte** 1. Accédez à l’hôte à l’aide d’une connexion SSH. Pour plus d’informations sur la connexion à une instance à l’aide de SSH, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) dans le *Guide de l’utilisateur Amazon EC2*. 1. Copiez la clé publique Amazon Redshift à partir de la console ou du texte de réponse de la CLI. 1. Copiez et collez le contenu de la clé publique dans le fichier `/home//.ssh/authorized_keys` de l’hôte distant. `` doit correspondre à la valeur du champ « username » du fichier manifeste. Incluez la chaîne complète, y compris le préfixe « `ssh-rsa` » et le suffixe « `Amazon-Redshift` ». Par exemple : ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Étape 3 : Configurer l’hôte pour accepter toutes les adresses IP du cluster Amazon Redshift Si vous travaillez avec une instance Amazon EC2 ou un cluster Amazon EMR, ajoutez les règles entrantes au groupe de sécurité de l’hôte pour autoriser le trafic depuis chaque nœud de cluster Amazon Redshift. Pour **Type**, sélectionnez SSH avec le protocole TCP sur le port 22. Pour **Source**, saisissez les adresses IP du nœud de cluster Amazon Redshift que vous avez récupérées dans [Étape 1 : Récupérer la clé publique de cluster et les adresses IP de nœud de cluster](#load-from-host-steps-retrieve-key-and-ips). Pour plus d’informations sur l’ajout de règles à un groupe de sécurité Amazon EC2, consultez [Autorisation du trafic entrant pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) dans le *Guide de l’utilisateur Amazon EC2*. Utilisez les adresses IP privées quand : + Vous disposez d'un cluster Amazon Redshift qui ne se trouve pas dans un Virtual Private Cloud (VPC) et d'une instance Amazon EC2-Classic, tous deux situés dans la même région. AWS + Vous avez un cluster Amazon Redshift situé dans un VPC et une instance Amazon EC2 -VPC, tous deux situés dans la même région et dans le même VPC. AWS Sinon, utilisez les adresses IP publiques. Pour plus d’informations sur l’utilisation d’Amazon Redshift dans un VPC, consultez [Gestion des clusters dans un cloud privé virtuel (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) dans le *Guide de gestion Amazon Redshift*. ## Étape 4 : Obtenir la clé publique de l’hôte Vous pouvez fournir le cas échéant la clé publique dans le fichier manifeste de telle sorte qu’Amazon Redshift puisse identifier l’hôte. La commande COPY ne nécessite pas la clé publique de l'hôte mais, pour des raisons de sécurité, nous vous recommandons vivement d'utiliser une clé publique pour empêcher les attaques man-in-the-middle « ». Vous pouvez trouver la clé publique de l’hôte à l’emplacement suivant, où `` correspond au nom unique de la clé publique de l’hôte : ``` : /etc/ssh/.pub ``` **Note** Amazon Redshift prend uniquement en charge les clés RSA. Nous ne prenons pas en charge les clés DSA. Lorsque vous créez votre fichier manifeste à l’étape 5, vous collez le texte de la clé publique dans le champ « Public Key » de l’entrée du fichier manifeste. ## Étape 5 : Créer un fichier manifeste La commande COPY peut se connecter à plusieurs hôtes à l’aide de SSH et créer plusieurs connexions SSH à chaque hôte. COPY exécute une commande via chaque connexion hôte, puis charge la sortie à partir des commandes en parallèle de la table. Le fichier manifeste est un fichier texte au format JSON qu’Amazon Redshift utilise pour se connecter à l’hôte. Le fichier manifeste spécifie les points de terminaison hôte SSH et les commandes qui sont exécutées sur les hôtes pour renvoyer les données à Amazon Redshift. Le cas échéant, vous pouvez inclure la clé publique de l’hôte, le nom d’utilisateur de connexion et un indicateur obligatoire pour chaque entrée. Créez le fichier manifeste sur votre ordinateur local. Dans une étape ultérieure, vous téléchargez le fichier vers Amazon S3. Le fichier manifeste est au format suivant : ``` { "entries": [ {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": ""}, {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": "host_user_name"} ] } ``` Le fichier manifeste contient une construction « entries » pour chaque connexion SSH. Chaque entrée représente une seule connexion SSH. Vous pouvez avoir plusieurs connexions à un seul hôte ou plusieurs connexions à plusieurs hôtes. Les guillemets doubles sont obligatoires comme illustré, aussi bien pour les noms de champ que pour les valeurs. La seule valeur qui n’a pas besoin de guillemets doubles est la valeur booléenne **true** ou **false** pour le champ obligatoire. La liste suivante décrit les champs dans le fichier manifeste. point de terminaison Adresse URL ou adresse IP de l’hôte. Par exemple, « `ec2-111-222-333.compute-1.amazonaws.com` » ou « `22.33.44.56` » command La commande qui sera exécutée par l’hôte pour générer une sortie texte ou binaire (lzop, gzip ou bzip2). La commande peut être n’importe quelle commande que l’utilisateur *« host\$1user\$1name »* est autorisé à exécuter. La commande peut être aussi simple que l’impression d’un fichier ou peut interroger une base de données ou lancer un script. La sortie (fichier texte, fichier binaire gzip, fichier binaire lzop ou fichier binaire bzip2) doit être sous une forme que la commande COPY Amazon Redshift peut intégrer. Pour plus d'informations, consultez [Préparation de vos données d’entrée](t_preparing-input-data.md). publickey (Facultatif) La clé publique de l’hôte. Si la clé est fournie, Amazon Redshift l’utilise pour identifier l’hôte. Si la clé publique n’est pas fournie, Amazon Redshift n’essaie pas d’identifier l’hôte. Par exemple, si la clé publique de l’hôte distant est `ssh-rsa AbcCbaxxx…xxxDHKJ root@amazon.com`, saisissez le texte suivant dans le champ de clé publique : `AbcCbaxxx…xxxDHKJ`. mandatory (Facultatif) Indique si la commande COPY doit échouer en cas d’échec de la connexion. L’argument par défaut est `false`. Si Amazon Redshift n’établit pas avec succès au moins une connexion, la commande COPY échoue. nom d’utilisateur (Facultatif) Nom d’utilisateur qui sera utilisé pour vous connecter au système hôte et exécuter la commande à distance. Le nom de connexion d’utilisateur doit être le même que celui de la connexion utilisée pour ajouter la clé publique au fichier de clés autorisées de l’hôte à l’étape 2. Le nom d’utilisateur par défaut est « redshift ». L’exemple suivant illustre un manifeste complet permettant d’ouvrir quatre connexions vers le même hôte et d’exécuter une commande différente sur chaque connexion : ``` { "entries": [ {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata1.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata2.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata3.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata4.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"} ] } ``` ## Étape 6 : charger le fichier manifeste sur un compartiment Amazon S3 Chargez le fichier manifeste sur un compartiment Amazon S3. Si le compartiment Amazon S3 ne réside pas dans la même AWS région que votre cluster Amazon Redshift, vous devez utiliser l'[REGION](copy-parameters-data-source-s3.md#copy-region)option pour spécifier la AWS région dans laquelle se trouve le manifeste. Pour plus d’informations sur la création d’un compartiment Amazon S3 et le chargement d’un fichier, consultez le [Guide de l’utilisateur Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/). ## Étape 7 : Exécuter la commande COPY pour charger les données Exécutez une commande [COPY](r_COPY.md) pour vous connecter à l’hôte et charger les données dans une table Amazon Redshift. Dans la commande COPY, spécifiez le chemin d’accès à l’objet Amazon S3 explicite pour le fichier manifeste et incluez l’option SSH. Par exemple, ``` COPY sales FROM 's3://amzn-s3-demo-bucket/ssh_manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' SSH; ``` **Note** Si vous utilisez la compression automatique, la commande COPY effectue deux lectures des données, ce qui signifie qu’elle exécute la commande distante à deux reprises. La première lecture consiste à fournir un échantillon pour l’analyse de la compression, puis la deuxième lecture charge réellement les données. Si la double exécution de la commande distante cause un problème en raison des effets secondaires potentiels, vous devez désactiver la compression automatique. Pour désactiver la compression automatique, exécutez la commande COPY avec l’option COMPUPDATE définie sur OFF. Pour plus d’informations, consultez [Chargement des tables avec compression automatique](c_Loading_tables_auto_compress.md). # Chargement de données à partir d’une table Amazon DynamoDB Vous pouvez utiliser la commande COPY pour charger une table avec les données d’une seule table Amazon DynamoDB. **Important** La table Amazon DynamoDB qui fournit les données doit être créée dans la AWS même région que votre cluster, sauf si vous utilisez [REGION](copy-parameters-data-source-s3.md#copy-region) l'option permettant de spécifier la région dans laquelle se AWS trouve la table Amazon DynamoDB. La commande COPY utilise l’architecture de traitement hautement parallèle (MPP) d’Amazon Redshift pour lire et charger les données en parallèle à partir d’une table Amazon DynamoDB. Vous pouvez profiter au maximum du traitement parallèle en définissant les styles de distribution de vos tables Amazon Redshift. Pour plus d'informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md). **Important** Lorsque la commande COPY lit des données à partir de la table Amazon DynamoDB, le transfert de données qui en résulte fait partie du débit alloué de la table. Pour éviter de consommer des quantités excessives de débit alloué en lecture, nous vous recommandons de ne pas charger les données à partir des tables Amazon DynamoDB qui se trouvent dans des environnements de production. Si vous chargez les données à partir des tables de production, nous vous recommandons de définir l’option READRATIO avec une valeur beaucoup plus basse que le pourcentage moyen de débit alloué inutilisé. Un paramètre READRATIO bas contribue à réduire les problèmes de limitation. Pour utiliser la totalité du débit alloué d’une table Amazon DynamoDB, définissez READRATIO avec la valeur 100. La commande COPY met en correspondance les noms d’attribut des éléments extraits de la table Amazon DynamoDB et les noms de colonne d’une table Amazon Redshift existante en utilisant les règles suivantes : + Les colonnes de la table Amazon Redshift sont mises en correspondance sans sensibilité à la casse avec les attributs d’élément Amazon DynamoDB. Si un élément de la table DynamoDB contient plusieurs attributs qui diffèrent uniquement par la casse, comme Prix et PRIX, la commande COPY échoue. + Les colonnes de la table Amazon Redshift qui ne correspondent pas à un attribut de la table Amazon DynamoDB sont chargées en tant que NULL ou vides, en fonction de la valeur spécifiée par l’option EMPTYASNULL de la commande [COPY](r_COPY.md). + Les attributs Amazon DynamoDB qui ne correspondent pas à une colonne de la table Amazon Redshift sont ignorés. Les attributs sont lus avant d’être mis en correspondance, et à fortiori les attributs ignorés consomment une partie du débit alloué de la table. + Seuls les attributs Amazon DynamoDB avec les types de données STRING et NUMBER sont pris en charge. Les types de données Amazon DynamoDB BINARY et SET ne sont pas pris en charge. Si une commande COPY tente de charger un attribut avec un type de données non pris en charge, la commande échoue. Si l’attribut ne correspond pas à une colonne de table Amazon Redshift, COPY n’essaie pas de le charger et aucune erreur n’est déclenchée. La commande COPY utilise la syntaxe suivante pour charger les données d’une table Amazon DynamoDB : ``` COPY FROM 'dynamodb://' authorization readratio ''; ``` Les valeurs *d'autorisation* sont les AWS informations d'identification nécessaires pour accéder à la table Amazon DynamoDB. Si ces informations d’identification correspondent à un utilisateur, cet utilisateur doit avoir la permission d’exécuter les opérations SCAN et DESCRIBE sur la table Amazon DynamoDB en cours de chargement. Les valeurs d'*autorisation* fournissent l' AWS autorisation dont votre cluster a besoin pour accéder à la table Amazon DynamoDB. Elle doit comprendre l’autorisation d’exécuter SCAN et DESCRIBE sur la table Amazon DynamoDB qui est en cours de chargement. Pour plus d’informations sur les autorisations requises, consultez [Autorisations IAM pour les commandes COPY, UNLOAD et CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). La méthode d’authentification recommandée est celle qui consiste à spécifier le paramètre IAM\$1ROLE et à fournir l’Amazon Resource Name (ARN) d’un rôle IAM avec les autorisations nécessaires. Pour de plus amples informations, veuillez consulter [Contrôle d’accès basé sur les rôles](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based). Pour vous authentifier à l'aide du paramètre IAM\$1ROLE, ** et ** comme indiqué dans la syntaxe suivante. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` L’authentification à l’aide d’un rôle IAM est présentée dans l’exemple suivant. ``` COPY favoritemovies FROM 'dynamodb://ProductCatalog' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Pour plus d’informations sur d’autres options d’autorisation, consultez [Paramètres d’autorisation](copy-parameters-authorization.md) Si vous voulez valider vos données sans charger le tableau, utilisez l’option NOLOAD avec la commande [COPY](r_COPY.md). L'exemple suivant charge la table FAVORITEMOVIES avec les données de la table DynamoDB. my-favorite-movies-table L’activité de lecture peut consommer jusqu’à 50 % du débit alloué. ``` COPY favoritemovies FROM 'dynamodb://my-favorite-movies-table' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' READRATIO 50; ``` Pour optimiser le débit, la commande COPY charge les données d’une table Amazon DynamoDB en parallèle sur les nœuds de calcul du cluster. ## Débit alloué avec compression automatique Par défaut, la commande COPY applique la compression automatique chaque fois que vous spécifiez une table cible vide sans encodage de compression. La compression automatique analyse initialement un grand nombre de lignes de la table Amazon DynamoDB. La taille de l’échantillon repose sur la valeur du paramètre COMPROWS. La valeur par défaut est de 100 000 lignes par tranche. Après le prélèvement, les lignes de l’exemple sont ignorées et la totalité de la table est chargée. Par conséquent, la plupart des lignes sont lues deux fois. Pour plus d’informations sur le fonctionnement de la compression, consultez [Chargement des tables avec compression automatique](c_Loading_tables_auto_compress.md). **Important** Lorsque la commande COPY lit les données de la table Amazon DynamoDB, y compris les lignes utilisées pour les prélèvements, le transfert des données obtenues fait partie du débit alloué de la table. ## Chargement de données multioctets à partir d’Amazon DynamoDB Si vos données incluent des caractères non-ASCII codés sur plusieurs octets (par exemple, les caractères chinois ou cyrilliques), vous devez charger les données dans des colonnes VARCHAR. Le type de données VARCHAR prend en charge les caractères UTF-8 codés sur quatre octets, mais le type de données CHAR n’accepte que les caractères ASCII codés sur un octet. Vous ne pouvez pas charger de caractères codés sur cinq octets ou plus dans des tables Amazon Redshift. Pour plus d’informations sur CHAR et VARCHAR, consultez [Types de données](c_Supported_data_types.md). # Vérification que les données ont été chargées correctement Une fois l’opération de chargement terminée, interrogez la table système [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) pour vérifier que les fichiers attendus ont été chargés. Exécutez la commande COPY et la vérification de la charge dans la même transaction afin qu’en cas de problème avec la charge, vous puissiez restaurer l’ensemble de la transaction. La requête suivante renvoie les entrées pour charger les tables dans la base de données TICKIT : ``` SELECT query, trim(filename) AS filename, curtime, status FROM stl_load_commits WHERE filename like '%tickit%' order by query; query | filename | curtime | status -------+---------------------------+----------------------------+-------- 22475 | tickit/allusers_pipe.txt | 2013-02-08 20:58:23.274186 | 1 22478 | tickit/venue_pipe.txt | 2013-02-08 20:58:25.070604 | 1 22480 | tickit/category_pipe.txt | 2013-02-08 20:58:27.333472 | 1 22482 | tickit/date2008_pipe.txt | 2013-02-08 20:58:28.608305 | 1 22485 | tickit/allevents_pipe.txt | 2013-02-08 20:58:29.99489 | 1 22487 | tickit/listings_pipe.txt | 2013-02-08 20:58:37.632939 | 1 22489 | tickit/sales_tab.txt | 2013-02-08 20:58:37.632939 | 1 (6 rows) ``` # Validation des données d’entrée Afin de valider les données des fichiers d’entrée Amazon S3 ou de la table Amazon DynamoDB avant que vous ne chargiez réellement les données, utilisez l’option NOLOAD avec la commande [COPY](r_COPY.md). Utilisez NOLOAD avec les mêmes commandes et options COPY que vous utiliseriez pour charger les données. NOLOAD vérifie l’intégrité de toutes les données sans les charger dans la base de données. L’option NOLOAD affiche les erreurs qui se produisent si vous tentez de charger les données. Par exemple, si vous avez spécifié un chemin Amazon S3 incorrect pour le fichier d’entrée, Amazon Redshift affiche l’erreur suivante. ``` ERROR: No such file or directory DETAIL: ----------------------------------------------- Amazon Redshift error: The specified key does not exist code: 2 context: S3 key being read : location: step_scan.cpp:1883 process: xenmaster [pid=22199] ----------------------------------------------- ``` Pour résoudre les messages d’erreur, consultez [Référence des erreurs de chargement](r_Load_Error_Reference.md). Pour obtenir un exemple d’utilisation de l’option NOLOAD, consultez [Commande COPY avec l’option NOLOAD](r_COPY_command_examples.md#r_COPY_command_examples-load-noload-option). # Chargement des tables avec compression automatique Vous pouvez appliquer manuellement des codages de compression aux colonnes des tables, en fonction de votre propre évaluation des données. Vous pouvez également utiliser la commande COPY avec COMPUPDATE définie sur ON pour analyser et appliquer automatiquement la compression en fonction des exemples de données. Vous pouvez utiliser la compression automatique lorsque vous créez et chargez une nouvelle table. La commande COPY effectue une analyse de compression. Vous pouvez également effectuer une analyse de la compression sans charger les données ou en modifiant la compression sur une table en exécutant la commande [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) sur une table déjà remplie. Par exemple, vous pouvez exécuter ANALYZE COMPRESSION lorsque vous souhaitez analyser la compression sur une table pour une utilisation ultérieure, tout en préservant les instructions DDL (Data Definition Language) existantes. La compression automatique équilibre les performances globales lors du choix des encodages de compression. Les analyses à plage restreinte peuvent mal s’exécuter si les colonnes de clé de tri sont beaucoup plus compressées que les autres colonnes de la même requête. Par conséquent, la compression automatique ignore la phase d’analyse des données sur les colonnes de clé de tri et conserve les types d’encodage définis par l’utilisateur. La compression automatique choisit l’encodage RAW si vous n’avez pas explicitement défini de type d’encodage. ANALYZE COMPRESSION se comporte de la même manière. Pour des performances optimales de requête, envisagez d’utiliser RAW pour les clés de tri. ## Fonctionnement de la compression automatique Lorsque le paramètre COMPUPDATE est défini sur ON, la commande COPY applique la compression automatique chaque fois que vous exécutez la commande COPY avec une table cible vide et que toutes les colonnes de la table ont l’encodage RAW ou aucun codage. Pour appliquer la compression automatique à une table vide, quel que soit son encodage de compression actuel, exécutez la commande COPY avec l’option COMPUPDATE définie sur ON. Pour désactiver la compression automatique, exécutez la commande COPY avec l’option COMPUPDATE définie sur OFF. Vous ne pouvez pas appliquer la compression automatique sur une table qui contient déjà des données. **Note** L’analyse de la compression automatique requiert assez de lignes dans les données de chargement (au moins 100 000 lignes par tranche) pour générer un échantillon significatif. La compression automatique exécute ces opérations en arrière-plan dans le cadre de la transaction de chargement : 1. Un échantillon initial de lignes est chargé depuis le fichier d’entrée. La taille de l’échantillon dépend de la valeur du paramètre COMPROWS. La valeur par défaut est 100 000. 1. Les options de compression sont choisies pour chaque colonne. 1. Les exemples de ligne sont supprimés de la table. 1. La table est recrée avec les encodages de compression choisis. 1. La totalité du fichier en entrée est chargé et compressé à l’aide des nouveaux encodages. Une fois que vous exécutez la commande COPY, la table est entièrement chargée, compressée et prête à être utilisée. Si vous chargez plus de données ultérieurement, les lignes ajoutées sont compressées selon l’encodage existant. Si vous souhaitez uniquement effectuer une analyse de la compression, exécutez ANALYZE COMPRESSION, qui est beaucoup plus efficace que l’exécution complète de la commande COPY. Ensuite, vous pouvez évaluer les résultats pour décider d’utiliser la compression automatique ou de recréer manuellement la table. La compression automatique n’est prise en charge que pour la commande COPY. Vous pouvez aussi appliquer manuellement l’encodage de compression lorsque vous créez la table. Pour plus d’informations sur l’encodage de la compression, consultez [Compression de colonnes pour réduire la taille des données stockées](t_Compressing_data_on_disk.md). ## Exemple de compression automatique Dans cet exemple, supposons que la base de données TICKIT contienne une copie de la table LISTING appelée BIGLIST et que vous souhaitiez appliquer la compression automatique à cette table lorsqu’elle est chargée avec 3 millions de lignes environ. **Pour charger et compresser automatiquement la table** 1. Vérifiez que la table est vide. Vous ne pouvez appliquer la compression automatique qu’à une table vide : ``` TRUNCATE biglist; ``` 1. Chargez la table avec une simple commande COPY. Même si la table est vide, un certain encodage antérieur peut avoir été spécifié. Pour permettre à Amazon Redshift d’effectuer une analyse de la compression, définissez le paramètre COMPUPDATE sur ON. ``` COPY biglist FROM 's3://amzn-s3-demo-bucket/biglist.txt' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' COMPUPDATE ON; ``` Comme aucune option COMPROWS n’est spécifiée, la taille de l’échantillon par défaut et recommandée de 100 000 lignes par tranche est utilisée. 1. Regardez le nouveau schéma de la table BIGLIST afin de vérifier les schémas d’encodage choisis automatiquement. ``` SELECT "column", type, encoding from pg_table_def where tablename = 'biglist'; Column | Type | Encoding ----------------+-----------------------------+---------- listid | integer | az64 sellerid | integer | az64 eventid | integer | az64 dateid | smallint | none numtickets | smallint | az64 priceperticket | numeric(8,2) | az64 totalprice | numeric(8,2) | az64 listtime | timestamp without time zone | az64 ``` 1. Vérifiez que le nombre attendu de lignes a été chargé : ``` select count(*) from biglist; count --------- 3079952 (1 row) ``` Lorsque les lignes sont ajoutés par la suite à cette table à l’aide des instructions COPY ou INSERT, les mêmes encodages de compression sont appliqués. # Optimisation de stockage pour les tables étroites Si vous avez une table avec très peu de colonnes, mais un très grand nombre de lignes, les trois colonnes d’identité de métadonnées masquées (INSERT\$1XID, DELETE\$1XID, ROW\$1ID) consomment une quantité disproportionnée de l’espace disque pour la table. Afin d’optimiser la compression des colonnes masquées, chargez la table en une seule transaction COPY chaque fois que possible. Si vous chargez la table avec plusieurs commandes COPY distinctes, la colonne INSERT\$1XID ne compresse pas correctement. Vous devez effectuer une opération VACUUM si vous utilisez plusieurs commandes COPY, mais cela n’améliore pas la compression d’INSERT\$1XID. # Chargement des valeurs par défaut des colonnes Vous pouvez le cas échéant définir une liste de colonnes dans votre commande COPY. Si une colonne de la table est omise de la liste des colonnes, COPY charge la colonne avec la valeur fournie par l’option DEFAULT qui a été spécifiée dans la commande CREATE TABLE ou avec NULL si l’option DEFAULT n’a pas été spécifiée. Si la commande COPY tente d’affecter NULL à une colonne qui est définie comme NOT NULL, elle échoue. Pour plus d’informations sur l’attribution de l’option DEFAULT, consultez [CREATE TABLE](r_CREATE_TABLE_NEW.md). Lors du chargement à partir des fichiers de données sur Amazon S3 les colonnes de la liste des colonnes doivent être dans le même ordre que les champs du fichier de données. Si un champ du fichier de données n’a pas une colonne correspondante dans la liste des colonnes, la commande COPY échoue. Lors du chargement à partir d’une table Amazon DynamoDB, l’ordre n’importe pas. Tous les champs des attributs Amazon DynamoDB qui ne correspondent pas à une colonne de la table Amazon Redshift sont ignorés. Les restrictions suivantes s’appliquent lorsque vous utilisez la commande COPY pour charger les valeurs DEFAULT dans une table : + Si une COLONNE [IDENTITY](r_CREATE_TABLE_NEW.md#identity-clause) est incluse dans la liste des colonnes, l’option EXPLICIT\$1IDS doit également être spécifiée dans la commande [COPY](r_COPY.md), sans quoi la commande COPY échoue. De même, si une colonne IDENTITY est absent de la liste des colonnes et que l’option EXPLICIT\$1IDS est spécifiée, l’opération COPY échoue. + Comme l’expression DEFAULT évaluée pour une colonne donnée est identique pour toutes les lignes chargées, une expression DEFAULT qui utilise une fonction RANDOM() se verra attribuer la même valeur pour toutes les lignes. + Les expressions DEFAULT contenant CURRENT\$1DATE ou SYSDATE sont définies sur l’horodatage de la transaction en cours. Pour obtenir un exemple, consultez « Charger les données à partir d’un fichier avec les valeurs par défaut » dans [Exemples de commandes COPY](r_COPY_command_examples.md). # Résolution des problèmes de chargement de données Lorsque vous chargez des données dans des tables Amazon Redshift, vous pouvez rencontrer des erreurs provenant d’Amazon S3, des données d’entrée non valides et des erreurs de commande COPY. Les sections suivantes fournissent des informations sur l’identification et la résolution des erreurs de chargement de données. **Topics** + [Résolution des problèmes liés à l’intégration des événements S3 et aux erreurs COPY JOB](s3-integration-troubleshooting.md) + [ServiceException Erreurs S3](s3serviceexception-error.md) + [Tables système pour la résolution des problèmes de chargement de données](system-tables-for-troubleshooting-data-loads.md) + [Erreurs de chargement de caractères multioctets](multi-byte-character-load-errors.md) + [Référence des erreurs de chargement](r_Load_Error_Reference.md) # Résolution des problèmes liés à l’intégration des événements S3 et aux erreurs COPY JOB Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations d’événements Amazon S3 et à COPY JOB avec Amazon Redshift. ## Échec de la création de l’intégration d’événéments S3 Si la création de l’intégration d’événements S3 a échoué, le statut de l’intégration est `Inactive`. Assurez-vous que les informations suivantes sont correctes pour votre entrepôt des données Amazon Redshift : + Vous avez ajouté le principal autorisé et la source d’intégration appropriés pour votre espace de noms cible dans Amazon Redshift. Consultez [Conditions préalables à la création d’une intégration d’événements S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). + Vous avez ajouté la bonne stratégie basée sur les ressources au compartiment Amazon S3 source. Consultez [Conditions préalables à la création d’une intégration d’événements S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). ## Vos données Amazon S3 n’apparaissent pas dans la base de données cible Si les données d’un COPY JOB n’apparaissent pas, vérifiez les points suivants. + Interrogez SYS\$1COPY\$1JOB\$1DETAIL pour savoir si le fichier Amazon S3 a été chargé, s’il est en attente d’ingestion ou s’il s’agit d’une erreur. Pour plus d’informations, consultez [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md). + Consultez STL\$1ERROR ou SYS\$1COPY\$1JOB\$1INFO si le fichier Amazon S3 ne s’y trouve pas ou si le temps d’attente est inattendu. Recherchez les erreurs d’identification ou tout élément indiquant que l’intégration est inactive. Pour plus d’informations, consultez [STL\$1ERROR](r_STL_ERROR.md) et [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md). # ServiceException Erreurs S3 Les ServiceException erreurs s3 les plus courantes sont causées par une chaîne d'informations d'identification mal formatée ou incorrecte, par le fait que votre cluster et votre compartiment se trouvent dans des AWS régions différentes et par des autorisations Amazon S3 insuffisantes. La section fournit des informations de dépannage pour chaque type d’erreur. ## Chaîne d’informations d’identification non valide Si votre chaîne d’informations d’identification a été incorrectement formatée, vous recevez le message d’erreur suivant : ``` ERROR: Invalid credentials. Must be of the format: credentials 'aws_access_key_id=;aws_secret_access_key= [;token=]' ``` Vérifiez que la chaîne d’informations d’identification ne contient pas d’espaces ou de sauts de ligne, et qu’elle est placée entre guillemets simples. ## ID de clé d’accès non valide Si votre ID de clé d’accès n’existe pas, vous recevez le message d’erreur suivant : ``` [Amazon](500310) Invalid operation: S3ServiceException:The AWS Access Key Id you provided does not exist in our records. ``` Il s’agit souvent d’une erreur de copier-coller. Vérifiez que l’ID de clé d’accès a été saisi correctement. Si vous utilisez des clés de séance temporaire, vérifiez que la valeur de `token` est définie. ## Clé d’accès secrète non valide Si votre clé d’accès secrète est incorrecte, vous recevrez le message d’erreur suivant : ``` [Amazon](500310) Invalid operation: S3ServiceException:The request signature we calculated does not match the signature you provided. Check your key and signing method.,Status 403,Error SignatureDoesNotMatch ``` Il s’agit souvent d’une erreur de copier-coller. Vérifiez que la clé d’accès secrète a été entrée correctement et qu’il s’agit de la bonne clé pour l’ID de clé d’accès. ## Le compartiment est dans une autre région Le compartiment Amazon S3 spécifié dans la commande COPY doit se trouver dans la même AWS région que le cluster. Si votre compartiment Amazon S3 et votre cluster sont dans des régions différentes, vous recevrez une erreur similaire à celle-ci : ``` ERROR: S3ServiceException:The bucket you are attempting to access must be addressed using the specified endpoint. ``` Vous pouvez créer un compartiment Amazon S3 dans une région spécifique en sélectionnant la région lorsque vous créez le compartiment à l’aide de la console de gestion Amazon S3 ou en spécifiant un point de terminaison lorsque vous créez le compartiment à l’aide de l’API ou de la CLI Amazon S3. Pour plus d'informations, consultez [Chargement de fichiers sur Amazon S3 à utiliser avec COPY](t_uploading-data-to-S3.md). Pour plus d’informations sur les régions Amazon S3, consultez [Accès aux compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html#access-bucket-intro) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. Vous pouvez aussi spécifier la région à l’aide de l’option [REGION](copy-parameters-data-source-s3.md#copy-region) de la commande COPY. ## Accès refusé Si l’utilisateur ne dispose pas d’autorisations suffisantes, vous recevez le message d’erreur suivant : ``` ERROR: S3ServiceException:Access Denied,Status 403,Error AccessDenied ``` L’une des causes possibles est que l’utilisateur identifié par les informations d’identification ne dispose pas d’un accès LIST et GET au compartiment Amazon S3. Pour d’autres causes, consultez [Résolution des erreurs d’accès refusé (403 interdit) dans Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html) dans le *Guide de l’utilisateur d’Amazon Simple Storage Service*. Pour plus d’informations sur la gestion de l’accès des utilisateurs aux compartiments, consultez [Identity and Access Management dans Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) dans le *Guide de l’utilisateur d’Amazon Simple Storage Service*. # Tables système pour la résolution des problèmes de chargement de données Les tables système Amazon Redshift suivantes peuvent être utiles pour le dépannage des problèmes de chargement de données : + Interrogez [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) pour découvrir les erreurs qui se sont produites lors de chargements spécifiques. + Interrogez [STL\$1FILE\$1SCAN](r_STL_FILE_SCAN.md) pour afficher les temps de chargement de fichiers spécifiques ou pour voir si un fichier spécifique a été lu. + Interrogez [STL\$1S3CLIENT\$1ERROR](r_STL_S3CLIENT_ERROR.md) pour trouver les détails des erreurs rencontrées lors du transfert de données à partir d’Amazon S3. **Pour rechercher et diagnostiquer des erreurs de chargement** 1. Créez une vue ou définissez une requête qui renvoie des informations détaillées sur les erreurs de chargement. L'exemple suivant joint la table STL\$1LOAD\$1ERRORS à la table STV\$1TBL\$1PERM pour associer la table aux noms de table réels. IDs ``` create view loadview as (select distinct tbl, trim(name) as table_name, query, starttime, trim(filename) as input, line_number, colname, err_code, trim(err_reason) as reason from stl_load_errors sl, stv_tbl_perm sp where sl.tbl = sp.id); ``` 1. Définissez l’option MAXERRORS de votre commande COPY avec une valeur assez grande pour permettre à la commande COPY de renvoyer des informations utiles sur vos données. Si COPY rencontre des erreurs, un message d’erreur vous dirige vers la consultation de la table STL\$1LOAD\$1ERRORS pour plus de détails. 1. Interrogez la vue LOADVIEW pour voir les détails de l’erreur. Par exemple : ``` select * from loadview where table_name='venue'; ``` ``` tbl | table_name | query | starttime --------+------------+-------+---------------------------- 100551 | venue | 20974 | 2013-01-29 19:05:58.365391 | input | line_number | colname | err_code | reason +----------------+-------------+---------+----------+-------------------- | venue_pipe.txt | 1 | 0 | 1214 | Delimiter not found ``` 1. Résolvez le problème dans le fichier d’entrée ou le script de chargement, en fonction des informations que la vue renvoie. Certaines erreurs de chargement classique à surveiller particulièrement : + Incompatibilité entre les types de données de la table et les valeurs des champs des données d’entrée. + Incompatibilité entre le nombre de colonnes de la table et le nombre de champs des données d’entrée. + Guillemets non appariés. Amazon Redshift prend en charge les guillemets simples et doubles ; toutefois, ces guillemets doivent être bien équilibrés. + Format incorrect pour les date/time données des fichiers d'entrée. + Out-of-range valeurs dans les fichiers d'entrée (pour les colonnes numériques). + Le nombre de valeurs distinctes pour une colonne dépasse la limite de son encodage de compression. # Erreurs de chargement de caractères multioctets Les colonnes avec un type de données CHAR acceptent uniquement les caractères UTF-8 codés sur un octet, jusqu’à la valeur d’octet 127, ou la valeur hexadécimale 7F, qui est également le jeu de caractères ASCII. Les colonnes VARCHAR acceptent les caractères UTF-8 multioctets, jusqu’à un maximum de quatre octets. Pour plus d’informations, consultez [Types caractères](r_Character_types.md). Si, dans vos données de chargement, une ligne contient un caractère non valide pour le type de données de colonne, COPY renvoie une erreur et enregistre une ligne dans la table du journal système STL\$1LOAD\$1ERRORS avec le numéro d’erreur 1220. Le champ ERR\$1REASON comprend la séquence d’octets, en hexadécimal, pour le caractère non valide. Au lieu de corriger les caractères non valides dans vos données de chargement, vous pouvez également remplacer les caractères non valides pendant le processus de chargement. Pour remplacer les caractères UTF-8 non valides, spécifiez l’option ACCEPTINVCHARS avec la commande COPY. Si l’option ACCEPTINVCHARS est définie, le caractère que vous spécifiez remplace le point de code. Si l’option ACCEPTINVCHARS n’est pas définie, Amazon Redshift accepte les caractères comme UTF-8 valides. Pour plus d'informations, consultez [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars). La liste de points de code suivante est composée d’UTF-8 valides. Les opérations COPY ne renvoient pas d’erreur si l’option ACCEPTINVCHARS n’est pas définie. Toutefois, ces points de code ne sont pas des caractères valides. Vous pouvez utiliser l’option [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars) pour remplacer un point de code par un caractère que vous spécifiez. Ces points de code incluent la plage de valeurs de `0xFDD0` à `0xFDEF` et des valeurs allant jusqu’à `0x10FFFF`, se terminant par `FFFE` ou `FFFF` : + `0xFFFE`, `0x1FFFE`, `0x2FFFE`, …, `0xFFFFE`, `0x10FFFE` + `0xFFFF`, `0x1FFFF`, `0x2FFFF`, …, `0xFFFFF`, `0x10FFFF` L’exemple suivant affiche le motif de l’erreur lorsque COPY tente de charger le caractère UTF-8 `e0 a1 c7a4` dans une colonne CHAR. ``` Multibyte character not supported for CHAR (Hint: Try using VARCHAR). Invalid char: e0 a1 c7a4 ``` Si l’erreur est liée à un type de données VARCHAR, le motif de l’erreur inclut un code d’erreur ainsi que la séquence hexadécimale UTF-8 non valide. L’exemple suivant affiche le motif de l’erreur lorsque la commande COPY tente de charger le caractère UTF-8 `a4` dans un champ VARCHAR. ``` String contains invalid or unsupported UTF-8 codepoints. Bad UTF-8 hex sequence: a4 (error 3) ``` Le tableau suivant répertorie les descriptions et les solutions de contournement suggérées pour les erreurs de chargement VARCHAR. Si l’une de ces erreurs se produit, remplacez le caractère par une séquence de code UTF-8 valide ou supprimez le caractère. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/multi-byte-character-load-errors.html) # Référence des erreurs de chargement Si des erreurs se produisent lors du chargement des données à partir d’un fichier, interrogez la table [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) afin d’identifier l’erreur et de déterminer l’explication possible. La table suivante répertorie tous les codes d’erreur qui peuvent se produire au cours des chargements de données : ## Codes d’erreur de chargement [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_Load_Error_Reference.html) # Créer une intégration d’événements S3 pour copier automatiquement des fichiers à partir de compartiments Amazon S3 **Note** La version préliminaire pour la copie automatique est terminée. Par conséquent, la version préliminaire des clusters sera automatiquement supprimée 30 jours après la fin de la période de prévisualisation. Si vous envisagez de continuer à utiliser la copie automatique, nous vous recommandons de recréer vos tâches de copie automatique existantes sur un autre cluster Amazon Redshift. La mise à niveau d’un cluster préliminaire vers la dernière version d’Amazon Redshift n’est pas prise en charge. Vous pouvez utiliser un auto-copy job pour charger des données dans vos tables Amazon Redshift à partir de fichiers stockés dans Amazon S3. Amazon Redshift détecte lorsque de nouveaux fichiers Amazon S3 sont ajoutés au chemin spécifié dans votre commande COPY. Une commande COPY est ensuite automatiquement exécutée sans que vous ayez à créer un pipeline d’ingestion de données externe. Amazon Redshift suit les fichiers qui ont été chargés. Amazon Redshift détermine le nombre de fichiers regroupés par commande COPY. Vous pouvez voir les commandes COPY qui en résultent dans les vues système. La première étape pour créer un COPY JOB automatique consiste à créer une intégration d’événements S3. Lorsqu’un nouveau fichier apparaît dans le compartiment source Amazon S3, Amazon Redshift gère ensuite le chargement des fichiers dans votre base de données à l’aide de la commande COPY. ## Conditions préalables à la création d’une intégration d’événements S3 Pour configurer l’intégration de votre événement s3, vérifiez que les prérequis suivants sont remplis. + Votre compartiment Amazon S3 doit avoir une stratégie de compartiment qui accorde plusieurs autorisations Amazon S3. Par exemple, l'exemple de politique suivant autorise des autorisations pour le compartiment `amzn-s3-demo-bucket` de ressources hébergé dans*us-east-1*. Le compartiment Amazon S3 et l’intégration se trouvent dans la même Région AWS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Auto-Copy-Policy-01", "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": [ "s3:GetBucketNotification", "s3:PutBucketNotification", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket:*", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:redshift:us-east-1:111122223333:integration:*" }, "StringEquals": { "aws:SourceAccount": "111122223333" } } } ] } ``` ------ + Votre cluster alloué Amazon Redshift cible ou votre espace de noms Redshift sans serveur cible doit avoir l’autorisation d’accéder au compartiment. Vérifiez qu’un rôle IAM associé à votre cluster ou à votre espace de noms sans serveur dispose d’une politique IAM qui accorde les autorisations appropriées. La politique doit autoriser `s3:GetObject` à la fois pour une ressource de compartiment telle que `amzn-s3-demo-bucket` et `s3:ListBucket` une ressource de compartiment et son contenu tel que `amzn-s3-demo-bucket/*`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AutoCopyReadId", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } ] } ``` ------ Ajoutez votre politique à un rôle IAM doté d’une relation de confiance pour le rôle comme suit. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Si votre entrepôt de données cible est un cluster alloué, vous pouvez associer un rôle IAM à votre cluster alloué à l’aide de la console Amazon Redshift, onglet **Autorisations de cluster** dans les détails de votre cluster. Pour plus d’informations sur la façon d’associer un rôle à votre cluster alloué, consultez la section [Associer des rôles IAM à des clusters](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role-associating-with-clusters.html) dans le *Guide de gestion Amazon Redshift*. Si votre entrepôt de données cible est Redshift sans serveur, vous pouvez associer un rôle IAM à votre espace de noms sans serveur à l’aide de la console Redshift sans serveur, onglet **Sécurité et chiffrement** dans les détails de votre espace de noms. Pour plus d’informations sur la façon d’associer un rôle à votre espace de noms sans serveur, consultez [Octroi d’autorisations à Amazon Redshift sans serveur](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-security-other-services.html) dans le *Guide de gestion Amazon Redshift*. + Votre entrepôt de données Amazon Redshift doit également disposer d’une politique de ressources autorisant le compartiment Amazon S3. Si vous utilisez la console Amazon Redshift, lorsque vous créez l’intégration d’événements s3, Amazon Redshift propose **Effectuez les corrections pour moi** permettant d’ajouter cette politique à votre entrepôt de données Amazon Redshift. Pour mettre à jour vous-même une politique de ressources, vous pouvez utiliser la [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/redshift/put-resource-policy.html) AWS CLI commande. Par exemple, pour associer une politique de ressources à votre cluster provisionné Amazon Redshift afin d'intégrer un événement S3 à un compartiment Amazon S3, exécutez une AWS CLI commande similaire à la suivante. L'exemple suivant montre une politique pour un espace de noms de cluster provisionné dans le compte *us-east-1* Région AWS for user. *123456789012* Le bucket est nommé*amzn-s3-demo-bucket*. ``` aws redshift put-resource-policy \ --policy file://rs-rp.json \ --resource-arn "arn:aws:redshift: us-east-1:123456789012:namespace/cc4ffe56-ad2c-4fd1-a5a2-f29124a56433" ``` Où `rs-rp.json` contient : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": "redshift:AuthorizeInboundIntegration", "Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/myRedshiftRole" }, "Action": "redshift:CreateInboundIntegration", "Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } } ] } ``` ------ Pour associer une politique de ressources à votre espace de noms Redshift Serverless pour l'intégration d'un événement S3 à un compartiment Amazon S3, exécutez une AWS CLI commande similaire à la suivante. L'exemple suivant montre une politique pour un espace de noms sans serveur dans le compte utilisateur *us-east-1* Région AWS for. *123456789012* Le bucket est nommé*amzn-s3-demo-bucket*. ``` aws redshift put-resource-policy \ --policy file://rs-rp.json \ --resource-arn "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1" ``` Où `rs-rp.json` contient : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": "redshift:AuthorizeInboundIntegration", "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/myUser" }, "Action": "redshift:CreateInboundIntegration", "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } } ] } ``` ------ ## Création d’une intégration d’événements S3 Pour configurer votre copy job, vous devez d’abord définir une intégration d’événements S3. ------ #### [ Amazon Redshift console ] **Pour créer une intégration d’événements Amazon S3 sur la console Amazon Redshift** 1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) 1. Dans le panneau de navigation de gauche, choisissez **Intégrations d’événements S3**. 1. Choisissez **Créer une intégration d’événements Amazon S3** pour ouvrir l’assistant et créer une intégration d’événements S3 à utiliser avec la copie automatique. Votre compartiment Amazon S3 source et votre entrepôt de données Amazon Redshift cible doivent se trouver dans la même Région AWS. Spécifiez les informations suivantes lors des étapes de création d’une intégration : + **Nom de l'intégration** — Il s'agit d'un identifiant unique pour toutes les intégrations que vous détenez Compte AWS actuellement Région AWS. + **Description** : il s’agit d’un texte qui décrit l’intégration d’événements Amazon S3 pour référence ultérieure. + **Compartiment source S3** : le compartiment Amazon S3 se trouve-t-il dans le compartiment actuel Compte AWS et Région AWS est-il à l'origine de l'ingestion de données dans Amazon Redshift ? + **Entrepôt de données Amazon Redshift** : il s’agit du cluster alloué Amazon Redshift ou groupe de travail Redshift sans serveur cible qui reçoit les données de l’intégration. Si votre Amazon Redshift cible est sur le même compte, vous pouvez sélectionner la cible. Si la cible se trouve dans un autre compte, vous devez spécifier l’**ARN de l’entrepôt de données Amazon Redshift**. La cible doit disposer d’une politique de ressources avec des principaux autorisés et une source d’intégration. Si vous n’avez pas les bonnes politiques de ressources sur la cible et que celle-ci se trouve dans le même compte, vous pouvez sélectionner l’option **Effectuez les corrections pour moi** afin d’appliquer automatiquement les politiques de ressources lors du processus de création d’intégration. Si votre cible se trouve dans une autre région Compte AWS, vous devez appliquer manuellement la politique en matière de ressources à l'entrepôt Amazon Redshift. 1. Entrez jusqu’à 50 **Clés** de balise, avec une **valeur** facultative : pour fournir des métadonnées supplémentaires sur l’intégration. 1. Une page de révision s’affiche dans laquelle vous pouvez choisir **Créer une intégration d’événements S3**. ------ #### [ AWS CLI ] Pour créer une intégration d'événements Amazon S3 à l'aide de AWS CLI, utilisez la `create-integration` commande avec les options suivantes : + `integration-name` : spécifiez le nom de l’intégration. + `source-arn` : spécifiez l’ARN du compartiment source Amazon S3. + `target-arn` : spécifiez l’ARN de l’espace de noms du cluster alloué Amazon Redshift ou du groupe de travail Redshift sans serveur cible. L’exemple suivant crée une intégration en fournissant le nom de l’intégration, l’ARN source et l’ARN cible. L’intégration n’est pas chiffrée. ``` aws redshift create-integration \ --integration-name s3-integration \ --source-arn arn:aws:s3:us-east-1::s3-example-bucket \ --target-arn arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 { "IntegrationArn": "arn:aws:redshift:us-east-1:123456789012:integration:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "IntegrationName": "s3-integration", "SourceArn": "arn:aws:s3:::s3-example-bucket", "SourceType": "s3-event-notifications", "TargetArn": "arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "Status": "creating", "Errors": [], "CreateTime": "2024-10-09T19:08:52.758000+00:00", "Tags": [] } ``` Vous pouvez également utiliser les AWS CLI commandes suivantes pour gérer l'intégration de vos événements S3. + `delete-integration` : spécifiez un ARN d’intégration pour supprimer une intégration d’événements S3. + `modify-integration` : spécifiez un ARN d’intégration pour modifier le nom ou la description (ou les deux) d’une intégration d’événements S3. + `describe-integrations` : spécifiez un ARN d’intégration pour afficher les propriétés d’une intégration d’événements S3. Consultez le [https://docs.aws.amazon.com/cli/latest/reference/redshift/](https://docs.aws.amazon.com/cli/latest/reference/redshift/) pour plus d’informations sur ces commandes. ------ Amazon Redshift crée ensuite une intégration d’événements S3 avec la source et la cible associées, le statut et les informations relatives au statut d’une tâche de copie automatique associée. Vous pouvez consulter les informations relatives à une intégration d’événements S3 sur la console Amazon Redshift en choisissant **Intégrations d’événements S3** et en choisissant l’intégration pour en afficher les détails. Les intégrations sont séparées par celles créées **Dans mon compte** et celles **D’autres comptes**. La liste **Dans mon compte** indique les intégrations où la source et la cible se trouvent dans le même compte. La liste **D’autres comptes** indique les intégrations dans lesquelles la source appartient à un autre compte. Si vous supprimez une intégration d’événements S3, le statut COPY JOB correspondant passe de `1` (actif) à `0` (inactif/en attente). Cependant, le COPY JOB correspondant n’est pas automatiquement supprimé. Si vous essayez ultérieurement de créer un COPY JOB portant le même nom, il se peut qu’il y ait un conflit. ## Création et suivi d’un COPY JOB Une fois l’intégration créée, sur la page **Détails de l’intégration d’événements S3** correspondant à l’intégration que vous avez créée, choisissez **Créer une tâche de copie automatique** pour accéder à Amazon Redshift Query Editor V2 où vous pouvez créer la tâche de copie automatique pour l’intégration. Amazon Redshift fait correspondre le compartiment de la clause FROM de l’instruction COPY JOB CREATE au compartiment utilisé pour l’intégration d’événements S3. Pour plus d’informations sur l’utilisation d’Amazon Redshift Query Editor V2, consultez [Interrogation d’une base de données à l’aide d’Amazon Redshift Query Editor V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2.html) dans le *Guide de gestion Amazon Redshift*. Par exemple, exécutez la commande COPY suivante dans l’éditeur de requêtes v2 pour créer un COPY JOB automatique qui associe le compartiment Amazon S3 `s3://amzn-s3-demo-bucket/staging-folder` à une intégration d’événements Amazon S3. ``` COPY public.target_table FROM 's3://amzn-s3-demo-bucket/staging-folder' IAM_ROLE 'arn:aws:iam::123456789012:role/MyLoadRoleName' JOB CREATE my_copy_job_name AUTO ON; ``` Vous définissez une COPY JOB une seule fois. Les mêmes paramètres sont utilisés pour les future exécutions. Pour définir et gérer un COPY JOB, vous devez disposer d’une autorisation. Pour plus d’informations sur l’octroi et la révocation d’une autorisation sur un COPY JOB, consultez [GRANT](r_GRANT.md) et [REVOKE](r_REVOKE.md). Pour plus d’informations sur l’octroi et la révocation d’autorisations étendues pour un COPY JOB, consultez [Octroi d’autorisations étendues](r_GRANT.md#grant-scoped-syntax) et [Révocation d’autorisations étendues](r_REVOKE.md#revoke-scoped-permissions). Vous gérez les opérations de chargement à l’aide des options CREATE, LIST, SHOW, DROP, ALTER et RUN des tâches. Pour plus d’informations, consultez [COPY JOB](r_COPY-JOB.md). Vous pouvez interroger les vues du système pour voir le statut et la progression de COPY JOB. Les vues sont fournies comme suit : + [SYS\$1COPY\$1JOB](SYS_COPY_JOB.md) – contient une ligne pour chaque COPY JOB actuellement définie. + [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md) : contient des informations sur les fichiers en attente, en erreur et ingérés pour chaque COPY JOB. + [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md) : contient les messages enregistrés à propos d’un COPY JOB. + [SYS\$1LOAD\$1HISTORY](SYS_LOAD_HISTORY.md) – contient des informations détaillées sur les commandes COPY. + [SYS\$1LOAD\$1ERROR\$1DETAIL](SYS_LOAD_ERROR_DETAIL.md) – contient des informations détaillées sur les erreurs de commande COPY. + [SVV\$1COPY\$1JOB\$1INTEGRATIONS](SVV_COPY_JOB_INTEGRATIONS.md) : contient des informations détaillées sur les intégrations d’événements S3. + [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) – contient des erreurs provenant des commandes COPY. + [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) – contient des informations permettant de résoudre les problèmes liés au chargement des données d’une commande COPY. Pour plus d’informations sur la résolution des erreurs d’intégration d’événements S3, consultez [Résolution des problèmes liés à l’intégration des événements S3 et aux erreurs COPY JOB](s3-integration-troubleshooting.md). Pour obtenir la liste des fichiers chargés par un COPY JOB, exécutez le code SQL suivant, mais remplacez d'abord ** : ``` SELECT job_id, job_name, data_source, copy_query, filename, status, curtime FROM sys_copy_job copyjob JOIN stl_load_commits loadcommit ON copyjob.job_id = loadcommit.copy_job_id WHERE job_id = ; ``` ## Considérations relatives à la création d’une intégration d’événements S3 pour la copie automatique Tenez compte des éléments suivants lorsque vous utilisez la copie automatique. + Vous pouvez créer un maximum de 200 COPY JOBS pour chaque cluster ou groupe de travail d’un Compte AWS. + Vous pouvez créer 50 intégrations d’événements S3 pour chaque cible Amazon Redshift. + Vous ne pouvez pas créer d’intégration d’événements S3 avec un compartiment Amazon S3 source dont le nom du compartiment comporte un point (.). + Vous ne pouvez créer qu’une seule intégration d’événements S3 entre la même source et la même cible. En d’autres termes, il ne peut y avoir qu’une seule intégration d’événements S3 entre un compartiment Amazon S3 et un entrepôt de données Amazon Redshift à la fois. + Vous ne pouvez pas avoir de notifications d’événement existantes pour le type d’événement `S3_OBJECT_CREATED` défini dans le compartiment Amazon S3 source. Cependant, une fois l'intégration d'un événement S3 créée, vous pouvez mettre à jour la notification d'événement du compartiment Amazon S3 prefix/suffix avec une portée plus restreinte. De cette façon, vous pouvez également effectuer une configuration `S3_OBJECT_CREATED` prefix/suffix pour une autre cible et éviter tout conflit avec l'intégration des événements S3. Si vous rencontrez des problèmes liés au fait que la copie automatique ne s'exécute pas comme prévu, préparez le AWS CloudTrail journal de l'`s3:PutBucketNotificationConfiguration`action sur votre compartiment S3 pour la période en question lorsque vous contactez AWS Support. ## Régions prises en charge Voici les régions AWS disponibles pour la copie automatique. | Région | Copie automatique | | --- | --- | | Afrique (Le Cap) | Available | | Asie-Pacifique (Hong Kong) | Available | | Asie-Pacifique (Taipei) | Available | | Asie-Pacifique (Tokyo) | Available | | Asie-Pacifique (Séoul) | Available | | Asie-Pacifique (Osaka) | Available | | Asie-Pacifique (Mumbai) | Available | | Asie-Pacifique (Hyderabad) | Available | | Asie-Pacifique (Singapour) | Available | | Asie-Pacifique (Sydney) | Available | | Asie-Pacifique (Jakarta) | Available | | Asie-Pacifique (Melbourne) | Available | | Asie-Pacifique (Malaisie) | Available | | Asie-Pacifique (Nouvelle Zélande) | Non disponible | | Asie-Pacifique (Thaïlande) | Available | | Canada (Centre) | Available | | Canada-Ouest (Calgary) | Available | | Chine (Pékin) | Available | | Chine (Ningxia) | Available | | Europe (Francfort) | Available | | Europe (Zurich) | Available | | Europe (Stockholm) | Available | | Europe (Milan) | Available | | Europe (Espagne) | Available | | Europe (Irlande) | Available | | Europe (Londres) | Available | | Europe (Paris) | Available | | Israël (Tel Aviv) | Available | | Moyen-Orient (EAU) | Available | | Middle East (Bahrain) | Available | | Mexique (Centre) | Available | | Amérique du Sud (São Paulo) | Available | | USA Est (Virginie du Nord) | Available | | USA Est (Ohio) | Available | | USA Ouest (Californie du Nord) | Available | | USA Ouest (Oregon) | Available | | AWS GovCloud (USA Est) | Available | | AWS GovCloud (US-Ouest) | Available | # Chargement de tables avec les commandes DML Amazon Redshift prend en charge les commandes standard du langage de manipulation de données (INSERT, UPDATE et DELETE), que vous pouvez utiliser pour modifier les lignes des tables. Vous pouvez aussi utiliser la commande TRUNCATE pour des suppressions en bloc rapides. **Note** Nous vous encourageons vivement à utiliser la commande [COPY](r_COPY.md) pour charger de grandes quantités de données. La lenteur liée à l’utilisation d’instructions INSERT pour remplir une table peut être prohibitive. Sinon, si vos données existent déjà dans d’autres tables de bases de données Amazon Redshift, utilisez INSERT INTO ... SELECT FROM ou CREATE TABLE AS pour améliorer les performances. Pour plus d’informations, consultez [INSERT](r_INSERT_30.md) ou [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Si vous insérez, mettez à jour ou supprimez un nombre important de lignes dans une table, par rapport au nombre de lignes avant les modifications, exécutez les commandes ANALYZE et VACUUM sur la table lorsque vous avez terminé. Si un certain nombre de petites modifications s’accumulent au fil du temps dans votre application, vous souhaiterez peut-être planifier les commandes ANALYZE et VACUUM pour qu’elles s’exécutent à intervalles réguliers. Pour plus d’informations, consultez [Analyse des tables](t_Analyzing_tables.md) et [Exécution de l’opération VACUUM sur les tables](t_Reclaiming_storage_space202.md). **Topics** + [Mise à jour et insertion de nouvelles données](t_updating-inserting-using-staging-tables-.md) # Mise à jour et insertion de nouvelles données Vous pouvez ajouter de manière efficace de nouvelles données à une table existante à l’aide de la commande MERGE. Effectuez une opération de fusion en créant une table intermédiaire, puis utilisez l’une des méthodes décrites dans cette section pour mettre à jour la table cible à partir de la table intermédiaire. Pour en savoir plus sur la commande MERGE, consultez [MERGE](r_MERGE.md). [Exemples de fusion](merge-examples.md) utilise un exemple de jeu de données pour Amazon Redshift, appelé jeu de données TICKIT. Comme condition préalable, vous pouvez configurer les tables et les données TICKIT en suivant les instructions disponibles dans [Démarrage avec les tâches courantes liées aux bases de données](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Des informations plus détaillées sur le jeu de données en exemple sont disponibles dans la [base de données en exemple](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). ## Méthode de fusion 1 : remplacement des lignes existantes Si vous remplacez toutes les colonnes de la table cible, le moyen le plus rapide d’effectuer une fusion est de remplacer les lignes existantes. La table cible est analysée une seule fois, et une jointure interne est utilisée pour supprimer les lignes qui sont appelées à être mises à jour. Une fois que les lignes ont été supprimées, elles sont remplacées par de nouvelles lignes via une opération d’insertion unique à partir de la table intermédiaire. Utilisez cette méthode si toutes les conditions suivantes sont vraies : + Votre table cible votre table intermédiaire contiennent les mêmes colonnes. + Vous avez l’intention de remplacer toutes les données des colonnes de la table cible par toutes les colonnes de la table intermédiaire. + Vous allez utiliser toutes les lignes de la table intermédiaire dans la fusion. Si l’un de ces critères ne s’applique pas, utilisez la méthode de fusion 2 : spécification d’une liste de colonnes sans utiliser MERGE, décrite dans la section suivante. Si vous n’utilisez pas toutes les lignes de la table intermédiaire, filtrez les instructions DELETE et INSERT en utilisant une clause WHERE pour ignorer les lignes qui ne sont pas modifiées. Cependant, si la plupart des lignes de la table intermédiaire ne prennent pas part à la fusion, nous recommandons d’exécuter les commandes UPDATE et INSERT en étapes distinctes, comme décrit ultérieurement dans cette section. ## Méthode de fusion 2 : spécification d’une liste de colonnes sans utiliser MERGE Utilisez cette méthode pour mettre à jour des colonnes spécifiques de la table cible au lieu de remplacer des lignes entières. Cette méthode prend plus de temps que la méthode précédente, car elle nécessite une étape de mise à jour supplémentaire et elle n’utilise pas la commande MERGE. Utilisez cette méthode si l’une des conditions suivantes est vraie : + Certaines colonnes de la table cible ne doivent pas être mises à jour. + La plupart des lignes de la table intermédiaire ne sont pas utilisées dans les mises à jour. **Topics** + [Méthode de fusion 1 : remplacement des lignes existantes](#merge-method-replace-existing-rows) + [Méthode de fusion 2 : spécification d’une liste de colonnes sans utiliser MERGE](#merge-method-specify-column-list) + [Création d’une table temporaire intermédiaire](merge-create-staging-table.md) + [Exécution d’une opération de fusion par remplacement des lignes existantes](merge-replacing-existing-rows.md) + [Exécution d’une opération de fusion en spécifiant une liste de colonnes sans utiliser la commande MERGE](merge-specify-a-column-list.md) + [Exemples de fusion](merge-examples.md) # Création d’une table temporaire intermédiaire La *table intermédiaire* est une table temporaire qui contient toutes les données qui seront utilisées pour apporter des modifications à la *table cible*, mises à jour et insertions incluses. Une opération de fusion nécessite une jointure entre la table intermédiaire et la table cible. Pour rassembler les lignes de la jointure, définissez la clé de distribution de la table intermédiaire avec la même colonne que la clé de distribution de la table cible. Par exemple, si la table cible utilise une colonne de clé étrangère comme clé de distribution, utilisez la même colonne pour la clé de distribution de la table intermédiaire. Si vous créez la table intermédiaire à l’aide d’une instruction [CREATE TABLE LIKE](r_CREATE_TABLE_NEW.md#create-table-like), la table intermédiaire hérite de la clé de distribution de la table parent. Si vous utilisez une instruction CREATE TABLE AS, la nouvelle table n’hérite pas de la clé de distribution. Pour plus d'informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md) Si la clé de distribution n’est pas la même que la clé primaire et que la clé de distribution n’est pas mise à jour dans le cadre de l’opération de fusion, ajoutez un prédicat de jointure redondant sur les colonnes de clé de distribution pour permettre une jointure colocalisée. Par exemple : ``` where target.primarykey = stage.primarykey and target.distkey = stage.distkey ``` Pour vérifier que la requête utilise une jointure colocalisée, exécutez la requête avec [EXPLAIN](r_EXPLAIN.md) et recherchez DS\$1DIST\$1NONE sur l’ensemble des jointures. Pour plus d'informations, consultez [Évaluation du plan de requête](c_data_redistribution.md) # Exécution d’une opération de fusion par remplacement des lignes existantes Exécutez la totalité de l’opération de fusion détaillée dans la procédure, sauf la création et la suppression de la table intermédiaire temporaire, dans une même transaction. La transaction est annulée en cas d’échec d’une étape. L’utilisation d’une seule transaction réduit aussi le nombre de validations, ce qui permet de gagner du temps et d’économiser des ressources. **Pour exécuter une opération de fusion par remplacement des lignes existantes** 1. Créez une table intermédiaire, puis complétez-la avec les données à fusionner, comme illustré dans le pseudocode suivant. ``` CREATE temp table stage (like target); INSERT INTO stage SELECT * FROM source WHERE source.filter = 'filter_expression'; ``` 1. Utilisez MERGE pour effectuer une jointure interne avec la table intermédiaire afin de mettre à jour les lignes de la table cible qui ont une correspondance dans la table intermédiaire, puis insérez toutes les lignes restantes dans la table cible qui n’ont pas de correspondance dans la table intermédiaire. Nous vous recommandons d’exécuter les opérations de mise à jour et d’insertion dans une même commande MERGE. ``` MERGE INTO target USING stage [optional alias] on (target.primary_key = stage.primary_key) WHEN MATCHED THEN UPDATE SET col_name1 = stage.col_name1 , col_name2= stage.col_name2, col_name3 = {expr} WHEN NOT MATCHED THEN INSERT (col_name1 , col_name2, col_name3) VALUES (stage.col_name1, stage.col_name2, {expr}); ``` 1. Supprimez la table intermédiaire. ``` DROP TABLE stage; ``` # Exécution d’une opération de fusion en spécifiant une liste de colonnes sans utiliser la commande MERGE Exécutez la totalité de l’opération de fusion détaillée dans la procédure dans une même transaction. La transaction est annulée en cas d’échec d’une étape. L’utilisation d’une seule transaction réduit aussi le nombre de validations, ce qui permet de gagner du temps et d’économiser des ressources. **Pour exécuter une opération de fusion par spécification d’une liste de colonnes** 1. Placez l’ensemble de l’opération dans un seul bloc de transactions. ``` BEGIN transaction; … END transaction; ``` 1. Créez une table intermédiaire, puis complétez-la avec les données à fusionner, comme illustré dans le pseudocode suivant. ``` create temp table stage (like target); insert into stage select * from source where source.filter = 'filter_expression'; ``` 1. Mettez à jour la table cible à l’aide d’une jointure interne avec la table intermédiaire. + Dans la clause UPDATE, listez explicitement les colonnes à mettre à jour. + Effectuez une jointure interne avec la table intermédiaire. + Si la clé de distribution est différente de la clé primaire et que la clé de distribution n’est pas mise à jour, ajoutez une jointure redondante sur la clé de distribution. Pour vérifier que la requête utilise une jointure colocalisée, exécutez la requête avec [EXPLAIN](r_EXPLAIN.md) et recherchez DS\$1DIST\$1NONE sur l’ensemble des jointures. Pour plus d'informations, consultez [Évaluation du plan de requête](c_data_redistribution.md) + Si votre table cible est triée par horodatage, ajoutez un prédicat pour tirer parti des analyses à plage restreinte sur la table cible. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md). + Si vous n’utilisez pas toutes les lignes de la fusion, ajoutez une clause pour filtrer les lignes que vous ne voulez pas modifier. Par exemple, ajoutez un filtre d’inégalité sur une ou plusieurs colonnes afin d’exclure les lignes qui n’ont pas changé. + Placez les opérations de mise à jour, de suppression et d’insertion dans un même bloc de transaction de telle sorte qu’en cas de problème, tout puisse être annulé. Par exemple : ``` begin transaction; update target set col1 = stage.col1, col2 = stage.col2, col3 = 'expression' from stage where target.primarykey = stage.primarykey and target.distkey = stage.distkey and target.col3 > 'last_update_time' and (target.col1 != stage.col1 or target.col2 != stage.col2 or target.col3 = 'filter_expression'); ``` 1. Supprimez les lignes superflues de la table intermédiaire à l’aide d’une jointure interne avec la table cible. Certaines lignes de la table cible correspondent déjà aux lignes correspondantes de la table intermédiaire, tandis que d’autres ont été mises à jour lors de l’étape précédente. Dans les deux cas, elles ne sont pas nécessaires pour l’insertion. ``` delete from stage using target where stage.primarykey = target.primarykey; ``` 1. Insérez les lignes restantes de la table intermédiaire. Utilisez la même liste de la colonne dans la clause VALUES que celle que vous avez utilisée dans l’instruction UPDATE à l’étape 2. ``` insert into target (select col1, col2, 'expression' from stage); end transaction; ``` 1. Supprimez la table intermédiaire. ``` drop table stage; ``` # Exemples de fusion Les exemples suivants effectuent une fusion pour mettre à jour la table SALES. Le premier exemple utilise la méthode la plus simple pour supprimer les lignes de la table cible, puis insérer toutes les lignes de la table intermédiaire. Comme le deuxième exemple nécessite une mise à jour des colonnes de la sélection, elle inclut une étape de mise à jour supplémentaire. [Exemples de fusion](#merge-examples) utilise un exemple de jeu de données pour Amazon Redshift, appelé jeu de données TICKIT. Comme condition préalable, vous pouvez configurer les tables et les données TICKIT en suivant les instructions disponibles dans le guide [Démarrage avec les tâches courantes liées aux bases de données](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Des informations plus détaillées sur le jeu de données en exemple sont disponibles dans la [base de données en exemple](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). **Exemple de source de données de fusion** Les exemples de cette section nécessitent un exemple de source de données qui inclut les mises à jour et les insertions. Pour les exemples, nous allons créer un exemple de table nommée SALES\$1UPDATE qui utilise les données de la table SALES. Nous allons remplir la nouvelle table avec des données aléatoires qui représentant les nouvelles activités de vente pour décembre. Nous allons utiliser l’exemple de table SALES\$1UPDATE pour créer la table intermédiaire dans les exemples suivants. ``` -- Create a sample table as a copy of the SALES table. create table tickit.sales_update as select * from tickit.sales; -- Change every fifth row to have updates. update tickit.sales_update set qtysold = qtysold*2, pricepaid = pricepaid*0.8, commission = commission*1.1 where saletime > '2008-11-30' and mod(sellerid, 5) = 0; -- Add some new rows to have inserts. -- This example creates a duplicate of every fourth row. insert into tickit.sales_update select (salesid + 172456) as salesid, listid, sellerid, buyerid, eventid, dateid, qtysold, pricepaid, commission, getdate() as saletime from tickit.sales_update where saletime > '2008-11-30' and mod(sellerid, 4) = 0; ``` **Exemple de fusion qui remplace les lignes existantes sur la base de clés correspondantes** Le script suivant utilise la table SALES\$1UPDATE pour effectuer une opération de fusion sur la table SALES avec de nouvelles données pour l’activité de vente de décembre. Cet exemple remplace les lignes de la table SALES qui ont été mises à jour. Pour cet exemple, nous allons mettre à jour les colonnes qtysold et pricepaid, mais laisser commission et saletime inchangées. ``` MERGE into tickit.sales USING tickit.sales_update sales_update on ( sales.salesid = sales_update.salesid and sales.listid = sales_update.listid and sales_update.saletime > '2008-11-30' and (sales.qtysold != sales_update.qtysold or sales.pricepaid != sales_update.pricepaid)) WHEN MATCHED THEN update SET qtysold = sales_update.qtysold, pricepaid = sales_update.pricepaid WHEN NOT MATCHED THEN INSERT (salesid, listid, sellerid, buyerid, eventid, dateid, qtysold , pricepaid, commission, saletime) values (sales_update.salesid, sales_update.listid, sales_update.sellerid, sales_update.buyerid, sales_update.eventid, sales_update.dateid, sales_update.qtysold , sales_update.pricepaid, sales_update.commission, sales_update.saletime); -- Drop the staging table. drop table tickit.sales_update; -- Test to see that commission and salestime were not impacted. SELECT sales.salesid, sales.commission, sales.salestime, sales_update.commission, sales_update.salestime FROM tickit.sales INNER JOIN tickit.sales_update sales_update ON sales.salesid = sales_update.salesid AND sales.listid = sales_update.listid AND sales_update.saletime > '2008-11-30' AND (sales.commission != sales_update.commission OR sales.salestime != sales_update.salestime); ``` **Exemple de fusion qui spécifie une liste de colonnes sans utiliser MERGE** L’exemple suivant effectue une opération de fusion pour mettre à jour SALES avec de nouvelles données pour l’activité de vente de décembre. Nous avons besoin d’exemples de données qui incluent les opérations de mise à jour et d’insertion, ainsi que les lignes qui n’ont pas changé. Pour cet exemple, nous voulons mettre à jour les colonnes QTYSOLD et PRICEPAID, mais laisser COMMISSION et SALETIME telles quelles. Le script suivant utilise la table SALES\$1UPDATE pour effectuer une opération de fusion sur la table SALES. ``` -- Create a staging table and populate it with rows from SALES_UPDATE for Dec create temp table stagesales as select * from sales_update where saletime > '2008-11-30'; -- Start a new transaction begin transaction; -- Update the target table using an inner join with the staging table -- The join includes a redundant predicate to collocate on the distribution key –- A filter on saletime enables a range-restricted scan on SALES update sales set qtysold = stagesales.qtysold, pricepaid = stagesales.pricepaid from stagesales where sales.salesid = stagesales.salesid and sales.listid = stagesales.listid and stagesales.saletime > '2008-11-30' and (sales.qtysold != stagesales.qtysold or sales.pricepaid != stagesales.pricepaid); -- Delete matching rows from the staging table -- using an inner join with the target table delete from stagesales using sales where sales.salesid = stagesales.salesid and sales.listid = stagesales.listid; -- Insert the remaining rows from the staging table into the target table insert into sales select * from stagesales; -- End transaction and commit end transaction; -- Drop the staging table drop table stagesales; ``` # Exécution d’une copie complète Une copie recrée et remplit une table à l’aide d’une insertion en bloc, qui trie automatiquement la table. Si une table possède une grande région non triée, une copie complète est beaucoup plus rapide qu’une opération VACUUM. Nous vous recommandons d’effectuer des mises à jour simultanées dans le cadre d’une opération de copie complète seulement si vous pouvez en assurer le suivi. Une fois le processus terminé, déplacez les mises à jour delta dans la nouvelle table. Une opération VACUUM prend automatiquement en charge les mises à jour simultanées. Vous pouvez choisir l’une des quatre méthodes pour créer une copie de la table d’origine : + Utilisez la table DDL d’origine. Si la commande CREATE TABLE DDL est disponible, il s’agit de la méthode préférée et la plus rapide. Si vous créez une nouvelle table, vous pouvez spécifier tous les attributs de table et de colonne, y compris la clé primaire et les clés étrangères. Vous pouvez trouver le DDL d’origine à l’aide de la fonction SHOW TABLE. + Utilisez CREATE TABLE LIKE. Si le DDL d’origine n’est pas disponible, vous pouvez utiliser CREATE TABLE LIKE pour recréer la table d’origine. La nouvelle table hérite des attributs encoding, distribution key, sort key et not-null de la table parent. La nouvelle table n’hérite pas de la clé primaire et des attributs de clés étrangères de la table parent, mais vous pouvez les ajouter avec [ALTER TABLE](r_ALTER_TABLE.md). + Créez une table temporaire et tronquez la table d’origine. Si vous devez conserver les attributs de clé primaire et de clé étrangère de la table parent. Si la table parent présente des dépendances, vous pouvez utiliser CREATE TABLE ... AS (CTAS) pour créer une table temporaire. Tronquez ensuite la table d’origine et remplissez-la à partir de la table temporaire. L’utilisation d’une table temporaire améliore les performances de façon significative par rapport à l’utilisation d’une table permanente, mais il existe un risque de perte des données. Une table temporaire est automatiquement supprimée à la fin de la séance dans laquelle elle a été créée. TRUNCATE valide immédiatement, même à l’intérieur d’un bloc de transaction. Si l’opération TRUNCATE réussit, mais que la session s’arrête avant la fin de l’opération INSERT suivante, les données sont perdues. Si la perte de données n’est pas acceptable, utilisez une table permanente. Après avoir créé une copie d’une table, vous pouvez être amené à accorder l’accès à la nouvelle table. Vous pouvez utiliser [GRANT](r_GRANT.md) pour définir les privilèges d’accès. Pour consulter et octroyer tous les privilèges d’accès d’une table, vous devez être l’une des personnes suivantes : + Un super-utilisateur. + Le propriétaire de la table que vous souhaitez copier. + Un utilisateur disposant du privilège ACCESS SYSTEM TABLE pour consulter les privilèges de la table et du privilège d’octroi pour toutes les autorisations pertinentes. En outre, vous pouvez être amené à octroyer une autorisation d’utilisation pour le schéma dans lequel se trouve votre copie complète. L’octroi d’une autorisation d’utilisation est nécessaire si le schéma de votre copie complète est différent du schéma de la table d’origine, et s’il ne s’agit pas non plus du schéma `public`. Pour consulter et octroyer des privilèges d’utilisation, vous devez être l’une des personnes suivantes : + Un super-utilisateur. + Un utilisateur pouvant octroyer l’autorisation USAGE pour le schéma de la copie complète. **Pour exécuter une copie complète à l’aide de la table DDL d’origine** 1. (Facultatif) Recréez la table DDL en exécutant un script appelé `v_generate_tbl_ddl`. 1. Créer une copie de la table à l’aide du CREATE TABLE DDL d’origine. 1. Utilisez une instruction INSERT INTO … SELECT pour remplir la copie avec les données de la table d’origine. 1. Vérifiez les autorisations octroyées pour l’ancienne table. Vous pouvez trouver ces autorisations dans la vue système SVV\$1RELATION\$1PRIVILEGES. 1. Si nécessaire, accordez les autorisations de l’ancienne table à la nouvelle. 1. Accordez l’autorisation d’utilisation à tous les groupes et utilisateurs qui disposent de privilèges dans la table d’origine. Cette étape n’est pas nécessaire si la table de la copie complète se trouve dans le schéma `public` ou dans le même schéma que la table d’origine. 1. Supprimez la table d’origine. 1. Utilisez une instruction ALTER TABLE pour renommer la copie avec le nom d’origine de la table. L’exemple suivant effectue une copie complète de la table SAMPLE en utilisant un double de SAMPLE nommé sample\$1copy. ``` --Create a copy of the original table in the sample_namespace namespace using the original CREATE TABLE DDL. create table sample_namespace.sample_copy ( … ); --Populate the copy with data from the original table in the public namespace. insert into sample_namespace.sample_copy (select * from public.sample); --Check SVV_RELATION_PRIVILEGES for the original table's privileges. select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type; --Grant the original table's privileges to the copy table. grant DELETE on table sample_namespace.sample_copy to group group1; grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2; grant SELECT on table sample_namespace.sample_copy to user1; grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2; --Grant usage permission to every group and user that has privileges in the original table. grant USAGE on schema sample_namespace to group group1, group group2, user1, user2; --Drop the original table. drop table public.sample; --Rename the copy table to match the original table's name. alter table sample_namespace.sample_copy rename to sample; ``` **Pour effectuer une copie complète à l’aide de CREATE TABLE LIKE** 1. Créez une table à l’aide de CREATE TABLE LIKE. 1. Utilisez une instruction INSERT INTO … SELECT pour copier les lignes de la table en cours vers la nouvelle table. 1. Vérifiez les autorisations octroyées pour l’ancienne table. Vous pouvez trouver ces autorisations dans la vue système SVV\$1RELATION\$1PRIVILEGES. 1. Si nécessaire, accordez les autorisations de l’ancienne table à la nouvelle. 1. Accordez l’autorisation d’utilisation à tous les groupes et utilisateurs qui disposent de privilèges dans la table d’origine. Cette étape n’est pas nécessaire si la table de la copie complète se trouve dans le schéma `public` ou dans le même schéma que la table d’origine. 1. Supprimez la table actuelle. 1. Utilisez une instruction ALTER TABLE pour renommer la nouvelle table avec le nom d’origine de la table. L’exemple suivant effectue une copie complète de la table SAMPLE à l’aide de CREATE TABLE LIKE. ``` --Create a copy of the original table in the sample_namespace namespace using CREATE TABLE LIKE. create table sameple_namespace.sample_copy (like public.sample); --Populate the copy with data from the original table. insert into sample_namespace.sample_copy (select * from public.sample); --Check SVV_RELATION_PRIVILEGES for the original table's privileges. select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type; --Grant the original table's privileges to the copy table. grant DELETE on table sample_namespace.sample_copy to group group1; grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2; grant SELECT on table sample_namespace.sample_copy to user1; grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2; --Grant usage permission to every group and user that has privileges in the original table. grant USAGE on schema sample_namespace to group group1, group group2, user1, user2; --Drop the original table. drop table public.sample; --Rename the copy table to match the original table's name. alter table sample_namespace.sample_copy rename to sample; ``` **Pour effectuer une copie en créant une table temporaire et en tronquant la table d’origine** 1. Utilisez CREATE TABLE AS pour créer une table temporaire avec les lignes de la table d’origine. 1. Tronquez la table en cours. 1. Utilisez une instruction INSERT INTO … SELECT pour copier les lignes de la table temporaire vers la table d’origine. 1. Suppression de la table temporaire. L’exemple suivant effectue une copie complète de la table SALES en créant une table temporaire et en tronquant la table d’origine. Comme la table d’origine est conservée, vous n’avez pas besoin d’accorder d’autorisations à la table de copie. ``` --Create a temp table copy using CREATE TABLE AS. create temp table salestemp as select * from sales; --Truncate the original table. truncate sales; --Copy the rows from the temporary table to the original table. insert into sales (select * from salestemp); --Drop the temporary table. drop table salestemp; ``` # Analyse des tables L’opération ANALYZE met à jour les métadonnées statistiques que le planificateur de requête utilise pour choisir les plans optimaux. Dans la plupart des cas, vous n’avez pas besoin d’exécuter explicitement la commande ANALYZE. Amazon Redshift surveille les modifications apportées à votre application et met à jour automatiquement les statistiques en arrière-plan. De plus, la commande COPY effectue automatiquement une analyse lorsqu’elle charge des données dans une table vide. Pour analyser explicitement une table ou la base de données complète, exécutez la commande [ANALYSE](r_ANALYZE.md). ## Analyse automatique Amazon Redshift surveille en permanence votre base de données et effectue automatiquement des opérations d’analyse en arrière-plan. Pour réduire au maximum l’impact sur vos performances système, l’analyse automatique s’exécute pendant les périodes où les charges de travail sont légères. L’analyse automatique est activée par défaut. Pour désactiver l’analyse automatique, attribuez au paramètre `auto_analyze` la valeur **false** en modifiant le groupe de paramètres de votre cluster. Pour réduire le temps de traitement et améliorer les performances globales du système, Amazon Redshift ignore l’analyse automatique pour toute table dont l’ampleur des modifications est petite. Une opération d'analyse ignore les tables contenant des up-to-date statistiques. Si vous exécutez ANALYZE dans le cadre de votre flux de travail ETL (extraction, transformation et chargement), l’analyse automatique ignore les tables dont les statistiques sont à jour. De façon similaire, une opération ANALYZE explicite ignore les tables pour lesquelles l’analyse automatique a mis à jour les statistiques. ## Analyse des données des nouvelles tables Par défaut, la commande COPY effectue une opération ANALYZE après avoir chargé des données dans une table vide. Vous pouvez forcer une opération ANALYZE, indépendamment du fait qu’une table soit vide ou non, en définissant STATUPDATE avec la valeur ON. Si vous spécifiez STATUPDATE OFF, l’opération ANALYZE n’est pas effectuée. Seul le propriétaire de la table ou un super-utilisateur peut exécuter la commande ANALYZE ou la commande COPY avec STATUPDATE ayant ON comme valeur. Amazon Redshift analyse également les nouvelles tables que vous créez avec les commandes suivantes : + CREATE TABLE AS (CTAS) + CREATE TEMP TABLE AS + SELECT INTO Amazon Redshift renvoie un message d’avertissement lorsque vous exécutez une requête sur une nouvelle table qui n’a pas été analysée après le chargement initial de ses données. Aucun avertissement n’est fourni lorsque vous interrogez une table après un chargement ou une mise à jour ultérieur(e). Le même message d’avertissement est renvoyé lorsque vous exécutez la commande EXPLAIN sur une requête qui référence des tables qui n’ont pas été analysées. Chaque fois qu’un ajout de données à une table non vide modifie de façon importante la taille de la table, vous pouvez mettre à jour explicitement les statistiques. Pour ce faire, vous pouvez exécuter une commande ANALYZE ou utiliser l’option STATUPDATE ON avec la commande COPY. Pour afficher les détails du nombre de lignes qui ont été insérées ou supprimées depuis la dernière opération ANALYZE, interrogez la table catalogue système [PG\$1STATISTIC\$1INDICATOR](r_PG_STATISTIC_INDICATOR.md). Vous pouvez définir la portée de la commande [ANALYSE](r_ANALYZE.md) en spécifiant l’une des valeurs suivantes : + La totalité de la base de données actuelle + Une seule table + Une ou plusieurs colonnes spécifiques d’une seule table + Colonnes qui sont susceptibles d’être utilisées comme prédicats dans des requêtes La commande ANALYZE obtient un échantillon de lignes de la table, effectue quelques calculs et enregistre les statistiques de colonnes obtenues. Par défaut, Amazon Redshift exécute un exemple de passage pour la colonne DISTKEY et un autre exemple de passage pour toutes les autres colonnes de la table. Si vous souhaitez générer des statistiques pour un sous-ensemble de colonnes, vous pouvez spécifier une liste de colonnes séparées par des virgules. Vous pouvez exécuter ANALYZE avec la clause PREDICATE COLUMNS pour ignorer les colonnes qui ne sont pas utilisées comme prédicats. Comme les opérations ANALYZE sont gourmandes en ressources, exécutez-les uniquement sur des tables et des colonnes qui nécessitent des mises à jour des statistiques. Vous n’avez pas besoin d’analyser toutes les colonnes de toutes les tables régulièrement ou selon le même calendrier. Si les données changent considérablement, analysez les colonnes qui sont fréquemment utilisées dans les cas suivants : + Tri et regroupement d’opérations + Jointures + Prédicats de requête Pour réduire le délai de traitement et améliorer les performances globales du système, Amazon Redshift ignore ANALYZE pour chaque table dont le pourcentage de lignes modifiées est faible, comme déterminé par le paramètre [analyze\$1threshold\$1percent](r_analyze_threshold_percent.md). Par défaut, le seuil d’analyse est défini sur 10 %. Vous pouvez modifier le seuil d’analyse pour la séance en cours en exécutant une commande [SET](r_SET.md). Les colonnes qui sont moins susceptibles d’exiger des analyses fréquentes sont celles qui représentent des faits et des mesures, ainsi que les attributs associés qui sont jamais réellement interrogés, comme les colonnes VARCHAR volumineuses. Par exemple, considérons la table LISTING de la base de données TICKIT. ``` select "column", type, encoding, distkey, sortkey from pg_table_def where tablename = 'listing'; column | type | encoding | distkey | sortkey ---------------+--------------------+----------+---------+--------- listid | integer | none | t | 1 sellerid | integer | none | f | 0 eventid | integer | mostly16 | f | 0 dateid | smallint | none | f | 0 numtickets | smallint | mostly8 | f | 0 priceperticket | numeric(8,2) | bytedict | f | 0 totalprice | numeric(8,2) | mostly32 | f | 0 listtime | timestamp with... | none | f | 0 ``` Si cette table est chargée tous les jours avec un grand nombre de nouveaux enregistrements, la colonne LISTID, qui est fréquemment utilisée dans les requêtes comme clé de jointure, doit être analysée régulièrement. Si TOTALPRICE et LISTTIME sont les contraintes fréquemment utilisées dans les requêtes, vous pouvez analyser ces colonnes et la clé de distribution sur chaque jour de la semaine. ``` analyze listing(listid, totalprice, listtime); ``` Supposons que les vendeurs et les événements de l'application soient beaucoup plus statiques et que la date IDs fasse référence à un ensemble de jours fixes couvrant seulement deux ou trois ans. Dans ce cas, les valeurs uniques de ces colonnes ne changent pas de façon significative. Cependant, le nombre d’instances de chaque valeur unique augmente de façon continue. En outre, prenons l’exemple d’une situation où les mesures NUMTICKETS et PRICEPERTICKET sont interrogées peu fréquemment par rapport à la colonne TOTALPRICE. Dans ce cas, vous pouvez exécuter la commande ANALYZE sur l’ensemble de la table une fois tous les week-ends afin de mettre à jour les statistiques des cinq colonnes qui ne sont pas analysées quotidiennement : **Colonnes de prédicat** Comme solution pratique autre que spécifier une liste de colonnes, vous pouvez choisir d’analyser uniquement les colonnes susceptibles d’être utilisées comme prédicats. Quand vous exécutez une requête, les colonnes qui sont utilisées dans une jointure, une condition de filtre ou une clause group by sont marquées en tant que comme colonnes de prédicat dans le catalogue système. Lorsque vous exécutez ANALYZE avec la clause PREDICATE COLUMNS, l’opération d’analyse inclut uniquement les colonnes qui remplissent les critères suivants : + La colonne est marquée en tant que colonne de prédicat. + La colonne est une clé de distribution. + La colonne fait partie d’une clé de tri. Si aucune des colonnes d’une table n’est marquée comme prédicat, ANALYZE inclut toutes les colonnes, même si PREDICATE COLUMNS est spécifié. Si aucune colonne n’est marquée comme colonne de prédicat, c’est peut-être parce que la table n’a pas encore été interrogée. Vous pouvez choisir d’utiliser PREDICATE COLUMNS lorsque votre modèle de requête de charge de travail est relativement stable. Lorsque le modèle de requête est variable, avec des colonnes différentes souvent utilisées comme prédicats, l’utilisation de PREDICATE COLUMNS peut se traduire temporairement par des statistiques obsolètes. Des statistiques obsolètes peuvent donner lieu à des plans d’exécution de requête peu efficaces et à des lenteurs d’exécution. Cependant, la fois suivante où vous exécutez ANALYZE avec PREDICATE COLUMNS, les nouvelles colonnes de prédicat sont incluses. Pour afficher des détails sur les colonnes de prédicat, utilisez la requête SQL suivante pour créer une vue nommée PREDICATE\$1COLUMNS. ``` CREATE VIEW predicate_columns AS WITH predicate_column_info as ( SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name, CASE WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||') WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||') WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||') ELSE NULL::varchar END AS pred_ts FROM pg_statistic s JOIN pg_class c ON c.oid = s.starelid JOIN pg_namespace ns ON c.relnamespace = ns.oid JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum) SELECT schema_name, table_name, col_num, col_name, pred_ts NOT LIKE '2000-01-01%' AS is_predicate, CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use, CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze FROM predicate_column_info; ``` Supposons que vous exécutez la requête suivante sur la table LISTING. Notez que les colonnes LISTID, LISTTIME et EVENTID sont utilisées dans les clauses de jointure, de filtre et group by. ``` select s.buyerid,l.eventid, sum(l.totalprice) from listing l join sales s on l.listid = s.listid where l.listtime > '2008-12-01' group by l.eventid, s.buyerid; ``` Lorsque vous interrogez la vue PREDICATE\$1COLUMNS, comme illustré dans l’exemple suivant, vous voyez que les colonnes LISTID, EVENTID et LISTTIME sont marquées en tant que colonnes de prédicat. ``` select * from predicate_columns where table_name = 'listing'; ``` ``` schema_name | table_name | col_num | col_name | is_predicate | first_predicate_use | last_analyze ------------+------------+---------+----------------+--------------+---------------------+-------------------- public | listing | 1 | listid | true | 2017-05-05 19:27:59 | 2017-05-03 18:27:41 public | listing | 2 | sellerid | false | | 2017-05-03 18:27:41 public | listing | 3 | eventid | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41 public | listing | 4 | dateid | false | | 2017-05-03 18:27:41 public | listing | 5 | numtickets | false | | 2017-05-03 18:27:41 public | listing | 6 | priceperticket | false | | 2017-05-03 18:27:41 public | listing | 7 | totalprice | false | | 2017-05-03 18:27:41 public | listing | 8 | listtime | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41 ``` Tenir les statistiques à jour améliore les performances des requêtes en permettant au planificateur de requête de choisir les plans optimaux. Amazon Redshift actualise automatiquement les statistiques en arrière-plan. Vous pouvez également exécuter explicitement la commande ANALYZE. Si vous choisissez d’exécuter explicitement ANALYZE, procédez comme suit : + Exécutez la commande ANALYZE avant d’exécuter les requêtes. + Exécutez la commande ANALYZE sur la base de données systématiquement à la fin de chaque chargement ou cycle de mise à jour régulier. + Exécutez la commande ANALYZE sur les nouvelles tables que vous créez et sur les tables ou les colonnes existantes qui subissent des modifications significatives. + Envisagez d’exécuter les opérations ANALYZE selon différents échéanciers pour différents types de tables et de colonnes, en fonction de leur utilisation dans les requêtes et leur propension au changement. + Pour gagner du temps et économiser des ressources de cluster, utilisez la clause PREDICATE COLUMNS lorsque vous exécutez ANALYZE. Vous n’avez pas besoin d’exécuter explicitement la commande ANALYZE après la restauration d’un instantané sur un cluster alloué ou un espace de noms sans serveur, ni après la reprise d’un cluster alloué suspendu. En pareils cas, Amazon Redshift conserve les informations de table système, ce qui rend les commandes ANALYZE manuelles inutiles. Amazon Redshift continuera à exécuter des opérations d’analyse automatique selon les besoins. Une opération d'analyse ignore les tables contenant des up-to-date statistiques. Si vous exécutez ANALYZE dans le cadre de votre flux de travail ETL (extraction, transformation et chargement), l’analyse automatique ignore les tables dont les statistiques sont à jour. De façon similaire, une opération ANALYZE explicite ignore les tables pour lesquelles l’analyse automatique a mis à jour les statistiques. ## Historique de la commande ANALYZE Il est utile de savoir quand la commande ANALYZE a été exécutée pour la dernière fois sur une table ou une base de données. Quand une commande ANALYZE est exécutée, Amazon Redshift exécute plusieurs requêtes qui ressemblent à ceci : ``` padb_fetch_sample: select * from table_name ``` Interrogez STL\$1ANALYZE pour afficher l’historique des opérations d’analyse. Si Amazon Redshift analyse une table à l’aide d’une analyse automatique, la colonne `is_background` est définie sur `t` (true). Sinon, elle est définie sur `f` (false). L’exemple suivant joint la table STV\$1TBL\$1PERM pour afficher le nom de la table et les détails de l’exécution. ``` select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, a.starttime, a.endtime from stl_analyze a join stv_tbl_perm t on t.id=a.table_id where name = 'users' order by starttime; xid | name | status | rows | modified_rows | starttime | endtime -------+-------+-----------------+-------+---------------+---------------------+-------------------- 1582 | users | Full | 49990 | 49990 | 2016-09-22 22:02:23 | 2016-09-22 22:02:28 244287 | users | Full | 24992 | 74988 | 2016-10-04 22:50:58 | 2016-10-04 22:51:01 244712 | users | Full | 49984 | 24992 | 2016-10-04 22:56:07 | 2016-10-04 22:56:07 245071 | users | Skipped | 49984 | 0 | 2016-10-04 22:58:17 | 2016-10-04 22:58:17 245439 | users | Skipped | 49984 | 1982 | 2016-10-04 23:00:13 | 2016-10-04 23:00:13 (5 rows) ``` Sinon, vous pouvez exécuter une requête plus complexe qui renvoie toutes les instructions exécutées dans chaque transaction terminée et qui incluaient une commande ANALYZE : ``` select xid, to_char(starttime, 'HH24:MM:SS.MS') as starttime, datediff(sec,starttime,endtime ) as secs, substring(text, 1, 40) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid desc, starttime; xid | starttime | secs | substring -----+--------------+------+------------------------------------------ 1338 | 12:04:28.511 | 4 | Analyze date 1338 | 12:04:28.511 | 1 | padb_fetch_sample: select count(*) from 1338 | 12:04:29.443 | 2 | padb_fetch_sample: select * from date 1338 | 12:04:31.456 | 1 | padb_fetch_sample: select * from date 1337 | 12:04:24.388 | 1 | padb_fetch_sample: select count(*) from 1337 | 12:04:24.388 | 4 | Analyze sales 1337 | 12:04:25.322 | 2 | padb_fetch_sample: select * from sales 1337 | 12:04:27.363 | 1 | padb_fetch_sample: select * from sales ... ``` # Exécution de l’opération VACUUM sur les tables Amazon Redshift peut trier et effectuer automatiquement une opération VACUUM DELETE sur les tables en arrière-plan. Pour nettoyer les tables après un chargement ou une série de mises à jour incrémentielles, vous pouvez également exécuter la commande [VACUUM](r_VACUUM_command.md), sur toute la base de données ou sur chaque table individuelle. **Note** Seuls les utilisateurs disposant des autorisations nécessaires peuvent efficacement vider une table. Si VACUUM est exécutée sans les autorisations de table nécessaires, l’opération se termine correctement, mais n’a aucun effet. Pour obtenir la liste des autorisations de table valides permettant d’exécuter VACUUM efficacement, consultez [VACUUM](r_VACUUM_command.md). C’est pourquoi nous vous recommandons de nettoyer les tables individuellement en fonction des besoins. Nous vous recommandons également cette approche, car le nettoyage de toute la base de données peut être une opération coûteuse. ## Tri automatique des tables Amazon Redshift trie automatiquement les données en arrière-plan pour gérer les données de la table selon l’ordre de la clé de tri. Amazon Redshift assure le suivi de vos requêtes d’analyse afin de déterminer à quelles sections de la table le tri sera appliqué. Amazon Redshift assure également le suivi des requêtes de scan provenant de clusters de dimensionnement simultané. Pour les architectures multi-clusters utilisant le partage de données Amazon Redshift, Amazon Redshift suit également les requêtes de scan provenant des clusters/workgroups consommateurs de votre maillage de données, clusters/workgroups y compris dans différentes régions. Les statistiques d'analyse du cluster principal, des clusters de dimensionnement simultané et des clusters de consommateurs sont agrégées afin de déterminer les sections du tableau qui bénéficieront du tri. Selon la charge du système, Amazon Redshift lance le tri automatiquement. Ce tri automatique réduit la nécessité d’exécuter la commande VACUUM pour que les données restent dans l’ordre de la clé de tri. Si vous souhaitez que les données soient triées dans l’ordre de la clé de tri, par exemple après un chargement de données volumineux, vous pouvez toujours exécuter la commande VACUUM manuellement. Afin de déterminer s’il sera utile pour votre table d’exécuter une commande VACUUM SORT, surveillez la colonne `vacuum_sort_benefit` dans [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Amazon Redshift suit les requêtes d’analyse qui utilisent la clé de tri de chaque table. Amazon Redshift estime le pourcentage maximum d’amélioration en analysant et filtrant les données de chaque table (si la table a été complètement triée). L’estimation est visible dans la colonne `vacuum_sort_benefit` de [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Vous pouvez utiliser cette colonne avec la colonne `unsorted` afin de déterminer à quel moment il est utile pour les requêtes d’exécuter une opération VACUUM SORT sur une table. La colonne `unsorted` reflète l’ordre de tri physique d’une table. La colonne `vacuum_sort_benefit` spécifie l’impact du tri d’une table en exécutant manuellement une opération VACUUM SORT. Par exemple, réfléchissez à la requête suivante : ``` select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1; ``` ``` table | unsorted | vacuum_sort_benefit -------+----------+--------------------- sales | 85.71 | 5.00 event | 45.24 | 67.00 ``` Pour la table « sales », même si la table n’est pas triée à \$186 %, l’impact de la requête sur la performance pour la table est de 5 % seulement. Cela peut être parce qu’une petite partie de la table a été utilisée par les requêtes ou parce qu’un petit nombre de requêtes ont eu accès à la table. Pour la table « event », elle n’est pas triée physiquement à \$145 %. Mais l’impact de la requête sur la performance est de 67 %, ce qui indique qu’une partie plus importante de la table a été utilisée pour les requêtes ou qu’un grand nombre de requêtes ont eu accès à la table. L’exécution de l’opération VACUUM SORT peut potentiellement être utile pour la table « event ». ## Suppression de vide automatique Lorsque vous effectuez une suppression, les lignes sont marquées pour suppression, mais ne sont pas supprimées. Amazon Redshift exécute automatiquement une opération VACUUM DELETE en arrière-plan en fonction du nombre de lignes supprimées dans les tables de base de données. Amazon Redshift planifie l’exécution de VACUUM DELETE au cours des périodes à charge réduite et suspend l’opération au cours des périodes à charge élevée. **Topics** + [Tri automatique des tables](#automatic-table-sort) + [Suppression de vide automatique](#automatic-table-delete) + [Fréquence de VACUUM](#vacuum-frequency) + [Phase de tri et phase de fusion](#vacuum-stages) + [Seuil de VACUUM](#vacuum-sort-threshold) + [Types d’opération VACUUM](#vacuum-types) + [Réduire la durée des opérations vacuum](vacuum-managing-vacuum-times.md) ## Fréquence de VACUUM Vous devez exécuter la commande VACUUM aussi souvent que nécessaire pour assurer des performances de requêtes constantes. Prenez en compte ces facteurs au moment de déterminer la fréquence d’exécution de votre commande VACUUM : + Exécutez la commande VACUUM pendant les périodes où vous prévoyez une activité minimale sur le cluster, telles que le soir ou les fenêtres dédiées d’administration de la base de données. + Exécutez les commandes VACUUM en dehors des fenêtres de maintenance. Pour plus d’informations, consultez [Planifier la maintenance Windows](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html). + Une grande région non triée se traduit par des temps d’exécution de la commande VACUUM plus longs. Si vous différez la commande, son exécution prendra plus de temps, car un plus grand nombre de données doit être réorganisé. + VACUUM est une opération I/O intensive. Par conséquent, plus la réalisation de votre aspirateur est longue, plus elle aura d'impact sur les requêtes simultanées et les autres opérations de base de données exécutées sur votre cluster. + VACUUM prend plus de temps pour les tables qui utilisent le tri entrelacé. Pour déterminer si les tables entrelacées doivent être retriées, interrogez la vue [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). ## Phase de tri et phase de fusion Amazon Redshift effectue une opération VACUUM en deux étapes : tout d’abord, il trie les lignes de la région non triée, puis, si nécessaire, il fusionne les lignes nouvellement triées en fin de la table avec les lignes existantes. Lors de l’exécution de la commande VACUUM sur une grande table, l’opération procède par une série d’étapes consistant en tris incrémentiels suivis de fusions. Si l’opération échoue ou si Amazon Redshift passe hors connexion pendant l’opération, la table ou la base de données partiellement aspirées se trouvent dans un état cohérent, mais vous devez relancer manuellement l’opération VACUUM. Les tris incrémentiels sont perdus, mais les lignes fusionnées qui ont été validées avant la défaillance n’ont pas besoin d’être aspirées à nouveau. Si la région non triée est grande, le temps perdu peut être important. Pour plus d’informations sur les étapes de tri et de fusion, consultez [Réduction du volume des lignes fusionnées](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows). Les utilisateurs peuvent accéder aux tables pendant qu’elles sont aspirées. Vous pouvez exécuter des requêtes et des opérations d’écriture pendant qu’une table est l’objet de la commande VACUUM, mais lorsque DML et une commande VACUUM s’exécutent en même temps, les deux peuvent prendre plus de temps. Si vous exécutez les instructions UPDATE et DELETE pendant une opération VACUUM, les performances du système peuvent être réduites. Les fusions incrémentielles bloquent temporairement les opérations UPDATE et DELETE simultanée, tandis que les opérations UPDATE et DELETE bloquent à leur tour temporairement les étapes de la fusion incrémentielle sur les tables concernées. Les opérations DDL, telles que ALTER TABLE, sont bloquées tant que l’opération VACUUM sur la table n’est pas finie. **Note** Divers modificateurs pour l’opération VACUUM contrôlent la façon dont elle fonctionne. Vous pouvez les utiliser pour adapter l’opération aux besoins actuels. Par exemple, l’utilisation de VACUUM RECLUSTER accélère l’opération VACUUM, car elle n’effectue pas d’opération de fusion complète. Pour plus d'informations, consultez [VACUUM](r_VACUUM_command.md). ## Seuil de VACUUM Par défaut, la commande VACUUM ignore la phase de tri pour toute table dans laquelle plus de 95 % des lignes sont déjà triées. L’omission de la phase de tri peut améliorer considérablement les performances de l’opération VACUUM. Pour modifier le seuil de tri par défaut d’une seule table, incluez le nom de la table et le paramètre TO *seuil* PERCENT lorsque vous exécutez la commande VACUUM. ## Types d’opération VACUUM Pour plus d’informations sur les différents types d’opérations VACUUM, consultez [VACUUM](r_VACUUM_command.md). # Réduire la durée des opérations vacuum Amazon Redshift trie automatiquement les données et exécute l’opération VACUUM DELETE en arrière-plan. Cela réduit la nécessité d’exécuter la commande VACUUM. L’exécution de l’opération vacuum est un processus qui peut prendre beaucoup de temps. Selon la nature de vos données, nous vous conseillons de suivre les pratiques suivantes afin de réduire la durée des opérations vacuum. **Topics** + [Choix de réindexation](#r_vacuum-decide-whether-to-reindex) + [Réduction de la taille de la région non triée](#r_vacuum_diskspacereqs) + [Réduction du volume des lignes fusionnées](#vacuum-managing-volume-of-unmerged-rows) + [Charger vos données dans l’ordre de la clé de tri](#vacuum-load-in-sort-key-order) + [Utilisez des tables de séries chronologiques pour réduire les données stockées](#vacuum-time-series-tables) ## Choix de réindexation Vous pouvez souvent améliorer de façon significative les performances des requêtes en utilisant un style de tri entrelacé, mais au fil du temps les performances peuvent se dégrader si la distribution des valeurs des colonnes de clé de tri change. Lorsque vous chargez initialement une table entrelacée vide à l’aide de COPY ou CREATE TABLE AS, Amazon Redshift crée automatiquement l’index entrelacé. Si vous chargez initialement une table entrelacée à l’aide d’INSERT, vous devez exécuter VACUUM REINDEX après pour initialiser l’index entrelacé. Au fil du temps, à mesure que vous ajoutez des lignes avec de nouvelles valeurs de clé de tri, les performances peuvent se dégrader si la distribution des valeurs dans les colonnes de clés change. Si vos nouvelles lignes se trouvent principalement dans la plage de valeurs des clés de tri existantes, vous n’avez pas besoin de réindexer. Exécutez VACUUM SORT ONLY ou VACUUM FULL pour rétablir l’ordre de tri. Le moteur de requête est en mesure d’utiliser l’ordre de tri pour sélectionner efficacement les blocs de données qui doivent être analysés pour traiter une requête. Pour un tri entrelacé, Amazon Redshift analyse les valeurs des colonnes de clé de tri pour déterminer l’ordre de tri optimal. Si la distribution des valeurs de clés change, ou est altérée, au fur et à mesure que les lignes sont ajoutées, la politique de tri n’est plus optimale et l’avantage des performances de tri se dégrade. Pour réanalyser la distribution des clés de tri, vous pouvez exécuter une opération VACUUM REINDEX. Comme l’opération de réindexation prend du temps, pour décider si une table peut bénéficier d’une réindexation, interrogez la vue [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). Par exemple, la requête suivante affiche les détails des tables qui utilisent les clés de tri entrelacé. ``` select tbl as tbl_id, stv_tbl_perm.name as table_name, col, interleaved_skew, last_reindex from svv_interleaved_columns, stv_tbl_perm where svv_interleaved_columns.tbl = stv_tbl_perm.id and interleaved_skew is not null; tbl_id | table_name | col | interleaved_skew | last_reindex --------+------------+-----+------------------+-------------------- 100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45 100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45 100072 | part | 0 | 1.65 | 2015-04-22 22:05:45 100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45 (4 rows) ``` La valeur de `interleaved_skew` est un rapport qui indique le degré de déformation. Une valeur égale à 1 signifie qu’il n’y a pas de déformation. Si la déformation est supérieure à 1,4, une opération VACUUM REINDEX améliore généralement les performances, sauf si la déformation est inhérente à l’ensemble jeu sous-jacent. Vous pouvez utiliser la valeur de date dans `last_reindex` pour déterminer le temps qui s’est écoulé depuis la dernière réindexation. ## Réduction de la taille de la région non triée La région non triée croît lors du chargement de grandes quantités de nouvelles données dans des tables qui contiennent déjà des données ou lorsque vous ne pas videz pas les tables dans le cadre de vos opérations régulières de maintenance. Pour éviter les longues opérations VACUUM, utilisez les pratiques suivantes : + Exécutez les opérations VACUUM sur une base régulière. Si vous chargez vos tables par petits incréments (mises à jour quotidiennes qui représentent un faible pourcentage du nombre total de lignes de la table, par exemple), l’exécution régulière de VACUUM aide à s’assurer que les opérations VACUUM individuelles se déroulent rapidement. + Exécutez d’abord le chargement le plus important. Si vous avez besoin de charger une nouvelle table avec plusieurs opérations COPY, exécutez d’abord le chargement le plus important. Lorsque vous exécutez un chargement initial dans une table nouvelle ou tronquée, toutes les données sont chargées directement dans la région triée et, par conséquent, aucune opération VACUUM n’est obligatoire. + Tronquez une table au lieu de supprimer toutes les lignes. La suppression des lignes d’une table ne récupère pas l’espace que les lignes occupaient jusqu’à ce que vous effectuiez une opération VACUUM ; cependant, la troncation d’une table vide la table et récupère l’espace, et, par conséquent, aucune opération VACUUM n’est obligatoire. Une autre solution consiste à supprimer la table et à la recréer. + Tronquez ou supprimez les tables de test. Si vous chargez un petit nombre de lignes dans une table à des fins de test, ne supprimez pas les lignes lorsque vous avez terminé. A la place, tronquez la table et rechargez les lignes dans le cadre de l’opération de chargement de production suivante. + Exécutez une copie complète. Si une table qui utilise une table de clé de tri composée possède une grande région non triée, une copie complète est beaucoup plus rapide qu’une opération VACUUM. Une copie complète recrée et remplit une table à l’aide d’une insertion en bloc, qui retrie automatiquement la table. Si une table possède une grande région non triée, une copie complète est beaucoup plus rapide qu’une opération VACUUM. Cependant, vous ne pouvez pas effectuer de mises à jour simultanées pendant une opération de copie complète, alors que cela est possible durant une opération VACUUM. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md). ## Réduction du volume des lignes fusionnées Si une opération VACUUM doit fusionner de nouvelles lignes dans la région triée d’une table, le temps nécessaire pour l’opération augmente au fur et à mesure que la table se développe. Vous pouvez améliorer les performances de l’opération VACUUM en réduisant le nombre de lignes à fusionner. Avant une opération VACUUM, une table se compose d’une région triée en tête de table, suivie d’une région non triée, qui croît chaque fois que des lignes sont ajoutées ou mises à jour. Lorsqu’un ensemble de lignes est ajouté par une opération COPY, le nouvel ensemble de lignes est trié sur la clé de tri tel qu’il est ajouté à la région non triée en fin de table. Les nouvelles lignes sont classées au sein de leur propre ensemble, mais pas au sein de la région non triée. Le schéma suivant illustre la région non triée après deux opérations COPY successives, où la clé de tri est CUSTID. Pour plus de simplicité, cet exemple montre une clé de tri composée, mais les mêmes principes s’appliquent aux clés de tri entrelacé, sauf que l’impact de la région non triée est une plus grande pour les tables entrelacées. ![\[Table non triée contenant les enregistrements de deux opérations COPY.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region.png) Une opération VACUUM restaure l’ordre de tri de la table en deux étapes : 1. Triez la région non triée dans une région nouvellement triée. La première étape est relativement bon marché, parce que seule la région non triée est réécrite. Si la plage des valeurs de clé de tri de la région nouvellement triée est supérieure à la plage existante, seules les nouvelles lignes doivent être réécrites, et l’opération VACUUM est terminée. Par exemple, si la région triée contient des valeurs d’ID comprises entre 1 et 500 et que les opérations de copie suivantes ajoutent des valeurs de clé supérieures à 500, seule la région non triée doit être réécrite. 1. Fusionnez la région nouvellement triée avec la région précédemment triée. Si les clés de la région nouvellement triée chevauchent les clés de la région triée, l’opération VACUUM doit fusionner les lignes. En commençant par le début de la région nouvellement triée (à la clé de tri la plus basse), l’opération VACUUM écrit les lignes fusionnées à partir de la région précédemment triée et de la région nouvellement triée dans un nouvel ensemble de blocs. L’étendue selon laquelle la nouvelle plage de clés de tri chevauche les clés de tri existantes détermine l’étendue selon laquelle la région précédemment triée doit être réécrite. Si les clés non triées sont dispersées à travers la plage de tri existante, une opération VACUUM peut avoir besoin de réécrire Des parties existantes de la table. Le schéma suivant montre comment une opération VACUUM trie et fusionne les lignes qui sont ajoutées à une table où CUSTID est la clé de tri. Comme chaque opération de copie ajoute un nouvel ensemble de lignes avec des valeurs de clé qui chevauchent les clés existantes, presque la totalité de la table doit être réécrite. Le schéma illustre une seule étape de tri et fusion, mais, en pratique, une grand opération VACUUM se compose d’une série d’étapes incrémentielles de tri et de fusion. ![\[Une opération VACUUM sur la table d’exemple en deux étapes. Les nouvelles lignes sont d’abord triées, puis fusionnées avec les lignes existantes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) Si la plage de clés de tri d’un ensemble de nouvelles lignes chevauche la plage des clés existantes, le coût de l’étape de fusion continue à croître proportionnellement à la taille de la table au fur et à mesure que la table augmente, tandis que le coût de l’étape de tri demeure proportionnel à la taille de la région non triée. Dans un tel cas, le coût de l’étape de fusion éclipse le coût de l’étape de tri, comme l’illustre le schéma suivant. ![\[Schéma montrant comment l’étape de fusion devient plus coûteuse lorsque les nouvelles lignes ont des clés de tri qui se chevauchent avec des lignes existantes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) Pour déterminer quelle proportion d’une table a été refusionnée, interrogez SVV\$1VACUUM\$1SUMMARY après la fin de l’opération VACUUM. La requête suivante affiche les conséquences de six opérations VACUUM successives tandis que CUSTSALES croît au fil du temps. ``` select * from svv_vacuum_summary where table_name = 'custsales'; table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_ | | partitions | increments | time | delta | delta | delta | partitions -----------+------+------------+------------+------------+-------+------------+---------+--------------- custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47 custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47 custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47 custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47 custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47 custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47 (6 rows) ``` La colonne merge\$1increments fournit une indication de la quantité de données qui a été fusionnée pour chaque opération VACUUM. Si le nombre d’incréments de fusion sur des opérations VACUUM consécutives augmente proportionnellement à la croissance de la taille de la table, cela indique que chaque opération VACUUM refusionne un nombre croissant de lignes de la table, car la région existante et la région nouvellement triée se chevauchent. ## Charger vos données dans l’ordre de la clé de tri Si vous chargez vos données dans l’ordre de la clé de tri avec une commande COPY, vous aurez peut-être moins (voire plus du tout) besoin d’avoir recours à l’opération VACUUM. La commande COPY ajoute automatiquement de nouvelles lignes à la région triée de la table lorsque toutes les conditions suivantes sont définies sur true : + La table utilise une clé de tri composée avec une seule colonne de tri. + La colonne de tri est NOT NULL. + La table est triée ou vide à 100 %. + Toutes les nouvelles lignes sont plus élevées dans l’ordre de tri que les lignes existantes, y compris les lignes marquées pour la suppression. Dans ce cas, Amazon Redshift utilise les huit premiers octets de la clé de tri pour déterminer l’ordre de tri. + La commande COPY ne déclenche pas certaines optimisations de charge. Lors du chargement de gros volumes de données, Amazon Redshift peut optimiser les performances en créant de nouvelles partitions triées plutôt qu'en ajoutant des lignes à la région triée de la table. Par exemple, supposons que vous ayez une table qui enregistre les événements clients à l’aide d’un ID client et de l’heure. Si vous triez sur l’ID client, il est probable que la plage des clés de tri des nouvelles lignes ajoutées par les chargements incrémentiels chevauchent la plage existante, comme illustré dans l’exemple précédent, ce qui conduit à une opération VACUUM coûteuse. Si vous définissez votre clé de tri sur une colonne d’horodatage, vos nouvelles lignes sont ajoutées dans l’ordre de tri à la fin de la table, comme l’illustre le schéma suivant, ce qui rend l’opération VACUUM moins (voire plus du tout) nécessaire. ![\[Table qui utilise une colonne d’horodatage comme clé de tri pour obtenir de nouveaux enregistrements qui n’ont pas besoin d’être triés.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## Utilisez des tables de séries chronologiques pour réduire les données stockées Si vous maintenez les données pendant une période aléatoire, utilisez une série de tables, comme l’illustre le schéma suivant. ![\[Cinq tables contenant des données provenant de cinq trimestres. La table la plus ancienne est supprimée pour conserver une année de continuité.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) Créez une table chaque fois que vous ajoutez un ensemble de données, puis supprimez la table la plus ancienne de la série. Vous bénéficiez d’un double avantage : + Vous évitez le coût supplémentaire de suppression des lignes, parce qu’une opération DROP TABLE est beaucoup plus efficace qu’une opération DELETE massive. + Si les tables sont triées par horodate, aucune opération VACUUM n’est nécessaire. Si chaque table contient les données pour un mois, une opération VACUUM devra au plus réécrire la valeur d’un mois de données, même si les tables ne sont pas triées par horodatage. Vous pouvez créer une vue UNION ALL à utiliser par les requêtes de création de rapports qui masque le fait que les données sont stockées en plusieurs tables. Si une requête filtre sur la clé de tri, le planificateur de requête peut efficacement ignorer toutes les tables qui ne sont pas utilisées. Comme une opération UNION ALL peut être moins efficace pour les autres types de requêtes, vous devez évaluer les performances de la requête dans le contexte de toutes les requêtes qui utilisent les tables. # Gestion des opérations d’écriture simultanées Certaines applications nécessitent non seulement une interrogation et un chargement simultanés, mais également la possibilité d’écrire sur plusieurs tables ou sur la même table simultanément. Dans ce contexte, *simultanément* entraîne un chevauchement, non planifié pour s’exécuter exactement au même moment. Deux transactions sont considérées comme simultanées si la seconde démarre avant que la première ne soit validée. Les opérations simultanées peuvent provenir de différentes séances contrôlées par le même utilisateur ou par différents utilisateurs. Amazon Redshift prend en charge ces types d’applications en permettant que les tables soient lues tandis qu’elles sont chargées ou modifiées de façon incrémentielle. Les requêtes voient simplement la dernière version validée, ou *instantané*, des données plutôt que d’attendre la validation de la version suivante. Si vous souhaitez qu’une requête donnée attende la validation d’une autre opération d’écriture, vous devez le planifier en conséquence. **Note** Amazon Redshift prend en charge un comportement de *validation automatique* par défaut dans lequel chaque commande SQL exécutée séparément est validée individuellement. Si vous placez un ensemble de commandes dans un bloc de transaction (défini par les instructions [BEGIN](r_BEGIN.md) et [FIN](r_END.md)), le bloc est validé comme une seule transaction et, par conséquent, vous pouvez le restaurer si nécessaire. Les exceptions à ce comportement sont les commandes TRUNCATE et VACUUM, qui valident automatiquement toutes les modifications en attente effectuées dans la transaction actuelle. Certains clients SQL émettent automatiquement des commandes BEGIN et COMMIT, de sorte que le client contrôle si un groupe d’instructions est exécuté en tant que transaction ou si chacune des instructions est exécutée indépendamment. Consultez la documentation relative à de l’interface que vous utilisez. Par exemple, lors de l’utilisation du pilote JDBC Amazon Redshift, un `PreparedStatement` JDBC avec une chaîne de requête qui contient plusieurs commandes SQL (séparées par des points-virgules) exécute toutes les instructions en tant qu’une seule transaction. En revanche, si vous utilisez SQL Workbench/J et que vous définissez AUTO COMMIT ON, si vous exécutez plusieurs instructions, chaque instruction s'exécute comme une transaction distincte. Les rubriques suivantes décrivent certains des concepts et scénarios clés qui impliquent les transactions, les instantanés de base de données, les mises à jour et le comportement simultané. **Topics** + [Niveaux d’isolement dans Amazon Redshift](c_serial_isolation.md) + [Écriture et read/write opérations](c_write_readwrite.md) + [Exemples d’écritures simultanées](r_Serializable_isolation_example.md) + [Résolution des problèmes d’isolation sérialisable](c_serial_isolation-serializable-isolation-troubleshooting.md) # Niveaux d’isolement dans Amazon Redshift Les opérations d’écriture simultanées sont prises en charge dans Amazon Redshift de manière protective, à l’aide de verrous d’écriture sur les tables et du principe d’*isolement sérialisable*. L’isolement sérialisable préserve l’illusion qu’une transaction s’exécutant sur une table est la seule transaction qui soit en cours d’exécution sur cette table. Les bases de données Amazon Redshift prennent en charge les opérations d’écriture simultanées en faisant en sorte que chaque opération utilise la dernière version validée, ou instantané, de ses données au début de la transaction. Un instantané de base de données est créé au sein d’une transaction sur la première occurrence de la plupart des instructions SELECT, des commandes DML telles que COPY, DELETE, INSERT, UPDATE et TRUNCATE, et des commandes DDL suivantes : + ALTER TABLE (pour ajouter ou supprimer des colonnes) + CREATE TABLE + DROP TABLE + TRUNCATE TABLE Aucune autre transaction ne peut modifier cet instantané, ce qui signifie que les transactions sont isolées les unes des autres. Les transactions simultanées sont donc invisibles les unes aux autres ; elles ne peuvent pas détecter les modifications de chacune d’elles. Toute exécution simultanée de transactions doit produire les mêmes résultats que l’exécution en série de ces transactions. Si aucune exécution en série de ces transactions ne peut produire les mêmes résultats, la transaction qui exécute une instruction qui pourrait interrompre la mise en série est arrêtée et annulée. Supposons, par exemple, qu’un utilisateur tente d’exécuter deux transactions simultanées, T1 et T2. L’exécution de T1 et de T2 doit produire les mêmes résultats comme dans l’un des scénarios suivants : + T1 et T2 sont exécutées en série dans cet ordre. + T2 et T1 sont exécutées en série dans cet ordre. Les niveaux d’isolement d’Amazon Redshift permettent d’éviter les problèmes suivants : + Lectures corrompues : une lecture corrompue se produit lorsqu’une transaction lit des données qui n’ont pas encore été validées. Supposons, par exemple, que la transaction 1 mette à jour une ligne. La transaction 2 lit la ligne mise à jour avant que T1 ne valide la mise à jour. Si T1 annule la modification, T2 aura lu des données dans des lignes non validées qu’Amazon Redshift considère désormais comme n’ayant jamais existé. + Lectures non répétables : une lecture non répétable se produit lorsqu’une seule transaction lit deux fois la même ligne mais obtient des données différentes à chaque fois. Supposons, par exemple, que la transaction 1 lise une ligne. La transaction 2 met à jour ou supprime cette ligne et valide la mise à jour ou la suppression. Si T1 relit la ligne, il récupère différentes valeurs de ligne ou découvre que la ligne a été supprimée. + Fantômes : un fantôme est une ligne qui correspond aux critères de recherche mais qui n’est pas initialement visible. Supposons, par exemple, que la transaction 1 lise un ensemble de lignes répondant à ses critères de recherche. La transaction 2 génère une nouvelle ligne dans une instruction UPDATE ou INSERT qui correspond aux critères de recherche de T1. Si T1 réexécute son instruction de recherche, elle obtient un ensemble de lignes différent. ## Isolement SNAPSHOT et SERIALIZABLE Dans les bases de données Amazon Redshift, l’isolement SERIALIZABLE et SNAPSHOT sont des types de niveau d’isolement sérialisable. L’isolement SNAPSHOT est le niveau d’isolement par défaut lors de la création de clusters alloués et de groupes de travail sans serveur, ce qui vous permet de traiter des volumes de données plus importants que l’isolement SERIALIZABLE en moins de temps. L’isolement SERIALIZABLE prend plus de temps, mais implémente des contraintes plus strictes sur les transactions simultanées. Ce niveau d’isolement permet d’éviter les problèmes tels que les anomalies de distorsion d’écriture en autorisant la validation d’une seule transaction, tout en annulant toutes les autres transactions simultanées présentant une erreur de violation d’isolement sérialisable. Voici un exemple chronologique de la façon dont deux opérations d’écriture simultanées seraient gérées lors de l’utilisation de l’isolement SNAPSHOT. L’instruction UPDATE de chaque utilisateur est autorisée à être validée car elle n’entre pas en conflit en tentant de mettre à jour les mêmes lignes. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c_serial_isolation.html) Si le même scénario est exécuté à l’aide d’une isolation sérialisable, Amazon Redshift met fin à l’utilisateur 2 en raison d’une violation sérialisable et renvoie une erreur `1023`. Pour plus d’informations, consultez [Résolution des problèmes d’isolation sérialisable](c_serial_isolation-serializable-isolation-troubleshooting.md). Dans ce cas, seul l’utilisateur 1 peut s’engager avec succès. ## Considérations Lorsque vous utilisez les niveaux d’isolement dans Amazon Redshift, prenez en considération les éléments suivants : + Interrogez la vue du catalogue STV\$1DB\$1ISOLATION\$1LEVEL pour afficher le niveau d’isolement utilisé par votre base de données. Pour plus d’informations, consultez [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md). + Interrogez la vue PG\$1DATABASE\$1INFO pour savoir combien de transactions simultanées sont prises en charge pour votre base de données. Pour plus d’informations, consultez [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + Les tables catalogue système (PG) et autres tables système Amazon Redshift ne sont pas verrouillées dans une transaction. Par conséquent, les modifications apportées aux objets de base de données qui proviennent d’opérations DDL et TRUNCATE sont visibles lors de la validation de transactions simultanées. Par exemple, supposons que cette table A existe dans la base de données lorsque deux transactions simultanées, T1 et T2, démarrent. Supposons que T2 renvoie une liste de tables en les sélectionnant dans la table de catalogue PG\$1TABLES. Ensuite, T1 supprime la table A et valide la suppression, puis T2 affiche les tables à nouveau. La table A n’apparaît plus dans la liste. Si T2 essaie d’interroger la table supprimée, Amazon Redshift renvoie une erreur indiquant que la relation n’existe pas. La requête de catalogue qui renvoie la liste des tables à T2 ou vérifie que la table A existe n’est pas soumise aux mêmes règles d’isolement que les opérations réalisées sur les tables de l’utilisateur. Les transactions pour les mises à jour de ces tables s’exécutent dans un mode d’isolement validé en lecture. + Les tables de catalogue préfixées par PG ne prennent pas en charge l’isolement SNAPSHOT. # Écriture et read/write opérations Vous pouvez gérer le comportement spécifique des opérations d’écriture simultanées en décidant quand et comment exécuter différents types de commandes. Les commandes suivantes sont pertinentes pour cette discussion : + Les commandes COPY, qui effectuent les chargements (initiaux ou incrémentiels) + Les commandes INSERT qui ajoutent une ou plusieurs lignes à la fois + Les commandes UPDATE, qui modifient les lignes existantes + Les commandes DELETE, qui suppriment des lignes Les opérations COPY et INSERT sont de pures opérations de lecture/écriture. Les opérations DELETE et UPDATE sont read/write des opérations (pour que les lignes soient supprimées ou mises à jour, elles doivent d'abord être lues). Les résultats des opérations d’écriture simultanées dépendent des commandes spécifiques qui sont exécutées simultanément. Les opérations UPDATE et DELETE se comportent différemment, car elles s’appuient sur une table initiale lue avant toute écriture. Étant donné que les transactions simultanées sont invisibles les unes pour UPDATEs les autres, les deux DELETEs doivent lire un instantané des données du dernier commit. Lorsque la première opération UPDATE ou DELETE libère son verrou, la deuxième opération UPDATE ou DELETE doit déterminer si les données qu’il va utiliser sont potentiellement obsolètes. Elles ne le sont pas, car la deuxième transaction n’obtient pas son instantané des données tant que la première transaction n’a pas libéré son verrou. ## Situation de blocage potentiel pour les transactions d’écriture simultanées impliquant plusieurs tables Quand les transactions impliquent des mises à jour de plusieurs tables, il y a toujours la possibilité que les transactions soient bloquées quand elles essaient d’écrire sur le même ensemble de tables. Une transaction libère tous les verrous de table à la fois lors d’une validation ou d’une annulation ; elle ne les libère pas un à la fois. Par exemple, supposons que les transactions T1 et T2 commencent approximativement en même temps. Si T1 commence à écrire dans la table A et T2 commence à écrire dans la table B, les deux transactions peuvent se poursuivre sans conflit. Cependant, si T1 finit d’écrire sur la table A et doit commencer à écrire sur la table B, elle ne sera pas en mesure de poursuivre, car T2 continue de maintenir le verrou sur B. De même, si T2 finit d’écrire sur la table B et doit commencer à écrire sur la table A, elle n’est pas en mesure de poursuivre, car T1 continue de maintenir le verrou sur A. Comme aucune transaction ne peut libérer les verrous tant que toutes les opérations d’écriture ne sont pas validées, aucune transaction ne peut se poursuivre. Afin d’éviter ce genre de blocage, vous devez planifier soigneusement les opérations d’écriture simultanées. Par exemple, vous devez toujours mettre à jour les tables dans le même ordre des transactions et, si vous spécifiez des verrous, verrouillez les tables dans le même ordre avant d’effectuer les opérations DML. ## Situation de blocage potentiel pour les transactions d’écriture simultanées impliquant une seule table Dans un environnement d’isolement d’instantané, des blocages peuvent se produire lors de l’exécution de transactions d’écriture simultanées sur la même table. Le blocage de l’isolement d’instantané se produit lorsque des instructions INSERT ou COPY simultanées partagent un verrou et progressent, et qu’une autre instruction doit effectuer une opération (UPDATE, DELETE, MERGE ou DDL) nécessitant un verrou exclusif sur la même table. Réfléchissez au scénario suivant : Transaction 1 (T1) : ``` INSERT/COPY INTO table_A; ``` Transaction 2 (T2) : ``` INSERT/COPY INTO table_A; table_A ``` Un blocage peut se produire lorsque plusieurs transactions comportant des opérations INSERT ou COPY sont exécutées simultanément sur la même table avec un verrou partagé, et que l’une de ces transactions suit son opération d’écriture pure par une opération nécessitant un verrou exclusif, telle qu’une instruction UPDATE, MERGE, DELETE ou DDL. Pour éviter les blocages dans ces situations, vous pouvez séparer les instructions nécessitant un verrouillage exclusif (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEinstructions) sur la même table. Vous pouvez inclure une logique de nouvelle tentative dans vos applications pour contourner les blocages potentiels. # Exemples d’écritures simultanées Les exemples de pseudo-code suivants montrent comment les transactions se poursuivent ou attendent quand elles sont exécutées simultanément. ## Exemples d’écritures simultanées avec isolement sérialisable ### Opérations COPY simultanées sur la même table avec isolement sérialisable La transaction 1 copie les lignes dans la table LISTING : ``` begin; copy listing from ...; end; ``` La transaction 2 commence simultanément dans une séance distincte et tente de copier de nouvelles lignes dans la table LISTING. La transaction 2 doit attendre que la transaction 1 libère le verrou en écriture sur la table LISTING, puis peut poursuivre. ``` begin; [waits] copy listing from ; end; ``` Le même comportement se produirait si l’une d’une transactions ou les deux contenaient une commande INSERT au lieu d’une commande COPY. ### Opérations DELETE simultanées de la même table avec isolement sérialisable La transaction 1 supprime des lignes d’une table : ``` begin; delete from listing where ...; end; ``` La transaction 2 commence simultanément et tente de supprimer des lignes de la même table. Elle réussit, car elle attend que la transaction 1 ait terminé avant de tenter de supprimer des lignes. ``` begin [waits] delete from listing where ; end; ``` Le même comportement se produit si l’une des transactions ou les deux contiennent une commande UPDATE sur la même table au lieu d’une commande DELETE. ### Transactions simultanées avec un mélange d’opérations de lecture et d’écriture avec isolement sérialisable Dans cet exemple, la transaction 1 supprime des lignes de la table USERS, recharge la table, exécute une requête COUNT(\$1), puis une commande ANALYZE, avant de valider : ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` Pendant ce temps, la transaction 2 démarre. Cette transaction tente de copier les lignes supplémentaires dans la table USERS, analyse la table, puis exécute la même requête COUNT(\$1) comme première transaction : ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` La deuxième transaction réussit, car elle doit attendre que la première soit terminée. Sa requête COUNT renvoie le nombre en fonction de la charge qu’il a terminée. ## Exemples d’écritures simultanées avec isolement d’instantané ### Opérations COPY simultanées sur la même table avec isolement d’instantané La transaction 1 copie les lignes dans la table LISTING : ``` begin; copy listing from ...; end; ``` La transaction 2 commence simultanément dans une séance distincte et tente de copier de nouvelles lignes dans la table LISTING. La transaction 2 peut progresser simultanément jusqu’à ce que l’une des transactions ait besoin d’écrire des données dans la table cible `listing`, point auquel elle s’exécutera de manière séquentielle. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` Le même comportement se produirait si l’une d’une transactions ou les deux contenaient une commande INSERT au lieu d’une commande COPY. ### Opérations DELETE simultanées de la même table avec isolement d’instantané Les opérations DELETE ou UPDATE simultanées à partir de la même table avec isolement d’instantané s’exécutent de la même manière que les opérations exécutées avec isolement sérialisable. ### Transactions simultanées avec un mélange d’opérations de lecture et d’écriture avec isolement d’instantané Les transactions simultanées exécutées avec des combinaisons d’opérations avec isolement d’instantané s’exécutent de la même manière que les transactions avec des combinaisons d’opérations exécutées avec une isolement sérialisable. # Résolution des problèmes d’isolation sérialisable ## ERROR:1023 DETAIL : Violation d’isolement sérialisable sur une table dans Redshift Lorsqu’Amazon Redshift détecte une erreur d’isolement sérialisable, le message d’erreur suivant s’affiche. ``` ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift ``` Pour corriger une erreur d’isolement sérialisable, vous pouvez essayer l’une des méthodes suivantes : + Réessayez la transaction annulée. Amazon Redshift a détecté qu’une charge de travail simultanée n’est pas sérialisable. Il suggère des lacunes dans la logique de l’application, qui peuvent généralement être contournées en réessayant la transaction qui a rencontré l’erreur. Si le problème persiste, essayez l’une des autres méthodes. + Déplacez les opérations qui ne doivent pas se trouver dans la même transaction atomique hors de la transaction. Cette méthode s’applique lorsque des opérations individuelles à l’intérieur de deux transactions se comparent entre elles d’une façon pouvant affecter le résultat de l’autre transaction. Par exemple, les deux séances suivantes lancent chacune une transaction. ``` Session1_Redshift=# begin; ``` ``` Session2_Redshift=# begin; ``` Le résultat d’une instruction SELECT dans chaque transaction peut être affecté par une instruction INSERT dans l’autre. En d’autres termes, supposons que vous exécutez les instructions suivantes en série, dans n’importe quel ordre. Dans chaque cas, le résultat est l’une des instructions SELECT renvoyant une ligne de plus que si les transactions avaient été exécutées de manière simultanée. Il n’existe aucun ordre dans lequel les opérations peuvent s’exécuter en série et produire le même résultat que si elles étaient exécutées de manière simultanée. Ainsi, la dernière opération exécutée entraîne une erreur d’isolement sérialisable. ``` Session1_Redshift=# select * from tab1; Session1_Redshift=# insert into tab2 values (1); ``` ``` Session2_Redshift=# insert into tab1 values (1); Session2_Redshift=# select * from tab2; ``` Dans de nombreux cas, le résultat de l’instruction SELECT n’est pas important. En d’autres termes, l’atomicité des opérations dans les transactions n’est pas important. Dans ces cas-là, déplacez les instructions SELECT hors de leurs transactions, comme illustré dans les exemples suivants. ``` Session1_Redshift=# begin; Session1_Redshift=# insert into tab1 values (1) Session1_Redshift=# end; Session1_Redshift=# select * from tab2; ``` ``` Session2_Redshift # select * from tab1; Session2_Redshift=# begin; Session2_Redshift=# insert into tab2 values (1) Session2_Redshift=# end; ``` Dans ces exemples, il n’y a aucune référence croisée dans les transactions. Les deux instructions INSERT n’ont aucun effet l’une sur l’autre. Dans ces exemples, il existe au moins un ordre dans lequel les transactions peuvent s’exécuter en série et produire le même résultat que si elle étaient exécutées de manière simultanée. Cela signifie que les transactions sont sérialisables. + Forcez la sérialisation en verrouillant toutes les tables de chaque séance. La commande [LOCK](r_LOCK.md) bloque les opérations pouvant entraîner des erreurs d’isolement sérialisable. Lorsque vous utilisez la commande LOCK, veillez à procéder comme suit : + Verrouillez toutes les tables affectées par la transaction, notamment celles affectées par les instructions SELECT en lecture seule à l’intérieur de la transaction. + Verrouillez les tables dans le même ordre, quel que soit l’ordre dans lequel ces opérations sont exécutées. + Verrouillez toutes les tables au début de la transaction, avant d’exécuter la moindre opération. + Utiliser l’isolation des instantanés pour les transactions simultanées Utilisez une commande ALTER DATABASE avec l’isolation des instantanés. Pour plus d’informations sur le paramètre SNAPSHOT pour ALTER DATABASE, consultez [Parameters](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters). ## ERROR:1018 DETAIL : La relation n’existe pas Lorsque vous exécutez des opérations Amazon Redshift simultanément dans différentes séances, un message d’erreur similaire au suivant s’affiche. ``` ERROR: 1018 DETAIL: Relation does not exist. ``` Les transactions dans Amazon Redshift suivent l’isolement des instantanés. Lorsqu’une transaction a démarré, Amazon Redshift prend un instantané de la base de données. Pour tout le cycle de vie de la transaction, la transaction est exécutée sur l’état de la base de données tel qu’il est reflété dans l’instantané. Si la transaction effectue la lecture à partir d’une table qui n’existe pas dans l’instantané, elle renvoie le message d’erreur 1018 affiché précédemment. Même lorsqu’une autre transaction simultanée crée une table après que la transaction a pris l’instantané, la transaction ne peut pas effectuer la lecture à partir de la table créée. Pour corriger cette erreur d’isolement de sérialisation, vous pouvez essayer de faire démarrer la transaction à un moment où vous savez que la table existe. Si la table est créée par une autre transaction, ce moment commence au moins après que cette transaction a été validée. Assurez-vous également qu’aucune transaction simultanée qui aurait pu supprimer la table n’a été validée. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session2 = # BEGIN; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # SELECT * FROM A; ``` La dernière opération exécutée en tant qu’opération de lecture par session2 entraîne une erreur d’isolement sérialisable. Cette erreur se produit lorsqu’une session2 prend un instantané et que la table a déjà été supprimée par une session1 validée. En d’autres termes, même si une session3 simultanée a créé la table, la session2 ne voit pas la table car elle ne se trouve pas dans l’instantané. Pour résoudre cette erreur, vous pouvez réorganiser les séances comme suit. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # BEGIN; session2 = # SELECT * FROM A; ``` Lorsque la session2 prend son instantané, la session3 a déjà été validée et la table se trouve dans la base de données. La session2 peut effectuer la lecture à partir de la table sans aucune erreur. # Didacticiel : chargement des données à partir d’Amazon S3 Dans ce didacticiel, vous examinerez le processus de chargement de données dans vos tables de base de données Amazon Redshift depuis les fichiers de données d’un compartiment Amazon S3 de bout en bout. Dans ce didacticiel, vous allez effectuer les opérations suivantes : + Téléchargez des fichiers de données qui utilisent des formats CSV, délimités par un caractère et à largeur fixe. + Créez un compartiment Amazon S3 pour contenir vos fichiers de données, puis chargez les fichiers de données dans le compartiment. + Lancez un cluster Amazon Redshift et créez des tables de base de données ; + Utilisez les commandes COPY pour charger les tables depuis les fichiers de données sur Amazon S3 ; + Résolvez les erreurs de chargement et modifiez vos commandes COPY pour corriger les erreurs. ## Conditions préalables Vous avez besoin des prérequis suivants : + Un AWS compte pour lancer un cluster Amazon Redshift et créer un compartiment dans Amazon S3. + Vos AWS informations d'identification (rôle IAM) pour charger les données de test depuis Amazon S3. Si vous avez besoin d’un nouveau rôle IAM, consultez [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html). + Client SQL tel que l’éditeur de requêtes de la console Amazon Redshift. Ce didacticiel est conçu pour se suffire à lui-même. En plus de ce didacticiel, nous vous recommandons de suivre les didacticiels suivants pour avoir une compréhension plus complète de la conception et de l’utilisation des bases de données Amazon Redshift : + Le [Guide de démarrage d’Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) vous explique le processus de création d’un cluster Amazon Redshift et de chargement d’exemples de données. ## Présentation de Vous pouvez ajouter des données à vos tables Amazon Redshift en utilisant une commande INSERT ou une commande COPY. À l’échelle et à la vitesse d’un entrepôt des données Amazon Redshift, la commande COPY est beaucoup plus rapide et plus efficace que les commandes INSERT. La commande COPY utilise l’architecture de traitement massivement parallèle (MPP) Amazon Redshift pour lire et charger des données en parallèle depuis plusieurs sources de données. Vous pouvez charger depuis des fichiers de données dans Amazon S3, Amazon EMR ou n’importe quel hôte distant accessible via une connexion SSH (Secure Shell). Ou vous pouvez charger directement depuis une table Amazon DynamoDB. Dans ce didacticiel, vous utilisez la commande COPY pour charger les données à partir d’Amazon S3. Bon nombre des principes présentés ici s’appliquent également au chargement depuis d’autres sources de données. Pour en savoir plus sur l’utilisation de la commande COPY, consultez les ressources suivantes : + [Bonnes pratiques de chargement des données sur Amazon Redshift](c_loading-data-best-practices.md) + [Chargement de données à partir d’Amazon EMR](loading-data-from-emr.md) + [Chargement des données à partir des hôtes distants](loading-data-from-remote-hosts.md) + [Chargement de données à partir d’une table Amazon DynamoDB](t_Loading-data-from-dynamodb.md) ## Étape 1 : créer un cluster Si vous disposez déjà d’un cluster que vous souhaitez utiliser, vous pouvez ignorer cette étape. Pour les exercices de ce didacticiel, vous utilisez un cluster à quatre nœuds. **Pour créer un cluster** 1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) Dans le menu de navigation, choisissez le **Tableau de bord des clusters alloués**. **Important** Veillez à ce que vous disposiez des autorisations nécessaires pour exécuter les opérations de cluster. Pour plus d'informations sur l'octroi des autorisations nécessaires, consultez [Autoriser Amazon Redshift à accéder aux AWS services](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html). 1. En haut à droite, choisissez la AWS région dans laquelle vous souhaitez créer le cluster. Dans le cadre de ce didacticiel, sélectionnez **USA Ouest (Oregon)**. 1. Dans le menu de navigation, choisissez **Clusters**, puis choisissez **Créer un cluster**. La page **Créer un cluster** s’affiche. 1. Dans la page **Créer un cluster**, saisissez les paramètres de votre cluster. Choisissez vos propres valeurs pour les paramètres, sauf pour modifier les valeurs suivantes : + Choisissez **dc2.large** pour le type de nœud. + Choisissez **4** pour le **nombre de nœuds**. + Dans la section **Autorisations de cluster**, choisissez un rôle IAM dans **Rôles IAM disponibles**. Ce rôle doit avoir été créé précédemment et avoir accès à Amazon S3. Choisissez ensuite **Associate IAM role (Associer un rôle IAM)** pour l’ajouter à la liste des **Rôles IAM associés** pour le cluster. 1. Choisissez **Créer un cluster**. Suivez les étapes du [Guide de démarrage d’Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) pour vous connecter à votre cluster à partir d’un client SQL et tester une connexion. Vous n’avez pas besoin de suivre les dernières étapes de la mise en route pour créer des tables, télécharger des données et essayer des exemples de requêtes. ## Étape 2 : Télécharger les fichiers de données Au cours de cette étape, vous téléchargez un ensemble d’exemples de fichiers de données sur votre ordinateur. Dans l’étape suivante, vous chargez les fichiers dans un compartiment Amazon S3. **Pour télécharger les fichiers de données** 1. Téléchargez le fichier compressé : [LoadingDataSampleFiles.zip.](samples/LoadingDataSampleFiles.zip) 1. Extrayez les fichiers dans un dossier sur votre ordinateur. 1. Vérifiez que votre dossier contient les fichiers suivants. ``` customer-fw-manifest customer-fw.tbl-000 customer-fw.tbl-000.bak customer-fw.tbl-001 customer-fw.tbl-002 customer-fw.tbl-003 customer-fw.tbl-004 customer-fw.tbl-005 customer-fw.tbl-006 customer-fw.tbl-007 customer-fw.tbl.log dwdate-tab.tbl-000 dwdate-tab.tbl-001 dwdate-tab.tbl-002 dwdate-tab.tbl-003 dwdate-tab.tbl-004 dwdate-tab.tbl-005 dwdate-tab.tbl-006 dwdate-tab.tbl-007 part-csv.tbl-000 part-csv.tbl-001 part-csv.tbl-002 part-csv.tbl-003 part-csv.tbl-004 part-csv.tbl-005 part-csv.tbl-006 part-csv.tbl-007 ``` ## Étape 3 : Charger les fichiers dans un compartiment Amazon S3 Au cours de cette étape, vous allez créer un compartiment Amazon S3 et chargez les fichiers de données dans le compartiment. ### **Pour charger les fichiers dans un compartiment Amazon S3** 1. Créez un compartiment dans Amazon S3. Pour plus d’informations sur la création d’un compartiment, consultez [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. 1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Choisissez **Créer un compartiment**. 1. Choisissez un Région AWS. Créez le compartiment dans la même région que votre cluster. Si votre cluster se trouve dans la région USA Ouest (Oregon), choisissez **USA Ouest (Oregon) (us-west-2)**. 1. Dans la zone **Nom du compartiment** de la boîte de dialogue **Créer un compartiment**, entrez un nom de compartiment. Le nom de compartiment que vous choisissez doit être unique parmi tous les noms de compartiment existants dans Amazon S3. Afin de garantir cette unicité, vous pouvez ajouter le nom de votre organisation en préfixe du nom de vos compartiments. Les noms de compartiment doivent respecter certaines règles. Pour plus d’informations, consultez [Limites et restrictions applicables aux compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. 1. Choisissez les valeurs par défaut recommandées pour les autres options. 1. Choisissez **Créer un compartiment**. Une fois le compartiment créé dans Amazon S3, celui-ci s’affiche dans la console, dans le volet **Compartiments**. 1. Créez un dossier. 1. Choisissez le nom du nouveau compartiment. 1. Choisissez le bouton **Créer un dossier**. 1. Nommez le nouveau dossier **load**. **Note** Le compartiment que vous avez créé ne figure pas dans un environnement de test (sandbox). Au cours de cet exercice, vous ajoutez des objets dans un véritable compartiment. Un montant nominal vous est facturé pour le temps de stockage des objets dans le compartiment. Pour plus d’informations sur les tarifs Amazon S3, consultez la page de [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/). 1. Chargez les fichiers de données dans le nouveau compartiment Amazon S3. 1. Choisissez le nom du dossier de données. 1. Dans l’assistant Charger, choisissez **Ajouter des fichiers**. Suivez les instructions de la console Amazon S3 pour charger tous les fichiers que vous avez téléchargés et extraits. 1. Choisissez **Charger**. **Informations d’identification de l’utilisateur** La commande COPY Amazon Redshift doit avoir un accès en lecture aux objets du fichier du compartiment Amazon S3. Si vous utilisez les mêmes informations d’identification de l’utilisateur pour créer le compartiment Amazon S3 que pour exécuter la commande COPY Amazon Redshift, celle-ci dispose de toutes les autorisations nécessaires. Si vous souhaitez utiliser les informations d’identification d’un autre utilisateur, vous pouvez accorder l’accès en utilisant les contrôles d’accès Amazon S3. La commande Amazon Redshift COPY nécessite au moins ListBucket des GetObject autorisations pour accéder aux objets du fichier dans le compartiment Amazon S3. Pour plus d’informations sur le contrôle de l’accès aux ressources Amazon S3, consultez [Gestion des autorisations d’accès à vos ressources Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). ## Étape 4 : Créer des exemples de tables Pour ce didacticiel, vous utilisez un ensemble de tables basées sur le schéma SSB (Star Schema Benchmark). Le diagramme suivant illustre le modèle de données SSB. ![\[Les cinq tables du schéma SSB et leurs relations les unes avec les autres.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/tutorial-optimize-tables-ssb-data-model.png) Il est possible que les tables SSB existent déjà dans la base de données actuelle. Le cas échéant, supprimez les tables de la base de données avant de les créer à l’aide des commandes CREATE TABLE de l’étape suivante. Les tables utilisées dans ce didacticiel peuvent avoir des attributs différents des tables existantes. **Pour créer des exemples de tables** 1. Pour supprimer les tables SSB, exécutez les commandes suivantes dans votre client SQL. ``` drop table part cascade; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` 1. Exécutez les commandes CREATE TABLE suivantes dans votre client SQL. ``` CREATE TABLE part ( p_partkey INTEGER NOT NULL, p_name VARCHAR(22) NOT NULL, p_mfgr VARCHAR(6), p_category VARCHAR(7) NOT NULL, p_brand1 VARCHAR(9) NOT NULL, p_color VARCHAR(11) NOT NULL, p_type VARCHAR(25) NOT NULL, p_size INTEGER NOT NULL, p_container VARCHAR(10) NOT NULL ); CREATE TABLE supplier ( s_suppkey INTEGER NOT NULL, s_name VARCHAR(25) NOT NULL, s_address VARCHAR(25) NOT NULL, s_city VARCHAR(10) NOT NULL, s_nation VARCHAR(15) NOT NULL, s_region VARCHAR(12) NOT NULL, s_phone VARCHAR(15) NOT NULL ); CREATE TABLE customer ( c_custkey INTEGER NOT NULL, c_name VARCHAR(25) NOT NULL, c_address VARCHAR(25) NOT NULL, c_city VARCHAR(10) NOT NULL, c_nation VARCHAR(15) NOT NULL, c_region VARCHAR(12) NOT NULL, c_phone VARCHAR(15) NOT NULL, c_mktsegment VARCHAR(10) NOT NULL ); CREATE TABLE dwdate ( d_datekey INTEGER NOT NULL, d_date VARCHAR(19) NOT NULL, d_dayofweek VARCHAR(10) NOT NULL, d_month VARCHAR(10) NOT NULL, d_year INTEGER NOT NULL, d_yearmonthnum INTEGER NOT NULL, d_yearmonth VARCHAR(8) NOT NULL, d_daynuminweek INTEGER NOT NULL, d_daynuminmonth INTEGER NOT NULL, d_daynuminyear INTEGER NOT NULL, d_monthnuminyear INTEGER NOT NULL, d_weeknuminyear INTEGER NOT NULL, d_sellingseason VARCHAR(13) NOT NULL, d_lastdayinweekfl VARCHAR(1) NOT NULL, d_lastdayinmonthfl VARCHAR(1) NOT NULL, d_holidayfl VARCHAR(1) NOT NULL, d_weekdayfl VARCHAR(1) NOT NULL ); CREATE TABLE lineorder ( lo_orderkey INTEGER NOT NULL, lo_linenumber INTEGER NOT NULL, lo_custkey INTEGER NOT NULL, lo_partkey INTEGER NOT NULL, lo_suppkey INTEGER NOT NULL, lo_orderdate INTEGER NOT NULL, lo_orderpriority VARCHAR(15) NOT NULL, lo_shippriority VARCHAR(1) NOT NULL, lo_quantity INTEGER NOT NULL, lo_extendedprice INTEGER NOT NULL, lo_ordertotalprice INTEGER NOT NULL, lo_discount INTEGER NOT NULL, lo_revenue INTEGER NOT NULL, lo_supplycost INTEGER NOT NULL, lo_tax INTEGER NOT NULL, lo_commitdate INTEGER NOT NULL, lo_shipmode VARCHAR(10) NOT NULL ); ``` ## Étape 5 : Exécuter les commandes COPY Vous exécutez des commandes COPY pour charger chacune des tables dans le schéma SSB. Les exemples de commande COPY illustrent le chargement dans différents formats, à l’aide de plusieurs options de la commande COPY, ainsi que la résolution des erreurs de chargement. ### Syntaxe de la commande COPY La syntaxe de base de la commande [COPY](r_COPY.md) est la suivante. ``` COPY table_name [ column_list ] FROM data_source CREDENTIALS access_credentials [options] ``` Pour exécuter une commande COPY, fournissez les valeurs suivantes. **Nom de la table** Table cible de la commande COPY. La table doit déjà exister dans la base de données. La table peut être temporaire ou permanente. La commande COPY ajoute les nouvelles données d’entrée à toutes les lignes existantes de la table. **Liste de colonnes** Par défaut, la commande COPY charge les champs depuis les données source dans les colonnes de la table dans l’ordre. Vous pouvez spécifier facultativement une *liste de colonnes,*, qui une liste séparée par des virgules des noms de colonnes, pour mapper les champs de données à des colonnes spécifiques. Vous n’utilisez pas de listes de colonnes de ce didacticiel. Pour plus d’informations, consultez [Column List](copy-parameters-column-mapping.md#copy-column-list) dans la référence de la commande COPY. Source de données Vous pouvez utiliser la commande COPY pour charger les données à partir d’un compartiment Amazon S3, un cluster Amazon EMR, un hôte distant à l’aide d’une connexion SSH, ou d’une table Amazon DynamoDB. Dans le cadre de ce didacticiel, vous chargez des fichiers de données dans un compartiment Amazon S3. Lorsque vous chargez depuis Amazon S3, vous devez fournir le nom du compartiment et l’emplacement des fichiers de données. Pour cela, fournissez soit un chemin d’accès à l’objet pour les fichiers de données ou l’emplacement du fichier manifeste qui répertorie explicitement chaque fichier de données et son emplacement. + Préfixe de clé Un objet stocké dans Amazon S3 est identifié par la clé d’objet, qui inclut le nom du compartiment, les noms des dossiers, le cas échéant, et le nom de l’objet. Un *préfixe de clé *fait référence à un ensemble d’objets portant le même préfixe. Le chemin d’accès de l’objet est un préfixe de clé que la commande COPY utilise pour charger tous les objets partageant le même préfixe de clé. Par exemple, le préfixe de clé `custdata.txt` peut faire référence à un seul fichier ou à un ensemble de fichiers, notamment `custdata.txt.001`, `custdata.txt.002` et ainsi de suite. + Fichier manifeste Dans certains cas, vous aurez peut-être besoin de charger des fichiers avec des préfixes différentes, par exemple des fichiers provenant de plusieurs compartiments ou dossiers. Dans d’autres, vous devrez peut-être exclure des fichiers qui partagent un préfixe. Dans ces cas, vous pouvez utiliser un fichier manifeste. Un *fichier manifeste* répertorie explicitement chaque fichier de chargement et sa clé d’objet unique. Vous utilisez un fichier manifeste pour charger la table PART ultérieurement dans ce didacticiel. **Informations d’identification** Pour accéder aux AWS ressources contenant les données à charger, vous devez fournir les informations d'identification d' AWS accès à un utilisateur disposant de privilèges suffisants. Ces informations d’identification incluent un rôle IAM Amazon Resource Name (ARN). Pour charger des données depuis Amazon S3, les informations d'identification doivent inclure ListBucket des GetObject autorisations. Des informations d’identification supplémentaires sont nécessaires si vos données sont chiffrées. Pour plus d’informations, consultez [Paramètres d’autorisation](copy-parameters-authorization.md) dans la référence de la commande COPY. Pour plus d’informations sur la gestion de l’accès, consultez [Gestion des autorisations d’accès à vos ressources Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). Options Vous pouvez spécifier un certain nombre de paramètres avec la commande COPY afin de définir les formats de fichiers, gérer les formats de données, gérer les erreurs et contrôler d’autres fonctions. Dans ce didacticiel, vous utilisez les fonctions et les options de la commande COPY suivantes : + Préfixe de clé Pour plus d’informations sur le chargement à partir de plusieurs fichiers en spécifiant un préfixe de clé, consultez [Charger la table PART à l’aide de NULL AS](#tutorial-loading-load-part). + Format CSV Pour plus d’informations sur le chargement de données au format CSV, consultez [Charger la table PART à l’aide de NULL AS](#tutorial-loading-load-part). + NULL AS Pour plus d’informations sur le chargement de PART à l’aide de l’option NULL AS, consultez [Charger la table PART à l’aide de NULL AS](#tutorial-loading-load-part). + Format délimité par un caractère Pour plus d’informations sur l’utilisation de l’option DELIMITER, consultez [Les options DELIMITER et REGION](#tutorial-loading-load-supplier). + REGION Pour plus d’informations sur l’utilisation de l’option REGION, consultez [Les options DELIMITER et REGION](#tutorial-loading-load-supplier). + Largeur de format fixe Pour plus d’informations sur le chargement de la table CUSTOMER à partir de données de largeur fixe, consultez [Charger la table CUSTOMER à l’aide de MANIFEST](#tutorial-loading-load-customer). + MAXERROR Pour plus d’informations sur l’utilisation de l’option MAXERROR, consultez [Charger la table CUSTOMER à l’aide de MANIFEST](#tutorial-loading-load-customer). + ACCEPTINVCHARS Pour plus d’informations sur l’utilisation de l’option ACCEPTINVCHARS, consultez [Charger la table CUSTOMER à l’aide de MANIFEST](#tutorial-loading-load-customer). + MANIFEST Pour plus d’informations sur l’utilisation de l’option MANIFEST, consultez [Charger la table CUSTOMER à l’aide de MANIFEST](#tutorial-loading-load-customer). + DATEFORMAT Pour plus d’informations sur l’utilisation de l’option DATEFORMAT, consultez [Charger la table DWDATE à l’aide de DATEFORMAT](#tutorial-loading-load-dwdate). + GZIP, LZOP et BZIP2 Pour plus d’informations sur la compression de vos fichiers, consultez [Chargement de plusieurs fichiers de données](#tutorial-loading-load-lineorder). + COMPUPDATE Pour plus d’informations sur l’utilisation de l’option COMPUPDATE, consultez [Chargement de plusieurs fichiers de données](#tutorial-loading-load-lineorder). + Plusieurs fichiers Pour plus d’informations sur le chargement de plusieurs fichiers, consultez [Chargement de plusieurs fichiers de données](#tutorial-loading-load-lineorder). ### Chargement des tables SSB Vous utilisez les commandes COPY suivantes pour charger chacune des tables dans le schéma SSB. La commande de chaque table illustre les différentes options COPY et des techniques de résolution des problèmes. Pour charger les tables SSB, procédez comme suit : 1. [Remplacez le nom et les AWS informations d'identification du bucket](#tutorial-loading-run-copy-replaceables) 1. [Charger la table PART à l’aide de NULL AS](#tutorial-loading-load-part) 1. [Charger la table CUSTOMER à l’aide de MANIFEST](#tutorial-loading-load-customer) 1. [Charger la table DWDATE à l’aide de DATEFORMAT](#tutorial-loading-load-dwdate) #### Remplacez le nom et les AWS informations d'identification du bucket Les commandes COPY de ce didacticiel sont présentées au format suivant. ``` copy table from 's3:///load/key_prefix' credentials 'aws_iam_role=arn:aws:iam:::role/' options; ``` Pour chaque commande COPY, procédez de la façon suivante : 1. **Remplacez-le par le nom d'un compartiment situé dans la même région que votre cluster. Cette étape suppose que le compartiment et le cluster se situent dans la même région. Vous pouvez aussi spécifier la région à l’aide de l’option [REGION](copy-parameters-data-source-s3.md#copy-region) de la commande COPY. 1. Remplacez ** et ** par votre propre rôle Compte AWS et celui d'IAM. Le segment de la chaîne d’informations d’identification entre guillemets simples ne doit pas comporter d’espaces ou de sauts de ligne. Notez que le format de l’ARN peut être légèrement différent de celui de l’exemple. Il est préférable de copier l’ARN du rôle depuis la console IAM afin de garantir son exactitude lorsque vous exécutez les commandes COPY. #### Charger la table PART à l’aide de NULL AS Au cours de cette étape, vous utilisez les options CSV et NULL AS pour charger la table PART. La commande COPY peut charger des données depuis plusieurs fichiers en parallèle, ce qui est beaucoup plus rapide que le chargement depuis un seul fichier. Pour illustrer ce principe, les données de chaque table de ce didacticiel sont divisées réparties dans huit fichiers, même si les fichiers sont très petits. Au cours d’une étape ultérieure, vous comparez la différence de temps entre le chargement d’un fichier unique et le chargement de plusieurs fichiers. Pour plus d'informations, consultez [Chargement de fichiers de données](c_best-practices-use-multiple-files.md). **Préfixe de clé** Vous pouvez charger à partir de plusieurs fichiers en spécifiant un préfixe de clé à l’ensemble de fichiers ou en répertoriant explicitement les fichiers dans un fichier manifeste. Au cours de cette étape, vous utilisez un préfixe de clé. Au cours d’une étape ultérieure, vous utilisez un fichier manifeste. Le préfixe de clé `'s3://amzn-s3-demo-bucket/load/part-csv.tbl'` charge l’ensemble de fichiers suivant dans le dossier `load`. ``` part-csv.tbl-000 part-csv.tbl-001 part-csv.tbl-002 part-csv.tbl-003 part-csv.tbl-004 part-csv.tbl-005 part-csv.tbl-006 part-csv.tbl-007 ``` **Format CSV** Le format CSV, qui signifie des valeurs séparées par une virgule, est un format couramment utilisé pour importer et exporter les données de feuille de calcul. Le format CSV est plus souple que le format séparé par une virgule, car il vous permet d’inclure des chaînes entre guillemets dans les champs. Le type de guillemets par défaut pour la commande COPY exécutée depuis le format CSV est celui des guillemets doubles ( " ), mais vous pouvez spécifier un autre type de guillemets à l’aide de l’option QUOTE AS. Lorsque vous utilisez les guillemets dans un champ, précédez le caractère de guillemets supplémentaires. L’extrait suivant d’un fichier de données au format CSV pour la table PART illustre des chaînes entourées de guillemets (`"LARGE ANODIZED BRASS"`). Il montre également une chaîne entourée de doubles guillemets dans une chaîne entourée de guillemets (`"MEDIUM ""BURNISHED"" TIN"`). ``` 15,dark sky,MFGR#3,MFGR#47,MFGR#3438,indigo,"LARGE ANODIZED BRASS",45,LG CASE 22,floral beige,MFGR#4,MFGR#44,MFGR#4421,medium,"PROMO, POLISHED BRASS",19,LG DRUM 23,bisque slate,MFGR#4,MFGR#41,MFGR#4137,firebrick,"MEDIUM ""BURNISHED"" TIN",42,JUMBO JAR ``` Les données de la table PART contiennent des caractères qui entraînent l’échec de la commande COPY. Dans cet exercice, vous allez résoudre les erreurs et les corriger. Pour charger des données au format , ajoutez `csv`csv à votre commande COPY. Exécutez la commande suivante afin de charger la table PART. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv; ``` Vous pourriez recevoir un message d’erreur similaire au suivant. ``` An error occurred when executing the SQL command: copy part from 's3://amzn-s3-demo-bucket/load/part-csv.tbl' credentials' ... ERROR: Load into table 'part' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000] Execution time: 1.46s 1 statement(s) failed. 1 statement(s) failed. ``` Pour obtenir plus d’informations sur l’erreur, interrogez la table STL\$1LOAD\$1ERRORS. La requête suivante utilise la fonction SUBSTRING pour réduire les colonnes afin de faciliter la lecture et utilise LIMIT 10 pour réduire le nombre de lignes renvoyées. Vous pouvez ajuster les valeurs dans `substring(filename,22,25)` afin d’autoriser la longueur du nom de votre compartiment. ``` select query, substring(filename,22,25) as filename,line_number as line, substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text, substring(raw_field_value,0,15) as field_text, substring(err_reason,0,45) as reason from stl_load_errors order by query desc limit 10; ``` ``` query | filename | line | column | type | pos | --------+-------------------------+-----------+------------+------------+-----+---- 333765 | part-csv.tbl-000 | 1 | | | 0 | line_text | field_text | reason ------------------+------------+---------------------------------------------- 15,NUL next, | | Missing newline: Unexpected character 0x2c f ``` **NULL AS** Les fichiers de données `part-csv.tbl` utilisent la marque de fin NUL (`\x000` ou `\x0`) pour indiquer des valeurs NULL. **Note** Malgré une orthographe très similaire, NUL et NULL ne sont pas identiques. NUL est un caractère UTF-8 avec le point de code `x000` qui est souvent utilisé pour indiquer la fin de l’enregistrement. NULL est une valeur SQL qui représente l’absence de données. Par défaut, COPY traite une marque de fin NUL comme une marque de fin d’enregistrement et met fin à l’enregistrement, ce qui entraîne souvent des résultats inattendus ou une erreur. Il n’existe pas de méthode standard unique pour indiquer NULL dans les données de texte. Par conséquent, l’option de commande NULL AS COPY vous permet de spécifier le caractère à remplacer par NULL lors du chargement de la table. Dans cet exemple, vous voulez exécuter la commande COPY pour traiter la marque de fin NUL en tant que valeur NULL. **Note** La colonne de la table qui reçoit la valeur NULL doit être configurée comme *acceptant la valeur null*. Autrement dit, elle ne doit pas inclure la contrainte NOT NULL dans la spécification CREATE TABLE. Pour charger la table PART en utilisant l’option AS NULL, exécutez la commande COPY suivante. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv null as '\000'; ``` Pour vérifier que la commande COPY a chargé des valeurs NULL, exécutez la commande suivante pour sélectionner uniquement les lignes qui contiennent la valeur NULL. ``` select p_partkey, p_name, p_mfgr, p_category from part where p_mfgr is null; ``` ``` p_partkey | p_name | p_mfgr | p_category -----------+----------+--------+------------ 15 | NUL next | | MFGR#47 81 | NUL next | | MFGR#23 133 | NUL next | | MFGR#44 (2 rows) ``` #### Les options DELIMITER et REGION Les options DELIMITER et REGION sont importantes pour comprendre comment charger des données. **Format délimité par un caractère** Les champs situés dans un fichier délimité par un caractère sont séparés par un caractère spécifique, comme une barre verticale ( \$1 ), une virgule ( , ) ou une tabulation ( \$1t ). Les fichiers délimités par un caractère peuvent utiliser n’importe quel caractère ASCII unique, notamment l’un des caractères ASCII non affichables, comme le délimiteur. Vous spécifiez le délimiteur à l’aide de l’option DELIMITER. Le délimiteur par défaut est une barre verticale ( \$1 ). L’extrait suivant des données de la table SUPPLIER utilise le format délimité par une barre verticale. ``` 1|1|257368|465569|41365|19950218|2-HIGH|0|17|2608718|9783671|4|2504369|92072|2|19950331|TRUCK 1|2|257368|201928|8146|19950218|2-HIGH|0|36|6587676|9783671|9|5994785|109794|6|19950416|MAIL ``` **REGION** Dans la mesure du possible, vous devez localiser vos données de chargement dans la même AWS région que votre cluster Amazon Redshift. Si vos données et votre cluster se trouvent dans la même région, cela vous permet de réduire la latence et d’éviter des coûts de transfert régional de données. Pour de plus amples informations, veuillez consulter [Bonnes pratiques de chargement des données sur Amazon Redshift](c_loading-data-best-practices.md). Si vous devez charger des données provenant d'une autre AWS région, utilisez l'option REGION pour spécifier la AWS région dans laquelle se trouvent les données de chargement. Si vous spécifiez une région, toutes les données de chargement, notamment les fichiers manifestes, doivent se situer dans la région désignée. Pour plus d’informations, consultez [REGION](copy-parameters-data-source-s3.md#copy-region). Si votre cluster se trouve dans la région USA Est (Virginie du Nord) et que votre compartiment Amazon S3 se trouve dans la région USA Ouest (Oregon), la commande COPY suivante montre comment charger la table SUPPLIER à partir de données séparées par une barre verticale. ``` copy supplier from 's3://amzn-s3-demo-bucket/ssb/supplier.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' delimiter '|' gzip region 'us-west-2'; ``` #### Charger la table CUSTOMER à l’aide de MANIFEST Au cours de cette étape, vous utilisez les options FIXEDWIDTH, MAXERROR, ACCEPTINVCHARS et MANIFEST pour charger la table CUSTOMER. Les exemples de données de cet exercice contiennent des caractères qui entraînent des erreurs lorsque COPY tente de les charger. Vous utilisez l’option MAXERRORS et la table système STL\$1LOAD\$1ERRORS pour résoudre les erreurs de chargement, puis utiliser les options ACCEPTINVCHARS et MANIFEST pour éliminer les erreurs. **Format à largeur fixe** Le format à largeur fixe définit chaque champ en tant que nombre de caractères fixe, plutôt que comme des champs séparés par un délimiteur. L’extrait suivant des données de la table CUSTOMER utilise le format à largeur fixe. ``` 1 Customer#000000001 IVhzIApeRb MOROCCO 0MOROCCO AFRICA 25-705 2 Customer#000000002 XSTf4,NCwDVaWNe6tE JORDAN 6JORDAN MIDDLE EAST 23-453 3 Customer#000000003 MG9kdTD ARGENTINA5ARGENTINAAMERICA 11-783 ``` L'ordre des label/width paires doit correspondre exactement à l'ordre des colonnes du tableau. Pour de plus amples informations, veuillez consulter [FIXEDWIDTH](copy-parameters-data-format.md#copy-fixedwidth). La chaîne de spécification à largeur fixe pour les données de la table CUSTOMER est la suivante. ``` fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' ``` Pour charger la table CUSTOMER à partir de données à largeur fixe, exécutez la commande suivante. ``` copy customer from 's3:///load/customer-fw.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10'; ``` Vous devez recevoir un message d’erreur similaire au suivant. ``` An error occurred when executing the SQL command: copy customer from 's3://amzn-s3-demo-bucket/load/customer-fw.tbl' credentials'... ERROR: Load into table 'customer' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000] Execution time: 2.95s 1 statement(s) failed. ``` **MAXERROR** Par défaut, la première fois que COPY rencontre une erreur, la commande échoue et renvoie un message d’erreur. Pour gagner du temps pendant le test, vous pouvez utiliser l’option MAXERROR pour indiquer à COPY d’ignorer un nombre d’erreurs spécifié avant d’échouer. Du fait que nous anticipons des erreurs la première fois que nous testons le chargement des données de la table CUSTOMER, ajoutez `maxerror 10` à la commande COPY. Pour effectuer le test en utilisant les options FIXEDWIDTH et MAXERROR, exécutez la commande suivante. ``` copy customer from 's3:///load/customer-fw.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' maxerror 10; ``` Cette fois-ci, au lieu d’un message d’erreur, vous recevez un message d’avertissement semblable au suivant. ``` Warnings: Load into table 'customer' completed, 112497 record(s) loaded successfully. Load into table 'customer' completed, 7 record(s) could not be loaded. Check 'stl_load_errors' system table for details. ``` L’avertissement indique que la commande COPY a rencontré sept erreurs. Pour vérifier les erreurs, interrogez la table STL\$1LOAD\$1ERRORS, comme illustré dans l’exemple suivant. ``` select query, substring(filename,22,25) as filename,line_number as line, substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text, substring(raw_field_value,0,15) as field_text, substring(err_reason,0,45) as error_reason from stl_load_errors order by query desc, filename limit 7; ``` Les résultats de la requête STL\$1LOAD\$1ERRORS doivent être similaires à ce qui suit. ``` query | filename | line | column | type | pos | line_text | field_text | error_reason --------+---------------------------+------+-----------+------------+-----+-------------------------------+------------+---------------------------------------------- 334489 | customer-fw.tbl.log | 2 | c_custkey | int4 | -1 | customer-fw.tbl | customer-f | Invalid digit, Value 'c', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 6 | c_custkey | int4 | -1 | Complete | Complete | Invalid digit, Value 'C', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 3 | c_custkey | int4 | -1 | #Total rows | #Total row | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 5 | c_custkey | int4 | -1 | #Status | #Status | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 1 | c_custkey | int4 | -1 | #Load file | #Load file | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8 334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8 (7 rows) ``` En examinant les résultats, vous pouvez voir qu’il y a deux messages dans la colonne `error_reasons` : + ``` Invalid digit, Value '#', Pos 0, Type: Integ ``` Ces erreurs sont entraînées par le fichier `customer-fw.tbl.log`. Le problème est qu’il existe un fichier journal, pas un fichier de données et qu’il ne doit pas être chargé. Vous pouvez utiliser un fichier manifeste pour éviter le chargement du fichier incorrect. + ``` String contains invalid or unsupported UTF8 ``` Le type de données VARCHAR prend en charge les caractères UTF-8 de 3 octets au maximum. Si les données de chargement contiennent des caractères non pris en charge ou non valides, vous pouvez utiliser l’option ACCEPTINVCHARS pour remplacer chaque caractère non valide par un caractère alternatif spécifié. Un autre problème se pose avec la charge qui est plus difficile à détecter : les résultats inattendus produits par la charge. Afin d’étudier ce problème, exécutez la commande suivante pour interroger la table CUSTOMER. ``` select c_custkey, c_name, c_address from customer order by c_custkey limit 10; ``` ``` c_custkey | c_name | c_address -----------+---------------------------+--------------------------- 2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE 2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE 3 | Customer#000000003 | MG9kdTD 3 | Customer#000000003 | MG9kdTD 4 | Customer#000000004 | XxVSJsL 4 | Customer#000000004 | XxVSJsL 5 | Customer#000000005 | KvpyuHCplrB84WgAi 5 | Customer#000000005 | KvpyuHCplrB84WgAi 6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx 6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx (10 rows) ``` Les lignes doivent être uniques, mais il existe des doublons. Pour vérifier les résultats inattendus, vous pouvez également vérifier le nombre de lignes qui ont été chargées. Dans notre cas, 100 000 lignes ont été chargées, mais le message de chargement a signalé le chargement de 112 497 enregistrements. Des lignes supplémentaires ont été chargées, car la commande COPY a chargé un fichier superflu, `customer-fw.tbl0000.bak`. Dans cet exercice, vous utilisez un fichier manifeste pour éviter de charger des fichiers incorrects. **ACCEPTINVCHARS** Par défaut, lorsque la commande COPY rencontre un caractère qui n’est pas pris en charge par le type de données de la colonne, il ignore la ligne et renvoie une erreur. Pour plus d’informations sur les caractères UTF-8 non valides, consultez [Erreurs de chargement de caractères multioctets](multi-byte-character-load-errors.md). Vous pouvez utiliser l’option MAXERRORS pour ignorer les erreurs et continuer le chargement, puis interroger STL\$1LOAD\$1ERRORS pour rechercher les caractères non valides et corriger les fichiers de données. Cependant, MAXERRORS est plus utile pour résoudre les problèmes de chargement et ne doit pas être utilisé, en général, dans un environnement de production. L’option ACCEPTINVCHARS est généralement un choix plus adapté à la gestion des caractères non valides. ACCEPTINVCHARS indique que la commande COPY doit remplacer chaque caractère non valide par un caractère valide spécifié et poursuivre l’opération de chargement. Vous pouvez spécifier n’importe quel caractère ASCII valide, sauf NULL, comme caractère de remplacement. Le caractère de remplacement par défaut est un point d’interrogation ( ? ). La commande COPY remplace les caractères de plusieurs octets par une chaîne de remplacement de la même longueur. Par exemple, un caractère de 4 octets serait remplacé par `'????'`. COPY renvoie le nombre de lignes qui contenaient les caractères UTF-8 non valides. Cette commande ajoute également une entrée à la table système STL\$1REPLACEMENTS pour chaque ligne affectée, jusqu’à un maximum de 100 lignes par tranche de nœud. Les caractères UTF-8 non valides supplémentaires sont également remplacés, mais ces événements de remplacement ne sont pas enregistrés. ACCEPTINVCHARS est valide uniquement pour les colonnes VARCHAR. Pour cette étape, vous ajoutez ACCEPTINVCHARS au caractère de remplacement `'^'`. **MANIFEST** Lorsque vous exécutez la commande COPY à partir d’Amazon S3 à l’aide d’un préfixe de clé, il y a un risque que vous chargiez des tables indésirables. Par exemple, le dossier `'s3://amzn-s3-demo-bucket/load/` contient huit fichiers de données partageant le préfixe de clé `customer-fw.tbl` : `customer-fw.tbl0000`, `customer-fw.tbl0001` et ainsi de suite. Cependant, le même dossier contient également les fichiers superflus `customer-fw.tbl.log` et `customer-fw.tbl-0001.bak`. Pour vous assurer que vous chargez tous les fichiers corrects et uniquement les fichiers corrects, utilisez un fichier manifeste. Le manifeste est un fichier texte au format JSON qui répertorie explicitement la clé d’objet unique de chaque fichier source à charger. Les objets de fichier peuvent se situer dans différents dossiers ou compartiments, mais ils doivent se trouver dans la même région. Pour plus d'informations, consultez [MANIFEST](copy-parameters-data-source-s3.md#copy-manifest). L’exemple suivant illustre le texte `customer-fw-manifest`. ``` { "entries": [ {"url":"s3:///load/customer-fw.tbl-000"}, {"url":"s3:///load/customer-fw.tbl-001"}, {"url":"s3:///load/customer-fw.tbl-002"}, {"url":"s3:///load/customer-fw.tbl-003"}, {"url":"s3:///load/customer-fw.tbl-004"}, {"url":"s3:///load/customer-fw.tbl-005"}, {"url":"s3:///load/customer-fw.tbl-006"}, {"url":"s3:///load/customer-fw.tbl-007"} ] } ``` **Pour charger les données de la table CUSTOMER en utilisant le fichier manifeste** 1. Ouvrez le fichier `customer-fw-manifest` dans un éditeur de texte. 1. Remplacez ** par le nom de votre compartiment. 1. Enregistrez le fichier. 1. Chargez le fichier dans le dossier de chargement de votre compartiment. 1. Exécutez la commande COPY suivante. ``` copy customer from 's3:///load/customer-fw-manifest' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' maxerror 10 acceptinvchars as '^' manifest; ``` #### Charger la table DWDATE à l’aide de DATEFORMAT Au cours de cette étape, vous utilisez les options DELIMITER et DATEFORMAT pour charger la table DWDATE. Lors du chargement des colonnes DATE et TIMESTAMP, COPY attend le format par défaut, qui est YYYY-MM-DD pour les dates et YYYY-MM-DD HH:MI:SS pour les horodatages. Si les données de chargement n’utilisent pas un format par défaut, vous pouvez utiliser DATEFORMAT et TIMEFORMAT pour spécifier le format. L’extrait suivant présente les formats de date du tableau DWDATE. Notez que les formats de date de la colonne deux sont incompatibles. ``` 19920104 1992-01-04 Sunday January 1992 199201 Jan1992 1 4 4 1... 19920112 January 12, 1992 Monday January 1992 199201 Jan1992 2 12 12 1... 19920120 January 20, 1992 Tuesday January 1992 199201 Jan1992 3 20 20 1... ``` **DATEFORMAT** Vous ne pouvez spécifier qu’un seul format de date. Si les données de chargement contiennent des formats incompatibles, éventuellement dans différentes colonnes, ou si le format n’est pas connu au moment du chargement, vous utilisez DATEFORMAT avec l’argument `'auto'`. Lorsque `'auto'` est spécifié, la commande COPY reconnaît tous les formats d’heure ou de date valides et les convertira au format par défaut. L’option `'auto'` reconnaît plusieurs formats qui ne sont pas pris en charge lors de l’utilisation d’une chaîne DATEFORMAT et TIMEFORMAT. Pour plus d'informations, consultez [Utilisation de la reconnaissance automatique avec DATEFORMAT et TIMEFORMAT](automatic-recognition.md). Pour charger la table DWDATE, exécutez la commande COPY suivante. ``` copy dwdate from 's3:///load/dwdate-tab.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' delimiter '\t' dateformat 'auto'; ``` #### Chargement de plusieurs fichiers de données Vous pouvez utiliser les options GZIP et COMPUPDATE pour charger une table. Vous pouvez charger une table à partir d’un seul fichier de données ou de plusieurs fichiers. Cela vous permet de comparer les temps de chargement pour les deux méthodes. **GZIP, LZOP et BZIP2** Vous pouvez compresser vos fichiers à l’aide des formats de compression gzip, lzop ou bzip2. Lors du chargement de fichiers compressés, la commande COPY décompresse les fichiers pendant le processus de chargement. La compression de vos fichiers enregistre l’espace de stockage et réduit les temps de chargement. **COMPUPDATE** Lorsque la commande COPY charge une table vide sans aucun codage de compression, elle analyse les données de chargement pour déterminer les encodages optimaux. Elle modifie ensuite la table afin d’utiliser ces encodages avant de commencer le chargement. Ce processus d’analyse prend du temps, mais il se produit, tout au plus, une fois par table. Pour gagner du temps, vous pouvez ignorer cette étape en désactivant COMPUPDATE. Pour permettre une évaluation précise de temps de la commande COPY, vous désactivez COMPUPDATE pour cette étape. **Plusieurs fichiers** La commande COPY peut charger les données de manière très efficace en chargeant plusieurs fichiers en parallèle plutôt qu’un seul fichier. Vous pouvez scinder vos données en fichiers de telle sorte que le nombre de fichiers soit un multiple du nombre de tranches de votre cluster. Le cas échéant, Amazon Redshift divise la charge de travail et répartit les données de façon uniforme entre les tranches. Le nombre de tranches par nœud dépend de la taille de nœud du cluster. Pour plus d’informations sur le nombre de tranches pour chaque taille de nœud, consultez la rubrique [À propos des clusters et nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) dans le *Guide de gestion Amazon Redshift*. Par exemple, les nœuds de calcul de votre cluster dans ce didacticiel se composent de deux tranches chacun, afin que le cluster à quatre nœuds se compose de huit tranches. Au cours des étapes précédentes, les données de chargement étaient contenues dans huit fichiers, même si les fichiers étaient très petits. Vous pouvez comparer la différence de temps entre le chargement d’un fichier volumineux unique et le chargement de plusieurs fichiers. Même les fichiers qui contiennent 15 millions d’enregistrements et occupent environ 1,2 Go sont très petits à l’échelle Amazon Redshift. Ils sont toutefois suffisants pour démontrer l’avantage que représente le chargement de plusieurs fichiers en termes de performances. L’image suivante présente les fichiers de données pour LINEORDER. ![\[Les données de la table LINEORDER sont réparties en neuf fichiers.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/tutorial-load-lineorder-files.png) **Pour évaluer les performances de la commande COPY avec plusieurs fichiers** 1. Dans un atelier de test, la commande suivante a été exécutée pour utiliser COPY à partir d’un seul fichier. Cette commande affiche un compartiment fictif. ``` copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-single.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' gzip compupdate off region 'us-east-1'; ``` 1. Les résultats ont été les suivants. Notez le délai d’exécution. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 51.56s ``` 1. La commande suivante a ensuite été exécutée pour utiliser COPY à partir de plusieurs fichiers. ``` copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-multi.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' gzip compupdate off region 'us-east-1'; ``` 1. Les résultats ont été les suivants. Notez le délai d’exécution. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 17.7s ``` 1. Comparez les temps d’exécution. Dans notre expérience, le temps de chargement de 15 millions d’enregistrements est passé de 51,56 secondes à 17,7 secondes, soit une diminution de 65,7 %. Ces résultats sont basés sur l’utilisation d’un cluster à quatre nœuds. Si votre cluster comporte plusieurs nœuds, les gains de temps sont multipliés. Pour des clusters Amazon Redshift classiques, avec des dizaines, voire des centaines de nœuds, la différence est encore plus spectaculaire. Si vous disposez d’un cluster à nœud unique, il y a peu de différence entre les temps d’exécution. ## Étape 6 : Vider et analyser la base de données Chaque fois que vous ajoutez, supprimez ou modifiez un grand nombre de lignes, vous devez exécuter une commande VACUUM, puis une commande ANALYZE. Une commande *vacuum* récupère l’espace des lignes supprimées et restaure l’ordre de tri. La commande ANALYZE met à jour les métadonnées des statistiques, ce qui permet à l’optimiseur de requête de générer des plans de requête plus précis. Pour plus d'informations, consultez [Exécution de l’opération VACUUM sur les tables](t_Reclaiming_storage_space202.md). Si vous chargez les données dans l’ordre d’une clé de tri, le vidage est rapide. Dans ce didacticiel, vous avez ajouté un grand nombre de lignes, mais vous les avez ajoutées à des tables vides. Dans ce cas, il est inutile d’y recourir, et vous n’a pas besoin de supprimer toutes les lignes. COPY met automatiquement à jour les statistiques après le chargement d'une table vide. Vos statistiques devraient donc l'être up-to-date. Cependant, pour des raisons de bonne gestion, vous terminez ce didacticiel en effectuant un vidage et une analyse de votre base de données. Pour vider et analyser la base de données, exécutez les commandes suivantes. ``` vacuum; analyze; ``` ## Étape 7 : Nettoyer vos ressources Votre cluster continue d’accumuler les frais aussi longtemps qu’il est en cours d’exécution. Une fois ce didacticiel terminé, vous devez rétablir votre environnement à l’état précédent en suivant les étapes décrites à l’[Étape 5 : Annuler les droits d’accès et supprimer votre exemple de cluster](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) du *Guide de démarrage d’Amazon Redshift*. Si vous souhaitez conserver le cluster, mais que vous voulez récupérer le stockage utilisé par les tables SSB, exécutez les commandes suivantes. ``` drop table part; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` ### Suivant [Résumé](#tutorial-loading-data-summary) ## Résumé Dans ce didacticiel, vous avez téléchargé les fichiers de données dans Amazon S3, puis utilisé les commandes COPY pour charger les données des fichiers dans des tables Amazon Redshift. Vous avez chargé des données à l’aide des formats suivants : + Délimité par un caractère + CSV + A largeur fixe Vous avez utilisé la table système STL\$1LOAD\$1ERRORS pour résoudre les erreurs de chargement, puis utilisé les options REGION, MANIFEST, MAXERROR, ACCEPTINVCHARS, DATEFORMAT et NULL AS pour résoudre les erreurs. Vous avez appliqué les bonnes pratiques suivantes au chargement des données : + [Utiliser une commande COPY pour charger les données](c_best-practices-use-copy.md) + [Chargement de fichiers de données](c_best-practices-use-multiple-files.md) + [Utiliser une seule commande COPY pour charger à partir de plusieurs fichiers](c_best-practices-single-copy-command.md) + [Compression de vos fichiers de données](c_best-practices-compress-data-files.md) + [Vérifier les fichiers de données avant et après un chargement](c_best-practices-verifying-data-files.md) Pour plus d’informations sur les bonnes pratiques Amazon Redshift, consultez les liens suivants : + [Bonnes pratiques de chargement des données sur Amazon Redshift](c_loading-data-best-practices.md) + [Bonnes pratiques Amazon Redshift pour la conception de tables](c_designing-tables-best-practices.md) + [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md)