From 8b4be00e40e309934d094759f8f31f0d1e98709c Mon Sep 17 00:00:00 2001 From: Meslin Olivier Date: Tue, 21 Nov 2023 19:28:32 +0100 Subject: [PATCH] Gros ajouts sur arrow --- 03_Fiches_thematiques/Fiche_arrow_duckdb.qmd | 252 +++++++++++++++---- 1 file changed, 205 insertions(+), 47 deletions(-) diff --git a/03_Fiches_thematiques/Fiche_arrow_duckdb.qmd b/03_Fiches_thematiques/Fiche_arrow_duckdb.qmd index bdbd9580..5f8fe010 100644 --- a/03_Fiches_thematiques/Fiche_arrow_duckdb.qmd +++ b/03_Fiches_thematiques/Fiche_arrow_duckdb.qmd @@ -1,77 +1,87 @@ # Manipuler des données avec `arrow` et `duckdb` {#arrow-duckdb} - ## Tâches concernées et recommandations L'utilisateur souhaite manipuler des données structurées sous forme de `data.frame` (sélectionner des variables, sélectionner des observations, créer des variables, joindre des tables). ::: {.callout-recommandation .icon} -* Pour des tables de données de taille petite et moyenne (inférieure à 1 Go ou moins d'un million d'observations), il est recommandé d'utiliser les *packages* `tibble`, `dplyr` et `tidyr` qui sont présentés dans la fiche [Manipuler des données avec le `tidyverse`](#tidyverse); -* Pour des tables de données de grande taille (plus de 1 Go ou plus d'un million d'observations), il est recommandé d'utiliser soit le _package_ `data.table` qui fait l'objet de la fiche [Manipuler des données avec `data.table`](#datatable), soit les _packages_ `arrow` et `duckdb` qui font l'objet de la présente fiche. +- Pour des tables de données de taille petite et moyenne (inférieure à 1 Go ou moins d'un million d'observations), il est recommandé d'utiliser les *packages* `tibble`, `dplyr` et `tidyr` qui sont présentés dans la fiche [Manipuler des données avec le `tidyverse`](#tidyverse); + +- Pour des tables de données de grande taille (plus de 1 Go ou plus d'un million d'observations), il est recommandé d'utiliser soit le *package* `data.table` qui fait l'objet de la fiche [Manipuler des données avec `data.table`](#datatable), soit les *packages* `arrow` et `duckdb` qui font l'objet de la présente fiche. -- Il est essentiel de travailler avec la dernière version d'`arrow`, de `duckdb` et de `R` car les _packages_ `arrow` et `duckdb` sont en cours de développement. +- Il est essentiel de travailler avec la dernière version d'`arrow`, de `duckdb` et de `R` car les *packages* `arrow` et `duckdb` sont en cours de développement. ::: ::: {.callout-remarque .icon} -Apprendre à bien utiliser `arrow` n'est ni simple ni rapide, car cela nécessite une bonne compréhension du fonctionnement de `R` et de `arrow`. +Apprendre à bien utiliser `arrow` n'est ni simple ni rapide, car cela nécessite une bonne compréhension du fonctionnement de `R` et de `arrow`. -- Il est indispensable de lire les fiches [Importer des fichiers Parquet](#importparquet) et [Manipuler des données avec le `tidyverse`](#tidyverse) avant de lire cette fiche. -- Il est complètement normal de rencontrer des erreurs difficiles à comprendre lorsqu'on commence à utiliser `arrow`, il ne faut donc pas se décourager. -- Il ne faut pas hésiter à demander de l'aide à des collègues, ou à poser des questions sur les salons Tchap adaptés (le salon Langage `R` par exemple). +- Il est indispensable de lire les fiches [Importer des fichiers Parquet](#importparquet) et [Manipuler des données avec le `tidyverse`](#tidyverse) avant de lire cette fiche. +- Il est complètement normal de rencontrer des erreurs difficiles à comprendre lorsqu'on commence à utiliser `arrow`, il ne faut donc pas se décourager. +- Il ne faut pas hésiter à demander de l'aide à des collègues, ou à poser des questions sur les salons Tchap adaptés (le salon Langage `R` par exemple). ::: - -## Présentation des _packages_ `arrow` et `duckdb` +## Présentation des *packages* `arrow` et `duckdb` ### Qu'est-ce qu'`arrow`? -Apache `arrow` est un projet _open-source_ qui propose une représentation standardisée des données tabulaires en mémoire vive, qui est à la fois efficace (les traitements sont rapides), interopérable (différents langages de programmation peuvent accéder aux mêmes données, sans conversion des données dans un autre format) et indépendante du langage de programmation utilisé. Un point important à retenir est donc que __`arrow` n'est pas un outil spécifique à `R`__, et il faut bien distinguer le projet `arrow` du _package_ `R` `arrow`. Ce _package_ propose simplement une interface qui permet d'utiliser le projet `arrow` avec `R`, et il existe d'autres interfaces pour se servir d'`arrow` avec d'autres langages: en Python, en Java, en Javascript, en Julia, etc. - +Apache `arrow` est un projet *open-source* qui propose une représentation standardisée des données tabulaires en mémoire vive, qui est à la fois efficace (les traitements sont rapides), interopérable (différents langages de programmation peuvent accéder aux mêmes données, sans conversion des données dans un autre format) et indépendante du langage de programmation utilisé. Un point important à retenir est donc que **`arrow` n'est pas un outil spécifique à `R`**, et il faut bien distinguer le projet `arrow` du *package* `R` `arrow`. Ce *package* propose simplement une interface qui permet d'utiliser le projet `arrow` avec `R`, et il existe d'autres interfaces pour se servir d'`arrow` avec d'autres langages: en Python, en Java, en Javascript, en Julia, etc. ### Spécificités de `arrow` Le projet `arrow` présente cinq spécificités: -- Représentation des données en mémoire: `arrow` organise les données en colonnes plutôt qu'en lignes (on parle de _columnar format_). Concrètement, cela veut dire que dans la RAM toutes les valeurs de la première colonne sont stockées de façon contiguë, puis les valeurs de la deuxième colonne, etc. Cette structuration des données rend les traitements très efficaces: si l'on veut par exemple calculer la moyenne d'une variable, `arrow` va accéder directement au bloc de mémoire vive qui contient cette colonne (indépendamment des autres colonnes de la table de données), d'où un traitement très rapide. +- Représentation des données en mémoire: `arrow` organise les données en colonnes plutôt qu'en lignes (on parle de *columnar format*). Concrètement, cela veut dire que dans la RAM toutes les valeurs de la première colonne sont stockées de façon contiguë, puis les valeurs de la deuxième colonne, etc. Cette structuration des données rend les traitements très efficaces: si l'on veut par exemple calculer la moyenne d'une variable, il est possible d'accéder directement au bloc de mémoire vive qui contient cette colonne (indépendamment des autres colonnes de la table de données), d'où un traitement très rapide. -- Utilisation avec Parquet : `arrow` est souvent utilisé pour manipuler des données stockées en format Parquet. Parquet est un format de stockage orienté colonne conçu pour être très rapide en lecture (voir la fiche [Importer des fichiers Parquet](#importparquet) pour plus de détails). `arrow` est optimisé pour travailler sur des fichiers Parquet, notamment lorsqu'ils contiennent des données très volumineuses. +- Utilisation avec Parquet : `arrow` est souvent utilisé pour manipuler des données stockées en format Parquet. Parquet est un format de stockage orienté colonne conçu pour être très rapide en lecture (voir la fiche [Importer des fichiers Parquet](#importparquet) pour plus de détails). `arrow` est optimisé pour travailler sur des fichiers Parquet, notamment lorsqu'ils contiennent des données très volumineuses. -- Traitement de données volumineuses: `arrow` est conçu pour traiter des données sans avoir besoin de les charger dans la mémoire vive. Cela signifie qu'`arrow` est capable de traiter des données très volumineuses, plus grosses que la mémoire vive dont on dispose. C'est un avantage majeur en comparaison aux autres approches possibles en `R` (`data.table` et `dplyr` par exemple). +- Traitement de données volumineuses: `arrow` est conçu pour traiter des données sans avoir besoin de les charger dans la mémoire vive. Cela signifie qu'`arrow` est capable de traiter des données très volumineuses, plus grosses que la mémoire vive dont on dispose. C'est un avantage majeur en comparaison aux autres approches possibles en `R` (`data.table` et `dplyr` par exemple). -- Interopérabilité : `arrow` est conçu pour être interopérable entre plusieurs langages de programmation tels que `R`, Python, Java, C++, etc. Cela signifie que les données peuvent être échangées entre ces langages sans avoir besoin de convertir les données, d'où des gains importants de temps et de performance. +- Interopérabilité : `arrow` est conçu pour être interopérable entre plusieurs langages de programmation tels que `R`, Python, Java, C++, etc. Cela signifie que les données peuvent être échangées entre ces langages sans avoir besoin de convertir les données, d'où des gains importants de temps et de performance. -- _Lazy Evaluation_: `arrow` prend en charge la _lazy evaluation_ (évaluation différée) dans certains contextes. Cela signifie que les traitements ne sont effectivement exécutés que lorsqu'ils sont nécessaires, ce qui peut améliorer les performances en évitant le calcul de résultats intermédiaires non utilisés. +- *Lazy Evaluation*: `arrow` prend en charge la *lazy evaluation* (évaluation différée) dans certains contextes. Cela signifie que les traitements ne sont effectivement exécutés que lorsqu'ils sont nécessaires, ce qui peut améliorer les performances en évitant le calcul de résultats intermédiaires non utilisés. -### A quoi sert le _package_ `arrow`? +### A quoi sert le *package* `arrow`? -Du point de vue d'un statisticien utilisant `R`, le _package_ `arrow` permet de faire trois choses: - -- Importer des données (exemples: fichiers CSV, fichiers Parquet, stockage S3) et les stocker en mémoire vive en format `arrow`; -- Manipuler des données en format `arrow` selon la syntaxe `dplyr` ou en SQL (grâce à `duckdb`); -- Stocker des données en format Parquet. +Du point de vue d'un statisticien utilisant `R`, le *package* `arrow` permet de faire trois choses: +- Importer des données (exemples: fichiers CSV, fichiers Parquet, stockage S3) et les stocker en mémoire vive en format `arrow`; +- Manipuler des données en format `arrow` selon la syntaxe `dplyr`, ou avec le langage SQL (grâce à `duckdb`); +- Écrire des données en format Parquet. ### Quels sont les avantages d'`arrow`? -En pratique, le _package_ `arrow` présente trois avantages: +En pratique, le *package* `arrow` présente trois avantages: + +- **Performances élevées**: `arrow` est très efficace et très rapide pour la manipulation de données tabulaires (nettement plus performant que `dplyr` par exemple); +- **Usage réduit des ressources**: `arrow` est conçu pour ne charger en mémoire que le minimum de données. Cela permet de réduire considérablement les besoins en mémoire, même lorsque les données sont volumineuses; +- **Facilité d'apprentissage** grâce aux approches `dplyr` et SQL: `arrow` peut être utilisé avec les verbes de `dplyr` (`select`, `mutate`, etc.) et/ou avec le langage SQL grâce à `duckdb`. Par conséquent, il n'est pas nécessaire d'apprendre une nouvelle syntaxe pour utiliser `arrow`, on peut s'appuyer sur la ou les approches que l'on maîtrise déjà. -- __Performances élevées__: `arrow` est très efficace et très rapide pour la manipulation de données tabulaires (nettement plus performant que `dplyr` par exemple); -- __Usage réduit des ressources__: `arrow` est conçu pour ne charger en mémoire que le minimum de données. Cela permet de réduire considérablement les besoins en mémoire, même lorsque les données sont volumineuses; -- __Facilité d'apprentissage__ grâce aux approches `dplyr` et SQL: `arrow` peut être utilisé avec les verbes de `dplyr` (`select`, `mutate`, etc.) et/ou avec le langage SQL grâce à `duckdb`. Par conséquent, il n'est pas nécessaire d'apprendre une nouvelle syntaxe pour utiliser `arrow`, on peut s'appuyer sur la ou les approches que l'on maîtrise déjà. +## Que faut-il savoir pour utiliser `arrow`? +Le _package_ `arrow` présente quatre caractéristiques importantes: -## Comment utiliser `arrow`? +- une structure de données spécifique: le `Arrow Table`; +- une utilisation via la syntaxe `dplyr`; +- un moteur d'exécution spécifique: `acero`; +- un mode de fonctionnement particulier: l'évaluation différée. -Pour utiliser `arrow`, il faut commencer par charger le _package_. En pratique, `arrow` s'utilise presque toujours avec `dplyr`, il est donc préférable de prendre l'habitude de charger les deux _packages_ ensemble. +### Charger et paramétrer le `arrow` + +Pour utiliser `arrow`, il faut commencer par charger le *package*. Comme `arrow` s'utilise presque toujours avec `dplyr` en pratique, il est préférable de prendre l'habitude de charger les deux *packages* ensemble. Par ailleurs, il est utile de définir systématiquement deux réglages qui sont importants pour les performances d'`arrow`: autoriser `arrow` à utiliser plusieurs processeurs en parallèle, et définir le nombre de processeurs qu'`arrow` peut utiliser. ```{r} library(arrow) library(dplyr) + +# Autoriser arrow à utiliser plusieurs processeurs en parallèle +options(arrow.use_threads = TRUE) +# Définir le nombre de processeurs qu'arrow peut utiliser +arrow::set_cpu_count(parallel::detectCores() %/% 2) ``` ### Le `data.frame` version `arrow`: le `Arrow Table` -**Le *package* `arrow` structure les données non pas dans un `data.frame` classique, mais dans un objet spécifique à `arrow`: le `Arrow Table`.** Dans un objet `Arrow Table`, les données sont organisées en colonnes plutôt qu'en lignes, conformément aux spécifications d'`arrow` (voir la présentation d'`arrow` ci-dessus). Pour convertir un `data.frame` en `Arrow Table`, il suffit d'utiliser la fonction `as_arrow_table()`. +**Le *package*`arrow` structure les données non pas dans un `data.frame` classique, mais dans un objet spécifique à `arrow`: le `Arrow Table`.** Dans un objet `Arrow Table`, les données sont organisées en colonnes plutôt qu'en lignes, conformément aux spécifications d'`arrow` (voir la présentation d'`arrow` ci-dessus). Pour convertir un `data.frame` en `Arrow Table`, il suffit d'utiliser la fonction `as_arrow_table()`. Par rapport à un `data.frame` standard ou à un `tibble`, le `Arrow Table` se distingue immédiatement sur trois points. Pour illustrer ces différences, on utilise la base permanente des équipements 2018 (table `bpe_ens_2018`), transformée en `tibble` d'une part et en `Arrow Table` d'autre part. @@ -85,7 +95,6 @@ bpe_ens_2018_arrow <- doremifasolData::bpe_ens_2018 |> as_arrow_table() Première différence: alors que les `data.frames` et les `tibbles` apparaissent dans la rubrique `Data` de l'environnement `RStudio` (cadre rouge dans la capture d'écran), les objets `Arrow Table` apparaissent dans la rubrique `Values` (cadre blanc). - ![](../pics/arrow/diff_environnement.png) Deuxième différence: alors que l'appel à un `data.frame` ou `tibble` en affiche les premières lignes, l'appel à un `Arrow Table` affiche uniquement des métadonnées (nombre de lignes et de colonnes, nom et type des colonnes). @@ -102,9 +111,8 @@ bpe_ens_2018_arrow Troisième différence: alors qu'il est possible d'afficher le contenu d'un `data.frame` ou d'un `tibble` en cliquant sur son nom dans la rubrique `Data` de l'environnement ou en utilisant la fonction `View()`, il n'est pas possible d'afficher directement le contenu d'un `Arrow Table`. Pour afficher le contenu d'un `Arrow Table`, il faut d'abord convertir le `Arrow Table` en `tibble` avec la fonction `collect()`. - ::: {.callout-conseil .icon} -Il arrive fréquemment que l'on souhaite jeter un coup d'oeil au contenu d'un `Arrow Table`. Toutefois, convertir directement un `Arrow Table` très volumineux en `tibble` pose de sérieux problèmes: temps de conversion, consommation importante de RAM, voire plantage de `R` si le `Arrow Table` est vraiment très gros. __Il est donc fortement conseillé de prendre un petit extrait du `Arrow Table` concerné et de convertir uniquement cet extrait en `tibble`.__ Voici un exemple de code qui le fait: +Il arrive fréquemment que l'on souhaite jeter un coup d'oeil au contenu d'un `Arrow Table`. Toutefois, convertir directement un `Arrow Table` très volumineux en `tibble` peut poser de sérieux problèmes: temps de conversion, consommation importante de RAM, voire plantage de `R` si le `Arrow Table` est vraiment très gros. **Il est donc fortement conseillé de prendre un petit extrait du `Arrow Table` concerné et de convertir uniquement cet extrait en `tibble`.** Voici un exemple de code qui le fait: ```{r, eval=FALSE} # Extraire les 1000 premières lignes du Arrow Table et les convertir en tibble @@ -114,26 +122,176 @@ View(extrait_bpe) ::: +### Manipuler des `Arrow Table` avec la syntaxe `dplyr` +__Le _package_ `R` `arrow` a été écrit de façon à ce qu'un `Arrow Table` puisse être manipulé avec les fonctions de `dplyr` (`select`, `filter`, `mutate`, `left_join`, etc.), comme s'il cette table était un `data.frame` ou `tibble` standard.__ Il est également possible d'utiliser sur un `Arrow Table` un certain nombre de fonctions des _packages_ du `tidyverse` (comme `stringr` et `lubridate`). Cela s'avère très commode en pratique, car lorsqu'on sait utiliser `dplyr` et le `tidyverse`, on peut commencer à utiliser `arrow` sans avoir à apprendre une nouvelle syntaxe de manipulation de données. -- la différence entre grammaire de traitement et moteur d'exécution; -- lazy evaluation avec arrow; -- La différence compute()/collect(); -- la différence entre charger les données avec `read_parquet` et `open_dataset`; -- La liste des fonctions connues par Acero; -- les fonctions définies par l'utilisateur (utilisation avancée) -- il est essentiel de rester en ArrowTable si on manipule des données volumineuses; -- l'interface arrow/duckdb -- l'utilisation de `duckdb` en plain SQL ou via `dbplyr`; +Voici un exemple dans lequel on calcule le nombre d'équipements par région, à partir d'un `tibble` et à partir d'un `Arrow table`. La seule différence apparente entre les deux traitement est la présence de la fonction `collect()` à la fin des instructions; cette fonction indique que l'on souhaite que le résultat du traitement soit stocké sous la forme d'un `tibble`. La raison d'être de ce `collect()` est expliqué plus loin, dans le paragraphe sur l'évaluation différée. +
+ + + + + + + + +
Manipulation d'un `tibble`Manipulation d'un `Arrow Table`
+```{r eval=FALSE,message=FALSE} +bpe_ens_2018_tbl |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) +``` + +```{r eval=FALSE,message=FALSE} +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) |> + collect() +``` +
-### Introduction +
-## Pour en savoir plus {#RessourcesArrow} -- la doc [`arrow`](xxx) ; -- la doc [`duckdb`](xxx) ; -- diverses ressources à citer. +### Le moteur d'exécution d'`arrow`: `acero` + +Il y a une différence fondamentale entre manipuler un `data.frame` ou un `tibble` et manipuler un `Arrow Table`, qui porte sur la __distinction entre syntaxe de manipulation des données et moteur d'exécution__. La syntaxe de manipulation des données sert à décrire décrire les manipulations de données qu'on veut faire (calculer des moyennes, faire des jointures...), indépendamment de la façon dont ces calculs sont effectivement réalisés. Inversement, le moteur d'exécution fait référence à la façon dont les opérations sur les données sont effectivement réalisées en mémoire, indépendamment de la façon dont elles ont été décrites par l'utilisateur. + +__La grande différence entre manipuler un `tibble` et manipuler un `Arrow Table` tient au moteur d'exécution__: si on manipule un `tibble` avec la syntaxe de `dplyr`, alors c'est le moteur d'exécution de `dplyr` qui fait les calculs; si on manipule un `Arrow Table` avec la syntaxe de `dplyr`, alors c'est le moteur d'exécution d'`arrow` (nommé `acero`) qui fait les calculs. C'est justement parce que le moteur d'exécution d'`arrow` est beaucoup plus efficace que celui de `dplyr` qu'`arrow` est beaucoup plus rapide. + + + + + + +__Cette différence de moteurs d'exécution a une conséquence technique importante__: une fois que l'utilisateur a défini des instructions avec la syntaxe `dplyr`, il est nécessaire que celles-ci soient converties pour que le moteur `acero` (implémenté en C++ et non en `R`) puissent les exécuter. De façon générale, `arrow` fait cette conversion de façon automatique et invisible, car le _package_ `arrow` contient la traduction C++ de plusieurs centaines de fonctions du `tidyverse`. Par exemple, le _package_ `arrow` contient la traduction C++ de la fonction `filter()` de `dplyr`, ce qui fait que les instructions `filter()` sont automatiquement converties de façon invisible. La liste des fonctions du _tidyverse_ supportés par `acero` est disponible sur [cette page](https://arrow.apache.org/docs/dev/r/reference/acero.html). Il arrive toutefois qu'on veuille utiliser une fonction non supportée par `acero`. Cette situation est décrite dans le paragraphe "Comment utiliser une fonction non supportée par `acero`". + + +### L'évaluation différée avec `arrow` (_lazy evaluation_) + +__Une caractéristique importante d'`arrow` est qu'il pratique l'évaluation différée (_lazy evaluation_): les calculs ne sont effectivement réalisés que lorsqu'ils sont nécessaires__. En pratique, cela signifie qu'`arrow` se contente de et ne fait aucun calcul tant que l'utilisateur ne le demande pas explicitement. Il existe deux fonctions pour déclencher l'évaluation d'un traitement `arrow`: `collect()` et `compute()`. Ces deux fonctions ont le même effet; la seule différence est que `collect()` renvoie le résultat du traitement sous la forme d'un `tibble`, tandis que `compute()` le renvoie sous la forme d'un `Arrow Table`. + +__L'évaluation différée permet d'améliorer les performances en évitant le calcul de résultats intermédiaires inutiles, et en optimisant les requêtes__ pour utiliser le minimum de données et le minimum de ressources. L'exemple suivant illustre l'intérêt de l'évaluation différée dans un cas simple. + + +```{r, message=FALSE} +# Étape 1: compter les équipements par département +equipements_par_departement <- bpe_ens_2018_arrow |> + group_by(DEP) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) + +# Étape 2: filtrer sur le département +equipements_par_departement |> filter(DEP == "59") |> collect() +``` + + +Dans cet exemple, on procède à un traitement en deux temps: on compte les équipements par département, puis on filtre sur le département. Il est important de souligner que la première étape ne réalise aucun calcul par elle-même, car elle ne comprend ni `collect()` ni `compute()`. L'objet `equipements_par_departement` n'est pas une table et ne contient pas de données, il contient simplement la requête (_query_) à appliquer à la table `bpe_ens_2018_arrow`. + +On pourrait penser que, lorsqu'on exécute l'ensemble de ce traitement, `arrow` se contente d'exécuter les instructions les unes après les autres: compter les équipements par département, puis conserver uniquement le département 59. Mais en réalité `arrow` fait beaucoup mieux que cela: __`arrow` analyse la requête avant de l'exécuter, et optimise le traitement pour minimiser le travail__. Dans le cas présent, `arrow` repère que la requête ne porte en fait que sur le département 59, et commence donc par filtrer les données sur le département avant de compter les équipements, de façon à ne conserver que le minimum de données nécessaires et à ne réaliser que le minimum de calculs. Ce type d'optimisation s'avère très utile quand les données à traiter sont très volumineuses. + +## Comment bien utiliser `arrow`? +### Savoir bien utiliser l'évaluation différée + +la différence entre charger les données avec `read_parquet` et `open_dataset`; + +### Utiliser des objets `Arrow Table` plutôt que des `tibble` + + + +il est essentiel de rester en ArrowTable avec compute() si on manipule des données volumineuses; + +### Comment utiliser une fonction non supportée par `acero` + + + +### Utiliser une fonction définie par l'utilisateur (utilisation avancée) + + + + + +
+ + + + + + + + + + + + + + + + + + +
Code exécuté dans `R`Signification
+```{r eval=FALSE,message=FALSE} +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) +``` +Définir une requête calculant le nombre total d'équipements par région (sans l'exécuter)
+```{r eval=FALSE,message=FALSE} +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) |> + compute() +``` +Calculer le nombre total d'équipements par région et renvoyer les résultats dans un `Arrow Table`
+```{r eval=FALSE,message=FALSE} +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) |> + collect() +``` +Calculer le nombre total d'équipements par région et renvoyer les résultats dans un `tibble`
+ +
+ +```{r} +# Définir une requête calculant le nombre total d'équipements par région (sans l'exécuter) +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) + +# Calculer le nombre total d'équipements par région et renvoyer un Arrow Table +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) |> + compute() + +# Calculer le nombre total d'équipements par région et renvoyer un tibble +bpe_ens_2018_arrow |> + group_by(REG) |> + summarise(NB_EQUIP_TOT = sum(NB_EQUIP)) |> + collect() + +``` + +::: + +## Plan de la fiche + +- FAIT lazy evaluation avec arrow; +- FAIT La différence compute()/collect(); +- la différence entre charger les données avec `read_parquet` et `open_dataset`; +- FAIT La liste des fonctions connues par Acero; +- les fonctions définies par l'utilisateur (utilisation avancée) +- il est essentiel de rester en ArrowTable avec compute() si on manipule des données volumineuses; +- l'interface arrow/duckdb +- l'utilisation de `duckdb` en plain SQL ou via `dbplyr`; + +## Pour en savoir plus {#RessourcesArrow} +- la doc [`arrow`](xxx) ; +- la doc [`duckdb`](xxx) ; +- diverses ressources à citer.