Caricare il giorno 15 in Dask e formare un modello di foresta casuale di Dask cuML
-
PDF del sito di questa documentazione
- Intelligenza artificiale
- Cloud pubblico e ibrido
- Virtualizzazione
-
Container
- Red Hat OpenShift con NetApp
Raccolta di documenti PDF separati
Creating your file...
In modo simile alla sezione precedente, caricare Criteo Click Logs Day 15 in Pandas e formare un modello di foresta casuale scikit-learn. In questo esempio, è stato eseguito il caricamento di DataFrame con Dask cuDF e il training di un modello di foresta casuale in Dask cuML. Nella sezione abbiamo confrontato le differenze di tempo e di scala per la formazione ""Confronto tra i tempi di formazione"."
criteo_dask_RF.ipynb
Questo notebook importa numpy
, cuml`e il necessario `dask
librerie, come mostrato nell'esempio seguente:
import cuml from dask.distributed import Client, progress, wait import dask_cudf import numpy as np import cudf from cuml.dask.ensemble import RandomForestClassifier as cumlDaskRF from cuml.dask.common import utils as dask_utils
Avviare Dask Client().
client = Client()
Se il cluster è configurato correttamente, è possibile visualizzare lo stato dei nodi di lavoro.
client workers = client.has_what().keys() n_workers = len(workers) n_streams = 8 # Performance optimization
Nel nostro cluster AKS viene visualizzato il seguente stato:
Si noti che Dask utilizza il paradigma di esecuzione pigro: Invece di eseguire il codice di elaborazione istantaneamente, Dask crea invece un DAG (Directed Acyclic Graph) di esecuzione. IL DAG contiene una serie di attività e le relative interazioni che ciascun lavoratore deve eseguire. Questo layout significa che i task non vengono eseguiti finché l'utente non dice a Task di eseguirli in un modo o nell'altro. Con Dask hai tre opzioni principali:
-
Call compute() su un DataFrame. questa chiamata elabora tutte le partizioni e restituisce i risultati allo scheduler per l'aggregazione finale e la conversione in cuDF DataFrame. Questa opzione deve essere utilizzata con parsimonia e solo in caso di risultati fortemente ridotti, a meno che il nodo dello scheduler non esaurisca la memoria.
-
Call Persistent() su un DataFrame. questa chiamata esegue il grafico, ma, invece di restituire i risultati al nodo scheduler, li mantiene in memoria nel cluster in modo che l'utente possa riutilizzare questi risultati intermedi lungo la pipeline senza dover eseguire nuovamente la stessa elaborazione.
-
Call head() su un DataFrame. proprio come con cuDF, questa chiamata restituisce 10 record al nodo Scheduler. Questa opzione consente di verificare rapidamente se il DataFrame contiene il formato di output desiderato o se i record stessi hanno senso, a seconda dell'elaborazione e del calcolo.
Pertanto, a meno che l'utente non chiami una di queste azioni, i lavoratori sono inattivi in attesa che lo scheduler avvii l'elaborazione. Questo paradigma di esecuzione pigro è comune nei moderni framework di calcolo distribuiti e paralleli come Apache Spark.
Il paragrafo seguente forma un modello di foresta casuale utilizzando Dask cuML per il calcolo distribuito con accelerazione GPU e calcola la precisione di previsione del modello.
Adsf # Random Forest building parameters n_streams = 8 # optimization max_depth = 10 n_bins = 16 n_trees = 10 cuml_model = cumlDaskRF(max_depth=max_depth, n_estimators=n_trees, n_bins=n_bins, n_streams=n_streams, verbose=True, client=client) cuml_model.fit(gdf_sliced_small, Y) # Model prediction pred_df = cuml_model.predict(gdf_test) # calculate accuracy cu_score = cuml.metrics.accuracy_score( test_y, pred_df )