Xgboost: Daskによる分散コンピューティング

@mrocklinDaskはsklearnと統合されていると思いました。 sklearnラッパーを見て、それが機能するかどうかを確認しましたか？

意味のある分散システムとの統合は、通常、ライブラリレベルではなく、アルゴリズムレベルで実行する必要があります。 SKLearnとDaskが互いに助け合う方法はいくつかありますが、それほど深くはありません。

Daskデータフレームは良いスタートです。 コードベースでは、パンダのデータフレームをチェックしています。 それが、daskデータフレームが出発点として適している場所かもしれません。

では、誰かが数テラバイトのdaskデータフレームを持って到着した場合はどうなるでしょうか。 それをパンダに変換して続行しますか？ または、クラスター全体でXGBoostをインテリジェントに並列化し、daskデータフレームを構成するさまざまなパンダデータフレームを指す方法はありますか？

ユーザーはバッチサイズを指定できますか？ 私は、partial_fitを通じてユーザーに利益をもたらすことができると思います。

コードの分散部分に精通しているcc @ tqchen 。

分散バージョンのxgboostは、分散ジョブランチャーにフックできます。理想的には、データパーティションフィードをxgboostに取り込み、続行します。

@mrocklin最も関連性の高い部分は、xgboostをspark / flinkのmapPartition関数に埋め込むxgboost-sparkおよびxgboost-flinkモジュールだと思います。 Daskにも似たようなものがあると思います

xgboost側からの要件は、XGBoostがプロセス間接続をラビットで処理し、クライアント側から（各ジョブを接続する）トラッカーを開始する必要があることです。

https://github.com/dmlc/xgboost/blob/master/jvm-packages/xgboost4j-spark/src/main/scala/ml/dmlc/xgboost4j/scala/spark/XGBoost.scala#L112の関連コードを参照してください

Rabitは他の分散システムに組み込まれるように設計されているので、Python側で調整するのはそれほど難しいことではないと思います。

Daskから他の分散システムを起動することは、通常、かなり実行可能です。 ホスティング分散システム（spark / flink / dask）からxg-boostにデータをどのように移動しますか？ それとも、これは小さなデータの分散トレーニング用ですか？

具体的には、次のようなシステムを構築することを期待しています。

• すべてのdaskワーカーで、Rabitサーバーを起動します。 Daskは、これらのRabitサーバーにお互いを見つけるのに十分な情報を提供します。
• 現在のトレーニングモデルを表すすべてのワーカーにローカルXGBoost状態を作成します
• このワーカーごとのオブジェクトをパンダのデータフレームまたはnumpy配列に繰り返しフィードします
• XGBoostから停止するように指示する信号を聞きます

これはあなたの期待と一致しますか？ 関連するPythonAPIを紹介するのは簡単ですか？

はい、Python APIについては、 https：//github.com/dmlc/xgboost/blob/master/tests/distributed/の関連情報を参照してください。

さらに行う必要があるのは、ドライバー側（daskを駆動する場所である可能性が高い）でラビットトラッカーを起動することです。これは、 https： //github.com/dmlc/dmlc-coreのdmlc-submitスクリプトで実行されます。

OK、前から私のアウトラインを記入してください：

XGBoostコードを実行する前に、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

同様のプロセスを経てPSTrackerを開始することもできます。 これは同じ集中型マシン上にあるべきですか、それともネットワーク内の他の場所にあるべきですか？ これらのいくつかがあるべきですか？ これはユーザーが構成できる必要がありますか？

最終的に、トラッカー（およびpstracker？）をラビットネットワークに参加させてブロックします。

rabit.join()  # join network

ワーカーノードでは、これらの環境変数（通常のdaskチャネルを介して移動します）をローカル環境にダンプする必要があります。 次に、 xgboost.rabit.init()を呼び出すだけで十分です。

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

Rabitコードを見ると、環境変数がこの情報を提供する唯一の方法であるように見えます。 これを確認できますか？ トラッカーのホスト/ポート情報を直接入力として提供する方法はありますか？

トレーニング

次に、numpy配列/ pandasデータフレーム/ scipyスパース配列をDMatrixオブジェクトに変換します。これは比較的簡単に思えます。 ただし、ワーカーごとに複数のデータバッチがある可能性があります。 利用可能になったときに、より多くのデータを使用して電車を数回呼び出すクリーンな方法はありますか？ 私はこれらの行のコメントについて心配しています：

# 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)

トレーニングを開始する前に、すべてのデータが到着するのを待つ必要がありますか？

データセット/問題の例

上記のすべてが正しいと仮定すると、人々がデモンストレーションに使用する標準の分散トレーニングの例はありますか？

pstrackerを起動する必要はありません。

• トラッカーは、おそらくスケジューラー（ドライバー）で1つの場所で開始する必要があり、データ量の多いジョブはなく、作業を接続するためだけに機能します。
• env argsは、rabit.initでkwargsとして渡すことができます。
• ツリーブースティングはバッチアルゴリズムであるため、トレーニングを開始する前に、すべてのデータが取り込まれるのを待つ必要があります。
  
  
  
  • ただし、各ワーカーはデータのシャード（行のサブセット）のみを取得する必要があることに注意してください。
  
  
  • 理想的には、データイターインターフェイスを使用して、データをミニバッチ方式でDMatrixに渡す必要があります。これにより、データセット全体をメモリに配置する必要がなくなります。
  
  
  • これはhttps://github.com/dmlc/xgboost/blob/master/include/xgboost/c_api.h#L117を介して行われますが、Pythonラッパーはまだありません。
  
  
  • 最初の解決策として、配列を直接渡すことをお勧めします
  
  

今朝は遊ぶ時間がありました。 ここでの結果： https ：//github.com/mrocklin/dask-xgboost

これまでのところ、単一のメモリ内データセットの分散学習のみを処理します。 いくつかの質問が生じました：

1. DMatrixオブジェクトをシリアル化して渡すための最良の方法は何ですか？
2. ブースター結果をシリアル化して返すための最良の方法は何ですか？
3. 上記の環境変数は、 rabit.initの引数にどのようにマッピングされますか？ rabit.initへの入力の予想される形式は正確には何ですか？ slave_envs()の結果をrabit.initに渡すことは、リストを期待しているため、明らかに機能しません。 各キー名を--keyに変換する必要がありますか？おそらくDMLCプレフィックスを削除して、小文字に変換しますか？
4. 正しさをテストする良い方法はありますか？ 2つのブースターオブジェクトをどのように比較しますか？ 分散トレーニングでまったく同じ結果と順次トレーニングが生成されることを期待する必要がありますか？

• 通常、DMatrixをシリアル化することはありません。これは、トレーニング時間のデータホルダーのようなものです。データは、dask（配列/データフレーム）によって渡され、共有されてから、xgboostに渡されると思います。
  
  
  
  • おそらくデータイテレータをxgboostに公開することで、メモリ内配列を直接経由する以外の方法でデータを渡すためのより良い方法を探ることができます。
  
  
• xgboostが両側にインストールされている限り、ブースターをピクルスにすることができます。
• 物事がどのように渡されるかを詳しく説明していないことについて申し訳ありませんが、

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

• 通常、分散型マシンと単一マシンからトレーニングされたブースターは同じではありませんが、ここで確認することがいくつかあります
  
  
  
  • すべての労働者から返されるブースターは同一でなければなりません
  
  
  • 予測検証エラーを探す場合、単一のマシンの場合とほぼ同じくらい低くする必要があります
  
  

これがどのように使用されるかについての一般的な質問がさらに2つあります（XGBoostの経験はなく、機械学習の経験はわずかです。無知を許してください）。

1. 同じ入力データで複数のワーカーを使用することは合理的ですか？ （XGBoostは計算上バインドされていますか？）
2. より大きなデータセットを操作する場合、各XGBoostワーカーに、そのデータがピアとは異なることを伝えるために特別なことをする必要がありますか？

より一般的なユースケースはどれですか？

各作業は、データの異なるパーティション（行ごと）で機能する必要があり、同じ入力データを参照するべきではありません。

• データが十分に大きくない場合は、マルチスレッドのベライゾンが行う必要があります
• 各作業は、パーティションで個別に統計を収集し、相互に同期します

これは通常、spark / flinkなどのフレームワークでのmapPartition操作に対応します

2つのワーカーを開始した場合、データセットに8行4列があるとします。

• ワーカー0は行0〜3から読み取ります
• ワーカー1は4行目から7行目を読み取ります

OK、今そこにあるのは少しきれいです。 結果が各ワーカーで生成されるので、結果を消費する能力があればいいのですが、今のところそれを回避しています。 現在の解決策は次のとおりです。

1. daskアレイまたはデータフレームをクラスターに永続化し、終了するのを待ちます
2. 各チャンク/パーティションがどこで終わったかを見つけます
3. 各ワーカーに、それらのチャンク/パーティションを正確に連結してトレーニングするように指示します

このソリューションは管理しやすいように見えますが、理想的ではありません。 xgboost-pythonが到着した結果を受け入れることができれば便利です。 しかし、次にやるべきことは、実際に試してみることだと思います。

例としてインターネットを見て回るつもりです。 誰かが偶然に、numpyまたはpandasAPIを使用して簡単に生成できる人為的な問題を抱えている場合は歓迎します。 それまでは、ランダムなデータを使用したラップトップの簡単な例を次に示します。

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>

誰かが見てみたい場合は、関連するコードがここにあります： https ：//github.com/mrocklin/dask-xgboost/blob/master/dask_xgboost/core.py

私が言ったように、私はXGBoostに不慣れなので、おそらく物事が欠けています。

試してみる典型的なおもちゃの例はhttps://github.com/dmlc/xgboost/tree/master/demo/dataにあります
それはlibsvm形式ですが、numpyにするには少し解析する必要があります

より大きなもの（実際にクラスターが必要になるもの）はありますか？ または、任意のサイズのデータ​​セットを生成する標準的な方法はありますか？

または、おそらくより良い質問は、「あなた（またはこの問題を読んでいる他の人）はここで何を見たいですか？」です。

建物は今予測します。 モデルをワーカーに戻し（ピクルス/アンピクルプロセスを実行）、一部のデータでbst.predictを呼び出すと、次のエラーが発生します。

Doing rabit call after Finalize

私の仮定では、この時点で、モデルは自己完結型であり、もはやウサギを使用する必要はありません。 クライアントマシンでは正常に動作しているようです。 predictを呼び出すときにこのエラーが発生する可能性がある理由はありますか？

予測の一部は依然としてrabitを使用しています。これは主に、予測子がトレーニングと共有されるいくつかの初期化ルーチンで学習者を使用しているためです。 最終的にはこれを修正する必要がありますが、今のところこれが当てはまります。

共通のデータセットで問題なく機能する限り、興味深い出発点になると思います。

とにかく中程度のデータにクラスターを使用する理由があります（クラスター環境でのスケジューリングが容易です）。pysparkユーザーの中には、少し宣伝すれば試してみたいと思う人もいるかもしれません。

本当に重要なデータセットをテストするのは大変でした。たとえば、10億行のデータセットを1つ試してみてください。 Kaggleは、関連性のある約1,000万の大きなデータセットである可能性があります。

このリポジトリは、航空会社のデータセットに対する実験を示しています。これは、数千万行と数十列にあると思います（1回のホットエンコーディングの後？）ベンチマークでは、10万行のサンプルを取得し、人工的に生成されたようです。このサンプルからのより大きなデータセット。 おそらく、必要に応じてこれをスケールアップすることができます。

これは、シングルコアでパンダとxgboostでこのデータを使用する例です。 データの準備、パラメータ、またはこれを適切に行う方法に関する推奨事項は大歓迎です。

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

とにかく、ここにオプションがあります。 航空会社のデータセットはよく知られているようで、実際には不便なほど大きくなる可能性があります。 繰り返しになりますが、機械学習は私の専門ではないので、これが適切かどうかはわかりません。

cc @TomAugspurger 、これについて考えているかもしれないような人のようです。

Daskとpredictに関しては、いつでも再びrabitを設定できます。 これは、物事を怠惰に保つのではなく、評価を強制するため、少し汚れた感じがします。 しかし、これは使用するのに深刻なブロッカーではありません。

予測に関するいくつかの問題が発生しています。 2つの質問：

1. 同じラビットセッション内でBooster.predict複数回呼び出すことはできますか？
2. rabit.init 、 Booster.predict 、 rabit.finalizeを別々のスレッドで呼び出すことはできますか？

現在、新しいトラッカーを作成し、ワーカーのメインスレッドでrabit.initを呼び出しています。 これは正常に機能します。 ただし、ワーカースレッドでBooster.predictを呼び出すと（各daskワーカーは計算用のスレッドプールを維持します）、 Doing rabit call after Finalizeのようなエラーが発生します。 何かお勧めはありますか？

予測の一部は依然としてrabitを使用しています。これは主に、予測子がトレーニングと共有されるいくつかの初期化ルーチンで学習者を使用しているためです。 最終的にはこれを修正する必要がありますが、今のところこれが当てはまります。

私はこれについて興味があります。 トレーニング済みモデルをワーカーからクライアントマシンにシリアル化-転送-逆シリアル化した後、ラビットネットワークがなくても、通常のデータで正常に動作するようです。 Rabitでトレーニングされたモデルを使用して、Rabitなしでデータを予測できるようです。 これも本番で必要なようです。 ここで、ウサギの訓練を受けたモデルを使用する際の制約について詳しく教えてください。

データセット/問題の例
上記のすべてが正しいと仮定すると、人々がデモンストレーションに使用する標準の分散トレーニングの例はありますか？

この実験の結果を再現できれば幸いです。

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

XGBoost（＃1950）の新しいビニング+高速履歴オプションを使用すると、同様の結果を得ることができるはずです。

試してみる典型的なおもちゃの例はhttps://github.com/dmlc/xgboost/tree/master/demo/dataにあります
それはlibsvm形式ですが、numpyにするには少し解析する必要があります

sklearnでこのPRに興味があるかもしれません： https ：//github.com/scikit-learn/scikit-learn/pull/935

@mrocklinモデルの再利用に制約はありません。 したがって、分散バージョンでトレーニングされたモデルは、シリアルバージョンで使用できます。 予測子の現在の制限（rabitでコンパイルした場合）がトレーニング関数と機能を混合している（つまり、rabit呼び出しが発生した）だけです。

あなたがそれを言うと、私たちは問題の解決策があるかもしれないと思います。 予測が問題を解決する前に、（何も渡さずに、予測者にそれが唯一のワーカーであると思わせる） rabit.initを実行するだけです。

はい。 確かにそれは問題を解決します。 dask-xgboostがpredictをサポートするようになりました： https ：//github.com/mrocklin/dask-xgboost/commit/827a03d96977cda8d104899c9f42f52dac446165

回避策@tqchenをありがとう！

これは、私のローカルラップトップ上の航空会社のデータセットの小さなサンプルでのdask.dataframeとxgboostのワークフローです。 これは誰にとっても大丈夫ですか？ ここで欠落しているXGBoostのAPI要素はありますか？

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

私の短期的な目標は、これについて短いブログ投稿を書くことです。そうすれば、XGBoostの経験が豊富で、時間のある他の誰かがこのプロジェクトを採用して推進できるようになります。 （私は、ここにいる他のみんなと同じように、このような他のいくつかのプロジェクトに同時に取り組んでいます。）

すでにS3バケットにあるという理由だけで、航空会社のデータセットに偏っています。 私は、Criteoデータセットが大規模でより良いデモンストレーションを行うことに同意します。

使用するパラメータや結果の判断方法がまだわかりません。 パラメータについては、 @ szilardの実験をここで使用できます。 予測を判断する良い方法はありますか？ たとえば、$＃$ labels_test $＃$と一致するpredictions > 0.5を探していますか？

おそらく、バイナリ分類の予測パフォーマンスを評価する最も一般的な方法（特に研究または競争の設定で）は、ROC曲線（AUC）の下の領域を使用することですが、実際のアプリケーションでは、「ビジネス」値に合わせたメトリックを使用する必要がありますモデルを使用して作成されました。

たとえば、labels_testに一致する0.5を超える予測を探していますか？

はい。 テストセットでそれを平均すると、これがテストの精度になります。 ただし、データセットのバランスが崩れている可能性があります（クリックよりもクリックがない方がはるかに多い）。 その場合、 ROCAUCスコアがより適切なメトリックです。

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

predictionsが、テストセットの各行のモデルによって推定された正の確率の1D配列であると仮定します。

