Solve rigourously the problem of selection of huge instances

[marcboulle]

Description

Contexte

Une instance "éléphant" désigne une instance si volumineuse qu'elle ne peut pas être chargée en mémoire. Cela peut concerner une instance multi-table comportant un nombre très élevé de records secondaires, ou un grand nombre de variables calculées de type Table, par exemple.

Les instances "éléphants" sont traitées en émettant un warning utilisateur, en ne conservant que les valeurs natives de la table principale, sans aucun record secondaire, et en attribuant la valeur manquante à toutes les variables dérivées. Le traitement se poursuit alors au mieux, avec simplement des warnings pour ces rares instances "éléphants".

Il est à noter qu’en fonction de la passe de traitement de la base, les instances "éléphants" ne sont pas nécessairement les mêmes, en raison des exigences mémoire différentes. Cela ne pose généralement pas de problème, puisque l’on traite toujours les mêmes instances d’une passe à l’autre.

Problème

Dans le cas très particulier où un critère de sélection implique une variable calculée impliquant une instance "éléphant", la valeur du critère peut devenir erronée si toutes les variables dérivées ont été mises à valeur manquante. Il y a donc un risque de sélection ou de non-sélection à tort, ce qui peut entraîner des variations dans le nombre d’instances sélectionnées entre différentes passes d’analyse.

Traitement actuel

Ce problème est correctement diagnostiqué, notamment depuis le commit V11 "Improve warning in case of selection involving huge records". En cas d’incohérence dans le nombre d’individus sélectionnés à chaque passe, une erreur est levée, et le traitement est interrompu.

Suggestion

Il serait pertinent de garantir que les instances sélectionnées restent les mêmes tout au long du processus, afin de permettre la poursuite des traitements d’analyse même si la sélection peut être incorrecte en cas d’instances éléphants".

Proposition de solution

Au lieu de refaire la sélection à chaque passe, il serait envisageable de :

• Effectuer la sélection uniquement lors de la passe initiale (pour les statistiques de base cf. KWClassStats::ComputeStats, appel de CollectBasicStats),
• Collecter les index des instances sélectionnées lors de cette première passe,
• Utiliser ces index lors des passes suivantes pour les tâches d’analyse, en ignorant temporairement le critère de sélection.

Pour cela, il faudrait étendre la classe KWDatabase afin d’exploiter une liste d’index d’instances sélectionnées :

• Cette extension est proche de la fonctionnalité GetMarkedInstances (utilisée en interne pour les benchmarks),
• Mais il faudrait en changer la sémantique :
  • Utiliser un dictionnaire d’index d’instances sélectionnées plutôt qu’un vecteur, pour une meilleure scalabilité,
  • Exploiter ces index en lieu et place du critère de sélection.

Ainsi, on garantirait que les instances sélectionnées restent les mêmes tout au long du processus d’analyse, même si certaines sélections sont incorrectes.

Rapport coût/bénéfice

Cette solution est relativement propre et pas trop complexe. Mais elle nécessite un développement conséquent (beaucoup de code à écrire et à tester), et répond à un problème très rare, actuellement géré de manière raisonnable via des warnings et erreurs.

Le rapport coût/bénéfice est donc extrêmement défavorable.

Contexte technique

• Version de Khiops : V11

[marcboulle]

Suggestion: déplacer cette issue dans le repo roadmap dev, car ce n'est pas réaliste de l'implémenter