Xgboost: Informatique distribuée avec Dask

@mrocklin Je pensais que Dask avait des intégrations avec sklearn. Avez-vous jeté un coup d'œil à notre wrapper sklearn pour voir si cela fonctionnera avec cela ?

Une intégration significative avec un système distribué doit généralement être effectuée au niveau de l'algorithme plutôt qu'au niveau de la bibliothèque. SKLearn et Dask peuvent s'entraider de certaines manières, oui, mais elles ne sont pas particulièrement profondes.

La trame de données Dask serait un bon début. Dans notre base de code, nous avons une vérification de la trame de données pandas. C'est peut-être là que la trame de données dask conviendrait comme point de départ.

Alors que se passe-t-il si quelqu'un arrive avec une trame de données dask de plusieurs téraoctets ? Le convertissez-vous simplement en Pandas et continuez? Ou existe-t-il un moyen de paralléliser XGBoost intelligemment sur un cluster, en pointant vers les différentes trames de données pandas qui composent une trame de données dask ?

Les utilisateurs peuvent spécifier la taille du lot ? J'imagine que les utilisateurs peuvent bénéficier de partial_fit.

cc @tqchen qui connaît mieux la partie distribuée du code.

La version distribuée de xgboost peut être accrochée à un lanceur de tâches distribué, idéalement obtenir un flux de partition de données dans xgboost puis continuer.

@mrocklin Je pense que la partie la plus pertinente est le module xgboost-spark et xgboost-flink, qui intègre xgboost dans la fonction mapPartition de spark/flink. Je suppose qu'il y aurait quelque chose de similaire dans Dask

L'exigence du côté xgboost est que XGBoost gère la connexion inter-processus par rabit, et devra démarrer un tracker (qui connecte chaque travail) du côté client.

voir le code pertinent dans https://github.com/dmlc/xgboost/blob/master/jvm-packages/xgboost4j-spark/src/main/scala/ml/dmlc/xgboost4j/scala/spark/XGBoost.scala#L112

Rabit est conçu pour être intégré dans un autre système distribué, donc je pense qu'il ne sera peut-être pas trop difficile de faire l'ajustement côté python.

Lancer d'autres systèmes distribués à partir de Dask est généralement assez faisable. Comment déplacez-vous les données du système distribué d'hébergement (spark/flink/dask) vers xg-boost ? Ou est-ce pour une formation distribuée sur les petites données ?

Plus concrètement, je prévois de construire un système comme suit :

• Sur chaque dask worker, je démarre un serveur Rabit. Dask donne à ces serveurs Rabit suffisamment d'informations pour se retrouver.
• Je crée un état XGBoost local sur chaque travailleur qui représente le modèle en cours de formation
• Je nourris à plusieurs reprises cet objet par travailleur pandas dataframes ou numpy arrays
• J'écoute un signal de XGBoost qui me dit d'arrêter

Cela correspond-il à votre attente ? Est-il facile pour vous de m'indiquer l'API Python pertinente ?

Oui, voir les informations pertinentes ici https://github.com/dmlc/xgboost/blob/master/tests/distributed/ pour l'API python.

Ce que vous devrez faire en plus, c'est démarrer un tracker rabit côté conducteur (probablement l'endroit qui pilote dask), cela se fait dans le script dmlc-submit ici https://github.com/dmlc/dmlc-core /tree/master/tracker/dmlc_tracker

OK, je remplis mon plan d'avant :

Avant d'exécuter un code XGBoost, nous avons mis en place un réseau Rabit

Sur le nœud conducteur/planificateur, nous démarrons un traqueur de rabit

envs = {'DMLC_NUM_WORKER' : nworker,
        'DMLC_NUM_SERVER' : nserver}

rabit = RabitTracker(hostIP=ip_address, nslave=num_workers)
envs.update(rabit.slave_envs())
rabit.start(args.num_workers)  # manages connections in background thread

Je peux également passer par un processus similaire pour démarrer un PSTracker . Cela devrait-il être sur la même machine centralisée ou devrait-il être ailleurs dans le réseau ? Devrait-il y en avoir quelques-uns? Cela devrait-il être configurable par l'utilisateur ?

