Webinaire CASD DATA TECH

DuckDB, même s’il est optimisé pour limiter la consommation de mémoire, peut parfois, pour certains traitement, consommer de la mémoire en plus importante quantité.

Il est possible de configurer certains paramètres pour limiter l’utilisation des ressources, mais dans une bulle partagée, une consommation excessive peut avoir un impact sur les autres utilisateurs de la bulle. Il s’agit plutôt d’une solution économique en principe.

Le sujet de la gestion mémoire a été abordé dans un article de blog de DuckDB : https://duckdb.org/2024/07/09/memory-management.html

Vous avez raison, si le volume de données est important, cela peut dépasser la limite de mémoire vive, et la conversion échouera. Mais il y a d’autres outils comme Spark pour traiter ce genre de données.

A priori, il n’y a pas de raison de constater des différences de performance. L’API python et l’API R sont simplement des clients qui transmettent les requêtes sur le moteur DuckDB en C++.

La différence de performance peut donc se faire sur la gestion de mémoire des deux langages par exemple. Le résultat d’un requête DuckDB en python avec la méthode `fetchdf()` est un pandas dataframe alors que dans R, c’est un dataframe R.

La gestion de mémoire n’est donc pas la même pour les deux structures de données.

Mais toutes les données chargées dans DuckDB et l’exécution des requêtes sont identiques.

Pour garantir des propriétés de lecture rapides et une taille minimale, un fichier parquet ne peut être édité facilement. C’est le paradigme Write Once – Read Many. L’idée est d’utiliser des outils de compression et de partitionnement qui rendent la modification où l’ajout plus complexe. Concrètement, modifier un fichier parquet, c’est le ré-écrire en quasi intégralité.

Techniquement, c’est tout à fait possible de faire une modification. Pour les tables avec un volume inférieur à 500 millions de lignes, l’écriture totale coute moins de 5 minutes.

Souvent la meilleure stratégie est en fait d’éditer les données tant qu’elles doivent être modifiées dans un format qui le supporte (CSV/Avro/base de données SQL/Oracle), puis d’exporter les données pour faire des analyses. C’est pour cela que les producteurs de données utilisent le parquet. Il s’agit d’un format pour arrêter une table à un instant t et procéder à des analyses dessus à plusieurs reprises, en profitant d’une taille de fichier minimale. Le choix du format doit être adapté à l’usage que l’on fait, et parquet est très adapté aux analyses, mais peu adapté aux opérations transactionnelles. Le critère est donc souvent plus l’usage que la temporalité, même s’il peut tout à fait entrer en compte dans la décision.

Pour répondre par un exemple : s’il faut ajouter des lignes à la table chaque jour ou chaque semaine, une base de données est plus adaptée. Si on produit des données, qu’on les arrête chaque mois pour les envoyer à l’analyse, produire un fichier parquet à la fin de chaque mois est très adapté.

Non, malheureusement, le même problème se pose : que l’on ajoute des lignes ou que l’on mette à jour des lignes, parquet va recalculer les métadonnées et réécrire des fichiers complets. On peut cependant le faire de façon détournée en utilisant un partitionnement.

Par exemple, une partition par jour contenant les données produites pour une journée donnée. L’ensemble des partitions constituent alors un fichier cohérent. Il suffit de créer un fichier parquet chaque jour, de le mettre avec les autres partitions et le fichier parquet d’ensemble inclue de fait les nouvelles lignes.

Enfin, il est probable qu’un format append-only natif tel que Avro soit une bonne solution, quitte à écrire un parquet plus tard quand les données sont prêtes à être analysées.

Oui, les deux technologies sont compatibles. DuckDb possède une extension : spatial extension (https://duckdb.org/docs/extensions/spatial/overview.html) qui permet l’utilisation de données spatiales.

DuckDB permet cette manipulation :

COPY (SELECT * FROM « C:\Users\…\votre\fichier.parquet ») TO « C:\Users\…\votre\fichier.csv » (HEADER, DELIMITER ‘,’);

Attention : le délimiteur choisi ici est la virgule, si vos données contiennent elles-mêmes des virgules, il vaut mieux choisir le point-virgule pour l’option Delimiter.

SAS utilise le type et format pour définir le schéma d’une table. Le format SAS peut être personnalisé, et les packages de conversion peuvent donc échouer à reconnaître de tels formats. Les formats et type par défaut de SAS peuvent donc être convertis sereinement, mais il n’existe pas de garantie à 100% si la table contient des formats personnalisés.

La documentation de duckdb ne semble pas mentionner d’options au moment de la lecture malheureusement. Mais c’est tout à fait possible de transformer le dataframe après lecture :

— sql

SELECT column_name, CASE WHEN column_name IN (‘NA’, ‘NULL’, ‘-999’) THEN NULL ELSE column_name END AS column_cleaned FROM read_parquet(‘data.parquet’);

—

Le partitionnement est transparent pour l’utilisateur en DuckDB. Si le chemin fournit est la racine et que l’on précise qu’il y a une partition, l’ensemble des données seront lues. Cependant, si vous fournissez un chemin vers un fichier précis, alors seul ce fichier sera lu.

D’un point de vue technique, si l’on effectue une partition : parquet va effectivement stocker les données dans des fichiers séparés et il sera obligé d’analyser chaque fichier individuellement s’il veut analyser l’ensemble des données.

Une captation du webinaire est disponible sur le site du CASD (voir la Mediathèque)

Tout à fait ! Merci pour ce retour d’expérience.

Nous n’avions pas connaissance de ce package. D’après la documentation de Duckdb https://duckdb.org/docs/api/r.html, le package dplyr est supporté officiellement par Duckdb. Il faut évaluer les points positifs et négatifs d’un package tiers par rapport au package officiel.

Parfois, les packages tiers sont moins performants mais plus facile à utiliser. Par exemple : Sparklyr pour faire du spark avec une syntaxe dplyr est souvent choisi au détriment de SparkR pour cette raison. Malgré des performances et une intégration moindre par rapport à SparkR, la syntaxe est beaucoup plus proche de dplyr. Pourtant, SparkR est bien l’API officielle.

La source des données est : https://www.kaggle.com/datasets/benoitfavier/immobilier-france