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.
# Création d'objets dans AWS Glue Data Catalog
AWS Lake Formation utilise le AWS Glue Data Catalog (catalogue de données) pour stocker les métadonnées relatives aux lacs de données, aux sources de données, aux transformations et aux cibles. Les métadonnées sont des données relatives aux données sous-jacentes de votre jeu de données. Chaque AWS compte possède un catalogue de données par AWS région.
Les métadonnées du catalogue de données sont organisées selon une hiérarchie de données à trois niveaux comprenant des catalogues, des bases de données et des tables. Il organise les données provenant de diverses sources dans des conteneurs logiques appelés catalogues. Chaque catalogue représente des données provenant de sources telles que les entrepôts de données Amazon Redshift, les Amazon DynamoDB bases de données et les sources de données tierces telles que Snowflake, MySQL, et de plus de 30 sources de données externes, qui sont intégrées via des connecteurs fédérés. Vous pouvez également créer de nouveaux catalogues dans le catalogue de données pour stocker les données dans des compartiments de table S3 ou dans le stockage géré Redshift (RMS).
Les tables stockent des informations sur les données sous-jacentes, notamment les informations de schéma, les informations de partition et l'emplacement des données. Les bases de données sont des ensembles de tables. Le catalogue de données contient également des liens vers des ressources, qui sont des liens vers des catalogues, des bases de données et des tables partagés dans des comptes externes, et sont utilisés pour l'accès entre comptes aux données du lac de données.
Le catalogue de données est un objet de catalogue imbriqué qui contient des catalogues, des bases de données et des tables. Il est référencé par l' Compte AWS ID et constitue le catalogue par défaut d'un compte et d'un Région AWS. Le catalogue de données utilise une hiérarchie à trois niveaux (catalog.database.table) pour organiser les tables.
+ Catalogue : niveau supérieur de la hiérarchie des métadonnées à trois niveaux du catalogue de données. Vous pouvez ajouter plusieurs catalogues dans un catalogue de données par le biais de la fédération.
+ Base de données : deuxième niveau de la hiérarchie des métadonnées comprenant des tables et des vues. Une base de données est également appelée schéma dans de nombreux systèmes de données tels qu'Amazon Redshift et Trino.
+ Tableau et affichage : troisième niveau de la hiérarchie des données à 3 niveaux du catalogue de données.
Toutes les tables Iceberg d'Amazon S3 sont stockées dans le catalogue de données par défaut avec Catalog ID = Compte AWS ID. Vous pouvez créer des catalogues fédérés dans lesquels sont stockées AWS Glue Data Catalog les définitions des tables dans Amazon Redshift, Amazon S3 Table Storage ou dans d'autres sources de données tierces par le biais de la fédération.
**Topics**
+ [Création d'un catalogue](creating-catalog.md)
+ [Création d’une base de données](creating-database.md)
+ [Création de tables](creating-tables.md)
+ [AWS Glue Data Catalog Vues du bâtiment](working-with-views.md)
# Création d'un catalogue
Les catalogues représentent le niveau le plus élevé ou le plus élevé de la hiérarchie de métadonnées à trois niveaux du. AWS Glue Data Catalog Vous pouvez utiliser plusieurs méthodes pour intégrer des données dans le catalogue de données et créer des catalogues à plusieurs niveaux.
Pour plus d'informations sur la création de catalogues à partir de sources de données externes, consultez[Intégrer vos données dans AWS Glue Data Catalog](bring-your-data-overview.md).
Pour créer un catalogue à l'aide de la console Lake Formation, vous devez être connecté en tant qu'administrateur de lac de données ou *créateur de catalogue*. Un créateur de catalogue est un directeur qui a obtenu l'`CREATE_CATALOG`autorisation de Lake Formation. Vous pouvez consulter la liste des créateurs de catalogues sur la page **Rôles et tâches administratifs** de la console Lake Formation. Pour consulter cette liste, vous devez disposer de l'autorisation `lakeformation:ListPermissions` IAM et être connecté en tant qu'administrateur de lac de données ou en tant que créateur de catalogue avec l'option d'octroi sur l'`CREATE_CATALOG`autorisation.
# Création d’une base de données
Les tables de métadonnées du catalogue de données sont stockées dans des bases de données. Vous pouvez créer autant de bases de données que vous le souhaitez, et vous pouvez accorder différentes autorisations Lake Formation pour chaque base de données.
Les bases de données peuvent avoir une propriété d'emplacement facultative. Cet emplacement se trouve généralement dans un site Amazon Simple Storage Service (Amazon S3) enregistré auprès de Lake Formation. Lorsque vous spécifiez un emplacement, les principaux n'ont pas besoin d'autorisations de localisation des données pour créer des tables de catalogue de données qui pointent vers des emplacements au sein de l'emplacement de la base de données. Pour de plus amples informations, veuillez consulter [Underlying data access control](access-control-underlying-data.md#data-location-permissions).
Pour créer une base de données à l'aide de la console Lake Formation, vous devez être connecté en tant qu'administrateur de lac de données ou *créateur de base de données*. Un créateur de base de données est un directeur qui a obtenu l'`CREATE_DATABASE`autorisation de Lake Formation. Vous pouvez consulter la liste des créateurs de bases de données sur la page **Rôles et tâches administratifs** de la console Lake Formation. Pour consulter cette liste, vous devez disposer de l'autorisation `lakeformation:ListPermissions` IAM et être connecté en tant qu'administrateur de lac de données ou en tant que créateur de base de données avec l'option d'octroi sur l'`CREATE_DATABASE`autorisation.
**Pour créer une base de données**
1. Ouvrez la AWS Lake Formation console sur [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)et connectez-vous en tant qu'administrateur de lac de données ou créateur de base de données.
1. Dans le volet de navigation, sous **Catalogue de données**, sélectionnez **Bases de données**.
1. Choisissez **Créer une base de données**.
1. Dans la boîte **de dialogue Créer une base** de données, entrez un nom de base de données, un emplacement facultatif et une description facultative.
1. Sélectionnez éventuellement **Utiliser uniquement le contrôle d'accès IAM pour les nouvelles tables de cette base de données**.
Pour de plus amples informations sur cette option, veuillez consulter [Modification des paramètres par défaut de votre lac de données](change-settings.md).
1. Choisissez **Créer une base de données**.
# Création de tables
AWS Lake Formation les tables de métadonnées contiennent des informations sur les données du lac de données, notamment des informations sur le schéma, les informations de partition et l'emplacement des données. Ces tables sont stockées dans le catalogue AWS Glue de données. Vous les utilisez pour accéder aux données sous-jacentes du lac de données et pour gérer ces données avec les autorisations de Lake Formation. Les tables sont stockées dans les bases de données du catalogue de données.
Il existe plusieurs méthodes pour créer des tables de catalogue de données :
+ Lancez un crawler dedans. AWS Glue Consultez [la section Définition des robots](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html) d'exploration dans le *guide du AWS Glue développeur*.
+ Créez et exécutez un flux de travail. Consultez [Importation de données à l'aide de flux de travail dans Lake Formation](workflows.md).
+ Créez une table manuellement à l'aide de la console Lake Formation, de AWS Glue l'API ou AWS Command Line Interface (AWS CLI).
+ Créez un tableau à l'aide de Amazon Athena.
+ Créez un lien de ressource vers une table dans un compte externe. Consultez [Création de liens vers des ressources](creating-resource-links.md).
# Création de tables Apache Iceberg
AWS Lake Formation prend en charge la création de tables Apache Iceberg qui utilisent le format de données Apache Parquet dans AWS Glue Data Catalog les données résidant dans Amazon S3. Une table dans le catalogue de données correspond à la définition des métadonnées qui représente les données dans un entrepôt de données. Par défaut, Lake Formation crée des tables Iceberg v2. Pour connaître la différence entre les tables v1 et v2, consultez la section [Modifications de version de format](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) dans la documentation Apache Iceberg.
[Apache Iceberg](https://iceberg.apache.org/) est un format de table ouvert pour les jeux de données analytiques très volumineux. Iceberg permet de modifier facilement votre schéma, également ce que l’on appelle l’évolution du schéma, ce qui signifie que les utilisateurs peuvent ajouter, renommer ou supprimer des colonnes d’une table de données sans perturber les données sous-jacentes. Iceberg fournit également une prise en charge pour la gestion des versions des données, ce qui permet aux utilisateurs de suivre les modifications apportées aux données au fil du temps. Cela active la fonctionnalité Time Travel, qui permet aux utilisateurs d’accéder aux versions historiques des données, de les interroger, mais aussi d’analyser les modifications apportées aux données entre les mises à jour et les suppressions.
Vous pouvez utiliser la console Lake Formation ou l'`CreateTable`opération de l' AWS Glue API pour créer une table Iceberg dans le catalogue de données. Pour plus d'informations, consultez [CreateTable action (Python : create\$1table](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)).
Lorsque vous créez une table Iceberg dans le catalogue de données, vous devez spécifier le format de la table et le chemin d’accès au fichier de métadonnées dans Amazon S3 pour pouvoir effectuer des lectures et des écritures.
Vous pouvez utiliser Lake Formation pour sécuriser votre table Iceberg à l'aide d'autorisations de contrôle d'accès précises lorsque vous enregistrez l'emplacement des données Amazon S3 auprès de celui-ci. AWS Lake Formation Pour les données source dans Amazon S3 et les métadonnées qui ne sont pas enregistrées auprès de Lake Formation, l'accès est déterminé par les politiques d'autorisation IAM pour Amazon S3 et AWS Glue les actions. Pour de plus amples informations, veuillez consulter [Gestion des autorisations relatives à Lake Formation](managing-permissions.md).
**Note**
Le catalogue de données ne prend pas en charge la création de partitions ni l’ajout de propriétés de table Iceberg.
**Topics**
+ [Conditions préalables](#iceberg-prerequisites)
+ [Création d’une table Iceberg](#create-iceberg-table)
## Conditions préalables
Pour créer des tables Iceberg dans le catalogue de données et configurer les autorisations d’accès aux données de Lake Formation, vous devez remplir les conditions suivantes :
1.
**Autorisations requises pour créer des tables Iceberg sans les données enregistrées auprès de Lake Formation :**
Outre les autorisations requises pour créer une table dans le catalogue de données, le créateur de table exige les autorisations suivantes :
+ `s3:PutObject` sur la ressource arn:aws:s3:::\$1bucketName\$1
+ `s3:GetObject` sur la ressource arn:aws:s3:::\$1bucketName\$1
+ `s3:DeleteObject` sur la ressource arn:aws:s3:::\$1bucketName\$1
1.
**Autorisations requises pour créer des tables Iceberg avec des données enregistrées auprès de Lake Formation :**
Pour utiliser Lake Formation afin de gérer et de sécuriser les données de votre lac de données, enregistrez votre site Amazon S3 contenant les données pour les tables auprès de Lake Formation. Cela permet à Lake Formation de vendre des informations d'identification à AWS des services d'analyse tels qu'Athena, Redshift Spectrum et Amazon EMR pour accéder aux données. Pour plus d'informations sur l'enregistrement d'un site Amazon S3, consultez[Ajouter un emplacement Amazon S3 à votre lac de données](register-data-lake.md).
Un principal qui lit et écrit les données sous-jacentes enregistrées auprès de Lake Formation doit disposer des autorisations suivantes :
+ `lakeformation:GetDataAccess`
+ `DATA_LOCATION_ACCESS`
Un principal qui possède des autorisations de localisation des données sur un emplacement possède également des autorisations d’emplacement sur tous les sites enfant.
Pour plus d'informations sur les autorisations de localisation des données, consultez[Contrôle d'accès aux données sous-jacent](access-control-underlying-data.md).
Pour activer le compactage, le service doit endosser un rôle IAM autorisé à mettre à jour les tables dans le catalogue de données. Pour plus de détails, consultez la section [Conditions préalables à l'optimisation des tables](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
## Création d’une table Iceberg
Vous pouvez créer des tables Iceberg v1 et v2 à l'aide de la console Lake Formation ou AWS Command Line Interface comme indiqué sur cette page. Vous pouvez également créer des tables Iceberg à l'aide de AWS Glue la console ou AWS Glue crawler. Pour plus d’informations, consultez [Data Catalog and Crawlers](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html) dans le Guide du développeur AWS Glue .
**Pour créer une table Iceberg**
------
#### [ Console ]
1. Connectez-vous à la AWS Management Console console Lake Formation et ouvrez-la à l'adresse [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Sous catalogue de données, choisissez **Tables**, puis utilisez le bouton **Créer une table** pour spécifier les attributs suivants :
+ **Nom de la table** : entrez le nom de la table. Si vous utilisez Athena pour accéder à des tables, utilisez ces [conseils de dénomination](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html) figurant dans le Guide de l’utilisateur Amazon Athena.
+ **Base de données** : Choisissez une base de données existante ou créez-en une nouvelle.
+ **Description : description de la** table. Vous pouvez écrire une description vous aidant à comprendre le contenu de la table.
+ **Format de tableau** : pour **Format de tableau**, choisissez Apache Iceberg.
![\[Option de table Apache Iceberg sélectionnée avec les options d'optimisation des tables.\]](http://docs.aws.amazon.com/fr_fr/lake-formation/latest/dg/images/table-optimization.png)
+ **Optimisation des tables**
+ **Compactage** : les fichiers de données sont fusionnés et réécrits pour supprimer les données obsolètes et regrouper les données fragmentées dans des fichiers plus volumineux et plus efficaces.
+ **Conservation des instantanés** : les instantanés sont des versions horodatées d’une table Iceberg. Les configurations de conservation des instantanés permettent aux clients de définir la durée de conservation des instantanés et le nombre d’instantanés à conserver. La configuration d’un optimiseur de conservation des instantanés peut aider à gérer la charge de stockage en supprimant les instantanés plus anciens et inutiles, ainsi que leurs fichiers sous-jacents associés.
+ **Suppression de fichiers orphelins** : les fichiers orphelins sont des fichiers qui ne sont plus référencés par les métadonnées de la table Iceberg. Ces fichiers peuvent s’accumuler au fil du temps, en particulier après des opérations telles que la suppression de tables ou l’échec de tâches ETL. L'activation de la suppression des fichiers orphelins permet AWS Glue d'identifier et de supprimer périodiquement ces fichiers inutiles, libérant ainsi de l'espace de stockage.
Pour plus d’informations, consultez [Optimisation des tables Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html).
+ **Rôle IAM** : pour exécuter le compactage, le service assume un rôle IAM en votre nom. Vous pouvez choisir un rôle IAM à l'aide de la liste déroulante. Assurez-vous que le rôle dispose des autorisations requises pour activer le compactage.
Pour en savoir plus sur les autorisations requises, consultez la section [Conditions préalables à l'optimisation des tables](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
+ **Emplacement** : Spécifiez le chemin d'accès au dossier dans Amazon S3 qui stocke la table de métadonnées. Iceberg a besoin d’un fichier de métadonnées et d’un emplacement dans le catalogue de données pour pouvoir effectuer des lectures et des écritures.
+ **Schéma** : choisissez **Ajouter des colonnes** pour ajouter des colonnes et les types de données des colonnes. Vous avez la possibilité de créer une table vide et de mettre à jour le schéma ultérieurement. Le catalogue de données prend en charge les types de données Hive. Pour plus d’informations, consultez [Hive data types](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462).
Iceberg vous permet de faire évoluer le schéma et la partition après avoir créé la table. Vous pouvez utiliser des [requêtes Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) pour mettre à jour le schéma de table et des [requêtes Spark](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) pour mettre à jour les partitions.
------
#### [ AWS CLI ]
```
aws glue create-table \
--database-name iceberg-db \
--region us-west-2 \
--open-table-format-input '{
"IcebergInput": {
"MetadataOperation": "CREATE",
"Version": "2"
}
}' \
--table-input '{"Name":"test-iceberg-input-demo",
"TableType": "EXTERNAL_TABLE",
"StorageDescriptor":{
"Columns":[
{"Name":"col1", "Type":"int"},
{"Name":"col2", "Type":"int"},
{"Name":"col3", "Type":"string"}
],
"Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/"
}
}'
```
------
# Optimisation des tables Iceberg
Lake Formation prend en charge plusieurs options d'optimisation des tables afin d'améliorer la gestion et les performances des tables Apache Iceberg utilisées par les moteurs AWS d'analyse et les tâches ETL. Ces optimiseurs permettent d’utiliser efficacement le stockage, d’améliorer les performances des requêtes et de gérer efficacement les données. Trois types d'optimiseurs de tables sont disponibles dans Lake Formation :
+ **Compactage** : le compactage des données compacte les petits fichiers de données afin de réduire l’utilisation du stockage et d’améliorer les performances de lecture. Les fichiers de données sont fusionnés et réécrits pour supprimer les données obsolètes et regrouper les données fragmentées dans des fichiers plus volumineux et plus efficaces. Le compactage peut être configuré pour s'exécuter automatiquement ou être déclenché manuellement selon les besoins.
+ **Conservation des instantanés** : les instantanés sont des versions horodatées d’une table Iceberg. Les configurations de conservation des instantanés permettent aux clients de définir la durée de conservation des instantanés et le nombre d’instantanés à conserver. La configuration d’un optimiseur de conservation des instantanés peut aider à gérer la charge de stockage en supprimant les instantanés plus anciens et inutiles, ainsi que leurs fichiers sous-jacents associés.
+ **Suppression de fichiers orphelins** : les fichiers orphelins sont des fichiers qui ne sont plus référencés par les métadonnées de la table Iceberg. Ces fichiers peuvent s’accumuler au fil du temps, en particulier après des opérations telles que la suppression de tables ou l’échec de tâches ETL. L'activation de la suppression des fichiers orphelins permet AWS Glue d'identifier et de supprimer périodiquement ces fichiers inutiles, libérant ainsi de l'espace de stockage.
Vous pouvez activer ou désactiver le compactage, la conservation des instantanés et les optimiseurs de suppression de fichiers orphelins pour les tables Iceberg individuelles du catalogue de données à l'aide de la AWS Glue console ou des opérations de l'API AWS CLI. AWS Glue
Pour plus d'informations, consultez la section [Optimisation des tables Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html) dans le guide du AWS Glue développeur.
# Recherche de tables
Vous pouvez utiliser la AWS Lake Formation console pour rechercher des tables du catalogue de données par nom, emplacement, base de données contenant, etc. Les résultats de recherche n'affichent que les tables pour lesquelles vous êtes autorisé à accéder à Lake Formation.
**Pour rechercher des tables (console)**
1. Connectez-vous à la console Lake Formation AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Dans le volet de navigation, choisissez **Tables**.
1. Positionnez le curseur dans le champ de recherche en haut de la page. Le champ contient le texte d'espace réservé *Rechercher le tableau par propriétés*.
Le menu **Propriétés** apparaît et indique les différentes propriétés de table à partir desquelles effectuer une recherche.
![\[Le menu des propriétés est déroulant à partir du champ de recherche et contient les entrées suivantes : nom, classification, base de données, emplacement, numéro de catalogue\]](http://docs.aws.amazon.com/fr_fr/lake-formation/latest/dg/images/search-for-tables.png)
1. Effectuez l’une des actions suivantes :
+ Recherche par base de données contenant.
1. Choisissez **Base de données** dans le menu **Propriétés**, puis choisissez une base de données dans le menu **Bases** de données qui apparaît ou tapez un nom de base de données et appuyez sur **Entrée**.
Les tables sur lesquelles vous avez des autorisations dans la base de données sont répertoriées.
1. (Facultatif) Pour réduire la liste à une seule table de la base de données, positionnez à nouveau le curseur dans le champ de recherche, choisissez **Nom** dans le menu **Propriétés**, puis choisissez un nom de table dans le menu **Tables** qui apparaît ou tapez un nom de table et appuyez sur **Entrée**.
La table unique est répertoriée, et le nom de la base de données et le nom de la table apparaissent sous forme de vignettes sous le champ de recherche.
![\[Sous le champ de recherche se trouvent deux vignettes : l'une intitulée Base de données, qui inclut le nom de la base de données sélectionnée, et l'autre intitulée Table, qui inclut le nom de la table sélectionnée. À droite des vignettes se trouve un bouton Effacer le filtre.\]](http://docs.aws.amazon.com/fr_fr/lake-formation/latest/dg/images/search-for-tables-with-filter.png)
Pour ajuster le filtre, fermez l'une des vignettes ou choisissez **Effacer le filtre**.
+ Effectuez une recherche par autres propriétés.
1. Choisissez une propriété de recherche dans le menu **Propriétés**.
**Pour effectuer une recherche par numéro de AWS compte, choisissez **Numéro de catalogue** dans le menu **Propriétés**, entrez un identifiant de AWS compte valide (par exemple, 111122223333), puis appuyez sur Entrée.**
Pour effectuer une recherche par lieu, choisissez **Emplacement** dans le menu **Propriétés**, puis sélectionnez un lieu **dans le menu Emplacements** qui apparaît. Toutes les tables situées à l'emplacement racine de l'emplacement sélectionné (par exemple, Amazon S3) sont renvoyées.
**Recherche de tables à l'aide de AWS CLI**
+ L'exemple suivant montre comment exécuter une recherche partielle. Le `--search-text` paramètre vous permet de rechercher des tables contenant le texte spécifié dans leurs métadonnées. Dans ce cas, il renvoie toutes les tables dont le nom, la description ou d'autres champs de métadonnées contiennent « client ».
```
aws glue search-tables
--search-text "customer"
--region Région AWS
--max-results 10
--sort-criteria "FieldName=Name,Sort=ASC"
```
# Partage des tables et des bases de données du catalogue de données entre les AWS comptes
Vous pouvez partager les ressources du catalogue de données (bases de données et tables) avec AWS des comptes externes en accordant à Lake Formation des autorisations sur les ressources aux comptes externes. Les utilisateurs peuvent ensuite exécuter des requêtes et des tâches qui joignent et interrogent des tables sur plusieurs comptes. Sous réserve de certaines restrictions, lorsque vous partagez une ressource de catalogue de données avec un autre compte, les principaux associés de ce compte peuvent utiliser cette ressource comme si elle figurait dans leur catalogue de données.
Vous ne partagez pas de ressources avec des responsables spécifiques dans des AWS comptes externes ; vous partagez les ressources avec un compte ou une AWS organisation. Lorsque vous partagez une ressource avec une AWS organisation, vous la partagez avec tous les comptes à tous les niveaux de cette organisation. L'administrateur du lac de données de chaque compte externe doit ensuite accorder des autorisations sur les ressources partagées aux principaux de son compte.
Pour plus d’informations, consultez [Partage de données entre comptes dans Lake Formation](cross-account-permissions.md) et [Octroi d'autorisations sur les ressources du catalogue de données](granting-catalog-permissions.md).
**Voir aussi :**
[Accès aux tables et aux bases de données partagées du catalogue de données et affichage](viewing-shared-resources.md)
[Conditions préalables](cross-account-prereqs.md)
# AWS Glue Data Catalog Vues du bâtiment
Dans le AWS Glue Data Catalog, une *vue* est une table virtuelle dont le contenu est défini par une requête SQL qui fait référence à une ou plusieurs tables. Vous pouvez créer une vue du catalogue de données qui référence jusqu'à 10 tables à l'aide d'éditeurs SQL pour Amazon Athena, Amazon Redshift ou Apache Spark à l'aide d'EMR Serverless ou de la version 5.0. AWS Glue Les tables de référence sous-jacentes d'une vue peuvent appartenir à la même base de données ou à différentes bases Compte AWS de données du même catalogue de données.
Vous pouvez référencer AWS Glue des tables standard et des tables dans des formats de table ouverts (OTF) tels que [Apache Hudi](https://hudi.incubator.apache.org/), Linux Foundation [Delta Lake](https://delta.io/) et [Apache Iceberg](https://iceberg.apache.org/), avec des données sous-jacentes stockées dans des emplacements Amazon S3 enregistrés auprès de. AWS Lake Formation En outre, vous pouvez créer des vues à partir de tables fédérées à partir de partages de données Amazon Redshift partagés avec Lake Formation.
## Différencier les vues du catalogue de données des autres types de vues
Les vues du catalogue de données sont différentes des vues Apache Hive, Apache Spark et Amazon Athena. La vue du catalogue de données est une fonctionnalité native du AWS Glue Data Catalog. Il s'agit d'une vue créée par un définisseur multidialecte. Vous pouvez créer une vue de catalogue de données à l'aide de l'un des services d'analyse pris en charge, tels qu'Athena ou Amazon Redshift Spectrum, et accéder à la même vue à l'aide d'autres services d'analyse pris en charge. D'autre part, les vues Apache Hive, Apache Spark et Athena sont créées indépendamment dans chaque service d'analyse, tel qu'Athena et Amazon Redshift, et sont visibles et accessibles uniquement au sein de ce service.
## Qu'est-ce qu'une vue définissante ?
Une vue de définition est une vue SQL qui fonctionne en fonction des autorisations du principal qui l'a créée. Le rôle de définition dispose des autorisations nécessaires pour accéder aux tables référencées, et il exécute l'instruction SQL qui définit la vue. Le définisseur crée la vue et la partage avec les autres utilisateurs grâce à un AWS Lake Formation contrôle d'accès précis.
Lorsqu'un utilisateur interroge la vue du définisseur, le moteur de requête utilise les autorisations du rôle du définisseur pour accéder aux tables de référence sous-jacentes. Cette approche permet aux utilisateurs d'interagir avec la vue sans avoir besoin d'accéder directement aux tables sources, ce qui améliore la sécurité et simplifie la gestion de l'accès aux données.
Pour configurer une vue de définition, le rôle IAM de définition peut se trouver dans le même AWS compte que les tables de base, ou dans un autre compte en utilisant des rôles de définition entre comptes. Pour plus d'informations sur les autorisations requises pour le rôle de définisseur, consultez[Conditions préalables à la création de vues](views-prereqs.md).
## Un cadre pour des vues multidialectes
Le catalogue de données permet de créer des vues à l'aide de plusieurs dialectes SQL (Structured Query Language). Le SQL est un langage utilisé pour stocker et traiter des informations dans une base de données relationnelle et chaque moteur AWS d'analyse utilise sa propre variante de SQL, ou dialecte SQL.
Vous créez une vue du catalogue de données dans un dialecte SQL à l'aide de l'un des moteurs de requêtes d'analyse pris en charge. Vous pouvez ensuite mettre à jour la vue à l'aide de l'`ALTER VIEW`instruction dans un autre dialecte SQL au sein de tout autre moteur d'analyse pris en charge. Cependant, chaque dialecte doit faire référence au même ensemble de tables, de colonnes et de types de données.
Vous pouvez accéder aux multiples dialectes disponibles pour la vue à l'aide de l'`GetTable`API AWS CLI et de la AWS console. Ainsi, la vue du catalogue de données est visible et disponible pour effectuer des requêtes sur les différents moteurs d'analyse pris en charge.
En définissant un schéma de vue commun et un objet de métadonnées que vous pouvez interroger à partir de plusieurs moteurs, les vues du catalogue de données vous permettent d'utiliser des vues uniformes sur l'ensemble de votre lac de données.
Pour plus de détails sur la façon dont le schéma est résolu pour chaque dialecte, consultez le [lien vers la référence de l'API](). Pour plus de détails sur les règles de correspondance pour les différents types, voir le [lien vers la section correspondante dans le document de l'API]().
## Intégration aux autorisations de Lake Formation
Vous pouvez l'utiliser AWS Lake Formation pour centraliser la gestion des autorisations sur les AWS Glue Data Catalog vues pour les utilisateurs. Vous pouvez accorder des autorisations détaillées sur les vues du catalogue de données à l'aide de la méthode des ressources nommées ou des balises LF, et les partager entre les AWS organisations et les unités organisationnelles. Comptes AWS Vous pouvez également partager et accéder aux vues du catalogue de données Régions AWS via des liens vers des ressources. Cela permet aux utilisateurs d'accéder aux données sans dupliquer la source de données et sans partager les tables sous-jacentes.
L'instruction `CREATE VIEW` DDL d'une vue du catalogue de données peut faire référence aux AWS Glue tables standard et aux tables dans des formats de table ouverts (OTF) tels que Hudi, Delta Lake et Iceberg avec des données sous-jacentes stockées dans des emplacements Amazon S3 enregistrés auprès de Lake Formation, ainsi qu'aux tables fédérées du partage de données Amazon Redshift partagées avec Lake Formation. Les tables peuvent être de n'importe quel format de fichier, à condition que le moteur utilisé pour interroger la vue prenne en charge ce format. Vous pouvez également faire référence aux fonctions intégrées du moteur sur lequel il est exécuté, mais d'autres ressources spécifiques au moteur peuvent ne pas être autorisées. Pour plus d'informations, consultez [Considérations et limites relatives aux affichages du catalogue de données](views-notes.md).
## Cas d’utilisation
Voici les principaux cas d'utilisation des vues du catalogue de données :
+ Créez et gérez les autorisations sur un schéma de vue unique. Cela vous permet d'éviter le risque d'autorisations incohérentes sur les vues dupliquées créées dans plusieurs moteurs.
+ Accordez des autorisations aux utilisateurs sur une vue qui référence plusieurs tables sans accorder d'autorisations directement sur les tables de référence sous-jacentes.
+ Réalisez un filtrage au niveau des lignes sur les tables à l'aide de balises LF (les balises LF ne sont mises en cascade que jusqu'au niveau des colonnes) en appliquant des balises LF aux vues et en accordant aux utilisateurs des autorisations basées sur les balises LF.
## Services AWS d'analyse pris en charge pour les vues
Les services AWS d'analyse suivants permettent de créer des vues de catalogue de données :
+ Amazon Redshift
+ Amazon Athena version 3
+ Apache Spark sur EMR sans serveur
+ Apache Spark sur AWS Glue la version 5.0
## Ressources supplémentaires
Vous pouvez en savoir plus sur le catalogue de données dans ce guide, ainsi qu'en utilisant les ressources suivantes :
La vidéo suivante montre comment créer des vues et les interroger depuis Athena et Amazon Redshift.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL)
**Topics**
+ [Différencier les vues du catalogue de données des autres types de vues](#diff-views)
+ [Qu'est-ce qu'une vue définissante ?](#definer-view)
+ [Un cadre pour des vues multidialectes](#multi-dialect)
+ [Intégration aux autorisations de Lake Formation](#lf-view-integ)
+ [Cas d’utilisation](#views-use-cases)
+ [Services AWS d'analyse pris en charge pour les vues](#views-supported-engines)
+ [Ressources supplémentaires](#views-addtional-resources)
+ [Conditions préalables à la création de vues](views-prereqs.md)
+ [Création de vues de catalogue de données à l'aide d'instructions DDL](create-views.md)
+ [Création de vues de catalogue de données à l'aide de AWS Glue APIs](views-api-usage.md)
+ [Octroi d'autorisations sur les vues du catalogue de données](grant-perms-views.md)
+ [Vues matérialisées](materialized-views.md)
# Conditions préalables à la création de vues
+ Pour créer des vues dans Data Catalog, vous devez enregistrer les emplacements de données Amazon S3 sous-jacents des tables de référence auprès de Lake Formation. Pour plus de détails sur l'enregistrement des données auprès de Lake Formation, voir[Ajouter un emplacement Amazon S3 à votre lac de données](register-data-lake.md).
+ Seuls les rôles IAM peuvent créer des vues de catalogue de données. Les autres identités IAM ne peuvent pas créer de vues de catalogue de données.
+ Le rôle IAM qui définit la vue doit disposer des autorisations suivantes :
+ `SELECT`Autorisation Lake Formation avec `Grantable` option sur toutes les tables de référence, toutes les colonnes incluses.
+ `CREATE_TABLE`Autorisation Lake Formation sur la base de données cible dans laquelle les vues sont créées.
+ Une politique de confiance pour que la Lake Formation et AWS Glue les services assument ce rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerAssumeRole1",
"Effect": "Allow",
"Principal": {
"Service": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
+ Le but : PassRole l'autorisation pour AWS Glue Lake Formation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerPassRole1",
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
}
}
}
]
}
```
------
+ AWS Glue et autorisations de Lake Formation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"Glue:GetDatabase",
"Glue:GetDatabases",
"Glue:CreateTable",
"Glue:GetTable",
"Glue:GetTables",
"Glue:BatchGetPartition",
"Glue:GetPartitions",
"Glue:GetPartition",
"Glue:GetTableVersion",
"Glue:GetTableVersions",
"Glue:PassConnection",
"lakeFormation:GetDataAccess"
],
"Resource": "*"
}
]
}
```
------
+ Vous ne pouvez pas créer de vues dans une base de données `Super` dotée d'une `ALL` autorisation accordée au `IAMAllowedPrincipals` groupe. Vous pouvez soit révoquer l'`Super`autorisation accordée au `IAMAllowedPrincipals` groupe sur une base de données, voir[Étape 4 : Basculez vos magasins de données vers le modèle d'autorisations Lake Formation](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4), soit créer une nouvelle base de données en décochant la case **Utiliser uniquement le contrôle d'accès IAM pour les nouvelles tables de cette base** de données sous **Autorisations par défaut pour les tables nouvellement créées**.
# Création de vues de catalogue de données à l'aide d'instructions DDL
Vous pouvez créer des AWS Glue Data Catalog vues à l'aide des éditeurs SQL pour Athena, Amazon Redshift et à l'aide du/. AWS Glue APIs AWS CLI
Pour créer une vue de catalogue de données à l'aide des éditeurs SQL, choisissez Athena ou Redshift Spectrum, puis créez la vue à l'aide d'une instruction DDL (`CREATE VIEW`Data Definition Language). Après avoir créé une vue dans le dialecte du premier moteur, vous pouvez utiliser une instruction `ALTER VIEW` DDL du second moteur pour ajouter les dialectes supplémentaires.
Lors de la définition des vues, il est important de prendre en compte les points suivants :
+ **Définition de vues multidialectes** : lorsque vous définissez une vue comportant plusieurs dialectes, les schémas des différents dialectes doivent correspondre. Chaque dialecte SQL aura une spécification de syntaxe légèrement différente. La syntaxe de requête définissant la vue du catalogue de données doit aboutir à la même liste de colonnes, y compris les types et les noms, dans tous les dialectes. Ces informations sont stockées dans `StorageDescriptor` la vue. Les dialectes doivent également faire référence aux mêmes objets de table sous-jacents du catalogue de données.
Pour ajouter un autre dialecte à une vue à l'aide du DDL, vous pouvez utiliser l'`ALTER VIEW`instruction. Si une `ALTER VIEW` instruction tente de mettre à jour la définition de la vue, par exemple en modifiant le descripteur de stockage ou les tables sous-jacentes de la vue, l'instruction indique par erreur « Incompatibilité entre le descripteur de stockage en entrée et le descripteur de stockage existant ». Vous pouvez utiliser les opérations SQL Cast pour vous assurer que les types de colonnes de vue correspondent.
+ **Mettre à jour une vue** — Pour mettre à jour la vue, vous pouvez utiliser l'`UpdateTable`API. Si vous mettez à jour la vue sans faire correspondre les descripteurs de stockage ou les tables de référence, vous pouvez fournir l'`FORCE`indicateur (voir la documentation SQL du moteur pour la syntaxe). Après une mise à jour forcée, la vue prendra en compte les tables forcée `StorageDescriptor` et de référence. Tout autre `ALTER VIEW` DDL doit correspondre aux valeurs modifiées. Une vue qui a été mise à jour pour contenir des dialectes incompatibles sera considérée comme « obsolète ». L'état de la vue est visible dans la console Lake Formation et à l'aide de l'`GetTable`opération.
+ **Référencer un type de colonne varchar sous forme de chaîne** — Il n'est pas possible de convertir un type de colonne varchar de Redshift Spectrum en chaîne. Si une vue est créée dans Redshift Spectrum avec un type de colonne varchar et qu'un dialecte ultérieur essaie de référencer ce champ sous forme de chaîne, le catalogue de données le traitera comme une chaîne sans avoir besoin de l'indicateur. `FORCE`
+ **Traitement des champs de type complexe** : Amazon Redshift traite tous les types complexes comme des [SUPER types](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html), tandis qu'Athena spécifie le type complexe. Si une vue possède un champ de `SUPER` type et qu'un autre moteur référence cette colonne comme un type complexe particulier, tel que struct (`>`), le catalogue de données suppose que le champ est du type complexe spécifique et l'utilise dans le descripteur de stockage, sans avoir besoin de l'`Force`indicateur.
Pour plus d'informations sur la syntaxe de création et de gestion des vues du catalogue de données, voir :
+ [Utilisation des AWS Glue Data Catalog vues](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html) dans le guide de l'utilisateur d'Amazon Athena.
+ [Syntaxe des requêtes d'affichage du catalogue Glue Data](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html) dans le guide de l'utilisateur d'Amazon Athena.
+ [Création de vues AWS Glue Data Catalog dans le manuel](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html) du développeur de base de données Amazon Redshift.
Pour plus d’informations sur les commandes SQL associées aux vues du catalogue de données, consultez [CREATE EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html), [ALTER EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html) et [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html).
Une fois que vous avez créé une vue du catalogue de données, les détails de la vue sont disponibles dans la console Lake Formation.
1. Choisissez **Views** sous Data Catalog dans la console Lake Formation.
1. La liste des vues disponibles apparaît sur la page des vues.
1. Choisissez une vue dans la liste et la page de détails affiche les attributs de la vue.
![\[La section inférieure contient cinq onglets disposés horizontalement, chaque onglet contenant les informations correspondantes.\]](http://docs.aws.amazon.com/fr_fr/lake-formation/latest/dg/images/view-definition.png)
Schema
Choisissez une `Column` ligne, puis sélectionnez **Modifier les balises LF pour mettre à jour les valeurs des balises** ou attribuer de nouvelles balises LF.
Définitions SQL
Vous pouvez consulter la liste des définitions SQL disponibles. Sélectionnez **Ajouter une définition SQL**, puis choisissez un moteur de requête pour ajouter une définition SQL. Choisissez un moteur de requête (Athena ou Amazon Redshift) sous `Edit definition` la colonne pour mettre à jour une définition SQL.
Étiquettes LF
Choisissez **Modifier les balises LF** pour modifier les valeurs d'une balise ou attribuer de nouvelles balises. Vous pouvez utiliser les balises LF pour accorder des autorisations sur les vues.
Accès intercomptes
Vous pouvez consulter la Comptes AWS liste des organisations et unités organisationnelles (OUs) qui ont partagé la vue du catalogue de données avec vous.
Tableaux sous-jacents
Les tables sous-jacentes référencées dans la définition SQL utilisée pour créer la vue sont affichées sous cet onglet.
# Création de vues de catalogue de données à l'aide de AWS Glue APIs
Vous pouvez utiliser AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html)et [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs pour créer et mettre à jour des vues dans le catalogue de données. Les `UpdateTable` opérations `CreateTable` et ont une nouvelle `TableInput` structure pour `ViewDefinition``SearchTables`, tandis que les `GetTableVersions` opérations `GetTable``GetTables`,`GetTableVersion`,, fournissent la syntaxe des vues `ViewDefinition` dans leur sortie. En outre, il existe un nouveau `Status` champ dans la sortie de l'`GetTable`API.
Deux nouvelles AWS Glue connexions sont disponibles pour valider le dialecte SQL pour chaque moteur de requête pris en charge, Amazon Athena ainsi que pour Amazon Redshift.
Les `CreateTable` et `UpdateTable` APIs sont asynchrones lorsqu'ils sont utilisés avec des vues. Lorsque ceux-ci APIs sont appelés avec plusieurs dialectes SQL, l'appel est validé par chaque moteur afin de déterminer si le dialecte peut être exécuté sur ce moteur et si le schéma obtenu de la vue de chaque dialecte correspond. Le AWS Glue service utilise ces connexions pour effectuer des appels internes aux moteurs d'analyse. Ces appels simulent ce que fait le moteur pour valider si un DDL `CREATE VIEW` ou `ALTER VIEW` SQL a été exécuté sur le moteur.
Si le code SQL fourni est valide et que les schémas correspondent aux différents dialectes de vue, l' AWS Glue API valide le résultat de manière atomique. Atomicity permet de créer ou de modifier des vues avec plusieurs dialectes sans aucune interruption.
**Topics**
+ [Création de AWS Glue connexions pour valider le statut](views-api-usage-connection.md)
+ [Validation de l'état de génération de vues](views-api-usage-get-table.md)
+ [États et opérations asynchrones](views-api-usage-async-states.md)
+ [Afficher les scénarios d'échec de création lors d'opérations asynchrones](views-api-usage-errors.md)
# Création de AWS Glue connexions pour valider le statut
Pour créer ou mettre à jour une AWS Glue Data Catalog vue à l'aide `UpdateTable` des opérations `CreateTable` or, vous devez créer un nouveau type de AWS Glue connexion à des fins de validation et le fournir au moteur d'analyse pris en charge. Ces connexions sont nécessaires pour utiliser les vues du catalogue de données avec Athena ou Amazon Redshift. Vous pouvez créer ces connexions uniquement à l'aide du AWS CLI AWS SDKs, ou AWS Glue APIs. Vous ne pouvez pas utiliser le AWS Management Console pour créer la AWS Glue connexion.
**Note**
Si le rôle de définition de la vue et le rôle appelant `CreateTable` ou `UpdateTable` sont différents, ils ont tous deux besoin d'une `glue:PassConnection` autorisation dans leur déclaration de politique IAM.
Pour plus d'informations, consultez la documentation relative à la [création d'une connexion](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI .
**AWS CLI commande pour créer une connexion**
Voici une AWS CLI commande permettant de créer une connexion :
```
aws glue create-connection --region us-east-1
--endpoint-url https://glue.us-east-1.amazonaws.com
--cli-input-json file:///root/path/to/create-connection.json
```
**AWS CLI entrée JSON**
Pour Amazon Redshift :
```
{
"CatalogId": "123456789012",
"ConnectionInput": {
"ConnectionType": "VIEW_VALIDATION_REDSHIFT",
"Name": "views-preview-cluster-connection-2",
"Description": "My first Amazon Redshift validation connection",
"ConnectionProperties": {
"DATABASE": "dev",
"CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster"
}
}
}
```
Pour Amazon Athena :
```
{
"CatalogId": "123456789012",
"ConnectionInput": {
"ConnectionType": "VIEW_VALIDATION_ATHENA",
"Name": "views-preview-cluster-connection-3",
"Description": "My first Amazon Athena validation connection",
"ConnectionProperties": {
"WORKGROUP_NAME": "workgroup-name"
}
}
}
```
# Validation de l'état de génération de vues
Lorsque vous exécutez les `UpdateTable` opérations `CreateTable` or, le `Status` champ de sortie de l'`GetTable`API affiche les détails de l'état de création de la vue. Pour les `create` demandes pour lesquelles la table n'existe pas déjà, AWS Glue crée une table vide pendant la durée du processus asynchrone. Lorsque vous appelez`GetTable`, vous pouvez transmettre un indicateur booléen facultatif`IncludeStatusDetails`, qui affiche les informations de diagnostic relatives à la demande. En cas d'échec, cet indicateur affiche un message d'erreur avec les statuts individuels de chaque dialecte.
Des erreurs lors des opérations de création, de lecture, de mise à jour et de suppression de vues (CRUD) peuvent survenir soit pendant le traitement dans le service AWS Glue/Lake Formation, soit lors de la validation SQL de la vue dans Amazon Redshift ou Athena. Lorsqu'une erreur se produit lors de la validation dans un moteur, le AWS Glue service fournit le message d'erreur renvoyé par le moteur.
**Champs de statut**
Les champs de statut sont les suivants :
+ Statut : statut générique, indépendant des différents types d'emplois :
+ QUEUED
+ EN\$1COURS
+ SUCCESS
+ ÉCHEC
+ Action : indique quelle action a été appelée sur la table, actuellement uniquement `CREATE` ou quelles `UPDATE` opérations sont disponibles.
Il est important de faire la distinction entre `CREATE` les opérations `UPDATE` et lorsque vous travaillez avec des vues. Le type d'opération détermine la manière dont vous devez interroger les tables.
Une `UPDATE` opération signifie que la table existe déjà dans le catalogue de données. Dans ce cas, vous pouvez continuer à interroger la table créée précédemment sans aucun problème. D'autre part, une `CREATE ` opération indique que la table n'a jamais été créée avec succès auparavant. Si une table est marquée pour`CREATE`, toute tentative d'interrogation échouera car la table n'existe pas encore dans le système. Il est donc essentiel d'identifier le type d'opération (UPDATE ou CREATE) avant de tenter d'interroger une table.
+ RequestedBy — L'ARN de l'utilisateur qui a demandé la modification asynchrone.
+ UpdatedBy — L'ARN de l'utilisateur qui a modifié manuellement pour la dernière fois le processus de modification asynchrone, par exemple en demandant une annulation ou une modification.
+ Erreur — Ce champ n'apparaît que lorsque l'état est **FAILED**. Il s'agit d'un message d'exception au niveau du parent. Il peut y avoir des erreurs différentes pour chaque dialecte.
+ ErrorCode — Le type d'exception.
+ ErrorMessage — une brève description de l'exception.
+ RequestTime — une chaîne de date au format ISO 8601 indiquant l'heure à laquelle la modification a été initiée.
+ UpdateTime — une chaîne de date au format ISO 8601 indiquant l'heure à laquelle l'état a été mis à jour pour la dernière fois.
# États et opérations asynchrones
Lorsque vous exécutez une `glue:CreateTable` demande, la création asynchrone de la vue du catalogue de données commence. Dans les sections suivantes, ce document décrit une AWS Glue vue disponible dans une `glue:GetTable` réponse. `Status` Par souci de concision, cette section omet la réponse complète.
```
{
"Table": {
...
"Status": {
...
"Action": "CREATE",
"State": "QUEUED",
}
}
}
```
Les deux attributs ci-dessus représentent des informations de diagnostic importantes qui indiquent l'état de l'opération asynchrone, ainsi que les actions qui peuvent être effectuées sur cette vue. Vous trouverez ci-dessous les valeurs possibles que ces attributs peuvent prendre.
1. `Status.Action`
1. CREATE
1. UPDATE
1. `Status.State`
1. QUEUED
1. EN\$1COURS
1. SUCCESS
1. ÉCHEC
Il est également important de noter que certaines mises à jour d'une vue du catalogue de données ne nécessitent pas d'opération asynchrone. Par exemple, on peut souhaiter mettre à jour l'`Description`attribut de la table. Comme cela ne nécessite aucune opération asynchrone, les métadonnées de table résultantes n'en comporteront aucune`Status`, et l'attribut le sera. `NULL`
```
{
"Table": {
...,
"Description": "I changed this attribute!"
}
}
```
Ensuite, cette rubrique explique comment les informations d'état ci-dessus peuvent avoir un impact sur les opérations pouvant être effectuées sur une AWS Glue vue.
**colle : CreateTable**
Il n'y a aucun changement pour cette API par rapport au `glue:CreateTable` fonctionnement de n'importe quelle table Glue. `CreateTable`peut être appelé pour n'importe quel nom de table qui n'existe pas déjà.
**colle : UpdateTable**
Cette opération ne peut pas être effectuée sur une AWS Glue vue dont les informations d'état sont les suivantes :
1. Action = CRÉER et état = EN FILE D'ATTENTE
1. Action == CREATE et État == IN\$1PROGRESS
1. Action == CRÉATION et état == ÉCHEC
1. Action == MISE À JOUR et état == EN ATTENTE
1. Action == MISE À JOUR et état == IN\$1PROGRESS
En résumé, vous ne pouvez mettre à jour une vue du catalogue de données que si elle répond aux exigences suivantes.
1. Il a été créé avec succès pour la première fois.
1. Action == CRÉATION et état == SUCCÈS
1. Il a atteint l'état terminal après une opération de mise à jour asynchrone.
1. Action == MISE À JOUR et état == SUCCÈS
1. Action == MISE À JOUR et état == ÉCHEC
1. Il possède un attribut d'`NULL`état à la suite d'une mise à jour synchrone.
**colle : DeleteTable**
Aucune modification n'est apportée à cette opération par rapport au `glue:DeleteTable` fonctionnement de n'importe quelle AWS Glue table. Vous pouvez supprimer une vue du catalogue de données quel que soit son état.
**colle : GetTable**
Aucune modification n'est apportée à cette opération par rapport au `glue:GetTable` fonctionnement de n'importe quelle AWS Glue table. Toutefois, vous ne pouvez pas interroger une vue du catalogue de données à partir des moteurs d'analyse tant qu'elle n'a pas été créée avec succès pour la première fois. `Action == CREATE and State == SUCCESS`. Après avoir créé une vue du catalogue de données avec succès pour la première fois, vous pouvez interroger la vue quel que soit son statut.
**Note**
Toutes les informations de cette section s'appliquent à tous les tableaux lus`GetTable`, APIs tels que`GetTables`, et`SearchTables`.
# Afficher les scénarios d'échec de création lors d'opérations asynchrones
Les exemples suivants sont représentatifs des types d'erreurs susceptibles de résulter d'appels d'API `CreateTable` ou de leur `UpdateTable` affichage. Ils ne sont pas exhaustifs car la surface d'erreur associée aux échecs de requêtes SQL est assez importante.
## Scénario 1 : échec de la requête Amazon Redshift
La requête fournie pour Amazon Redshift inclut un nom de table mal orthographié introuvable dans le catalogue de données lors de la validation. L'erreur qui en résulte est affichée dans le `Status` champ de la `GetTable` réponse à la vue.
`GetTable`demande :
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-72",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`réponse :
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:39:19-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:39:19-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"State": "SUCCESS"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"UpdateTime": "2024-07-11T11:39:37-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu
Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
}
}
]
}
}
}
}
```
## Scénario 2 : connexion Amazon Redshift non valide
Dans l'exemple suivant, la connexion Amazon Redshift est mal formée car elle fait référence à une base de données Amazon Redshift qui n'existe pas dans le point de terminaison fourni. cluster/serverless Amazon Redshift n'est pas en mesure de valider la vue et le `Status` champ de la `GetTable` réponse indique l'erreur (`"State": "FAILED"`provenant d'Amazon Redshift).
`GetTable`demande :
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-73",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection-malformed"
}
]
}
}
}
```
`GetTable`réponse :
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:27-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:27-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"State": "SUCCESS"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:43:38-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time
stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
}
}
]
}
}
}
}
```
## Scénario 3 : échec de la requête Athena
Le code SQL pour Athena ici n'est pas valide car la requête a mal orthographié le nom de la base de données. La validation de la requête Athena détecte cela et l'erreur qui en résulte est détectée dans l'`Status`objet lors d'un appel. `GetTable`
`GetTable`demande :
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-70",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`réponse :
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:09:53-07:00",
"UpdateTime": "2024-07-11T11:09:53-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:09:54-07:00",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"Action": "CREATE",
"State": "FAILED",
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:09:53-07:00",
"UpdateTime": "2024-07-11T11:09:53-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:09:54-07:00",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10:
41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J
ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
}
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"State": "SUCCESS"
}
]
}
}
}
}
```
## Scénario 4 : les descripteurs de stockage ne correspondent pas
Le code SQL fourni pour le dialecte Athena sélectionne `col1` et `col2` tandis que le SQL pour Redshift sélectionne uniquement. `col1` Cela entraîne une erreur de non-concordance du descripteur de stockage.
`GetTable`demande :
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-71",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`réponse :
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:22:02-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:22:02-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
}
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:22:49-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
}
}
]
}
}
}
}
```
# Octroi d'autorisations sur les vues du catalogue de données
Après avoir créé des vues dans le AWS Glue Data Catalog, vous pouvez accorder des autorisations de lac de données sur Comptes AWS les vues aux responsables des organisations et des unités organisationnelles. Vous pouvez accorder des autorisations à l'aide de balises LF ou de la méthode de ressource nommée. Pour plus d'informations sur le balisage des ressources, consultez[Contrôle d'accès basé sur des balises Lake Formation](tag-based-access-control.md). Pour plus d'informations sur l'octroi direct d'autorisations sur les vues, consultez[Octroi d'autorisations sur les vues à l'aide de la méthode de ressource nommée](granting-view-permissions.md).
# Vues matérialisées
**Topics**
+ [Différenciation des vues matérialisées des autres types de vues](#materialized-views-differentiating)
+ [Cas d’utilisation](#materialized-views-use-cases)
+ [Concepts clés](#materialized-views-key-concepts)
+ [Autorisations pour les vues matérialisées](#materialized-views-permissions)
+ [Création et gestion de vues matérialisées](#materialized-views-creating-managing)
+ [Stockage et accès aux données](#materialized-views-storage-access)
+ [Intégration avec AWS Lake Formation les autorisations](#materialized-views-lake-formation)
+ [Surveillance et débogage](#materialized-views-monitoring-debugging)
+ [Gestion des tâches d'actualisation](#materialized-views-managing-refresh-jobs)
+ [Surveillance et résolution des problèmes](#materialized-views-monitoring-troubleshooting)
+ [Considérations et restrictions](#materialized-views-considerations-limitations)
Dans le catalogue de AWS Glue données, une vue matérialisée est une table gérée qui stocke le résultat précalculé d'une requête SQL au format Apache Iceberg. Contrairement aux vues standard du catalogue de données qui exécutent la requête à chaque accès, les vues matérialisées stockent physiquement les résultats de la requête et les mettent à jour à mesure que les tables sources sous-jacentes changent. Vous pouvez créer des vues matérialisées à l'aide d'Apache Spark version 3.5.6\$1 dans Amazon Athena, Amazon EMR ou. AWS Glue
Les vues matérialisées font référence aux tables Apache Iceberg enregistrées dans le catalogue de AWS Glue données, les données précalculées étant stockées sous forme de tables Apache Iceberg dans des compartiments Amazon S3 Tables ou des compartiments à usage général Amazon S3, ce qui les rend accessibles depuis plusieurs moteurs de requêtes, notamment Amazon Athena, Amazon Redshift et des moteurs tiers compatibles avec Iceberg.
## Différenciation des vues matérialisées des autres types de vues
Les vues matérialisées diffèrent fondamentalement AWS Glue des vues du catalogue de données, des vues Apache Spark et des vues Amazon Athena. Alors que les vues du catalogue de données sont des tables virtuelles qui exécutent la définition de la requête SQL à chaque accès, les vues matérialisées stockent physiquement les résultats des requêtes précalculés. Cela élimine les calculs redondants et améliore considérablement les performances des requêtes pour les transformations complexes fréquemment utilisées.
Les vues matérialisées diffèrent également des pipelines de transformation de données traditionnels créés avec des tâches AWS Glue ETL ou Spark personnalisées. Au lieu d'écrire du code personnalisé pour gérer la détection des modifications, les mises à jour incrémentielles et l'orchestration du flux de travail, vous définissez des vues matérialisées à l'aide de la syntaxe SQL standard. Le catalogue de AWS Glue données surveille automatiquement les tables sources, détecte les modifications et actualise les vues matérialisées à l'aide d'une infrastructure informatique entièrement gérée.
## Cas d’utilisation
Les principaux cas d'utilisation des vues matérialisées sont les suivants :
+ **Accélérez les requêtes analytiques complexes** : créez des vues matérialisées qui précalculent les jointures, les agrégations et les fonctions de fenêtre coûteuses. Les moteurs Spark réécrivent automatiquement les requêtes suivantes pour utiliser les résultats précalculés, réduisant ainsi la latence des requêtes et les coûts de calcul.
+ **Simplifiez les pipelines de transformation des données** : remplacez les tâches ETL complexes qui gèrent la détection des modifications, les mises à jour incrémentielles et l'orchestration du flux de travail par de simples définitions de vues matérialisées basées sur SQL. Le catalogue AWS Glue de données gère automatiquement toute la complexité opérationnelle.
+ **Activez l'analyse en libre-service avec un accès régi aux données** : créez des vues matérialisées sélectionnées qui transforment les données brutes en ensembles de données prêts à être utilisés par l'entreprise. Accordez aux utilisateurs l'accès à des vues matérialisées sans exposer les tables sources sous-jacentes, ce qui simplifie la gestion de la sécurité tout en renforçant les analyses en libre-service.
+ **Optimisez l'ingénierie des fonctionnalités pour l'apprentissage automatique** : définissez des vues matérialisées qui implémentent des transformations de fonctionnalités pour les modèles ML. La fonctionnalité d'actualisation automatique garantit que les magasins de fonctionnalités restent à jour au fur et à mesure de l'évolution des données sources, tandis que l'actualisation incrémentielle minimise les coûts de calcul.
+ **Mettez en œuvre un partage de données efficace** : créez des vues matérialisées qui filtrent et transforment les données pour des consommateurs spécifiques. Partagez des vues matérialisées entre les comptes et les régions en AWS Lake Formationéliminant le besoin de duplication des données tout en maintenant une gouvernance centralisée.
## Concepts clés
### Actualisation automatique
L'actualisation automatique est une fonctionnalité qui surveille en permanence vos tables sources et met à jour les vues matérialisées selon un calendrier que vous définissez. Lorsque vous créez une vue matérialisée, vous pouvez spécifier une fréquence d'actualisation à l'aide d'une planification basée sur le temps avec des intervalles allant jusqu'à une heure. Le catalogue de AWS Glue données utilise l'infrastructure informatique gérée de Spark pour exécuter les opérations d'actualisation en arrière-plan, en gérant de manière transparente tous les aspects de la détection des modifications et des mises à jour incrémentielles.
Lorsque les données source changent entre les intervalles d'actualisation, la vue matérialisée devient temporairement obsolète. Les requêtes accédant directement à la vue matérialisée peuvent renvoyer des résultats obsolètes jusqu'à la fin de la prochaine actualisation planifiée. Pour les scénarios nécessitant un accès immédiat aux données les plus récentes, vous pouvez exécuter une actualisation manuelle à l'aide de la commande `REFRESH MATERIALIZED VIEW` SQL.
### Actualisation incrémentielle
L'actualisation incrémentielle est une technique d'optimisation qui traite uniquement les données modifiées dans les tables sources depuis la dernière actualisation, plutôt que de recalculer l'intégralité de la vue matérialisée. Le catalogue de AWS Glue données utilise la couche de métadonnées d'Apache Iceberg pour suivre efficacement les modifications apportées aux tables sources et déterminer quelles parties de la vue matérialisée nécessitent des mises à jour.
Cette approche réduit considérablement les coûts de calcul et la durée d'actualisation par rapport aux opérations d'actualisation complètes, en particulier pour les grands ensembles de données où seul un faible pourcentage des données change entre les cycles d'actualisation. Le mécanisme d'actualisation incrémentielle fonctionne automatiquement ; il n'est pas nécessaire d'écrire une logique personnalisée pour détecter ou traiter les données modifiées.
### Réécriture automatique des requêtes
La réécriture automatique des requêtes est une fonctionnalité d'optimisation des requêtes disponible dans les moteurs Spark d'Amazon Athena, Amazon EMR et. AWS Glue Lorsque vous exécutez une requête sur des tables de base, l'optimiseur Spark analyse votre plan de requête et détermine automatiquement si les vues matérialisées disponibles peuvent répondre plus efficacement à la requête. S'il existe une vue matérialisée appropriée, l'optimiseur réécrit la requête de manière transparente afin d'utiliser les résultats précalculés au lieu de traiter les tables de base.
Cette optimisation s'effectue sans qu'il soit nécessaire de modifier le code de votre application ou les instructions de requête. L'optimiseur Spark garantit que la réécriture automatique des requêtes ne s'applique que lorsque la vue matérialisée est actuelle et peut produire des résultats précis. Si une vue matérialisée est obsolète ou ne répond pas entièrement aux exigences de la requête, l'optimiseur exécute le plan de requête d'origine par rapport aux tables de base, en privilégiant l'exactitude par rapport aux performances.
### Afficher le rôle du définisseur
Une vue matérialisée fonctionne en fonction des autorisations du rôle IAM qui l'a créée, connu sous le nom de rôle de définition de vue. Le rôle de définisseur doit avoir un accès en lecture à toutes les tables de base référencées dans la définition de la vue matérialisée et créer des autorisations de table sur la base de données cible. Lorsque le catalogue de AWS Glue données actualise une vue matérialisée, il assume le rôle de définisseur pour accéder aux tables sources et écrire les résultats mis à jour.
Ce modèle de sécurité vous permet d'accorder aux utilisateurs l'accès aux vues matérialisées sans leur accorder d'autorisations directes sur les tables sources sous-jacentes. Si le rôle de définition de vues perd l'accès à une table de base, les opérations d'actualisation suivantes échoueront jusqu'à ce que les autorisations soient restaurées.
## Autorisations pour les vues matérialisées
Pour créer et gérer des vues matérialisées, vous devez configurer AWS Lake Formation les autorisations. Le rôle IAM qui crée la vue matérialisée (le rôle de définition) nécessite des autorisations spécifiques sur les tables sources et les bases de données cibles.
### Autorisations requises pour le rôle de définisseur
Le rôle de définition doit disposer des autorisations Lake Formation suivantes :
+ Sur les tables sources : autorisations SELECT ou ALL sans filtres de ligne, de colonne ou de cellule
+ Sur la base de données cible : autorisation CREATE\$1TABLE
+ Sur le catalogue AWS Glue de données GetTable et les autorisations CreateTable d'API
Lorsque vous créez une vue matérialisée, l'ARN du rôle de définition est stocké dans la définition de la vue. Le catalogue AWS Glue de données assume ce rôle lors de l'exécution des opérations d'actualisation automatique. Si le rôle de définition perd l'accès aux tables sources, les opérations d'actualisation échoueront tant que les autorisations ne seront pas restaurées.
### Autorisations IAM pour les tâches AWS Glue
Le rôle IAM de votre AWS Glue travail nécessite les autorisations suivantes :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetCatalog",
"glue:GetCatalogs",
"glue:GetTable",
"glue:GetTables",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetDatabase",
"glue:GetDatabases",
"cloudwatch:PutMetricData"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:*:/aws-glue/*"
]
},
{
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess"
],
"Resource": "*"
}
]
}
```
Le rôle que vous utilisez pour l'actualisation automatique de Materialized View doit disposer de l'PassRole autorisation iam : sur le rôle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/materialized-view-role-name"
]
}
]
}
```
Pour que Glue actualise automatiquement la vue matérialisée pour vous, le rôle doit également respecter la politique de confiance suivante qui permet au service d'assumer le rôle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "glue.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Si la vue matérialisée est stockée dans des compartiments de tables S3, vous devez également ajouter l'autorisation suivante au rôle.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3tables:PutTableMaintenanceConfiguration"
],
"Resource": "arn:aws:s3tables:*:123456789012:*"
}
]
}
```
### Octroi de l'accès aux vues matérialisées
Pour autoriser d'autres utilisateurs à interroger une vue matérialisée, accordez l' AWS Lake Formation autorisation SELECT sur la table des vues matérialisées. Les utilisateurs peuvent interroger la vue matérialisée sans avoir besoin d'accéder directement aux tables sources sous-jacentes.
Pour des informations détaillées sur la configuration des autorisations de Lake Formation, consultez la section Octroi et révocation d'autorisations sur les ressources du catalogue de données dans le manuel du AWS Lake Formation développeur.
## Création et gestion de vues matérialisées
Vous créez des vues matérialisées à l'aide de l'`CREATE MATERIALIZED VIEW`instruction SQL dans les moteurs Spark. La définition de la vue spécifie la requête SQL qui définit la logique de transformation, la base de données cible et le nom de la table, ainsi que la configuration d'actualisation facultative. Vous pouvez définir des transformations complexes, notamment des agrégations, des jointures entre plusieurs tables, des filtres et des fonctions de fenêtre.
```
CREATE MATERIALIZED VIEW sales_summary
AS
SELECT
region,
product_category,
SUM(sales_amount) as total_sales,
COUNT(DISTINCT customer_id) as unique_customers
FROM sales_transactions
WHERE transaction_date >= current_date - interval '90' day
GROUP BY region, product_category;
```
Pour configurer l'actualisation automatique, incluez le calendrier d'actualisation dans la définition de votre vue :
```
CREATE MATERIALIZED VIEW sales_summary
SCHEDULE REFRESH EVERY 1 HOUR
AS
SELECT region, product_category, SUM(sales_amount) as total_sales
FROM sales_transactions
GROUP BY region, product_category;
```
Vous pouvez actualiser manuellement une vue matérialisée à tout moment à l'aide de la `REFRESH MATERIALIZED VIEW` commande :
```
REFRESH MATERIALIZED VIEW sales_summary;
```
Pour modifier le calendrier d'actualisation d'une vue matérialisée existante, utilisez l'`ALTER MATERIALIZED VIEW`instruction suivante :
```
ALTER MATERIALIZED VIEW sales_summary
ADD SCHEDULE REFRESH EVERY 2 HOURS;
```
### Vues matérialisées imbriquées
Vous pouvez créer des vues matérialisées qui font référence à d'autres vues matérialisées sous forme de tables de base, ce qui permet des transformations de données en plusieurs étapes. Lorsque vous créez des vues matérialisées imbriquées, le catalogue de AWS Glue données suit les dépendances et propage automatiquement les mises à jour dans la hiérarchie des vues matérialisées. Lorsqu'une vue matérialisée de base est actualisée, toutes les vues matérialisées en aval qui en dépendent sont mises à jour en conséquence.
Cette fonctionnalité vous permet de décomposer les transformations complexes en étapes logiques, d'améliorer la maintenabilité et de permettre l'actualisation sélective des couches de transformation en fonction de vos exigences en matière de fraîcheur des données.
## Stockage et accès aux données
Les vues matérialisées stockent les résultats précalculés sous forme de tables Apache Iceberg dans des compartiments S3 Tables ou de compartiments S3 à usage général au sein de votre compte. AWS Le catalogue de AWS Glue données gère tous les aspects de la maintenance des tables Iceberg, y compris le compactage et la conservation des instantanés, grâce aux fonctionnalités d'optimisation automatisées de S3 Tables.
Les vues matérialisées étant stockées sous forme de tables Iceberg, vous pouvez les lire directement à partir de n'importe quel moteur compatible avec Iceberg, notamment Amazon Athena, Amazon Redshift et des plateformes d'analyse tierces. Cette accessibilité multimoteur garantit que vos données précalculées restent accessibles dans l'ensemble de votre écosystème d'analyse sans duplication des données ni conversion de format.
## Intégration avec AWS Lake Formation les autorisations
Vous pouvez l'utiliser AWS Lake Formation pour gérer des autorisations précises sur les vues matérialisées. Le créateur de la vue devient automatiquement propriétaire de la vue matérialisée et peut accorder des autorisations à d'autres utilisateurs ou rôles à l'aide AWS Lake Formation de sa méthode de ressource nommée ou de balises LF.
Lorsque vous accordez à un utilisateur l'`SELECT`autorisation d'accéder à une vue matérialisée, il peut interroger les résultats précalculés sans avoir besoin d'accéder aux tables sources sous-jacentes. Ce modèle de sécurité simplifie la gestion de l'accès aux données et vous permet de mettre en œuvre le principe du moindre privilège, en permettant aux utilisateurs d'accéder uniquement aux transformations de données spécifiques dont ils ont besoin.
Vous pouvez partager des vues matérialisées entre AWS comptes, AWS organisations et unités organisationnelles à l'aide des fonctionnalités AWS Lake Formation de partage entre comptes. Vous pouvez également accéder à des vues matérialisées dans toutes AWS les régions à l'aide de liens vers des ressources, ce qui permet une gouvernance centralisée des données avec un accès distribué aux données.
## Surveillance et débogage
Le catalogue de AWS Glue données publie toutes les opérations d'actualisation des vues matérialisées et les métriques associées sur Amazon CloudWatch. Vous pouvez surveiller l'heure de début, l'heure de fin, la durée, le volume de données traité et l'état de l'actualisation grâce à CloudWatch des métriques. Lorsque les opérations d'actualisation échouent, les messages d'erreur et les informations de diagnostic sont enregistrés dans CloudWatch les journaux.
Vous pouvez configurer des CloudWatch alarmes pour recevoir des notifications lorsque les tâches d'actualisation dépassent la durée prévue ou échouent à plusieurs reprises. Le catalogue de AWS Glue données publie également les événements de modification relatifs aux exécutions d'actualisation réussies ou non, ce qui vous permet d'intégrer les opérations de visualisation matérialisée dans une automatisation plus large des flux de travail.
Pour vérifier l'état actuel d'une vue matérialisée, utilisez la commande `DESCRIBE MATERIALIZED VIEW` SQL, qui renvoie des métadonnées telles que l'état d'obsolescence, l'horodatage de la dernière actualisation et la configuration du calendrier d'actualisation.
## Gestion des tâches d'actualisation
### Lancer une actualisation manuelle
Déclenchez une actualisation immédiate en dehors de l'intervalle planifié.
Autorisation requise : les AWS informations d'identification utilisées pour effectuer l'appel d'API doivent être `glue:GetTable` autorisées à accéder à la vue matérialisée.
Pour le catalogue de tables S3 :
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id :s3tablescatalog/ \
--database-name \
--table-name
```
Pour Root Catalog :
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
### Vérification de l'état d'actualisation
Obtenez le statut d'une tâche d'actualisation spécifique :
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id
```
### Historique d'actualisation des annonces
Affichez toutes les tâches d'actualisation pour obtenir une vue matérialisée :
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name
```
**Note**
`:s3tablescatalog/`À utiliser pour les tables S3 ou `` pour le catalogue racine.
### Arrêt d'une actualisation en cours
Annuler une tâche d'actualisation en cours :
```
aws glue stop-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
## Surveillance et résolution des problèmes
Il existe trois méthodes pour surveiller les tâches d'actualisation des vues matérialisées :
### CloudWatch Métriques
Consultez les statistiques agrégées pour toutes vos tâches d'actualisation de vues matérialisées dans CloudWatch :
Métriques disponibles :
+ AWS/Glue l'espace de noms avec les dimensions suivantes :
+ CatalogId: identifiant de votre catalogue
+ DatabaseName: base de données contenant la vue matérialisée
+ TableName: nom de la vue matérialisée
+ TaskType: défini sur « MaterializedViewRefresh »
Affichage dans la console :
1. Accédez à la CloudWatch console → Métriques
1. Sélectionnez l'espace de AWS noms /Glue
1. Filtrer par dimensions : CatalogId, DatabaseName, TableName, TaskType
1. Afficher les indicateurs de réussite, d'échec et de durée des tâches
Exemple de requête de CloudWatch métriques :
```
{AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh
```
En utilisant AWS CLI :
```
aws cloudwatch get-metric-statistics \
--namespace AWS/Glue \
--metric-name \
--dimensions Name=CatalogId,Value= \
Name=DatabaseName,Value= \
Name=TableName,Value= \
Name=TaskType,Value=MaterializedViewRefresh \
--start-time \
--end-time \
--period 3600 \
--statistics Sum \
--region
```
### CloudWatch Journaux
Consultez les journaux d'exécution détaillés pour chaque exécution de tâches d'actualisation :
Groupe de journaux : `/aws-glue/materialized-views/`
Où se `` trouve un UUID (par exemple, abc12345-def6-7890-ghij-klmnopqrstuv).
Affichage des journaux :
```
# List log streams for a task run
aws logs describe-log-streams \
--log-group-name /aws-glue/materialized-views/ \
--region
# Get log events
aws logs get-log-events \
--log-group-name /aws-glue/materialized-views/ \
--log-stream-name \
--region
```
Dans CloudWatch la console :
1. Accédez à CloudWatch → Groupes de journaux
1. Recherchez /aws-glue/materialized-views/
1. Sélectionnez le groupe de journaux avec votre ID d'exécution de tâche
1. Afficher les journaux d'exécution détaillés, les erreurs et les résultats des tâches Spark
### Notifications
Abonnez-vous aux événements pour recevoir des notifications en temps réel concernant les modifications de l'état des tâches d'actualisation :
Types d'événements disponibles :
+ La tâche d'actualisation de Glue Materialized View a démarré
+ La tâche d'actualisation de Glue Materialized View a réussi
+ Echec de la tâche d'actualisation de Glue Materialized View
+ Échec de l'invocation de l'actualisation automatique de Glue Materialized View
Création d'une règle :
```
aws events put-rule \
--name materialized-view-refresh-notifications \
--event-pattern '{
"source": ["aws.glue"],
"detail-type": [
"Glue Materialized View Refresh Task Started",
"Glue Materialized View Refresh Task Succeeded",
"Glue Materialized View Refresh Task Failed",
"Glue Materialized View Auto-Refresh Invocation Failure"
]
}' \
--region
```
Ajouter une cible (par exemple, une rubrique SNS) :
```
aws events put-targets \
--rule materialized-view-refresh-notifications \
--targets "Id"="1","Arn"="arn:aws:sns:::" \
--region
```
### Affichage de l'état d'actualisation
Vérifiez l'état de vos tâches d'actualisation de vues matérialisées à l'aide de l' AWS Glue API :
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id \
--region
```
Ou listez toutes les opérations d'actualisation récentes :
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name \
--region
```
Cela montre :
+ Heure de la dernière actualisation
+ État d'actualisation (RÉUSSI, ÉCHEC, EXÉCUTION, ARRÊT)
+ ID d'exécution de la tâche
+ Messages d'erreur (en cas d'échec)
États d'actualisation courants :
+ EN COURS D'EXÉCUTION : le travail d'actualisation est en cours d'exécution
+ RÉUSSI : L'actualisation s'est terminée avec succès
+ ÉCHEC : une erreur s'est produite lors de l'actualisation
+ ARRÊTÉ : L'actualisation a été annulée manuellement
Résolution des problèmes d'échec des actualisations :
Si l'actualisation échoue, vérifiez :
1. Autorisations IAM : assurez-vous que le rôle de définisseur a accès à toutes les tables de base et à l'emplacement de la vue matérialisée
1. Disponibilité des tables de base : Vérifiez que toutes les tables référencées existent et sont accessibles
1. Validité de la requête : vérifiez que la requête SQL est valide pour le dialecte Spark SQL
1. Limites de ressources : vérifiez si vous avez atteint les limites d'actualisation simultanées de votre compte
Utilisez l' GetMaterializedViewRefreshTaskRun API pour récupérer des messages d'erreur détaillés.
## Considérations et restrictions
+ Les vues matérialisées peuvent uniquement faire référence aux tables Apache Iceberg enregistrées dans le catalogue de AWS Glue données en tant que tables de base.
+ La création de vues et la réécriture automatique des requêtes ne sont disponibles qu'à partir des moteurs Spark dans les versions 3.5.6 et supérieures d'Apache Spark sur Amazon Athena AWS Glue , Amazon EMR et (version 5.1).
+ Les vues matérialisées sont finalement cohérentes avec les tables de base. Au cours de la fenêtre d'actualisation, les requêtes accédant directement à la vue matérialisée peuvent renvoyer des données obsolètes. Pour accéder immédiatement aux données actuelles, effectuez une actualisation manuelle.
+ L'intervalle d'actualisation automatique minimum est d'une heure. Pour les cas d'utilisation nécessitant des mises à jour plus fréquentes, exécutez des actualisations manuelles par programmation à l'aide de la commande. `REFRESH MATERIALIZED VIEW`
+ La réécriture des requêtes privilégie l'exactitude par rapport aux performances. Si une vue matérialisée est obsolète ou ne peut pas répondre avec précision aux exigences de la requête, les moteurs Spark exécutent la requête d'origine sur les tables de base.