You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Comme évoqué dans la note de l'Insee en date du 2023-06-26 (diffusion générale), le format parquet est désormais officiellement recommandée dans un certain nombre de cas.
Il me semblerait intéressant de rajouter une boite :spécificité-insee: dans la fiche parquet en ce sens.
Les points importants selon moi sont :
"Parquet [...] devient donc le nouveau format de référence à privilégier pour toute mise à disposition interne de données détaillées sous forme de fichiers qu’elle provienne de traitements self comme de SI."
Ce format est particulièrement recommandé pour les traitements mettant à disposition des données détaillées volumineuses.
Un certain nombre de détails techniques :
il convient de partitionner le fichier (à partir de fichier de plus d'un million de lignes) selon le ou les critères d’usages les plus fréquents de ces données lorsque le producteur a connaissance de ces cas d’usage (ex : partition par département, par année ou selon une nomenclature au niveau idoine) ;
utiliser snappy comme format de compression qui correspond au format de compression par défaut en R.
Pour les variables de type date (ex : date de naissance, date de début de contrat), coder la date sous forme d’une chaîne de caractère en spécifiant bien le format et le séparateur dans les métadonnées (ex : AAAA-MM-JJ). Cette chaîne de caractère doit contenir toute l’information statistique disponible (dit autrement le codage de l’information sous forme d’une chaîne de caractère (string) ne doit pas conduire à détruire de l’information).
Suivre la documentation sur le nombre de partition maximal et optimal qui recommande, en général, d’éviter les fichiers de moins de 20 MB ou de plus de 2 GB et d’éviter d’avoir plus de 10 000 partitions.
Encoder les chaînes de caractères (string) en utf8 ce qui correspond au standard et au format d’encodage par défaut en R.
Utiliser la version la plus récente des librairies R et python utilisées pour créer/manipuler des fichiers parquet (notamment version récente d’arrow en R). De même utiliser la version la plus récente de spark et duckdb pour créer/manipuler des fichiers parquet.
The text was updated successfully, but these errors were encountered:
Je ne sais pas comment le formuler, mais il me semblerait important de préciser également ce point de la note : "la politique de l’Insee est [désormais] de proposer systématiquement le format Parquet". Vu que de nombreux agents en SSM exploitent également cette documentation, ça peut contribuer à diffuser le format dans le SSP, non ?
utiliser snappy comme format de compression qui correspond au format de compression par défaut en R.
Pour les variables de type date (ex : date de naissance, date de début de contrat), coder la date sous forme d’une chaîne de caractère en spécifiant bien le format et le séparateur dans les métadonnées (ex : AAAA-MM-JJ). Cette chaîne de caractère doit contenir toute l’information statistique disponible (dit autrement le codage de l’information sous forme d’une chaîne de caractère (string) ne doit pas conduire à détruire de l’information).
Pourquoi snappy ? Zstd est a priori meilleur en compromis compression/décompression, et est maintenant lu partout.
Pourquoi stocker une date en caractère ? Il me parait plus logique et maniable de la stocker en... date, pour bénéficier directement de toutes les fonctions opérant sur des dates et éviter les castings fastidieux.
Comme évoqué dans la note de l'Insee en date du 2023-06-26 (diffusion générale), le format parquet est désormais officiellement recommandée dans un certain nombre de cas.
Il me semblerait intéressant de rajouter une boite :spécificité-insee: dans la fiche parquet en ce sens.
Les points importants selon moi sont :
The text was updated successfully, but these errors were encountered: