Mises à jour dans les tables avec des partitions

Dans Athena, une table et ses partitions doivent utiliser les mêmes formats de données, mais leurs schémas peuvent différer. Lorsque vous créez une nouvelle partition, cette partition hérite généralement du schéma de la table. Au fil du temps, les schémas peuvent commencer à différer. Les raisons sont les suivantes :

• Si le schéma votre table change, les schémas des partitions ne sont pas mis à jour afin de rester synchronisés avec le schéma de la table.

• Le AWS Glue Crawler vous permet de découvrir des données dans des partitions dotées de différents schémas. Cela signifie que si vous créez une table dans Athena avec AWS Glue, une fois le traitement terminé par le robot, les schémas de la table et de ses partitions peuvent être différents.

• Si vous ajoutez des partitions directement à l'aide d'une AWS API.

Athena traite les tables avec des partitions correctement si elles répondent aux contraintes suivantes. Si ces contraintes ne sont pas satisfaites, Athena émet une erreur HIVE_PARTITION_SCHEMA_MISMATCH.

• Le schéma de chaque partition est compatible avec le schéma de la table.

• Le format des données de la table autorise le type de mise à jour que vous souhaitez réaliser : ajouter, supprimer, réorganiser les colonnes, ou modifier le type de données d'une colonne.

  Par exemple, pour les formats CSV et TSV, vous pouvez uniquement renommer les colonnes, ajouter de nouvelles colonnes à la fin de la table, et modifier le type de données d'une colonne si les types sont compatibles, mais vous ne pouvez pas supprimer des colonnes. Pour les autres formats, vous pouvez ajouter ou supprimer des colonnes, ou remplacer le type de données d'une colonne par un autre si les types sont compatibles. Pour plus d'informations, consultez la rubrique Récapitulatif : mises à jour et formats de données dans Athena.

Éviter les erreurs de non-correspondance de schéma pour les tables avec des partitions

Au début de l'exécution des requêtes, Athena vérifie le schéma de la table en s'assurant que le type de données de chaque colonne est compatible entre la table et la partition.

• Pour les types de stockage de données Parquet et ORC, Athena se base sur les noms de colonne et les utilise pour la vérification du schéma basée sur les noms de colonne. Cela élimine les erreurs HIVE_PARTITION_SCHEMA_MISMATCH pour les tables avec des partitions de type Parquet ou ORC. (Cela est vrai pour ORC si la SerDe propriété est définie pour accéder à l'index par son nom :orc.column.index.access=FALSE. Parquet lit l'index par nom (par défaut).

• Pour CSV, JSON et Avro, Athena utilise une vérification du schéma basée sur un index. Cela signifie que si vous rencontrez une erreur de non-correspondance de schéma, vous devez supprimer la partition qui provoque une non-correspondance de schéma et la recréer, de telle sorte qu'Athena puisse l'interroger sans risque d'échec.

Athena compare le schéma de la table aux schémas de la partition. Si vous créez une table au format CSV, JSON et AVRO dans Athena AWS Glue avec Crawler, une fois le traitement terminé, les schémas de la table et de ses partitions peuvent être différents. En cas de non-correspondance entre le schéma de la table et les schémas de partition, les requêtes échouent dans Athena en raison d'une erreur de vérification de schéma semblable à celle-ci : 'crawler_test.click_avro' is declared as type 'string', but partition 'partition_0=2017-01-17' declared column 'col68' as type 'double' (crawler_test.click_avro' est déclaré comme type 'chaîne', mais la partition 'partition_0=2017-01-17' a déclaré la colonne 'col68' comme type 'double').

Une solution de contournement pour ce type d'erreurs consiste à supprimer la partition qui provoque l'erreur et à la recréer. Pour plus d'informations, consultez ALTER TABLE DROP PARTITION et ALTER TABLE ADD PARTITION.