Finalement, mon tracker (et mes pstrackers ?) rejoint le réseau rabit et le bloque.

rabit.join()  # join network

Sur les nœuds de travail, je dois vider ces variables d'environnement (que je déplacerai via les canaux dask normaux) dans l'environnement local. Alors juste appeler xgboost.rabit.init() devrait suffire

import os
os.environ.update(envs)
xgboost.rabit.init()

En regardant le code Rabit, il semble que les variables d'environnement soient le seul moyen de fournir ces informations. Pouvez-vous vérifier cela ? Existe-t-il un moyen de fournir des informations sur l'hôte/le port du tracker en tant qu'entrées directes ?

Formation

Ensuite, je convertis mes tableaux numpy / pandas dataframes / scipy sparse arrays en objets DMatrix, cela semble relativement simple. Cependant, je suis susceptible d'avoir plusieurs lots de données par travailleur. Existe-t-il un moyen propre d'appeler le train plusieurs fois avec plus de données dès qu'elles sont disponibles ? Je suis préoccupé par les commentaires sur ces lignes:

# Run training, all the features in training API is available.
# Currently, this script only support calling train once for fault recovery purpose.
bst = xgb.train(param, dtrain, num_round, watchlist, early_stopping_rounds=2)

Doit-on attendre que toutes les données arrivent avant de commencer l'entraînement ?

Exemple de jeu de données / problème

En supposant que tout ce qui précède est correct, existe-t-il un exemple standard de formation distribuée que les gens utilisent pour la démonstration ?

Il n'est pas nécessaire de démarrer ptracker.

• Tracker n'a besoin d'être démarré qu'à un seul endroit, probablement sur le planificateur (pilote), il n'a pas de travail lourd en données et ne sert qu'à connecter les travaux.
• Les arguments env peuvent être passés en tant que kwargs dans rabit.init
• Étant donné que l'amélioration de l'arbre est un algorithme par lots, nous devons attendre que toutes les données soient ingérées avant de commencer l'entraînement.
  
  
  
  • Notez cependant que chaque travailleur n'a besoin de prendre qu'un fragment (sous-ensemble de lignes) de données.
  
  
  • Idéalement, nous devrions utiliser l'interface d'itération de données pour transmettre les données à DMatrix sous forme de mini-lot, de sorte que l'ensemble de données complet n'ait pas à rester en mémoire.
  
  
  • Cela se fait via https://github.com/dmlc/xgboost/blob/master/include/xgboost/c_api.h#L117 , qui n'ont pas encore de wrapper python.
  
  
  • Pour la première solution, je recommanderais de passer directement par array
  
  

J'ai eu un peu de temps pour jouer avec ça ce matin. Résultats ici : https://github.com/mrocklin/dask-xgboost

Jusqu'à présent, il ne gère que l'apprentissage distribué d'un seul ensemble de données en mémoire. Quelques questions se sont posées :

1. Quelle est la meilleure façon de sérialiser et de faire circuler des objets DMatrix ?
2. Quelle est la meilleure façon de sérialiser et de renvoyer un résultat Booster ?
3. Comment les variables d'environnement répertoriées ci-dessus correspondent-elles aux arguments dans rabit.init ? Quelle est précisément la forme attendue des entrées de rabit.init ? Passer le résultat de slave_envs() à rabit.init ne fonctionnera évidemment pas car il attend une liste. Devrions-nous convertir chaque nom de clé en --key , en supprimant peut-être le préfixe DMLC et en le convertissant en minuscules ?
4. Existe-t-il un bon moyen de tester l'exactitude? Comment comparer deux objets Booster ? Doit-on s'attendre à ce que la formation distribuée produise exactement le même résultat et la formation séquentielle ?

• Normalement, vous ne sérialisez pas DMatrix, cela ressemble plus à un détenteur de données de temps de formation, je suppose que les données sont transmises et partagées par dask (tableau/dataframe), puis transmises à xgboost
  
  
  
  • Nous pouvons explorer de meilleures façons de transmettre des données autrement que directement via un tableau en mémoire, éventuellement en exposant un itérateur de données à xgboost
  
  
