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.

Utiliser le partitionnement dynamique des identifiants

Lorsque vos données sont partitionnées par une propriété avec une cardinalité élevée ou lorsque les valeurs ne peuvent pas être connues à l’avance, vous pouvez utiliser le type de projection injected. Les noms d'utilisateur et les noms d'appareils ou de produits sont IDs des exemples de telles propriétés. Lorsque vous utilisez le type de projection injected pour configurer une clé de partition, Athena utilise les valeurs de la requête elle-même pour calculer l’ensemble des partitions qui seront lues.

Pour qu’Athena puisse exécuter une requête sur une table dont la clé de partition est configurée avec le type de projection injected, les critères suivants doivent être remplis :

Si l’un de ces critères n’est pas rempli, votre requête échoue avec l’erreur suivante :

CONSTRAINT_ VIOLATION : Pour la colonne de partition projetée injectée column_name, la WHERE clause ne doit contenir que des conditions d'égalité statiques, et au moins une de ces conditions doit être présente.

Quand utiliser le type injected de projection

Imaginez que vous disposiez d'un ensemble de données composé d'événements provenant d'appareils IoT, répartis sur les appareilsIDs. Ce jeu de données possède les caractéristiques suivantes :

Ce jeu de données est difficile à gérer en utilisant des métastores classiques. Il est difficile de synchroniser les partitions entre le stockage de données et le métastore, et le filtrage des partitions peut être lent lors de la planification des requêtes. Mais si vous configurez une table pour utiliser la projection de partition et que vous utilisez le type de projection injected, vous avez deux avantages : vous n’avez pas à gérer les partitions dans le métastore et vos requêtes n’ont pas à rechercher les métadonnées des partitions.

L’exemple CREATE TABLE suivant crée une table pour le jeu de données d’événements d’appareil que nous venons de décrire. La table utilise le type de projection injecté.

CREATE EXTERNAL TABLE device_events (
  event_time TIMESTAMP,
  data STRING,
  battery_level INT
)
PARTITIONED BY (
  device_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
  "projection.enabled" = "true",
  "projection.device_id.type" = "injected",
  "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}"
)

L’exemple de requête suivant recherche le nombre d’événements reçus par trois appareils spécifiques sur une période de 12 heures.

SELECT device_id, COUNT(*) AS events
FROM device_events
WHERE device_id IN (
  '4a770164-0392-4a41-8565-40ed8cec737e',
  'f71d12cf-f01f-4877-875d-128c23cbde17',
  '763421d8-b005-47c3-ba32-cc747ab32f9a'
)
AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00'
GROUP BY device_id

Lorsque vous exécutez cette requête, Athena voit les trois valeurs de la clé de partition device_id et les utilise pour calculer les emplacements des partitions. Athena utilise la valeur de la propriété storage.location.template pour générer les emplacements suivants :

Si vous omettez la propriété storage.location.template dans la configuration de projection de partition, Athena utilise le partitionnement de style Hive pour projeter les emplacements des partitions en fonction de la valeur contenue dans LOCATION (par exemple, s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e).