Remarques sur la rubrique 19 : Manipuler des données avec duckdb

[ericemc3]

J'ai lu avec beaucoup d'intérêt la fiche détaillée sur l'utilisation de DuckDB dans R (https://book.utilitr.org/03_Fiches_thematiques/Fiche_duckdb.html). Je pense qu'elle donne beaucoup de clés pratiques.

Voici quelques remarques et suggestions.

"Il est complètement normal de rencontrer des erreurs difficiles à comprendre lorsqu’on commence à utiliser duckdb, il ne faut donc pas se décourager."
Cette phrase me parait dissuasive et ne correspond pas à mon expérience.

19.2.2 À quoi sert le package duckdb?
Je dirais :

• Lire des sources de données dans une multitude de formats (csv, parquet, json, geojson, shape, postgresql...), y compris directement en ligne, y compris x fichiers d'un seul coup (en local comme avec S3, GCS ou HuggingFace)
• Manipuler...
• Écrire des données dans une multitude de formats (csv, parquet, json, formats SIG...)

19.2.3 Quels sont les avantages de duckdb?
"Disponibilité immédiate" : je ne suis pas d'accord avec l'assertion. Il n'y a pas en SQL de notion de prévisualiser un calcul sans l'exécuter totalement. En revanche, on peut préciser dans une requête un LIMIT. Mais si la requête présente des opérations dites bloquantes (ex : un tri final, une agrégation), elle devra quand même se calculer, même si toutes les données résultantes ne sont pas renvoyées au client.

"Ne pas nécessairement charger les données en mémoire" : point important, à préciser peut-être par "ne pas avoir à charger tout un jeu de données en mémoire avant de pouvoir le requêter". Un autre atout majeur de DuckDB : pouvoir interroger des fichiers en ligne de la même manière.

"Optimisations automatiques : ...ne lit que les lignes nécessaires..." : ce n'est pas exact. On peut dire qu'avec un format parquet par exemple, il lira les seuls row-groups identifiés comme contenant a priori les lignes nécessaires. Et avec CSV ou json, DuckDB doit bien lire toutes les lignes (filter pushdown impossible) et toutes les colonnes.

19.2.4 Quels sont les points d’attention à l’usage ?
"Traduction en SQL : duckdb traduit automatiquement les instructions dplyr en requêtes SQL".
Je ne suis pas sûr que ce soit la librairie duckdb qui fasse ça, je pense plutôt à dbplyr, ou à une association dbplyr/duckdb

19.4.4 Manipulation des données avec la syntaxe dplyr
"si le traitement se termine par print(n=nb_lignes): le calcul est exécuté partiellement,"
Ceci me parait un raccourci, le print() doit se contenter de rajouter un LIMIT à la fin de la requête, ce qui ne veut pas dire que les calculs sont exécutés partiellement (cf. supra).

19.4.6.1 On a éliminé des colonnes nécessaires
Je ne suis pas sûr de voir dans cet exemple et cette erreur une situation spécifique à DuckDB.

19.4.6.2 Convertir les types
L'exemple se comprend, mais c'est aussi l'occasion de rappeler à quel point SQL est plus élégant :

bpe_ens_2018_dataset %>%
  summarise(nb_boulangeries  = sum(NB_EQUIP * as.integer(TYPEQU == "B203")), .by = DEP)

FROM bpe_ens_2018_dataset
SELECT dep, sum(NB_EQUIP) FILTER (TYPEQU = 'B203')
GROUP BY ALL;

19.5.2 L’évaluation différée avec duckdb (lazy evaluation)
Je ne suis pas sûr que cet exemple soit bien choisi. HAVING intervient après l'agrégation et n'est a priori pas compris comme un filtre préalable.

SELECT DEP, SUM(NB_EQUIP) AS NB_EQUIP_TOT
FROM "bpe_ens_2018_dataset/*.parquet"
GROUP BY DEP
HAVING (DEP = '59')

"Un point essentiel est qu’avant l’instruction collect(), c’est le moteur SQL de duckdb qui fait les calculs, tandis qu’après l’instruction collect(), c’est le moteur de R qui fait les calculs".
En fait, avant un collect(), je ne suis pas sûr que grand chose se passe. Le collect() force d'abord la traduction en SQL de tout ce qui le précède (comme le fait un show_query()), opération prise en charge par DBI.
Ensuite ce SQL est passé à DuckDB qui l'exécute et revoie le jeu de données résultant vers DBI qui le transforme en tibble.

19.5.4.1 Séparer vos traitements SQL en blocs
Il me paraitrait bien de préciser qu'un dbExecute() peut s'appliquer à une chaine (entre '') comprenant plusieurs instructions SQL,
et aussi de donner une exemple avec des requêtes WITH() comme alternatives aux VIEWS si elles n'ont pas à être réutilisées.

19.6 Comparaison avec arrow
"Le projet duckdb est très récent." : ce projet a quand même 6 ans, la version 1.0.0 vient de sortir, "très récent" est peut-être un peu fort comme qualificatif.

Enfin, la librairie duckplyr, fruit d'un partenariat entre l'équipe dplyr chez Posit et DuckDB, pourrait mériter une évocation (https://duckdb.org/2024/04/02/duckplyr.html)