• Vous pouvez décaper Booster, tant que xgboost est installé des deux côtés.
• Désolé de ne pas avoir expliqué comment les choses sont passées, ça devrait être

rabit.init(['DMLC_KEY1=VALUE1', 'DMLC_KEY2=VALUE2']

• Normalement, le booster formé à partir d'une machine distribuée et d'une seule machine n'est pas le même, mais voici quelques points à vérifier
  
  
  
  • Le rappel renvoyé par tous les travailleurs doit être identique
  
  
  • À la recherche de l'erreur de validation prédictive, elle devrait être à peu près aussi faible que le cas d'une seule machine
  
  

Deux autres questions généralement sur la façon dont cela est utilisé (je n'ai aucune expérience avec XGBoost et seulement une petite expérience avec l'apprentissage automatique, veuillez pardonner mon ignorance).

1. Est-il raisonnable d'utiliser plusieurs travailleurs sur les mêmes données d'entrée ? (XGBoost est lié au calcul ?)
2. Si nous opérons sur des ensembles de données plus volumineux, dois-je faire quelque chose de spécial pour dire à chaque travailleur XGBoost que ses données diffèrent de celles de ses pairs ?

Quel cas d'utilisation est le plus courant ?

Chaque travail doit fonctionner sur une partition de données différente (par lignes), ils ne doivent PAS regarder les mêmes données d'entrée.

• Si les données ne sont pas assez volumineuses, une version multithread devrait suffire
• Chaque travail collectera des statistiques séparément sur sa partition et se synchronisera les uns avec les autres

Cela correspond normalement à l'opération mapPartition dans des frameworks comme spark/flink

Disons que mon ensemble de données a 8 lignes, 4 colonnes, si nous commençons deux travailleurs

• travailleur 0 lit à partir de la ligne 0-3
• travailleur 1 lit de la ligne 4 à 7

OK, ce qu'il y a maintenant est un peu plus propre. Ce serait bien si nous avions la possibilité de consommer les résultats tels qu'ils ont été générés sur chaque travailleur, mais nous avons travaillé autour de cela pour l'instant. Voici la solution actuelle :

1. Persistez le tableau dask ou la trame de données sur le cluster, attendez qu'il se termine
2. Trouver où chaque morceau/partition s'est terminé
3. Dites à chaque travailleur de concaténer exactement ces morceaux/partitions et de s'entraîner sur eux

Cette solution semble gérable, mais n'est pas idéale. Ce serait pratique si xgboost-python pouvait accepter les résultats au fur et à mesure qu'ils arrivaient. Cependant, je pense que la prochaine chose à faire est de l'essayer dans la pratique.

Je vais chercher sur internet des exemples. Si quelqu'un a un problème artificiel que je peux facilement générer avec l'API numpy ou pandas, ce serait le bienvenu. En attendant, voici un exemple trivial sur mon ordinateur portable avec des données aléatoires :

In [1]: import dask.dataframe as dd

In [2]: df = dd.demo.make_timeseries('2000', '2001', {'x': float, 'y': float, 'z': int}, freq='1s', partition_freq=
   ...: '1D')  # some random time series data

In [3]: df.head()
Out[3]: 
                            x         y     z
2000-01-01 00:00:00  0.778864  0.824796   977
2000-01-01 00:00:01 -0.019888 -0.173454  1023
2000-01-01 00:00:02  0.552826  0.051995  1083
2000-01-01 00:00:03 -0.761811  0.780124   959
2000-01-01 00:00:04 -0.643525  0.679375   980

In [4]: labels = df.z > 1000

In [5]: del df['z']

In [6]: df.head()
Out[6]: 
                            x         y
2000-01-01 00:00:00  0.778864  0.824796
2000-01-01 00:00:01 -0.019888 -0.173454
2000-01-01 00:00:02  0.552826  0.051995
2000-01-01 00:00:03 -0.761811  0.780124
2000-01-01 00:00:04 -0.643525  0.679375

In [7]: labels.head()
Out[7]: 
2000-01-01 00:00:00    False
2000-01-01 00:00:01     True
2000-01-01 00:00:02     True
2000-01-01 00:00:03    False
2000-01-01 00:00:04    False
Name: z, dtype: bool

In [8]: from dask.distributed import Client

In [9]: c = Client()  # creates a local "cluster" on my laptop

In [10]: from dask_xgboost import train
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)

