Meilleures pratiques pour UNLOAD from Timestream pour LiveAnalytics

Vous trouverez ci-dessous les meilleures pratiques relatives à la commande UNLOAD.

• La quantité de données qui peut être exportée vers le compartiment S3 à l'aide de la UNLOAD commande n'est pas limitée. Cependant, la requête expire au bout de 60 minutes et nous recommandons de ne pas exporter plus de 60 Go de données en une seule requête. Si vous devez exporter plus de 60 Go de données, répartissez le travail sur plusieurs requêtes.

• Bien que vous puissiez envoyer des milliers de demandes à S3 pour télécharger les données, il est recommandé de paralléliser les opérations d'écriture sur plusieurs préfixes S3. Reportez-vous à la documentation ici. Le taux d'appels de l'API S3 peut être limité lorsque plusieurs personnes readers/writers accèdent au même dossier.

• Compte tenu de la limite de longueur de clé S3 pour définir un préfixe, nous recommandons que les noms des compartiments et des dossiers ne dépassent pas 10 à 15 caractères, en particulier lors de l'utilisation d'une partitioned_by clause.

• Lorsque vous recevez un 4XX ou un 5XX pour des requêtes contenant l'UNLOADinstruction, il est possible que des résultats partiels soient écrits dans le compartiment S3. Timestream for LiveAnalytics ne supprime aucune donnée de votre bucket. Avant d'exécuter une autre UNLOAD requête avec la même destination S3, nous vous recommandons de supprimer manuellement les fichiers créés par l'échec de la requête. Vous pouvez identifier les fichiers écrits par une requête ayant échoué avec le code correspondantQueryExecutionId. En cas d'échec des requêtes, Timestream for LiveAnalytics n'exporte pas de fichier manifeste vers le compartiment S3.

• Timestream for LiveAnalytics utilise le téléchargement en plusieurs parties pour exporter les résultats des requêtes vers S3. Lorsque vous recevez un 4XX ou un 5XX de Timestream pour des requêtes contenant une instruction UNLOAD, Timestream LiveAnalytics for LiveAnalytics fait de son mieux pour abandonner le téléchargement en plusieurs parties, mais il est possible que certaines parties incomplètes soient laissées pour compte. C'est pourquoi nous vous recommandons de configurer un nettoyage automatique des téléchargements partitionnés incomplets dans votre compartiment S3 en suivant les instructions fournies ici.

Recommandations pour accéder aux données au format CSV à l'aide de l'analyseur CSV

• Les analyseurs CSV ne vous permettent pas d'avoir le même caractère dans le séparateur, le caractère d'échappement et le caractère entre guillemets.

• Certains analyseurs CSV ne peuvent pas interpréter les types de données complexes tels que les tableaux. Nous vous recommandons de les interpréter via le désérialiseur JSON.

Recommandations pour accéder aux données au format Parquet

1. Si votre cas d'utilisation nécessite la prise en charge des caractères UTF-8 dans le schéma, c'est-à-dire dans le nom de colonne, nous vous recommandons d'utiliser la bibliothèque Parquet-MR.

2. L'horodatage de vos résultats est représenté par un entier de 12 octets () INT96

3. Les séries temporelles seront représentées sous array<row<time, value>> la forme suivante : les autres structures imbriquées utiliseront les types de données correspondants pris en charge au format Parquet

Utilisation de la clause partition_by

• La colonne utilisée dans le partitioned_by champ doit être la dernière colonne de la requête de sélection. Si plusieurs colonnes sont utilisées dans le partitioned_by champ, les colonnes doivent être les dernières de la requête de sélection et dans le même ordre que celui utilisé dans le partition_by champ.

• Les valeurs de colonne utilisées pour partitionner les données (partitioned_bychamp) ne peuvent contenir que des caractères ASCII. Alors que Timestream pour LiveAnalytics autorise les caractères UTF-8 dans les valeurs, S3 ne prend en charge que les caractères ASCII en tant que clés d'objet.