Les solutions basées sur R, à la fois des rapports classiques et des analyses opérationnelles, ont fait leurs preuves dans un environnement d'entreprise. Sans aucun doute, RStudio et son équipe passionnée jouent un rôle important à cet égard . Dans les produits commerciaux RStudio, vous n'avez pas à penser aux problèmes d'infrastructure, mais simplement à échanger un peu d'argent contre une solution prête à l'emploi "prête à l'emploi" et à compter sur leurs développeurs et leur support. Dans les éditions open-source, et la plupart des installations dans les entreprises russes sont comme ça, vous devez penser vous-même aux problèmes d'infrastructure.
Les solutions R ferment bien le créneau des «données moyennes», quand il y a «un peu plus» de données que ce qui rentre dans Excel ou un système relationnel non configuré et des algorithmes et traitements complexes sont nécessaires, mais quand il est encore trop tôt pour déployer le «lancement complexe "de grandes dates, nos tâches sont toujours dans l'orbite de la Terre. Nous parlons de dizaines à centaines de téraoctets au total, qui peuvent facilement s'intégrer dans le backend de Clikhouse . Un point important: tout est dans un circuit interne, dans la très grande majorité des cas, TOTALEMENT coupé d'Internet.
Poursuivant une série de publications antérieures , raffine les blocs de construction pour une entreprise robuste R application .
Problématique
Pour une solution productive, vous devez garantir des résultats et des calculs reproductibles. Le problème de la reproductibilité est divisé en plusieurs directions différentes. Les gros blocs peuvent être distingués:
reproductibilité infrastructurelle. De nombreuses questions sont fermées avec une combinaison de technologies docker + renv + git.
reproductibilité du logiciel. De nombreuses questions sont fermées par la technologie des packages et des autotests.
«similitude» statistique des résultats. C'est là qu'intervient la spécificité de chaque tâche individuelle. Quelques points sont suggérés ci-dessous pour le garantir.
Quelle est la difficulté?
Algorithmes "mis en production"
peut être multiphase avec un temps de calcul cumulé de plusieurs heures;
«» ( , excel , ..);
, ;
;
.
, ;
, . .
( ) , . , . , prod (), dev .
, . , , . , . . , (availability) X% $Y. .
. , .
, .
. .
.
data.frame
, «» , .
, :
warning
message
, . , .
, .Rds
(1-1000 Ram) . 3 :
-- . , , .. .
:
, . Win-Vector.
pipe (%>%
). . - ( «» « », ), . , , .
.
:
tidylog. ,
tidylog
tidyverse
,dpylr::mutate
.
-
, :
«Debugging with RStudio by Jonathan McPherson»
«Advanced R», . «Debugging»
(shiny )?
browser()
. IDE. . -- . .
debug()
/undebug()
/debugonce()
. , .., .
traceback()
. .
options(datatable.verbose = TRUE)
.data.table
( , , ).
utils::getFromNamespace
. .
-
pryr::object_size()
. «» .
reprex
. .
gginnards
. ggplot.
browser()
, data.table
.
library(data.table)
library(magrittr)
dt <- as.data.table(mtcars) %>%
.[, {m <- head(.SD, 2); print(ls()); browser(); m}, by = gear]
#> [1] "-.POSIXt" "am" "carb" "Cfastmean" "cyl" "disp"
#> [7] "drat" "gear" "hp" "m" "mpg" "print"
#> [13] "qsec" "strptime" "vs" "wt"
#> Called from: `[.data.table`(., , {
#> m <- head(.SD, 2)
#> print(ls())
#> browser()
#> m
#> }, by = gear)
. ( ) , .
-
-
system.time({…})
-
-
.
? . , , .
-
Dans les problèmes pratiques, il peut y avoir toutes sortes de surprises, la magie des bigdata n'aide pas toujours, nous lisons le détective ironique "Utiliser AWK et R pour analyser 25tb"
Publication précédente - "Comment apprivoiser le process mining avec R dans une entreprise?" ...