In [11]: param = {'max_depth': 2, 'eta': 1, 'silent': 1, 'objective': 'binary:logistic'}  # taken from example

In [12]: bst = train(c, param, df, labels)
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)
[14:46:20] Tree method is automatically selected to be 'approx' for faster speed. to use old behavior(exact greedy algorithm on single machine), set tree_method to 'exact'
[14:46:20] Tree method is automatically selected to be 'approx' for faster speed. to use old behavior(exact greedy algorithm on single machine), set tree_method to 'exact'
[14:46:20] Tree method is automatically selected to be 'approx' for faster speed. to use old behavior(exact greedy algorithm on single machine), set tree_method to 'exact'
[14:46:20] Tree method is automatically selected to be 'approx' for faster speed. to use old behavior(exact greedy algorithm on single machine), set tree_method to 'exact'

In [13]: bst
Out[13]: <xgboost.core.Booster at 0x7fbaacfd17b8>

Le code pertinent est ici si quelqu'un veut jeter un coup d'œil : https://github.com/mrocklin/dask-xgboost/blob/master/dask_xgboost/core.py

Comme je l'ai dit, je suis nouveau sur XGBoost, donc il me manque probablement des choses.

un exemple de jouet typique à essayer est dans https://github.com/dmlc/xgboost/tree/master/demo/data
Il est cependant au format libsvm et nécessite un peu d'analyse pour le mettre dans numpy

Quelque chose de plus grand (pour lequel vous auriez réellement besoin d'un cluster) ? Ou existe-t-il un moyen standard de générer un ensemble de données de taille arbitraire ?

Ou, peut-être une meilleure question est : "Qu'est-ce que vous (ou quelqu'un d'autre lisant ce numéro) aimeriez voir ici ?"

Construire prévoir maintenant. Si je ramène le modèle à un travailleur (en passant par le processus de pickle/unpickle) et que j'appelle ensuite bst.predict sur certaines données, j'obtiens l'erreur suivante :

Doing rabit call after Finalize

Mon hypothèse était qu'à ce stade, le modèle est autonome et n'a plus besoin d'utiliser rabit. Cela semble fonctionner correctement sur la machine cliente. Des idées pourquoi je pourrais recevoir cette erreur lors de l'appel predict ?

Une partie de prédire utilise encore rabit, principalement parce que le prédicteur utilise toujours l'apprenant avec certaines routines d'initialisation partagées avec la formation. Finalement, cela devrait être corrigé, mais c'est le cas pour l'instant.

Je pense que tant que cela fonctionne bien pour l'ensemble de données commun, c'est un point de départ intéressant.

Il y a de toute façon des raisons d'utiliser un cluster pour les données moyennes (facilité de planification dans l'environnement de cluster), certains utilisateurs de pyspark pourraient être intéressés à l'essayer si nous en faisons un peu la publicité

Tester sur l'ensemble de données qui compte vraiment était difficile, par exemple (essayez 1 ensemble de données avec 1 milliard de lignes). Kaggle pourrait être un grand ensemble de données qui pourrait être pertinent, soit environ 10 millions.

Ce référentiel montre des expériences sur l'ensemble de données des compagnies aériennes, qui, je pense, se compose de dizaines de millions de lignes et de dizaines de colonnes (mille après un codage à chaud?) Pour leur référence, il semble qu'ils aient pris un échantillon de 100 000 lignes et généré artificiellement ensembles de données plus grands de cet échantillon. Nous pourrions probablement augmenter cela si nécessaire.

