Diffusion de bases statistiques : nouvelles interfaces et nouveaux formats

L’algorithme du moteur de recherche pourra être amélioré dans ce sens.

Il y a une facette sur le millésime dans le catalogue

Pas pour l’instant !

Un jeu de données chronologiques aura une url fixe. Un jeu de données millésimé aura une url variable, qui pourra dépendre de l’année mais dans un format lisible du type nom du dataset / millésime.

Les fichiers détail seront bien dans le catalogue mais sans filtre géographique. Ce dernier n’est disponible que pour les données agrégées en allant dans l’explorateur.

Elles sont conçues en fonction de l’intérêt a priori mais pourront être revues en fonction de la demande.

A court terme, les jeux de données seront cartographiés dans Statistiques locales
Parallèlement, il y a des travaux de cartographie fine à l’Insee, ce qui pourrait conduire à terme à une offre cartographique dans le catalogue.

Sirene est hors du champ de Melodi.

L’export sous forme de fichier de l’explorateur sera enrichi prochainement d’options, notamment d’options avec les libellés au lieu des codes

TadViewer permet déjà d’ouvrir, de filtrer et même pivoter un fichier Parquet. PowerBI, Tableau et d’autres outils du même style disposent de connecteurs Parquet. RowZero fait partie des nouveaux outils en ligne à tester, c’est un tableur super-puissant. SQL mérite dans tous les cas d’être (ré)examiné, sans a priori. DuckDB a introduit plusieurs simplifications qui le rendent particulièrement amical.

Oui en effet, ce guide Insee en donne quelques exemples concrets, tout comme cette vidéo. Parler de R ou Python signifie toutefois programmer, mais il est possible d’interroger dans R ou Python du format Parquet avec les librairies classiques (dplyr, pandas, polars) sans écrire de SQL.

Je ne connais pas d’API qui génère des formats parquet à la volée. Ce format demande un peu de temps de fabrication, pour atteindre tous ses bénéfices en compression et métadonnées. Un de ses intérêts est de pouvoir être lu directement, sans passer par une API. Pour info, les datasets Parquet sur data.gouv.fr sont affichables avec cette url : https://www.data.gouv.fr/fr/datasets/?format=parquet

Oui, précisément, à la fois générales (nombre de row-groups, type de chaque colonne…), et sur chaque colonne. Des statistiques sont même calculées (min/max, nb de valeurs distinctes) pour chaque colonne d’un row-group. Et possiblement bien davantage encore, par exemple pour un geoparquet : projection, bounding-box.

Ce n’est pas strictement un index au sens d’une base de données, mais un ensemble de métadonnées détaillées (cf. ci-dessus) permettant de « sauter » des blocs de données non pertinents pour une requête donnée. Un fichier parquet (ou une « partition » parquet décrit un « jeu de données » (dataset), et non une base de x jeux de données. Avec Parquet, le web devient LA base de données, et nous incite à ne plus dupliquer systématiquement les ressources. À côté de cela, DuckDB permet de constituer une base sous forme d’un unique fichier physique (comme une base SQLite), dans lequel vous pourrez loger des tables dont le format de stockage est proche de Parquet).

Je ne suis pas sûr que cela ait un sens, parquet est un format de fichier, que l’on peut interroger avec des moteurs SQL, mais aussi directement en C++, Java, Julia, etc. On pourrait par contre discuter de la conformité SQL de DuckDB, dont le SQL est très proche de celui de PostgreSQL, avec en plus de bonnes idées pour un SQL plus amical.

Peu actuellement, mais j’ai en tête d’écrire un article de blog sur ce sujet sur icem7.fr ! Comme pour une clé primaire, il faut veiller à trier sur une ou deux colonnes clés, celles souvent utilisées pour filtrer une requête (année, département…) Si le dataset dépasse le Go, un partitionnement s’envisage. Les colonnes doivent être précisément typées (entier/flottant/date/caractère/…) Un algorithme de compression de type SNAPPY ou ZSTD privilégié (éviter gzip). Les colonnes caractères avec peu de valeurs distinctes peuvent être « dictionnary-encoded » (cf. le concept de « factors » dans R). Enfin, c’est en testant un échantillon de requêtes sur plusieurs variantes que l’on identifie les meilleurs compromis (par exemple sur la taille des row-groups).

Déjà, Parquet peut vous éviter de dupliquer des fichiers en ligne. Sinon, vous pouvez les stocker sans nécessairement les encapsuler. Avec DuckDB par exemple, on n’a plus vraiment besoin de définir des clés primaires ou étrangères pour accélérer les requêtes avec jointures. Mais notez bien qu’avec Parquet on s’inscrit dans un schéma analytique (OLAP) lecture seule, plutôt que transactionnel (OLTP : écriture et lecture).

Parquet gère désormais le cryptage. Dans un même fichier, certaines colonnes sensibles peuvent être cryptées, sans que les autres le soient. DuckDB supporte depuis peu ce cryptage.

À partir d’un fichier CSV, vous pouvez spécifier quelques métadonnées éventuelles dans l’instruction COPY. Sachez toutefois que le parseur CSV dans DuckDB est particulièrement intelligent et détecte très bien tout seul les bons types de données (dates, entiers, caractères…). En particulier, il ne se trompe pas avec des codes comme 01001.