Clustering 4 variables, 139 millions de lignes de données, 30 GoSalut à tous,
Demande légèrement difficile. Un client potentiel dispose de données volumineuses et souhaite toutes les analyser.
Bien sûr, nous leur avons dit que l'échantillonnage aurait beaucoup plus de sens. Mais ils veulent encore tout analyser.
Nous leur avons également dit qu'ils auront besoin de beaucoup de RAM, ce qui signifiera l'installation du serveur. Pourtant, ils veulent savoir s'il sera possible d'analyser toutes leurs données.
Quelles suggestions avez-vous sur la façon dont nous pouvons répondre et leur fournir l'assurance que JMP fonctionnera pour eux ? Ou, si le clustering sur ce volume de données était un non-démarrage, ce serait également bon à savoir.
Les détails sur leurs données qu'ils ont fournies sont ci-dessous. Je ne voulais pas demander plus de détails à ce stade sans décider de la meilleure approche pour répondre à leur demande.
Nous voulons exécuter le cluster pour 10 mois de données pour le volume total comme ci-dessous :
Nombre de lignes : 138734720 (138,7 Millions de lignes)
Nombre de colonnes : 4
Volume de données : 30 Go
(Copier @MarcoSalfi car je serai absent du bureau après aujourd'hui.)
Merci!
Phil
Re : Clustering 4 variables, 139 M lignes de données, 30 GoDonc - TL; DR - essayez de reporter la question jusqu'au JMP 17. Cela ressemble beaucoup à quelque chose sur lequel ils travaillaient dans le cadre de la réponse aux besoins en données génomiques.
Avec quelque chose d'aussi gros dans JMP 16 - vous allez devoir le faire sur un gros cruncher. Et cela va prendre un certain temps pour faire le clustering si cela fonctionne du tout.Il semble que ni K signifie ni Hierarchical ne soient multi-threads ( https://www.jmp.com/support/notes/49/280.html ) afin qu'ils ne tirent aucun avantage d'un nombre élevé de processeurs.
Certaines choses qu'ils pourraient essayer pourraient être :
- Assurez-vous que toutes les données sont numériques et qu'elles sont compressées (c'est-à-dire exécutez Cols> Utilitaires> Compresser les colonnes sélectionnées sur tout).
- Les données catégorielles doivent être encodées à l'aide d'étiquettes à coder
- Essayez de reformuler les données. S'il y a un domaine temporel (ou quelque chose comme le temps), pouvez-vous le diviser de manière logique afin que FDE puisse être utilisé pour simplement l'ensemble de données, puis se regrouper sur les FPC? Cela serait utile pour les traces de capteurs, etc.
Meilleur,
M
Re : Clustering 4 variables, 139 M lignes de données, 30 GoSur un plan plus pratique, qu'essayent-ils de faire en regroupant des millions de lignes de 100 avec seulement 4 variables (ou est-ce 3 et la colonne 4 est un exemple de colonne d'ID). Cherchent-ils des modèles dans les rangées afin de pouvoir les regrouper ? Peut-être y a-t-il plus de variables cachées dans les lignes qui devraient être divisées en colonnes (comme l'heure/la date). Regrouper autant de lignes ne semble pas produire de valeur ou d'informations significatives (et encore moins comment les visualiser). Si les modèles sont ce qu'ils recherchent, ils doivent probablement réduire les lignes en colonnes supplémentaires (facteurs) qui représentent les groupements connus.
Comme @MikeD_Anderson laissé entendre, s'il s'agit d'une analyse basée sur le temps, FDE serait préférable de rechercher des modèles dans le temps au lieu de se regrouper. Les variables d'heure/date devraient être éliminées.
Re : Clustering 4 variables, 139 M lignes de données, 30 GoJe voulais mentionner que les données de cette taille sont assez courantes en génomique et je ne considère pas que la demande du client soit aussi extrême, et je ne pense pas non plus qu'un serveur soit nécessaire.Pour le nouveau travail de performance dans 17, nous ciblons principalement des tables larges (transposition de ce que vous décrivez), mais certaines tâches comme le clustering peuvent toujours être souhaitables sous forme haute.
J'ai juste essayé de créer une table 138734720 x 4 avec des données normales aléatoires sur un PC Windows avec 128 Go de RAM et j'ai exécuté la dernière version de 17 :
- K-Means : K=100, 30 itérations prennent 20 minutes et utilisent 44 Go de RAM
- Hiérarchique : Hybrid Ward, attache les processeurs à 100 % la plupart du temps, 16 cycles prennent 3,5 heures, 80 Go de RAM
- ACP : 15 minutes
Une astuce consiste à utiliser K-Means pour enregistrer des représentants pour chaque cluster, puis les hiérarchiser.
