Store

Stockage dans des fichiers Parquet

Parquet est un format de fichier de type très particulier dans lequel chaque champ contient un seul type de données spécifique (tel que in32, double, horodatage ou texte). Qlik Sense stocke les données internes sous forme de type double lâche, dans lequel les données provenant de différentes sources peuvent être combinées dans les mêmes champs. Étant donné qu'une seule partie des données de type double peut être stockée dans chaque champ dans Parquet, il est important de connaître le contenu de chaque champ. Par défaut, Qlik Sense utilise le type de champ pour déterminer le mode de stockage du champ. Lors du stockage de données dans des fichiers Parquet dans un format spécifique, vous devez spécifier le type de données de vos champs lors de leur chargement. Si vous tentez de stocker des données dans des champs incompatibles dans un fichier Parquet, comme des nombres dans un champ de texte ou du texte dans un champ d'horodatage, vous aboutirez à des valeurs nulles.

Lors du chargement de données à stocker dans Parquet, il est possible de modifier le comportement par défaut. Vous pouvez le formater de sorte à modifier votre type de données ou le baliser de sorte à appliquer de force des types de colonne spécifiques dans Parquet.

Formatage de données à des fins de stockage dans Parquet

Vous pouvez utiliser les fonctions de formatage Qlik Sense pour classifier vos données. Par exemple, la fonction Text(), Num(), Interval() ou Timestamp() peut appliquer des formats de données lors du stockage de données dans Parquet. Qlik Sense peut stocker des données dans presque 20 types de données différents, suivant les attributs de champ et les balises de champ automatiques. Pour plus d'informations, consultez Fonctions d'interprétation.

Formatage de données avec Num() et Text()

L'exemple suivant montre comment préparer des données pour leur stockage dans Parquet. La fonction Num() est appliquée au champ numérique. La fonction Text() est appliquée aux champs de texte et mixtes. Dans le cas de champs mixtes, la fonction Text() empêche le traitement du champ comme un champ numérique dans Parquet et le remplacement des valeurs textuelles par des valeurs nulles.

Balisage de données à des fins de stockage dans Parquet

Balisez les données à l'aide de balises $parquet pour appliquer de force des types de colonne spécifiques lors du stockage de données dans Parquet. Chaque type de données peut être appliquée de force via l'ajout de la balise de contrôle correspondante. Par exemple, pour stocker un champ au format INT32 dans Parquet, appliquez-lui la balise $parquet-int32 dans le script de chargement. Suivant le type de données, la représentation numérique ou sous forme de chaîne des données doubles sera stockée.

Vous pouvez utiliser les balises de contrôle Parquet suivantes pour baliser des champs afin de les stocker dans des fichiers Parquet.

Balisage de données à des fins de stockage dans Parquet

Dans cet exemple, deux balises sont utilisées pour définir les données pour Parquet. Le champ num reçoit la balise $parquet-int32 pour être défini comme un champ numérique au format INT32 dans Parquet.

Stockage de données imbriquées dans des fichiers Parquet

Vous pouvez stocker plusieurs tables dans des fichiers Parquet en les imbriquant dans des données structurées. Store supporte les nœuds structurés et les nœuds de liste dans un schéma en étoile. Les tables individuelles peuvent également être stockées en mode imbriqué via le spécificateur Delimiter is.

