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.
Considérations et restrictions
Cette section inclut les éléments à prendre en compte lors de l’utilisation d’optimiseurs de tables dans AWS Glue Data Catalog.
Durabilité et exactitude
Emplacements des tables S3 :
Lorsque plusieurs AWS Glue Data Catalog tables partagent le même emplacement Amazon S3 et que les optimiseurs sont activés, l'optimiseur de conservation des instantanés ou de suppression de fichiers orphelins pour une table peut supprimer les fichiers qui sont toujours référencés par l'autre table. Assurez-vous que chaque table sur laquelle les optimiseurs sont activés possède un emplacement Amazon S3 unique qui n'est partagé avec aucune autre table, y compris les tables de différentes bases de données.
Expiration du cycle de vie S3 :
Les règles d'expiration du cycle de vie d'Amazon S3 qui s'appliquent aux emplacements de stockage des tables Iceberg peuvent supprimer le manifeste et les fichiers de données qui sont toujours référencés par des instantanés actifs. Si votre bucket comporte des règles d'expiration du cycle de vie, assurez-vous qu'elles excluent le chemin de stockage des tables Iceberg.
Commissions différées :
Des validations différées peuvent se produire dans les pipelines de streaming à haut débit. Configurez orphanFileRetentionPeriodInDays pour dépasser le délai maximum attendu entre la création du fichier et la réussite de la validation, y compris les délais de traitement et les nouvelles tentatives de validation.
L'optimiseur de suppression de fichiers orphelins utilise les métadonnées de la table Iceberg disponibles lors de son exécution. Si un fichier atteint la limite d'âge configurée avant que le commit ne l'ajoute aux métadonnées de la table Iceberg, l'optimiseur peut identifier le fichier en tant que fichier orphelin et le supprimer.
Une validation ultérieure peut ensuite ajouter le fichier supprimé aux métadonnées de la table Iceberg. Cela peut entraîner l'échec des requêtes et des exécutions de l'optimiseur de table.
Problèmes connus
La documentation des optimiseurs de Catalog-level tables indique que « les tables dépourvues de leur propre configuration d'optimiseur hériteront de l'état désactivé au niveau du catalogue ». Il existe un problème connu selon lequel certaines tables ne disposant pas de leur propre configuration d'optimiseur peuvent ne pas hériter correctement de l'état désactivé de la configuration au niveau du catalogue. Utilisez les journaux d'exécution de la AWS Glue console et de l'optimiseur pour vérifier quels optimiseurs sont actuellement activés et exécutés dans votre compte, et désactivez ceux dont vous n'avez pas besoin.
Formats pris en charge et restrictions pour le compactage de données géré
Le compactage des données prend en charge divers types de fichiers et formats de compression pour la lecture et l’écriture de données, y compris la lecture de données provenant de tables chiffrées.
Contrôle de la simultanéité :
Apache Iceberg prend en charge un contrôle de simultanéité optimiste, permettant à plusieurs rédacteurs d'effectuer des opérations simultanément. Les conflits sont détectés et résolus au moment de la validation. Lorsque vous travaillez avec des pipelines de streaming, configurez les paramètres de nouvelle tentative appropriés via les propriétés des tables et les paramètres de compactage afin de gérer efficacement les écritures simultanées. Pour obtenir des conseils détaillés, consultez le blog AWS Big Data sur la gestion des écritures simultanées dans les tables Iceberg
Nouvelles tentatives de compactage :
Lorsque les opérations de compactage échouent quatre fois de suite, l'optimisation de la table de AWS Glue catalogue suspend automatiquement l'optimiseur pour éviter une consommation inutile de ressources informatiques. Examinez d'abord les journaux et essayez de comprendre pourquoi le compactage échoue à plusieurs reprises. Pour reprendre l'optimisation du compactage, vous pouvez réactiver l'optimiseur via la AWS Glue console ou l'API.
Le compactage des données prend en charge :
Chiffrement : le compactage des données prend uniquement en charge le chiffrement Amazon S3 par défaut (SSE-S3) et le chiffrement KMS côté serveur (). SSE-KMS
Stratégies de compactage — Binpack, tri et Z-order prises en charge par Apache Iceberg v3. Trie et ne Z-order peut être appliqué qu'aux colonnes contenant des types primitifs Iceberg.
-
Vous pouvez exécuter le compactage depuis le compte où réside le catalogue de données lorsque le compartiment Amazon S3 qui stocke les données sous-jacentes se trouve dans un autre compte. Pour ce faire, le rôle de compactage nécessite l’accès au compartiment Amazon S3.
Le compactage des données ne prend pas en charge actuellement :
-
Compactage sur des tables entre comptes : vous ne pouvez pas exécuter le compactage sur des tables entre comptes.
-
Compactage sur des tables entre régions : vous ne pouvez pas exécuter le compactage sur des tables entre régions.
Activation du compactage sur des liens de ressources
-
Tables de la classe de stockage Amazon S3 Express One Zone : vous ne pouvez pas exécuter le compactage sur les tables Amazon S3 Express One Zone Iceberg.
Z-order la stratégie de compactage ne prend pas en charge les types de données suivants :
Décimal
TimestampWithoutZone
Considérations relatives à la conservation des instantanés et aux optimiseurs de suppression de fichiers orphelins
Les considérations suivantes s’appliquent à la conservation des instantanés et aux optimiseurs de suppression des fichiers orphelins.
Les processus de conservation des instantanés et de suppression de fichiers orphelins ont une limite maximale de suppression de 1 000 000 fichiers par exécution. Lorsque vous supprimez des instantanés expirés, si le nombre de fichiers éligibles à la suppression dépasse 1 000 000, tous les fichiers restants au-delà de ce seuil continueront d’exister dans le stockage de la table en tant que fichiers orphelins.
-
Les instantanés sont conservés par l’optimiseur de conservation d’instantanés seulement lorsque les deux critères suivants sont remplis : le nombre minimum d’instantanés à conserver et la période de conservation spécifiée.
-
L’optimiseur de conservation d’instantanés supprime les métadonnées des instantanés expirés d’Apache Iceberg, empêchant ainsi les requêtes d’historique d’instantanés expirés et supprimant éventuellement les fichiers de données associés.
-
L’optimiseur de suppression des fichiers orphelins supprime les fichiers de données et de métadonnées qui ne sont plus référencés par les métadonnées Iceberg si leur date de création est antérieure à la période de conservation des fichiers orphelins à compter de l’exécution de l’optimiseur.
-
Apache Iceberg facilite le contrôle des versions grâce à des branches et des balises, qui sont des pointeurs nommés vers des états d’instantanés spécifiques. Chaque branche et balise suit son propre cycle de vie indépendant, régi par des politiques de conservation définies à leurs niveaux respectifs. Les AWS Glue Data Catalog optimiseurs tiennent compte de ces politiques de cycle de vie, garantissant ainsi le respect des règles de conservation spécifiées. Les politiques de conservation au niveau des branches et des balises ont priorité sur les configurations de l’optimiseur.
Pour plus d’informations, consultez Branching and Tagging
dans la documentation Apache Iceberg. -
Les optimiseurs de conservation des instantanés et de suppression de fichiers orphelins supprimeront les fichiers éligibles au nettoyage conformément aux paramètres configurés. Améliorez votre contrôle sur la suppression de fichiers en mettant en œuvre des politiques de gestion des versions et de cycle de vie S3 sur les compartiments appropriés.
Pour obtenir des instructions détaillées sur la configuration de la gestion des versions et la création de règles de cycle de vie, consultez https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html.
-
Pour déterminer correctement les fichiers orphelins, assurez-vous que l’emplacement de la table fourni et les éventuels sous-chemins ne se chevauchent pas ou ne contiennent pas de données provenant d’autres tables ou sources de données. Si les chemins se chevauchent, vous risquez une perte de données irrécupérable en cas de suppression involontaire de fichiers.
Important
orphanFileRetentionPeriodInDayss'applique uniquement à l'optimiseur de suppression de fichiers orphelins. L'optimiseur de rétention des instantanés n'utilise pas cette valeur et n'évalue pas l'âge des fichiers dans Amazon S3.
Dans cleanExpiredFiles ce castrue, les fichiers qui ne sont plus référencés par aucun instantané conservé sont supprimés dans le cadre de l'expiration des instantanés. Configurez snapshotRetentionPeriodInDays et numberOfSnapshotsToRetain en fonction de vos besoins en matière de voyage dans le temps et de restauration.
Exception de débogage OversizedAllocationException
Pour résoudre une exception OversizedAllocationException :
Réduisez la taille du lot du lecteur vectorisé et vérifiez. La taille du lot par défaut est de 5 000. Ceci est contrôlé dans
read.parquet.vectorization.batch-size.Si cela ne fonctionne pas même après plusieurs variations, désactivez la vectorisation. Ceci est contrôlé dans
read.parquet.vectorization.enabled.