@mrocklinフォローアップの質問の1つですが、daskはマルチスレッドワーカージョブを許可しますか？ 私はこれがGILのためにPythonにあまり関係がないことを知っています。 ただし、xgboostを使用すると、分散して相互に調整しながら、ワーカーごとにマルチスレッドトレーニングを実行できます。 xgboostのnthread引数は、常にそのワーカーの動作中のコアの数になるように設定する必要があります

簡単な答えは「はい」です。 Daskのほとんどの用途は、NumPy、Pandas、SKLearnなど、ほとんどがCおよびFortranコードであり、Pythonでラップされているプロジェクトです。 GILはこれらのライブラリに影響を与えません。 一部の人々は、PySpark RDD（ dask.bagを参照）と同様のアプリケーションにDaskを使用しており、影響を受けます。 ただし、このグループは少数派です。

そうです、Daskはマルチスレッドタスクを許可します。 XGBoostに複数のスレッドを使用するように指示するにはどうすればよいですか？ これまでの私の実験では、パラメータを変更せずにCPUの使用率が高いことがわかりました。それで、デフォルトですべてがうまく機能するのでしょうか。

XGBoostはデフォルトでマルチスレッドを使用し、nthreadが設定されていない場合、マシン上で（そのワーカーではなく）使用可能なすべてのCPUスレッドを使用します。 これにより、複数のワーカーが同じマシンに割り当てられている場合に競合状態が発生する可能性があります。

したがって、nthreadパラメーターをワーカーが使用できるコアの最大数に設定することは常に良いことです。 通常、良い習慣は、労働者ごとに約4スレッドを使用することです

確かに、で達成する必要があります
https://github.com/mrocklin/dask-xgboost/commit/c22d066b67c​​78710d5ad99b8620edc55182adc8f

2017年2月20日月曜日午後6時31分、Tianqi [email protected]
書きました：

XGBoostはデフォルトでマルチスレッドを使用し、利用可能なすべてのCPUを使用します
nthreadが設定されていない場合、（そのワーカーではなく）マシン上のスレッド。
これにより、複数のワーカーが同じに割り当てられている場合に競合状態が発生する可能性があります
機械。

したがって、nthreadパラメータを最大数に設定することは常に良いことです。
ワーカーが使用を許可されたコア。 通常、良い習慣は言う周りの使用です
ワーカーあたり4スレッド

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/dmlc/xgboost/issues/2032#issuecomment-281205747 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AASszPELRoeIvqEzyJhkKumIs-vd0PHiks5reiJngaJpZM4L_PXa
。

ノートブック： https ：//gist.github.com/19c89d78e34437e061876a9872f4d2df
短いスクリーンキャスト（6分）： https ：//youtu.be/Cc4E-PdDSro

重要なフィードバックは大歓迎です。 繰り返しになりますが、この分野での私の無知を許してください。

@mrocklin素晴らしいデモ！ param dictで'tree_method': 'hist', 'grow_policy': 'lossguide'を使用することで、実行時のパフォーマンス（および場合によってはメモリ使用量）を大幅に改善できると思います。

@ogriselに感謝します。 これらのパラメータを使用すると、トレーニング時間は6分から1分になります。 ただし、メモリ使用量はほぼ同じようです。

OK、これに戻ります。 トレーニングと実装以外のXGBoost操作はありますか？

@tqchenまたは@ogriselのいずれかが、 https：//github.com/mrocklin/dask-xgboost/blob/master/dask_xgboost/core.pyで実装を確認する時間があれば、感謝します。 ただし、外国のコードベースを調べることは、優先順位リストで常に高いとは限らないことを理解しています。

すべて問題がなければ、READMEにもう少し追加して、PyPIに公開します。そうすれば、おそらくこの問題を解決できます。

トレーニングと予測だけを配布する必要があると思います。 他のものはデータセットに応答しないため、配布する必要はありません

dask-xgboostをPyPIにプッシュし、 https：//github.com/dask/dask-xgboostに移動しました

ここであなたの助けをありがとう@tqchenと@ogrisel 。 コラボレーションにより、これは比較的簡単になりました。

ベンチマークを実行したい場合は、喜んでお手伝いさせていただきます。 それまでは、締めくくります。