Webinaires CASD DATA TECH

Spark

 

Mercredi 30 avril 2025 de 11h00 à 12h30

Spark

Programme :

  • La logique « spark » d’appel depuis les autres langages (API)
  • Les modalités de distribution des traitements spark (workers) en fonction de la localisation des données, du mode local ou cluster
  • Les types de transformations en Spark
  • Des exemples d’actions Spark (show, count, collect…)
  • Le principe de la « Lazy evaluation »
  • La gestion des ressources par Spark

Présentation :

  • Kamel GADOUCHE, Directeur du Centre d’accès sécurisé aux données CASD
  • Pengfei LIU, Ingénieur infrastructure Datascience CASD
  • Titouan RIGAUD, Ingénieur infrastructure Datascience CASD

Médiathèque :

Le replay

Les documents support

Foire aux Questions 

Spark s’intègre naturellement avec des langages qui possèdent cette faculté. On peut donc requêter avec Python ou R l’API rest ou utiliser une librairie qui lit du graphql. On obtient alors des objets Python/R que l’on peut convertir en objets Spark.
Cependant, cette solution passe difficilement à l’échelle, et ce n’est pas forcément l’objectif de Spark que de transformer des objets Python/R, car ces objets sont créés directement sur la session principale. Autrement dit : cette solution n’est pas distribuée jusqu’au moment où on commence effectivement à faire les traitements avec Spark. Si les volumes sont limités, c’est possible, mais pas forcément idéal.

A notre connaissance, il n’existe pas de façon Spark native de consommer des données API/graphQL. On doit donc passer par les librairies du langage mais en les encapsulant dans une User Defined Function (UDF) Spark. De telle sorte que c’est Spark qui fera la requête en s’appuyant sur le code Python. Cela assure qu’il n’y a pas une accumulation d’objets dans la session locale Python ou R, et qui risquent de de consommer beaucoup de mémoire.

Spark est conçu pour le traitement de données haute performance. Il n’est pas très adapté au développement web car c’est un framework, et non un langage. Cependant, Spark peut tout à fait s’intégrer dans un pipeline de traitement qui répond à ce cas d’usage. En utilisant Spark pour le traitement et la production des données à visualiser, ou de résultats (qui sont de volumes bien moindres par nature) puis, en re-transformant ces résultats en Python ou en R, on peut les visualiser ou mettre à disposition simplement. En effet, Python et R regorgent de librairies qui permettent de réaliser une interface web efficace : FastAPI/Dash plotly/Django/Flash/… pour Python ou PlumbeR pour R.

Effectivement, les lignes de codes ne sont pas toujours exécutées immédiatement ni dans l’ordre dans lesquelles elles sont écrites par l’utilisateur. Cependant, la garantie que Spark apporte est que le résultat est rigoureusement identique à la logique du code l’utilisateur.

Spark peut exécuter un filtre qui se situe à la fin des lignes utilisateurs en premier pour optimiser, mais cependant, il ne le fera que si cela n’a aucune incidence sur le résultat. Par exemple, si ce filtre intervient sur un dataframe qui est construit sur des lignes qui seraient retirées par ce filtre, le filtre sera bien appliqué à la fin et après le calcul intermédiaire.

Oui, le langage natif Scala est plus rapide. Cependant, les différences de performance entre Scala, PySpark et SparkR sont faibles. Cela ne semble pas un choix pertinent pour un utilisateur qui n’as pas un usage haute performance de Spark car Scala est moins pratique à utiliser que Python ou R. Si vous possédez déjà des notions en Python ou en R, la meilleure option est probablement de se tourner vers l’API Spark de ce langage.

Scala est tout à fait utilisable, performant et pour des codes amenés à tourner de façon fréquentes, sur des volumes importants, c’est un choix qui peut être pertinent.

L’installation de Spark peut être une opération difficile, que ce soit sur une machine Linux ou Windows, considérant le grand nombre de composants nécessaires et les multiples versions qui doivent être compatibles.

Le CASD propose donc un script d’installation automatique et une documentation afférente dans les bulles CASD afin de simplifier cette opération. Nous fournissons également un support en cas de problème d’installation par email. Ce script est disponible dans le dossier Raccourcis sur votre bureau utilisateur, et la documentation d’utilisation Spark ainsi que des exemples dans le guide de bonne pratique d’utilisation des logiciels.

Parquet et DuckDB

 

Mardi 4 février 2025 de 11h00 à 12h30

Programme :

  • Présentation du format parquet
  • Propriétés
  • Stockage en mode colonne / partition et format physique
  • Encodage et Compression : Exemples de gain en place

 

  • Présentation de l’outil DuckDB
  • DataBase «in process» / optimisation des ressources
  • Création de vue sur parquet
  • DuckDB dans R et python

 

Présentation :

  • Kamel GADOUCHE, Directeur du Centre d’accès sécurisé aux données CASD

Médiathèque :

Le replay

Les documents support

Foire aux Questions 

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’écrituretotale 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 doncsouvent 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)

Nous n’avions pas connaissance de ce package. D’après la documentation de Duckdbhttps://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.