Analyser les performances des ordinateurs sur des méthodes statistiques avec Big Data , nous pouvons simplement générer des données aléatoires et mesurer les performances à cet égard, non? Eh bien, il se peut que les données simulées ne fonctionnent pas comme des données réelles. Découvrons-le.
Régression logistique
Supposons que nous procédons à une analyse comparative de la régression logistique. Nous créons donc des régresseurs sous forme d’uniforme aléatoire et créons une réponse catégorique qui est affectée par les régresseurs. Nous utilisons un million de lignes. Voici un exemple de script pour le faire:
dt = newTable ("BenchmarkLogistic.jmp");
dt <
dt <
dt <
dt <
dt <
Si (RandomUniform () <1 / (1 + Exp (- (: X1-X2 + X3))), "Y", "N")));
Maintenant, nous courons Fit Model dans JMP et le chronométrer.
startTime = TickSeconds ();
Modèle ajusté (
Y (: YCat),
Effets (: X1,: X2,: X3),
Personnalité (logistique nominale),
Exécuter (tests du rapport de probabilité (1), tests de Wald (0))
)
firstTime = TickSeconds () - startTime; show (première fois);
Sur ma machine, cela fonctionne dans 6,53 secondes . Pas mal pour un million de lignes.
Je voulais transférer ces données sur un autre système afin de les comparer, mais il était gênant d'avoir toutes ces décimales dans les nombres uniformes aléatoires. Le repère devrait fonctionner aussi bien si je les arrondis à une décimale. J'ai donc modifié mon script de générateur de données en ajoutant une fonction Arrondi.
dt = newTable ("BenchmarkLogistic2.jmp");
dt <
dt <
dt <
dt <
dt <
Si (RandomUniform () <1 / (1 + Exp (- (: X1-X2 + X3))), "Y", "N")));
Maintenant, je lance la même régression logistique avec la même chose, à l'exception de l'arrondi, et il faut 1 seconde . Oui, ça coule six fois plus vite en utilisant des données arrondies!
Est-ce que la machine doit travailler plus fort en arithmétique avec plus de décimales? Bien sûr que non. Il n'utilise même pas d'arithmétique décimale. Il est converti en binaire et les bits s’étendent aussi loin que pour les données non arrondies.
Alors, qu'est-ce qui explique le mystère?
Eh bien, il s'avère qu'avec seulement 11 valeurs possibles pour chaque X, puisqu'il y a trois X, il n'y a que 1 331 combinaisons uniques pour les trois variables. La plate-forme logistique comprend en fait toutes les combinaisons uniques dans les données. Et quand il y a beaucoup de correspondances, il est capable de combiner les observations et de simplement parcourir les combinaisons uniques. Ainsi, pour la logistique, la plupart des calculs ont été effectués sur 1 331 combinaisons au lieu des 1 million de lignes. Ainsi, seulement une seconde au lieu de 6,53 secondes.
Alors, quelle est la leçon pour utiliser la logistique? Même si vous avez beaucoup de données, c'est le nombre de combinaisons uniques de valeurs qui compte plus que le nombre de lignes.
Et quelle est la leçon à tirer des données simulées? Si vous vous attendez à un petit nombre de niveaux, même si la variable est continue, vous devez simuler avec ce petit nombre de valeurs uniques, au lieu d'une distribution aléatoire continue.
Maintenant, avec un petit nombre de régresseurs, il est facile de tirer parti des combinaisons uniques. Mais à mesure que le nombre de régresseurs augmente, il est de moins en moins probable que vous puissiez réduire les données en un petit nombre de combinaisons uniques.
Autres plates-formes d'adaptation
Est-ce que les autres plates-formes d'adaptation font ce groupement? La personnalité des moindres carrés recherche également des combinaisons uniques, mais pas pour accélérer les calculs. Il doit les trouver pour le test de manque d'ajustement. Mais il s'avère que si vous avez des dizaines de millions de lignes, cela peut prendre quelques secondes pour obtenir ce test de manque d'ajustement, et le test n'est généralement pas intéressant pour les cas importants. Ainsi, pour accélérer les choses, lorsque le nombre de lignes est égal ou supérieur à 20 000, la valeur par défaut pour défaut d’ajustement est modifiée, de sorte qu’elle ne passe pas tout ce temps à faire quelque chose qui n’est habituellement pas souhaitée.
Qu'en est-il des données dans d'autres cas, tels que des arbres de décision? Cela fait-il une différence si les données simulées sont uniques ou arrondies? Oui. Lorsqu’il trie en fonction de ces valeurs X, il tire parti des égalités en les mettant de côté, de sorte qu’elles ne doivent plus être comparées - de sorte que moins vous avez de valeurs, plus le tri est rapide.
Clustering
Qu'en est-il du clustering? La manière dont les données sont générées aléatoirement pour mesurer la vitesse est-elle importante?
J'ai décidé de générer quatre ensembles de données simulées pour voir si les détails font la différence. J'ai commencé avec des données pures, indépendantes, normales et aléatoires: 10 000 lignes sur 50 colonnes. Le temps de regroupement était 28,83 secondes .
Maintenant, dans le monde réel, les données ne sont pas indépendantes. C'est corrélé. Ainsi, la prochaine exécution était le même type de données, mais transformée pour être hautement corrélée; chaque colonne avait une corrélation de 0,95 avec les autres. Le temps de regrouper qui était seulement 4,18 secondes - plus de six fois plus rapide !
Pourquoi serait-ce le cas? Il s'avère qu'avec ces corrélations, si vous prenez les composantes principales, 95% de la variation est dans la première composante principale. Donc, si vous regardez les distances entre les points - et raccourcissez la boucle de distance lorsque vous avez plus que la distance que vous compariez - alors la plupart du temps, il suffit de regarder le premier élément pour savoir qu'une certaine distance n'est pas la plus petite. Dans un cluster hiérarchique, nous faisons toujours une décomposition en valeurs singulières (SVD) des données avant de les regrouper afin que l'algorithme s'exécute plus rapidement. Le SVD est généralement beaucoup moins cher que le clustering hiérarchique, donc c'est un prix qui vaut généralement la peine d'être payé.
Mais le monde réel contient des données en bloc, sans quoi nous ne ferions pas de clustering. Cela va-t-il plus vite si les données sont en grappes naturelles plutôt que réparties plus uniformément dans l'espace? Nous avons généré un ensemble de données non corrélées mais groupées, où il y avait 100 groupes bien séparés avec 100 points dans chaque groupe. Le temps de regrouper qui était seulement 2,83 secondes . Lorsque les données sont naturellement groupées, la recherche de voisins proches est plus rapide car elle organise mieux l’espace.
Que faire si vous combinez la densité et les corrélations élevées? Dans ce cas, le temps passe à 0.98 secondes , 29 fois plus vite que lorsque nous avons commencé, même si les données étaient de la même taille et de la même distribution marginale.
|
| Aléatoire Non Corrélé |
|
28.833|
| Aléatoire Corrélé |
|
4.183|
| Grumeleux sans corrélation |
|
2,833|
| Corrompu Clumpy |
|
0,983
Maintenant que se passe-t-il si vous avez effectué ces mêmes tests dans un programme de clustering différent? Les algorithmes classiques de classification hiérarchique sont lents, prenant toujours quelque chose de proportionnel à n ^ 3 * p time. Mais avec l’utilisation de SVD par JMP et une version très rapide de la méthode de Ward, la méthode de Ward est beaucoup plus rapide que la méthode classique - bien que cela dépende de la rapidité des données, alors beaucoup plus lent.
// Aléatoire non corrélé
dtUncorr = asTable (J (10000,50, RandomNormal ()));
startTime = TickSeconds ();
dtUncorr <
timeUnCorr = TickSeconds () - startTime;
// Aléatoire Corrélé
theCorr = 0,05 * identité (50) +. 95 * j (50,50);
dtCorr = asTable (J (10000,50, RandomNormal ()) * Cholesky (theCorr) `);
startTime = TickSeconds ();
dtCorr <
timeCorr = TickSeconds () - startTime;
// Aléatoire groupé aléatoire non corrélé 100 touffes, 100 par touffe
dtClumped =
AsTable (DirectProduct (J (100,50,20 * RandomUniform ()), J (100,1,1)) + 1 1 J (10000,50, RandomNormal ()));
startTime = TickSeconds ();
dtClumped <
timeClumped = TickSeconds () - startTime;
// 100 grappes aléatoires groupées, 100 par grappe
data = DirectProduct (J (100,50,20 * RandomUniform () - 10), J (100,1,1)) + 1 1 J (10000,50, RandomNormal ());
dtClumpedCorr = AsTable (data * Cholesky (theCorr) `); données = 0;
startTime = TickSeconds ();
dtClumpedCorr <
timeClumpedCorr = TickSeconds () - startTime;
Catégoriser
Qu'en est-il des autres endroits dans JMP? Les caractéristiques des données importent-elles?
Oui. Généralement, les catégories vont plus vite s'il n'y en a pas trop. Si une catégorie compte moins de 5 000 niveaux, elle utilise des méthodes de tableau associatif pour créer des catégories et tire également parti du multithreading. Toutefois, s’il existe plus de 5 000 niveaux, et en particulier s’il en existe des millions, la charge d’allocation de mémoire devient coûteuse et il utilise plutôt des méthodes de tri.
Conclusion
Si vous devez analyser les performances d'une méthode à l'aide de données simulées, le choix des propriétés simulées importe beaucoup: il est préférable d'essayer de dupliquer les propriétés des données auxquelles vous souhaitez l'appliquer.
En bref, ça dépend ; les détails comptent.
JMP s'efforce de tirer parti des propriétés typiques des données réelles.
Remarque: Cela fait partie d'une série de billets de blog de John Sall intitulée Big Statistics. Lire tout son Big statistiques posts .
