Discussion :

[NeXiLeN]

​Bonjour,

Je réalise actuellement des analyses de données grand volume avec le logiciel R. Pour ce faire j'utilise un package en R pour stocker les données physiquement (package FF). Il faut savoir que le fichier (en CSV) fait pas loin de 5GB sur le système.

Je souhaite étudier ces données afin de construire un arbre décisionnel. La fonction de calcul utilisée est RPART, la seule qui soit aussi « flexible » pour faire ce genre de calcul. Elle fonctionne pour des plus petits jeux de données (30 000 Lignes x 17 000 Colonnes). Là pour 50 000 L x 20 000 C ,après processing, elle me remonte l'erreur suivante :

Error: cannot allocate vector of size 1.8 Gb

Alors que ma configuration système va plus loin que ça (8 GB) et que R est correctement configuré :

memory.limit() = 8078 Mb

Le problème est que lorsque je lance la fonction RPART qui va créer un arbre décisionnel en fonction des données. Il utilise les données stockées physiquement, mais créé l'arbre « dans l'interface » R, donc sur la RAM. Par conséquent sa construction sature la mémoire, d'où l'erreur qui intervient apparemment lorsque l'arbre dépasse 1.8 Gb. Je n'ai pas réussi à trouver de fonction/package sous R permettant de contrer ce problème.



Je souhaitais donc savoir si quelqu'un aurait une idée pour résoudre ce problème, ou bien connaissance de personnes le pouvant ?



Merci d'avance pour vos réponses.

[dev_ggy]

Bonjour,

Je ne suis pas un expert de la question, mais le package bigmemory, ff, ffm ou mmap qui d'après ce que je comprends permet de travailler sur le disque. Le problème que tu risques de rencontrer est lié comme tu le dis, aux calcules de la fonction RPART qui semble ne pas être implémentée avec ce type de libraire et je doute qu'il utilise des types abstraits de donner qui permettrais de palier a cela.

Personnellement, pour résoudre ce problème je sortirais de R pour utiliser Spark.

Je serais ravi de connaitre tes conclusions sur le sujet.

Cordialement.

[NeXiLeN]

Effectivement, les packages que tu sites sont très efficaces mais ne permettent que des choses "basiques" en terme de gestion des données. Je pensais qu'il existait peut être un package permettant d'indiquer à R d'utiliser l'espace disque plutôt que la RAM, mais cela ne semble pas être le cas. Les trois pistes potentielles sont:

- Utiliser le package RMR et la fonction MapReduce, voir même de pluguer tout ca avec Hadoop. C'est la piste que je suis, même si pour moi c'est un peu sortir la grosse artillerie pour pas grand chose au final.

- Implémenter (ou modifier) une nouvelle fonction RPART stockant les données sur l'espace disque et non la RAM.

- Utiliser Python ou Spark qui seront apparemment plus apte pour ce genre de problèmes.

Je ne manquerai pas d'indiquer la solution, si tenté que je la trouve ^^

[juliatheric]

Bonjour,

On peut diviser le problème en deux sous-problèmes.

1- Configuration matérielle et logicielle.
Pour ce genre de question, il est vraiment indispensable d'indiquer quelles étaient les sorties de sessionInfo() juste après le moment où l'erreur était survenue. Du premier post, comme il est question de memory.limit(), on peut déjà déduire que l'OS est Windows. Il reste à savoir si c'est un 32 ou un 64 bits et quelle est la version de R installée, là aussi, en indiquant également si le binaire de R était 32 ou 64 bits. Cela car la gestion de la mémoire dépend fortement de l'espace d'adressage que permet l'OS, voir help(Memory-limits).
Une autre information qui pourrait être très utile : relancer les traitements qui plantent (encapsulés dans une fonction) et juste après le crash, lancer traceback(). Comme ça, on aura une idée moins floue d'où venait le problème.

2- Conception de l'analyse statistique.
À part les dimensions du jeu de données (50 000 L x 20 000 C), quelques autres informations pourraient être utiles. Y'a-t-il beaucoup de valeurs manquantes ? Y'a-t-il des variables binaires, dans lequel cas des méthodes comme kNN pourraient faire l'affaire ? Quel est la formule, rpart(formula = ...), utilisée ?

