E come utilizzarlo in modo efficace nel modello XGBoost
Recentemente, io e i miei colleghi abbiamo lavorato su un grande servizio ad alto carico che utilizza il Xgboost modello di machine learning e Dask come strumento per l’elaborazione distribuita dei dati e la generazione di previsioni. Qui vorrei condividere i risultati secondo cui siamo stati in grado di massimizzare l’uso di Dask ai fini della preparazione dei dati e dell’adattamento del modello ML.
Cos’è Dask?
buio è una libreria per l’elaborazione distribuita di grandi quantità di dati. Il concetto di base è quello di dividere grandi array in piccole parti (partizioni).
Ecco come vengono archiviati ed elaborati i Dask Dataframes: le tabelle possono essere suddivise in piccoli frame di dati (guardalo come Pandas DataFrames) in modo che non sia necessario archiviare l’intera tabella nella RAM. L’intera tabella di origine potrebbe essere troppo grande per essere caricata in memoria, ma le singole partizioni sì. Inoltre, tale memorizzazione dei dati consente l’utilizzo efficiente di più core del processore per parallelizzare i calcoli.
Allo stesso tempo, la dimensione di queste partizioni (pezzi) è determinata dallo sviluppatore. Pertanto, lo stesso dataframe può essere diviso in più partizioni utilizzando ad esempio “Split 1” o “Split 2” (Figura 1).
La scelta della dimensione ottimale della partizione è fondamentale, perché se non è ottimale, l’elaborazione dei dati può rallentare. La dimensione ottimale della partizione dipende dalla dimensione del set di dati complessivo, nonché dalle risorse del server (o laptop): il numero di CPU e RAM disponibile.
Disclaimer: Successivamente, per comodità, misureremo la dimensione del dataset in base al numero di righe. Tutte le tabelle saranno composte da 4 colonne (3 funzionalità + 1 target). Quando abbiamo implementato l’algoritmo nel sistema, abbiamo creato tutte le dipendenze non dal numero di righe nelle tabelle, ma dal numero totale di elementi (righe x colonne).
Il problema
Dask può essere utilizzato per calcolare semplici statistiche e aggregazioni, ma Dask può anche essere utilizzato per addestrare grandi modelli di machine learning (utilizzando molti dati). Ad esempio, XGBoost. Dato che il servizio che stavamo sviluppando poteva richiedere di addestrare un modello su 2-10 milioni di record utilizzando solo 8-16 GB di RAM (nel caso di piccole macchine virtuali), abbiamo deciso di condurre degli esperimenti.
Anche nel caso di calcolo statistico semplice, la dimensione delle partizioni è molto importante perché può rallentare notevolmente l’algoritmo di calcolo in due casi:
- Le partizioni sono troppo grandi quindi ci vuole troppo tempo e risorse per elaborarli nella RAM
- Le partizioni sono troppo piccole quindi per elaborarli tutti Dask deve caricare queste tabelle nella RAM troppo spesso: viene dedicato più tempo alla sincronizzazione e al caricamento/download che ai calcoli stessi
Pertanto, l’utilizzo delle stesse risorse di elaborazione può ridurre significativamente le prestazioni del programma scegliendo una dimensione della partizione non ottimale (Figura 2). La Figura 2 mostra il tempo necessario per adattare il modello XGBoost ai dataframe Dask con dimensioni di partizione diverse. Viene mostrato il tempo di esecuzione medio su 5 esecuzioni.
In questo post, il algoritmo per la dimensione ottimale per la ricerca delle partizioni Dask Dataframes viene discusso. Tutte le tabelle mostrate in questo post vengono utilizzate per adattarsi al modello di apprendimento automatico Dask Xgboost. Condivideremo anche alcuni suggerimenti che potresti trovare utili.
Suggerimenti per la documentazione
Nella documentazione ufficiale di Dask ci sono pagine web con suggerimenti su come gestire correttamente gli oggetti Dask (dataframe, array, ecc.) come Best practice per Dask DataFrames.
In questa pagina, in particolare, puoi vedere tali consigli:
Dovresti puntare a partizioni che contengano circa 100 MB di dati ciascuna.
Tuttavia, questo consiglio è approssimativo e non tiene conto delle specifiche di calcolo del server, della dimensione del set di dati di origine e delle specificità della risoluzione del problema.
Configurazione dell’esperimento
Come accennato in precedenza, si presuppone che la dimensione ottimale della partizione dipenda dalle seguenti tre condizioni:
- Dimensione del set di dati completo;
- Risorse della CPU (numero di processi) che XGBoost e Dask possono utilizzare;
- Memoria ad accesso casuale disponibile (RAM).
Pertanto, durante gli esperimenti, il numero di risorse di calcolo è stato variato, così come la dimensione del set di dati di origine. Casi considerati:
- Dimensione della partizione, migliaia di righe: (5, 10, 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000) (13 casi)
- Dimensioni del set di dati completo, migliaia di righe: (100, 200, 300, 400, 500, 600, 1000, 2000, 3000, 4000) (10 casi)
- Risorse CPU (worker): (2, 3, 4) (3 casi)
- Memoria ad accesso casuale (RAM) disponibile per lavoratore: (1GB, 2GB, 4GB) (3 casi)
Nota: Lavoratore a Dask è un processo in un computer (su un server) che utilizza le risorse informatiche ad esso assegnate e viene eseguito in isolamento e in parallelo rispetto ad altri lavoratori.
Pertanto, sono stati analizzati 1170 casi (13 x 10 x 3 x 3). Per ottenere stime più affidabili del tempo di esecuzione, ciascun caso è stato avviato 5 volte. È stata quindi calcolata la media delle metriche (tempo di esecuzione).
Nell’ambito dell’indagine volevamo scoprire i limiti della dimensione del set di dati oltre i quali la macchina virtuale non sarebbe stata in grado di gestire il carico per scalare il servizio con maggiore successo.
Risultati
Innanzitutto, considera le visualizzazioni generali degli esperimenti. Abbiamo eseguito esecuzioni con diversi numeri di core della CPU e quantità di RAM, oltre a variare la dimensione del set di dati originale e la dimensione delle partizioni. Dopo aver completato gli esperimenti, abbiamo preparato una tabella che mostra solo le soluzioni ottimali (dimensioni delle partizioni). Le dimensioni ottimali delle partizioni sono quelle in cui il tempo di esecuzione con determinate condizioni (RAM, CPU e dimensioni del set di dati di origine) è minimo. Le matrici di correlazione delle metriche raccolte sono mostrate nella Figura 3.
Dal grafico puoi vedere che l’influenza maggiore sul tempo di esecuzione è stata ovviamente la dimensione del set di dati di origine. Anche il numero di lavoratori e la quantità di RAM hanno un effetto significativo sul tempo di adattamento. La dimensione del blocco ha un effetto relativamente debole. Tuttavia, ciò potrebbe essere dovuto al fatto che la dipendenza tra tempo di esecuzione e dimensione della partizione non è lineare, il che è confermato dalla curva della Figura 2. Inoltre, la Figura 4 conferma che le misurazioni sono state effettuate correttamente, poiché i risultati sono coerenti con i nostri aspettative.
Diamo un’occhiata all’animazione con grafici 3D (Animazione 1).
Nell’animazione, i casi ottimali (per ciascuna combinazione di numero di processi e RAM per lavoratore) sono cerchiati in rosso. Cioè, vengono mostrate le condizioni in cui il tempo di esecuzione dell’algoritmo era minimo per una determinata dimensione del set di dati, numero di core, RAM e dimensione della partizione. I grafici mostrano anche le superfici ottimali costanti a tratti in grigio (NB: la superficie è globale per tutti i casi).
Dall’animazione si può vedere che in alcuni fotogrammi non ci sono dati sugli esperimenti (nessun punto) (Figura 4). Ciò significa che le risorse computazionali proposte erano insufficienti per eseguire il modello.
Dall’immagine si può osservare che con questa dimensione del dataset, se il numero di nuclei è piccolo, dovrebbero essere formate partizioni più grandi. Si noti che questa dipendenza non vale per tutti i casi.
Sulla base dei risultati dei lanci con risorse computazionali insufficienti, è stata preparata la seguente visualizzazione (Figura 5).
Inoltre, sulla base delle statistiche raccolte sulle esecuzioni non riuscite, è stata raggiunta una conclusione (suggerimento): se la quantità di memoria è limitata, è più affidabile utilizzare una dimensione della partizione ridotta.
Discussione
Sulla base di questa ricerca, sono stati formati diversi suggerimenti per una configurazione più efficace del sistema basato sul modello Dask XGBoost. Tieni presente che questo studio è stato condotto per eseguire Dask in modo più efficiente su server relativamente piccoli (che non dispongono di centinaia di gigabyte di RAM e decine di CPU).
L’esperimento ha rivelato gli iperpiani ottimali. Sono modellati utilizzando Processi gaussiani. Sulla base di questo algoritmo vengono selezionate automaticamente le dimensioni ottimali della partizione (Animazione 2).
Come si può vedere dall’animazione, in media, la dimensione ottimale della partizione diminuisce quando aumenta il numero di righe nel set di dati di origine.
Conclusione (e suggerimenti)
Spero che tu sia interessato a leggere quale dimensione Patrician si è rivelata la dimensione ottimale per l’addestramento del modello XGBoost.
Mi rendo conto che questo articolo è diventato molto “tecnico”. Pertanto, per chi è riuscito a leggerlo fino alla fine, darò alcuni consigli:
- Se stai misurando il tempo di esecuzione, esegui sempre i calcoli più volte e calcola la media dei risultati poiché i tempi di esecuzione sono stocastici;
- Se hai dei dubbi sulla dimensione delle partizioni scegliere, è meglio commettere un errore in misura minore (altrimenti l’algoritmo non solo funzionerà a lungo, ma potrebbe bloccarsi con un errore);
- Per inizializzare un cluster localmente in Dask, il file cluster = LocalCluster() E Cliente(cluster) vengono utilizzati i comandi. Consigliamo vivamente di inizializzare un cluster di questo tipo solo una volta nel codice utilizzando il pattern Singleton. Puoi vedere come può essere implementato in Python Qui. Altrimenti, inizializzerai un nuovo cluster a ogni avvio;
- In media, la dimensione ottimale della partizione diminuisce quando aumenta il numero di righe nel set di dati di origine
La storia di Dask e dell’apprendimento automatico è stata presentata da Michail Sarafanov e il La squadra di Wiredhut
Fonte: towardsdatascience.com