Voici un exemple utilisant ces données avec pandas et xgboost sur un seul cœur. Toute recommandation sur la préparation des données, les paramètres ou la manière de le faire correctement serait la bienvenue.

In [1]: import pandas as pd

In [2]: df = pd.read_csv('train-0.1m.csv')

In [3]: df.head()
Out[3]: 
  Month DayofMonth DayOfWeek  DepTime UniqueCarrier Origin Dest  Distance  \
0   c-8       c-21       c-7     1934            AA    ATL  DFW       732   
1   c-4       c-20       c-3     1548            US    PIT  MCO       834   
2   c-9        c-2       c-5     1422            XE    RDU  CLE       416   
3  c-11       c-25       c-6     1015            OO    DEN  MEM       872   
4  c-10        c-7       c-6     1828            WN    MDW  OMA       423   

  dep_delayed_15min  
0                 N  
1                 N  
2                 N  
3                 N  
4                 Y  

In [4]: labels = df.dep_delayed_15min == 'Y'

In [5]: del df['dep_delayed_15min']

In [6]: df = pd.get_dummies(df)

In [7]: len(df.columns)
Out[7]: 652

In [8]: import xgboost as xgb
/home/mrocklin/Software/anaconda/lib/python3.5/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
  "This module will be removed in 0.20.", DeprecationWarning)

In [9]: dtrain = xgb.DMatrix(df, label=labels)

In [10]: param = {}  # Are there better choices for parameters?  I could use help here

In [11]: bst = xgb.train(param, dtrain)  # or other parameters here?
[17:50:28] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 124 extra nodes, 0 pruned nodes, max_depth=6
[17:50:30] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 120 extra nodes, 0 pruned nodes, max_depth=6
[17:50:32] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 120 extra nodes, 0 pruned nodes, max_depth=6
[17:50:33] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 116 extra nodes, 0 pruned nodes, max_depth=6
[17:50:35] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 112 extra nodes, 0 pruned nodes, max_depth=6
[17:50:36] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 114 extra nodes, 0 pruned nodes, max_depth=6
[17:50:38] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 106 extra nodes, 0 pruned nodes, max_depth=6
[17:50:39] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 116 extra nodes, 0 pruned nodes, max_depth=6
[17:50:41] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 104 extra nodes, 0 pruned nodes, max_depth=6
[17:50:43] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 100 extra nodes, 0 pruned nodes, max_depth=6

In [12]: test = pd.read_csv('test.csv')

In [13]: test.head()
Out[13]: 
  Month DayofMonth DayOfWeek  DepTime UniqueCarrier Origin Dest  Distance  \
0   c-7       c-25       c-3      615            YV    MRY  PHX       598   
1   c-4       c-17       c-2      739            WN    LAS  HOU      1235   
2  c-12        c-2       c-7      651            MQ    GSP  ORD       577   
3   c-3       c-25       c-7     1614            WN    BWI  MHT       377   
4   c-6        c-6       c-3     1505            UA    ORD  STL       258   

  dep_delayed_15min  
0                 N  
1                 N  
2                 N  
3                 N  
4                 Y  

In [14]: test_labels = test.dep_delayed_15min == 'Y'

In [16]: del test['dep_delayed_15min']

In [17]: test = pd.get_dummies(test)

In [18]: len(test.columns)  # oops, looks like the columns don't match up
Out[18]: 670

In [19]: dtest = xgb.DMatrix(test)

In [20]: predictions = bst.predict(dtest)  # this fails because of mismatched columns

Quoi qu'il en soit, voici une option. L'ensemble de données des compagnies aériennes semble bien connu et peut être trop volumineux dans la pratique. Encore une fois, l'apprentissage automatique n'est pas ma spécialité, donc je ne sais pas si c'est approprié ou non.

cc @TomAugspurger , qui semble être le genre de gars qui pourrait avoir des idées à ce sujet.

En ce qui concerne Dask et prédire, je peux toujours configurer à nouveau rabit. Cela semble un peu impur, car cela oblige à évaluer plutôt que de garder les choses paresseuses. Mais ce n'est pas un bloqueur sérieux à utiliser.

