Utilizzo dell’apprendimento automatico per caratterizzare i carichi di lavoro del database

I database ci aiutano da decenni a gestire i nostri dati. Come gran parte della tecnologia con cui lavoriamo quotidianamente, potremmo iniziare a darle per scontate e perdere l’opportunità di esaminarne l’utilizzo, e soprattutto il loro costo.

Ad esempio, Intel archivia gran parte del suo vasto volume di dati di produzione in un sistema di gestione di database relazionali (RDBMS) con elaborazione parallela di massa (MPP). Per tenere sotto controllo i costi di gestione dei dati, Intel IT ha deciso di valutare il nostro attuale RDBMS MPP rispetto a soluzioni alternative. Prima di poterlo fare, dovevamo comprendere meglio i carichi di lavoro del nostro database e definire un benchmark che fosse una buona rappresentazione di tali carichi di lavoro. Sapevamo che migliaia di ingegneri di produzione interrogavano i dati e sapevamo quanti dati venivano inseriti nel sistema. Tuttavia, avevamo bisogno di maggiori dettagli.

“Quali tipi di lavori costituiscono il carico di lavoro complessivo del database?”

“Come sono le domande?”

“Quanti utenti simultanei ci sono per ogni tipo di query?”

Vorrei presentare un esempio per illustrare meglio il tipo di informazioni di cui avevamo bisogno.

Immagina di aver deciso di aprire un salone di bellezza nella tua città natale. Desideri costruire una struttura in grado di soddisfare la domanda odierna di servizi e di favorire la crescita aziendale. Dovresti stimare quante persone saranno presenti nel negozio nelle ore di punta, in modo da sapere quante stazioni allestire. Devi decidere quali servizi offrire. Quante persone puoi servire dipende da tre fattori: 1) la velocità con cui lavorano le estetiste; 2) quante estetiste lavorano; e 3) quali servizi desidera il cliente (solo un taglio, o una manicure, una colorazione dei capelli e un massaggio, per esempio). Il “carico di lavoro” in questo caso è una funzione di ciò che vogliono i clienti e di quanti clienti ci sono. Ma anche questo varia nel tempo. Forse ci sono periodi in cui molti clienti vogliono solo rifiniture. Durante altri periodi (ad esempio, prima di San Valentino), sono richiesti sia il taglio che la colorazione dei capelli, eppure in altri momenti un massaggio potrebbe essere quasi l’unica richiesta (ad esempio, le persone che utilizzano tutte quelle carte regalo per massaggi che hanno appena ricevuto a San Valentino) . Potrebbe anche essere apparentemente casuale, estraneo a qualsiasi evento del calendario. Se ottieni più clienti nelle ore di punta e non hai abbastanza postazioni o estetiste qualificate, le persone dovranno aspettare e alcuni potrebbero ritenerlo troppo affollato e andarsene.

Quindi ora torniamo al database. Per il nostro RDBMS MPP, i “servizi” sono i diversi tipi di interazioni tra il database e gli ingegneri (consumo) e i sistemi che inviano i dati (acquisizione). L’acquisizione consiste in ETL (estrazione-trasformazione-caricamento) standard, ETL del percorso critico, caricamenti in blocco e richieste di inserimento/aggiornamento/eliminazione all’interno del DB (sia grandi che piccole). Il consumo consiste in report e query, alcuni eseguiti come processi batch, altri ad hoc.

All’inizio della caratterizzazione del nostro carico di lavoro, volevamo identificare i tipi di “servizi” di database che venivano eseguiti. Sapevamo che, come nel caso di un servizio di rifinitura rispetto a un servizio completo nell’esempio di un salone di bellezza, le richieste SQL potevano essere molto semplici o molto complesse o una via di mezzo. Ciò che non sapevamo era come generalizzare un’ampia varietà di queste richieste in qualcosa di più gestibile senza perdere qualcosa di importante. Piuttosto che fidarci del nostro istinto, volevamo essere metodici al riguardo. Abbiamo adottato un approccio innovativo per sviluppare una piena comprensione delle richieste SQL: abbiamo deciso di applicare tecniche di Machine Learning (ML) incluse K-significa clustering e alberi di classificazione e regressione (CART).

• K-significa che il clustering raggruppa punti dati simili in base a modelli sottostanti.
• CART è un algoritmo predittivo che produce criteri leggibili dall’uomo per suddividere i dati in sottogruppi ragionevolmente puri.

Nell’esempio del nostro salone di bellezza, potremmo usare K-significa clustering e CART per analizzare i clienti e identificare gruppi con somiglianze come “solo servizi per capelli”, “servizi per capelli e unghie” e “solo servizi per unghie”.

Per il nostro database, il nostro K-significa che gli sforzi di clustering e CART hanno rivelato che le richieste ETL erano costituite da sette cluster (previsti dal tempo della CPU, dall’I/O del thread più alto e dal tempo di esecuzione) e le richieste SQL potevano essere raggruppate in sei cluster (in base al tempo della CPU).

Una volta ottenuti i nostri raggruppamenti, abbiamo potuto fare il passo successivo, ovvero caratterizzare i vari periodi di punta. L’obiettivo era identificare qualcosa di equivalente ai tipi di carico di lavoro “normale”, “appena prima di San Valentino” e “appena dopo San Valentino”, ma senza conoscere in anticipo eventuali eventi di “San Valentino”. Abbiamo iniziato generando conteggi di richieste per ciascun gruppo per ogni ora in base a mesi di registri storici del database. Successivamente, abbiamo utilizzato K-significa raggruppare nuovamente, questa volta per creare cluster di intervalli di un’ora simili tra loro rispetto al conteggio delle richieste per gruppo. Infine, abbiamo selezionato alcuni slot di un’ora da ciascun cluster con il massimo utilizzo complessivo della CPU per creare carichi di lavoro di esempio.

L’aspetto migliore di questo processo è che è stato guidato da dati e approfondimenti affidabili basati sul machine learning. (Questo non è il caso della mia congettura post-San Valentino sui soli massaggi, perché non avevo carte regalo.) La caratterizzazione del carico di lavoro era essenziale per confrontare costi e prestazioni del nostro RDBMS MPP esistente e di diverse alternative. È possibile leggere il white paper di IT@Intel, “Minimizzare i costi di gestione dei dati di produzione”, per una discussione completa su come abbiamo creato un benchmark personalizzato e poi condotto diverse prove di concetto con i fornitori per eseguire il benchmark.