Proposition de fiche duckdb #512
Conversation
linogaliana
commented
Feb 22, 2024
linogaliana
commented
- Follow-up de Proposition de fiche duckdb #508. La fiche étant bien avancée, on peut maintenant passer à des commentaires et suggestions direct depuis une branche du dépôt principal
- @oliviermeslin , @pierre-lamarche, et @slithiaote (et tous les autres participants à Proposition de fiche duckdb #508) : c'est ici que ça se passe maintenant
* Create Fiche_duckdb.qmd * Update Fiche_duckdb.qmd * Fiche duckdb : fin * Update 03_Fiches_thematiques/Fiche_duckdb.qmd Co-authored-by: Olivier Meslin <[email protected]> * Apply suggestions from code review Co-authored-by: Olivier Meslin <[email protected]> * Update Fiche_duckdb.qmd * Apply suggestions from code review Co-authored-by: Pierre Lamarche <[email protected]> * Restructuration + commentaires de P Lamarche Aussi : ajout à la liste des contributeurs (suggestion d'Olivier Meslin) * Nuancer sur le volume de données * Compléter les conseils * Précision * Mettre un nom plus signifiant pour la connexion duckdb * Les backticks c'est la vie * L'italique aussi c'est la vie * Amélioration de la présentation du chargement des données * Reformulations * Les majuscules c'est la vie * Update Fiche_duckdb.qmd --------- Co-authored-by: Olivier Meslin <[email protected]> Co-authored-by: Pierre Lamarche <[email protected]> Co-authored-by: Olivier Meslin <[email protected]>
|
|
||
| **Utilisation de la mémoire vive** | ||
|
|
||
| Comme expliqué plus haut, les objets manipulés dans cette fiche sont des requêtes SQL, et ne nécessitent pas de mémoire vive. Les données déclarées par `read_parquet` sont stockées sur le disque dur, lues à la demande, et "oubliées" à la fin du calcul. On retourne le _résultat_ du calcul. |
There was a problem hiding this comment.
Ce paragraphe (et certains autres passages) me semblent donner l'impression que lorsque duckdb travaille à partir d'un fichier Parquet, tout se passe sur le disque sans passage par la mémoire. Or si c'est clair que duckdb optimise très fortement la quantité de données utilisées avec les filtres pushdown & co, il y a bien traitement de la donnée en mémoire à un moment non ? C'est du "larger than memory" mais pas non plus sans passage en mémoire
|
Aussi une remarque un peu plus générale sur cette fiche très instructive (merci @slithiaote !) : je suis pas sûr que l'utilisation de duckdb via des requêtes pur SQL devrait être considéré "usage avancé", mais juste une manière alternative d'interagir avec une BDD DuckDB. C'est sûr qu'on se place dans le contexte d'UtilitR en disant ça, mais en réalité SQL reste très répandu et bien connu dans le monde statistique, en particulier par les ex-utilisateurs de SAS par exemple. Du coup, pour les mêmes raisons, j'aurais tendance à réécrire le tout premier paragraphe de la fiche en "L’utilisateur souhaite manipuler des données structurées avec la syntaxe |
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
Co-authored-by: Romain Avouac <[email protected]>
|
Il me semble que la fiche ne présente pas comment installer puis charger deux extensions pourtant potentiellement utiles pour les utilisateurs.rices d' @pierre-lamarche ça sera également l'occasion de faire un encart spécificités pour l'insee: les extensions sur LS3, sur AUS et en local (perso j'ai jamais réussi à faire fonctionner en local httpfs à cause du proxy) |
There was a problem hiding this comment.
Merci beaucoup Sébastien pour cette proposition de fiche hyper utile et intéressante ! J'ai fait quelques propositions qui visent principalement à simplifier un peu le propos parce que, tout comme celle sur arrow, ça reste une fiche très compliquée (on aborde à la fois les bases de données, la lazy evaluation, l'interaction avec arrow...).
Comme dit précédemment, j'aurais trouvé intéressant d'ajouter le fait que, avec une base de données sur disque, on peut modifier des grosses tables sans devoir réécrire l'ensemble du fichier. Ca me paraît être un cas d'usage intéressant pour de la prod et de la diffusion de fichiers.
Et peut-être que ça vaudrait le coup de développer un peu plus la partie SQL ? Ca peut intéresser la communauté des SASseurs qui ont l'habitude d'utiliser des PROC SQL.
| - Écrire des données en format Parquet. | ||
|
|
||
|
|
||
| ### Quels sont les avantages de `duckdb`? |
There was a problem hiding this comment.
Je pense qu'il est important de préciser dans cette section et la suivante les points communs et les différences avec les autres paradigmes proposés dans utilitr, notamment arrow, afin que les utilisateurs puissent se diriger vers l'une, l'autre ou la combinaison des deux solutions.
|
|
||
| Pour contourner le manque de mémoire vive, on propose les quatre techniques suivantes : | ||
|
|
||
| - exécuter et sauvegarder les résultats au fur et à mesure. La commande `arrow::write_dataset` et la commande SQL `COPY request TO filename.parquet` savent le faire automatiquement, sans faire déborder la mémoire, pour certains calculs. |
There was a problem hiding this comment.
Un exemple serait bienvenu. Je ne comprends pas la différence avec le tiret 4.
| - Pour exécuter une fonction fenêtre, il faut pouvoir localiser les données en mémoire avec un _index_. | ||
| - Les fichiers `parquet` ont un index `min-max` : les fichiers sont structurés en blocs, et on indique le minimum et maximum des valeurs du bloc dans les métadonnées. Ceci permet de sauter la lecture d'un bloc si l'on s'intéresse à des valeurs en dehors de la plage `min-max`, parce que l'on filtre les données par exemple. | ||
| - En SQL, on peut créer un index, mais il faut que les données soient en mémoire, ce qui peut s'avérer être incompatible avec de très grosses volumétries. | ||
| - Par contre, on peut partitionner les données, et le moteur SQL sait utiliser le partitionnement comme un index. |
There was a problem hiding this comment.
Il me semble qu'il manque un exemple, le code ci-dessous ne montrant que comment créer un fichier de données partitionné.
Co-authored-by: JulienBlasco <[email protected]>
* supprime check_from qui est déprécié * quelques précisions sur comment ouvrir des fichiers parquet * une fonction par ligne * limiter le nb de coeurs * complements sur les fichiers intermédiaires * ajoute de quotes manquants * corrections sur les propositions des optimisations * ajout d'une section sur les paramètres de configuration * quelques ajouts sur SQL * Update 03_Fiches_thematiques/Fiche_duckdb.qmd * Update 03_Fiches_thematiques/Fiche_duckdb.qmd * Update 03_Fiches_thematiques/Fiche_duckdb.qmd * Update 03_Fiches_thematiques/Fiche_duckdb.qmd * Update 03_Fiches_thematiques/Fiche_duckdb.qmd --------- Co-authored-by: Olivier Meslin <[email protected]>