Vous rencontrez des problèmes avec la prévision. Deux questions:

1. Puis-je appeler Booster.predict plusieurs fois au cours de la même session de rabit ?
2. Puis-je appeler rabit.init , Booster.predict et rabit.finalize sur des threads séparés ?

Actuellement, je crée un nouveau tracker et j'appelle rabit.init sur le thread principal du travailleur. Cela fonctionne bien. Cependant, lorsque j'appelle Booster.predict dans les threads de travail (chaque travailleur dask maintient un pool de threads pour le calcul), j'obtiens des erreurs comme Doing rabit call after Finalize . Des recommandations ?

Une partie de prédire utilise encore rabit, principalement parce que le prédicteur utilise toujours l'apprenant avec certaines routines d'initialisation partagées avec la formation. Finalement, cela devrait être corrigé, mais c'est le cas pour l'instant.

Je suis curieux à ce sujet. Après avoir sérialisé-transféré-désérialisé le modèle formé d'un travailleur à ma machine cliente, il semble fonctionner correctement sur des données normales, même s'il n'y a pas de réseau rabit. Il semble qu'un modèle entraîné avec Rabit puisse être utilisé pour prédire des données sans rabit. Cela semble également être nécessaire en production. Pouvez-vous en dire plus sur les contraintes liées à l'utilisation d'un modèle entraîné par rabit ici ?

Exemple de jeu de données / problème
En supposant que tout ce qui précède est correct, existe-t-il un exemple standard de formation distribuée que les gens utilisent pour la démonstration ?

Je serais bien de reproduire les résultats de cette expérience:

https://github.com/Microsoft/LightGBM/wiki/Experiments#parallel-experiment