EDIT : help("Memory-limits") plutôt que help(Memory-limits)

[NeXiLeN]

Bonjour,

Tout d'abord merci pour cette réponse.

1 - Configuration du système:

sessionInfo()

R version 3.2.2 (2015-08-14)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

Lors de cette erreur j'avais 8Gb de RAM. Je suis maintenant à 14Gb et l'erreur n'est plus " cannot allocate vector of size 1.8 Gb" mais " cannot allocate vector of size 3.4 Gb". Par conséquent avoir plus de RAM aide à "améliorer" la résolution du problème mais ne résout pas tout. Sachant que je n'utilise pas les 10Gb restants.

traceback()

2: rpart.matrix(m)
1: rpart(Cst_Ata ~ ., data = Cst_Data, cp = 0)



2 - Les données

Aucune valeurs manquantes. Matrice de type "Logical", uniquement des True et False.
La fonction/package knnflex ne semble plus disponible sous R?
L'appel a la fonction est la suivante: tree <- rpart( Cst_Ata ~. , data = Cst_Data, cp=0)
La matrice complète est utilisée pour prédire les classes.

[juliatheric]

Bonjour,

Configuration du système.

Disclaimer. Pas de Windows tout près pour vérifier tous les détails.

Alors, l'OS est un 64 bits, ce qui élimine déjà une classe de soucis. Mais comme le processus R est toujours bridé, il y aurait un problème persistant d'adressage. En principe, un processus 64 bits (le processus, pas l'OS) ne devrait pas être autant bridé sur un Windows 7 ; voir https://msdn.microsoft.com/en-us/library/aa366778.aspx où la section "Memory and Address Space Limits" dit ceci :
Memory type : User-mode virtual address space for each 64-bit process
Limit in 64-bit Windows : x64: 8 TB
Quant à R, ?"Memory-limits" dit :
"There is a limit on the (user) address space of a single process such as the R executable. This is system-specific, and can depend on the executable."
Donc, ni Windows ni R vous cantonnent à 3.4 Gb, théoriquement vous avez jusqu'à 8 TB, c'est votre matériel qui pourrait être en cause.

Mais il y a une petite subtilité pour le processus R sous Windows. Comme vous avez un OS 64 bits, vous avez deux exécutables qui sont par défaut installés, à moins que vous n'ayez modifié les options par défaut ; l'un est un 32 bits, l'autre 64 bits. Assurez-vous que vous avez lancé le dernier pour faire vos traitements ("C(ou D,E,etc):\...\R\bin\..." =>> choisir le bon exécutable). Voir https://cran.rstudio.com/bin/windows...README.R-3.2.2 pour plus de détails.

Pour vérifier quelle est l'adressage d'un processus en cours d'exécution, voir le gestionnaire des tâches ou Process Explorer dans https://technet.microsoft.com/en-us/sysinternals
Pour tenter de forcer l'OS à allouer plus de mémoire à un processus, voir http://blogs.technet.com/b/markrussi...1/3092070.aspx


Analyse statistique
Il y a déjà une première bonne nouvelle : il n'y a pas de formule (dans le sens de ?stats::formula) car elle aurait été très pénalisante dans ce cas-ci (taille du jeu de données élevée). Il reste maintenant à exploiter ?"rpart::rpart.control" ; vous ne lui avez donné qu'un seul argument (cp) mais essayez de jouer sur ces paramètres :

• cp : choisir une valeur non-nulle ;
• minsplit : par défaut, c'est 20 ; essayez de l'augmenter considérablement ;
• minbucket ;
• xval et maxsurrogate : pour commencer, mettez-les à 0.

Pour plus de détails, voir aussi vignette(topic = "longintro", package = "rpart") dans la sixième section (Further options).

Dans les logs du crash, on remarque que celui-ci est survenu très tôt (voir https://github.com/cran/rpart/blob/master/R/rpart.R), ce n'est pas donc la peine d'aller dans d'autres considérations statistiques.

Si tout ce qui précède ne donne rien, indiquer les sorties de str(Cst_Data) mais aussi donner des logs plus détaillés (http://adv-r.had.co.nz/Exceptions-Debugging.html).

P.S. kNN était pour "k-nearest neighbour" et il y a énormément de packages qui font ça en R.