Una guida introduttiva all'ottimizzazione di costi e performance di BigQuery
Il problema
Immagini che la sua azienda gestisca diversi dataset BigQuery e che, un mese fa, abbia inserito un nuovo team di analisti che li interroga quotidianamente. Una mattina, mentre sorseggia tranquillamente il caffè (o il tè, per non discriminare nessuno), riceve la fattura GCP e scopre che i costi di analisi e storage di BigQuery sono saliti del 5.000%. Una notizia del genere potrebbe farle sputare di colpo la sua bevanda, con tanto di pasticcio su tastiera e monitor. Questo articolo la aiuterà a porre rimedio, se non addirittura a prevenire, una situazione così spiacevole, illustrando diversi metodi per ottimizzare i costi di BigQuery.
Partire dalle basi
Prima di mettere mano ai costi di BigQuery, occorre svolgere alcuni passaggi preliminari e avere alcune nozioni di base.
Li affronterò in questa prima parte della serie: una volta acquisite le basi e completata la preparazione, sarà tutto in discesa fino alla Parte 2 e oltre, dove si entrerà nel vivo delle ottimizzazioni.
Ecco cosa è bene sapere su slot di BigQuery, modelli di pricing e fattori che incidono sui costi:
Slot
Alla base dell'elaborazione di BigQuery c'è un costrutto chiamato slot. Uno slot è semplicemente una vCPU con una certa quantità di memoria associata: una sorta di mini-VM dedicata all'elaborazione di BigQuery. Quando si esegue una query in BigQuery, questa viene processata su un insieme di slot allocati. In teoria, maggiore è il numero di slot allocati e disponibili, più rapidamente le query verranno eseguite.
Uno slot esegue praticamente qualsiasi operazione richiesta nel corso di un job BigQuery.
Shuffle Slot
All'interno di BigQuery, un'operazione non documentata svolta dagli slot è lo shuffling dei dati. In qualsiasi momento, fino al 60% degli slot allocati al suo progetto può fungere da shuffle slot.
In termini molto semplici, lo shuffling consiste nel ridistribuire i dati elaborati in una nuova posizione, affinché lo step corrente o successivo del piano di esecuzione della query risulti più rapido. Il white paper di Google sull'architettura di BigQuery permette di approfondire il funzionamento dello shuffling. Lo shuffling rende l'esecuzione della query più efficiente, ma impegna slot preziosi in operazioni che non fanno avanzare direttamente l'esecuzione.
Modelli di pricing
BigQuery offre attualmente due modelli di pricing distinti: on-demand e flat-rate.
Pricing on-demand
Il modello predefinito è il pricing on-demand, che mette a disposizione 2.000 slot per le sue query e un ulteriore pool di slot, in quantità non dichiarata, per operazioni di load, copia tabelle ed extract. Quando in BigQuery si liberano slot in eccesso, il pool di 2.000 slot può aumentare, ma non c'è alcuna garanzia: meglio quindi non darlo per scontato. Per dare un riferimento, il massimo che ho riscontrato è stato attorno ai 3.500 slot in brevi raffiche.
In questo modello la fatturazione avviene a una tariffa fissa di 5 $ per TB di dati scansionati dalle query.
Per molte aziende è proprio questo il principale driver dei costi di BigQuery.
Pricing flat-rate
Il pricing flat-rate (o a slot) fissa un prezzo predefinito per le scansioni BigQuery, a potenziale scapito delle performance. Lo fa limitando il numero di slot disponibili a quanto pre-acquistato ed eliminando il prezzo di 5 $ per TB scansionato.
Gli slot (inclusi i Flex Slot di cui parlerò a breve) si acquistano sempre in blocchi da 100. Gli slot standard (cioè non Flex) vengono acquistati nell'ambito di un commitment con durata di un mese o di un anno. Tenga presente che, una volta effettuata, una prenotazione non può essere annullata facilmente. Un commitment mensile può essere convertito in commitment annuale, ma non viceversa.
C'è una piccola insidia su cosa accade al termine di un commitment, che cambia tra i due e che è stata modificata diverse volte. Per questo mi limito a rimandare alla documentazione Google sui commitment mensili e sui commitment annuali, nel caso le regole cambino di nuovo. Le consiglio vivamente di impostare promemoria sul calendario per essere avvisato con largo anticipo della scadenza, così da poter agire di conseguenza.
Detto ciò, con un modello di pricing flat-rate i suoi slot possono essere integrati, o sostituiti del tutto, da un ulteriore pool di slot chiamati Flex Slot. I Flex Slot sono identici per capacità e funzioni agli slot standard, ma offrono un commitment più breve e flessibile, con una durata minima di 60 secondi. Trascorso questo intervallo minimo, può cancellare la prenotazione in qualunque momento e gli slot scompaiono. In questo modo è possibile scalare gli slot verso l'alto o verso il basso secondo necessità. Tipicamente servono quando occorrono più slot per brevi periodi, ad esempio in caso di picchi di utilizzo o quando si esegue un job particolarmente oneroso che rischia di saturare tutti gli slot di una prenotazione. Un esempio classico è quello dei retailer durante il Black Friday o il Cyber Monday, le giornate di shopping più importanti negli Stati Uniti.
Al momento della stesura di questo articolo, 100 slot costano 2.000 USD per un commitment di 1 mese e 1.700 USD al mese per un commitment di 1 anno. Quindi, per eguagliare le performance dell'on-demand, dovrà acquistare venti blocchi da 100 slot, per un totale di 40.000 USD al mese con commitment mensile o di 34.000 USD al mese con commitment annuale. Per questo motivo, in linea generale, non conviene acquistare 2.000 slot a meno che non stia già spendendo almeno questa cifra in costi di scansione BigQuery.
Il piano per analizzare i costi
Prima di poter ottimizzare i costi è necessario analizzare i dati di utilizzo del suo progetto (o dei suoi progetti). Per farlo, dovrà accedere ai dati delle query nei suoi progetti/dataset.
Una breve precisazione per allineare le aspettative: affronto questo argomento in questa prima parte della serie in modo che possa configurare la raccolta e iniziare a registrare i dati di utilizzo, nel caso non riesca a leggere più parti tutte d'un fiato (o in piedi). I frutti di questo lavoro inizieranno a essere effettivamente raccolti a partire dalla parte 3.
Esistono due metodi per farlo: gli audit log sink e le tabelle INFORMATION_SCHEMA.
L'audit log sink è il metodo da preferire, perché i dati sono molto più ricchi e coprono più progetti, dataset e region; tuttavia, se non è già abilitato, ci vorrà del tempo prima che si popoli, man mano che vengono eseguiti job su BigQuery. Tenga presente che l'audit log sink comporta un piccolo costo, sotto forma di costi di storage BigQuery per i dati.
Le viste INFORMATION_SCHEMA, invece, esistono già in ogni dataset, progetto e region, ma, a differenza dell'audit log sink, ogni combinazione di dataset e region ha un proprio set di tabelle, quindi le query potrebbero dover essere eseguite più volte. Tenga inoltre presente che alcune informazioni mancano nelle tabelle INFORMATION_SCHEMA pur essendo presenti in quelle di audit log: alcuni esempi sono documentati come commenti nelle query SQL più avanti nell'articolo, dove non corrisponderanno 1 a 1 con le query dell'audit log sink.
Se opta per il metodo INFORMATION_SCHEMA può saltare la prossima sezione sulla configurazione dell'audit log sink, perché i suoi dati esistono già. C'è però un'avvertenza: i dati raccolti nell'audit log sink sono più ricchi di quelli forniti dalle viste INFORMATION_SCHEMA. Lo svantaggio è che, una volta configurato, il sink inizia a registrare i dati solo da quel momento in poi, quindi sarà necessario eseguire i workloads abituali per un certo periodo prima che i dati siano davvero utilizzabili. La durata di questo periodo dipende molto dai workloads in esecuzione e da ciò che si considera "normale" come frequenza.
Nota: se è già cliente DoiT e utilizza il dashboard BigQuery Lens nella nostra Cloud Management Platform (CMP), l'Audit Log Sink è già configurato nel suo ambiente. Le consiglio di servirsene per le operazioni descritte in questi articoli. Maggiori informazioni sono disponibili qui.
Il nome completo del dataset sarà
In tal caso può saltare la prossima sezione.
Configurare l'Audit Log Sink
Se ha scelto di utilizzare le viste INFORMATION_SCHEMA al posto dell'Audit Log sink, salti questa sezione.
Di seguito le istruzioni per configurare un Audit Log Sink. Le consiglio di eseguire questi comandi sulla sua macchina locale o nel Cloud Shell, con la CLI gcloud configurata per utilizzare il progetto in cui desidera memorizzare il dataset.
Per prima cosa esegua il comando seguente, aggiornando il nome del sink, il project ID e il nome del dataset:
gcloud logging sinks create <Sink Name> bigquery.googleapis.com/projects/<Project ID>/datasets/<Dataset Name> \ — use-partitioned-tables \
— log-filter=’protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata"’
Una volta eseguito, il comando restituirà un service account creato a questo scopo: copi l'indirizzo email completo di tale service account in un appunto.
Il passaggio successivo consiste nell'assegnare al service account appena creato il ruolo BigQuery Editor in ogni progetto che utilizza BigQuery. Come sempre nel cloud, ci sono diversi modi per farlo: di seguito i 3 più comuni, ovvero per singolo progetto, sull'intera organizzazione e su una folder all'interno di un'organizzazione.
Nota: per ottenere l'ID di progetto, folder e organizzazione, può accedere al "project picker" dalla parte alta della console GCP, dove troverà una colonna ID con l'identificativo della risorsa.
Per singolo progetto:
gcloud projects add-iam-policy-binding <Project ID> \
— member=<Service Account> — role=roles/bigquery.dataEditor
Sull'intera organizzazione:
gcloud organizations add-iam-policy-binding <Organization ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
Su una folder:
gcloud resource-manager folders add-iam-policy-binding <Folder ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
A questo punto i dati delle query inizieranno a essere salvati nel dataset specificato sopra. Tenga presente che, per ottenere una buona quantità di dati dopo l'esecuzione, dovrebbe attendere come minimo qualche giorno, o meglio qualche settimana per risultati ottimali. Più a lungo si raccolgono dati dal suo utilizzo abituale, meglio è, perché ciò le permetterà di individuare picchi o pattern ricorrenti.
Viste INFORMATION_SCHEMA
Le viste INFORMATION_SCHEMA esistono già in ogni dataset, progetto e region ma, a differenza dell'audit log sink, ogni combinazione di dataset e region dispone di un proprio set di tabelle, quindi le query potrebbero dover essere eseguite più volte. Le viste INFORMATION_SCHEMA omettono alcune informazioni presenti nelle tabelle di audit log. Alcuni esempi sono documentati come commenti nelle query SQL più avanti nella serie, dove non si allineano in modo preciso alle query dell'audit log sink.
Il vantaggio delle viste INFORMATION_SCHEMA è che i dati sono già disponibili anche se non ha configurato il sink.
Prossimi passi
Si conclude qui la prima parte della serie, che pone le basi per i metodi descritti nelle parti successive.