avec la nouvelle option binning + fast hist de XGBoost (#1950), il devrait être possible d'obtenir des résultats similaires.

un exemple de jouet typique à essayer est dans https://github.com/dmlc/xgboost/tree/master/demo/data
Il est cependant au format libsvm et nécessite un peu d'analyse pour le mettre dans numpy

Vous pourriez être intéressé par ce PR dans sklearn : https://github.com/scikit-learn/scikit-learn/pull/935

@mrocklin Il n'y a aucune contrainte sur la réutilisation du modèle. Ainsi, le modèle formé en version distribuée peut être utilisé en version série. C'est juste que la limitation actuelle du prédicteur (lorsqu'il est compilé avec rabit) a une fonction mixte avec la fonction d'entraînement (donc l'appel de rabit s'est produit).

Maintenant que vous le dites, je pense que nous pourrions avoir une solution au problème. Faites simplement un rabit.init (sans rien transmettre, et faites croire au prédicteur qu'il est le seul travailleur) avant que la prédiction ne résolve le problème

Oui. En effet cela résout le problème. dask-xgboost prend désormais en charge la prédiction : https://github.com/mrocklin/dask-xgboost/commit/827a03d96977cda8d104899c9f42f52dac446165

Merci pour la solution de contournement @tqchen !

Voici un flux de travail avec dask.dataframe et xgboost sur un petit échantillon de l'ensemble de données des compagnies aériennes sur mon ordinateur portable local. Est-ce que cela semble OK pour tout le monde ? Y a-t-il des éléments API de XGBoost qui me manquent ici ?

In [1]: import dask.dataframe as dd

In [2]: import dask_xgboost as dxgb

In [3]: df = dd.read_csv('train-0.1m.csv')

In [4]: df.head()
Out[4]: 
  Month DayofMonth DayOfWeek  DepTime UniqueCarrier Origin Dest  Distance  \
0   c-8       c-21       c-7     1934            AA    ATL  DFW       732   
1   c-4       c-20       c-3     1548            US    PIT  MCO       834   
2   c-9        c-2       c-5     1422            XE    RDU  CLE       416   
3  c-11       c-25       c-6     1015            OO    DEN  MEM       872   
4  c-10        c-7       c-6     1828            WN    MDW  OMA       423   

  dep_delayed_15min  
0                 N  
1                 N  
2                 N  
3                 N  
4                 Y  

In [5]: labels = df.dep_delayed_15min == 'Y'

In [6]: del df['dep_delayed_15min']

In [7]: df = df.categorize()

In [8]: df = dd.get_dummies(df)

In [9]: data_train, data_test = df.random_split([0.9, 0.1], random_state=123)

In [10]: labels_train, labels_test = labels.random_split([0.9, 0.1], random_state=123)

In [11]: from dask.distributed import Client

In [12]: client = Client()  # in a large-data situation I probably should have done this before calling categorize above (which requires computation)

In [13]: param = {}  # Are there better choices for parameters?

In [14]: bst = dxgb.train(client, {}, data_train, labels_train)
[14:00:46] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 120 extra nodes, 0 pruned nodes, max_depth=6
[14:00:48] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 120 extra nodes, 0 pruned nodes, max_depth=6
[14:00:50] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 122 extra nodes, 0 pruned nodes, max_depth=6
[14:00:53] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 118 extra nodes, 0 pruned nodes, max_depth=6
[14:00:55] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 120 extra nodes, 0 pruned nodes, max_depth=6
[14:00:57] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 114 extra nodes, 0 pruned nodes, max_depth=6
[14:00:59] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 118 extra nodes, 0 pruned nodes, max_depth=6
[14:01:01] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 118 extra nodes, 0 pruned nodes, max_depth=6
[14:01:04] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 94 extra nodes, 0 pruned nodes, max_depth=6
[14:01:06] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 102 extra nodes, 0 pruned nodes, max_depth=6

In [15]: bst
Out[15]: <xgboost.core.Booster at 0x7f689803af60>

In [16]: predictions = dxgb.predict(client, bst, data_test)

In [17]: predictions
Out[17]: 
Dask Series Structure:
npartitions=1
None    float32
None        ...
Name: predictions, dtype: float32
Dask Name: _predict_part, 9 tasks

Mon objectif à court terme est d'écrire un court article de blog à ce sujet afin que quelqu'un d'autre avec plus d'expérience avec XGBoost et avec plus de temps vienne adopter ce projet et le faire avancer. (Comme tout le monde ici, je travaille sur quelques autres projets comme celui-ci en même temps.)

Je suis partisan de l'ensemble de données des compagnies aériennes simplement parce que je l'ai déjà dans un compartiment S3. Je conviens cependant que l'ensemble de données Criteo permettrait une meilleure démonstration à grande échelle.

Je ne sais toujours pas quels paramètres utiliser ni comment juger du résultat. Pour les paramètres, je peux utiliser l'expérience de @szilard ici . Existe-t-il un bon moyen de juger les prédictions ? Par exemple, recherchons-nous predictions > 0.5 pour correspondre à labels_test ?

La façon la plus courante d'évaluer les performances prédictives pour la classification binaire (en particulier dans les contextes de recherche ou de compétition) consiste peut-être à utiliser l'aire sous la courbe ROC (AUC), bien que dans les applications du monde réel, il convient d'utiliser des métriques alignées sur les valeurs « métier ». réalisé à l'aide des modèles.

Par exemple, recherchons-nous des prédictions > 0,5 pour correspondre à labels_test ?

Oui. Si vous prenez la moyenne de cela sur l'ensemble de test, c'est la précision du test. Mais il est probable que le jeu de données soit déséquilibré (beaucoup plus d'absence de clic que de clics). Dans ce cas, le score ROC AUC est une meilleure mesure.

from sklearn.metrics import roc_auc_score
print(roc_auc_score(labels_test, predictions))

en supposant que predictions est un tableau 1D de probabilités positives estimées par le modèle pour chaque ligne de l'ensemble de test.

@mrocklin Une question de suivi, dask autorise-t-il les travaux de travail multithread ? Je sais que ce n'est pas très pertinent pour python à cause de GIL. Mais xgboost peut permettre une formation multithread par travailleur tout en se coordonnant les uns avec les autres de manière distribuée. Nous devons toujours définir les arguments nthread de xgboost comme étant le nombre de cœurs de travail de ce travailleur

La réponse courte est "oui". Dask est principalement utilisé avec des projets tels que NumPy, Pandas, SKLearn et d'autres qui ne sont principalement que du code C et Fortran, enveloppés de Python. Le GIL n'affecte pas ces bibliothèques. Certaines personnes utilisent Dask pour des applications similaires au PySpark RDD (voir dask.bag ) et seront affectées. Ce groupe est cependant minoritaire.

Alors oui, Dask autorise les tâches multi-thread. Comment dire à XGBoost d'utiliser plusieurs threads ? Dans mes expériences jusqu'à présent, je constate une utilisation élevée du processeur sans modifier aucun paramètre, alors peut-être que tout fonctionne bien par défaut ?

XGBoost utilise le multi-thread par défaut et utilisera tous les threads cpu disponibles sur la machine (au lieu de sur ce travailleur) si nthread n'est pas défini. Cela peut créer une condition de concurrence lorsque plusieurs travailleurs sont affectés à la même machine.

Il est donc toujours bon de définir le paramètre nthread sur le nombre maximum de cœurs que le travailleur est autorisé à utiliser. Habituellement, une bonne pratique consiste à utiliser environ 4 threads par travailleur

Bien sûr, devrait être accompli dans
https://github.com/mrocklin/dask-xgboost/commit/c22d066b67c78710d5ad99b8620edc55182adc8f

Le lundi 20 février 2017 à 18h31, Tianqi Chen [email protected]
a écrit:

XGBoost utilise le multithread par défaut et utilisera tout le processeur disponible
threads sur la machine (au lieu de sur ce travailleur) si nthread n'est pas défini.
Cela peut créer une condition de concurrence lorsque plusieurs travailleurs sont affectés au même
machine.

Il est donc toujours bon de définir le paramètre nthread sur le nombre maximum de
noyaux que le travailleur est autorisé à utiliser. Habituellement, une bonne pratique est d'utiliser autour de dire
4 fils par travailleur

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dmlc/xgboost/issues/2032#issuecomment-281205747 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AASszPELRoeIvqEzyJhkKumIs-vd0PHiks5reiJngaJpZM4L_PXa
.

Carnet : https://gist.github.com/19c89d78e34437e061876a9872f4d2df
Capture d'écran courte (six minutes) : https://youtu.be/Cc4E-PdDSro

Les commentaires critiques sont les bienvenus. Encore une fois, veuillez pardonner mon ignorance dans ce domaine.

@mrocklin super démo ! Je pense que les performances d'exécution (et éventuellement l'utilisation de la mémoire) pourraient être grandement améliorées en utilisant 'tree_method': 'hist', 'grow_policy': 'lossguide' dans le param dict.

Merci @ogrisel. Avec ces paramètres, le temps d'entraînement passe de six minutes à une minute. L'utilisation de la mémoire semble rester à peu près la même.

OK, revenons à cela. Y a-t-il des opérations XGBoost autres que former et prédire que nous devrions mettre en œuvre ?

@tqchen ou @ogrisel si l'un d'entre vous a le temps de parcourir l'implémentation sur https://github.com/mrocklin/dask-xgboost/blob/master/dask_xgboost/core.py , je vous en serais reconnaissant. Je comprends cependant que la recherche dans une base de code étrangère n'est pas toujours en tête des listes de priorités.

Si tout va bien, j'ajouterai un peu plus au README, publierai sur PyPI, et nous pourrons probablement fermer ce problème.

Je pense que seulement former et prédire doivent être distribués. D'autres choses n'ont pas à être distribuées puisqu'elles ne répondent pas sur le jeu de données

J'ai poussé dask-xgboost vers PyPI et l'ai déplacé vers https://github.com/dask/dask-xgboost

Merci @tqchen et @ogrisel pour votre aide ici. La collaboration a rendu cela relativement facile.

Je serais heureux d'aider les gens s'ils voulaient faire des benchmarks. D'ici là, fermeture.