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.
Cette section décrit certaines considérations relatives à l'utilisation des données d'horodatage dans Athena.
Note
Le traitement des horodatages a quelque peu changé entre les versions précédentes du moteur et la version 3 du moteur Athena. Pour plus d'informations sur les erreurs liées à l'horodatage qui peuvent se produire dans la version 3 du moteur Athena et sur les solutions proposées, consultez Modifications d'horodatage dans la référence Version 3 du moteur Athena.
Format pour écrire des données d'horodatage dans des objets Amazon S3
Le format dans lequel les données d'horodatage doivent être écrites dans les objets Amazon S3 dépend à la fois du type de données de colonne et de la SerDebibliothèque que vous utilisez.
-
Si vous avez une colonne de table de type
DATE, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au format ISOYYYY-MM-DDou un type de date intégré comme ceux de Parquet ou ORC. -
Si vous avez une colonne de table de type
TIME, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au format ISOHH:MM:SSou un type d'heure intégré comme ceux de Parquet ou ORC. -
Si vous avez une colonne de table de type
TIMESTAMP, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au formatYYYY-MM-DD HH:MM:SS.SSS(notez l'espace entre la date et l'heure) ou un type d'heure intégré comme ceux de Parquet, ORC ou Ion. Notez qu'Athena ne garantit pas le comportement des horodatages non valides (par exemple,).0000-00-00 08:00:00.000Note
Les horodatages Open CSVSer De constituent une exception et doivent être codés en tant qu'époques UNIX de résolution en millisecondes.
S'assurer que les données partitionnées dans le temps correspondent au champ d'horodatage d'un enregistrement
Le producteur des données doit s'assurer que les valeurs de partition correspondent aux données contenues dans la partition. Par exemple, si vos données ont une timestamp propriété et que vous utilisez Firehose pour les charger dans Amazon S3, vous devez utiliser le partitionnement dynamique car le partitionnement par défaut de Firehose est le suivant. wall-clock-based
Utiliser STRING comme type de données pour les clés de partition
Pour des raisons de performances, il est préférable d'utiliser STRING comme type de données pour les clés de partition. Même si Athena reconnaît les valeurs de partition au format YYYY-MM-DD comme des dates lorsque vous utilisez le type DATE, cela peut entraîner de mauvaises performances. Pour cette raison, nous vous recommandons d'utiliser plutôt le type de données STRING pour les clés de partition.
Comment écrire des requêtes pour des champs d'horodatage qui sont également partitionnés dans le temps
La façon dont vous rédigez les requêtes pour les champs d'horodatage partitionnés dans le temps dépend du type de table que vous souhaitez interroger.
Tables Hive
Avec les tables Hive les plus couramment utilisées dans Athena, le moteur de requête n'a aucune connaissance des relations entre les colonnes et les clés de partition. Pour cette raison, vous devez toujours ajouter des prédicats dans vos requêtes pour la colonne et pour la clé de partition.
Supposons, par exemple, que vous disposiez d'une colonne event_time et d'une clé de partition event_date et que vous souhaitiez interroger des événements survenus entre 23 h 00 et 03 h 00. Dans ce cas, vous devez inclure des prédicats dans votre requête pour la colonne et pour la clé de partition, comme dans l'exemple suivant.
WHERE event_time BETWEEN start_time AND end_time
AND event_date BETWEEN start_time_date AND end_time_dateTables Iceberg
Avec les tables Iceberg, vous pouvez utiliser des valeurs de partition calculées, ce qui simplifie vos requêtes. Supposons, par exemple, que votre table Iceberg ait été créée avec une clause PARTITIONED BY comme celle-ci :
PARTITIONED BY (event_date month(event_time))Dans ce cas, le moteur de requête réduit automatiquement les partitions en fonction des valeurs des prédicats event_time. Pour cette raison, votre requête doit uniquement spécifier un prédicat pour event_time, comme dans l'exemple suivant.
WHERE event_time BETWEEN start_time AND end_timePour de plus amples informations, veuillez consulter Création de tables Iceberg.
Lorsque vous utilisez le partitionnement caché d'Iceberg pour une colonne d'horodatage, Iceberg peut créer une partition sur une colonne de table construite dérivée d'une colonne d'horodatage et transformée en date pour un partitionnement plus efficace. Par exemple, il peut être créé event_date à partir de la colonne d'horodatage event_time et partitionner automatiquement. event_date Dans ce cas, le type de partition est une date.
Pour des performances de requête optimales lorsque vous utilisez la partition, filtrez sur des plages de jours complets pour activer le transfert des prédicats vers le bas. Par exemple, la requête suivante ne sera pas repoussée vers le bas car la plage ne peut pas être convertie en une seule partition de date, même si elle se situe en un jour :
WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-18 12:00:00'Utilisez plutôt une plage de jours complète pour autoriser le transfert des prédicats et améliorer les performances des requêtes, comme dans l'exemple suivant.
WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-19 00:00:00'Vous pouvez également utiliser la BETWEEN start_time AND end_time syntaxe ou utiliser les plages de plusieurs jours, à condition que les parties d'horodatage le soient. 00:00:00
Pour plus d'informations, consultez le billet de blog de Trino