Lors du stockage de tables, spécifiez les tables à inclure, séparées par des virgules. Par exemple : STORE Table1, Table2, Table3 INTO [lib://<file location>/<file name>.parquet] (parquet);. Vous pouvez contrôler les champs stockés via une liste de champs dans l'instruction Store. Par exemple STORE Field1, Field2, FROM Table1, Table2 INTO [lib://<file location>/<file name>.parquet] (parquet);. Tous les champs de la liste doivent se trouver dans une ou plusieurs des tables répertoriées. La première table de l'instruction Store sera utilisée comme table de faits dans le schéma en étoile.

Les noms de champ sont utilisés pour contrôler la manière dont les groupes seront créés et imbriqués. Par défaut, les noms de champ sont séparés en nœuds à l'aide d'un point (.). Il est possible de modifier le délimiteur en définissant la variable système FieldNameDelimiter ou en utilisant le spécificateur Delimiter is. Le spécificateur remplacera la variable système. Pour plus d'informations, consultez Utilisation des variables dans l'éditeur de chargement de données.

Les noms de champ sont séparés par le délimiteur et les parties sont utilisées pour créer le schéma avec les groupes imbriqués. Par exemple, STORE Field1, Field1.Field2, Field1.Field3, Field1.Field4 FROM Table1 INTO [nested.parquet] (parquet, delimiter is '.'); créera deux groupes (Group1 et Group2) avec Fields1, Field2 et Field3, Field4.

Lors du stockage de données imbriquées dans Parquet, les clés entre les tables sont transformées en nœuds de lien dans le schéma. Les tables sont transformées en nœuds structurés dans le schéma. Vous pouvez remplacer la transformation par défaut via des noms de champ.

Stockage de données imbriquées dans un fichier Parquet

Le schéma du fichier Parquet obtenu est le suivant :

Limitations

Le stockage de données imbriquées dans Parquet présente les limitations suivantes :

• Le stockage ne prend pas en charge les nœuds de carte.

• Le stockage n'inclut pas de champs clés générés via le chargement de fichiers Parquet imbriqués.

• Vous ne pouvez pas stocker ensemble des données provenant de tables qui ne sont pas liées à des champs clés.

• Le fichier imbriqué dénormalise le modèle de données. Les valeurs non référencées ne seront pas enregistrées et les valeurs référencées plusieurs fois seront copiées.

Lorsque vous utilisez une instruction Store dans un script de chargement dans Qlik Cloud, vous pouvez faire référence au dossier exact dans un espace dans lequel vous souhaitez stocker les fichiers créés. Suivez les règles relatives aux chemins d'accès aux dossiers d'espaces valides. Les comportements suivants s'appliquent eux aussi et sont propres aux instructions Store :

• Si l'espace existe, mais si le chemin d'accès au dossier spécifié n'existe pas, le chemin d'accès sera créé dans l'espace. Un ou plusieurs dossiers peuvent être créés, suivant la structure de dossiers définie. Le fichier y est généré et stocké.

• Si l'espace existe mais si le chemin d'accès au dossier spécifié utilise des délimiteurs de dossier non valides (par exemple, \, \\, //, /./ ou /../), l'instruction Store est tout de même exécutée. En revanche, le fichier de sortie est enregistré au chemin d'accès de premier niveau dans l'espace cible et portera un nom contenant son chemin d'accès complet et pas seulement le nom spécifié.

• Si l'espace n'existe pas, l'instruction Store ne peut pas être exécutée et renvoie une erreur.

Les exemples suivants montrent comment référencer un chemin d'accès à un dossier spécifique de l'espace au sein de votre instruction Store.

Stockage d'un fichier au chemin d'accès de premier niveau d'un espace

Dans cet exemple, la totalité de la table mytable est exportée dans Qlik Cloud Analytics sous forme de fichier nommé myfile.qvd. Le fichier est ajouté à l'espace partagé TeamSharedSpace. Le fichier ne se trouve dans aucun dossier spécifique, mais au chemin d'accès de premier niveau de l'espace.

Store * from mytable into [lib://TeamSharedSpace:DataFiles/myfile.qvd];

Stockage d'un fichier à un chemin d'accès à un dossier spécifique dans un espace

Dans cet exemple, la totalité de la table mytable est exportée dans Qlik Cloud Analytics sous forme de fichier nommé myfile.qvd. Le fichier est ajouté au dossier SalesData de l'espace TeamSharedSpace.

Store * from mytable into [lib://TeamSharedSpace:DataFiles/SalesData/myfile.qvd];