Stare al passo con le best practice di ottimizzazione dei costi di BigQuery è impegnativo: e se uno strumento le dicesse semplicemente cosa fare?
I costi di BigQuery continuano a salire: e adesso?
Certo, può scavare negli audit log alla ricerca di indizi, oppure leggere le BigQuery Best Practices di Google Cloud per capire meglio cosa si potrebbe ottimizzare.
Ma con un arretrato di altri progetti e mille emergenze da gestire, lei o il suo team potete davvero permettervi di dedicarci il tempo necessario? Per la nostra esperienza, nella maggior parte dei casi la risposta è un sonoro "No".
Quasi tutte le aziende con cui collaboriamo hanno semplicemente troppe attività di prodotto a priorità più alta e risorse di engineering troppo limitate per affrontare l'ottimizzazione dei costi di BigQuery. Di conseguenza, molte costruiscono la propria infrastruttura dati in BigQuery a tentoni, ritrovandosi poi a fare i conti con le conseguenze di quelle scelte.
E se invece avesse uno strumento che le dicesse semplicemente cosa fare?
È proprio per questo che abbiamo realizzato BigQuery Lens: fornisce raccomandazioni personalizzate, basate sulle best practice di BigQuery e sulla nostra esperienza al fianco di migliaia di clienti che ottimizzano l'uso di BigQuery.
Vediamo insieme alcune best practice di BigQuery e come metterle in pratica con BigQuery Lens.
"Grazie alle raccomandazioni di BigQuery Lens, abbiamo investito tempo nel partizionamento delle nostre tabelle chiave e siamo riusciti a ridurre la spesa per BigQuery del 25% al mese."
- Daniel Rimon, Head of Data Engineering, Resident
Come BigQuery Lens la aiuta a ottimizzare i costi
BigQuery Lens analizza i job BigQuery e i metadati delle tabelle e produce raccomandazioni di ottimizzazione concrete, con la possibilità di approfondire le statistiche di utilizzo del team.
Certo, può passare ore immerso negli audit log e nelle query, provando a costruire dashboard con Cloud Monitoring o interrogando INFORMATION_SCHEMA.JOBS, ma da queste fonti escono solo metriche di alto livello. Le conclusioni su cosa fare dovrà comunque trarle da solo.
BigQuery Lens rende semplice mettere in pratica le best practice.
Nello specifico, le sue raccomandazioni sono pensate per aiutarla a:
- Ridurre la quantità di dati scansionati grazie al clustering o al partizionamento delle tabelle
- Ridurre i costi dei job pianificati
- Sfruttare il flat-rate pricing quando ha senso
- Abbattere i costi di storage rimuovendo le tabelle inutilizzate
- Far rispettare l'uso dei campi di partizionamento nelle query
- Ridistribuire i job ricorrenti per ridurre il numero di slot da acquistare
Ridurre i byte processati con clustering e partizionamento delle tabelle
Sia che interroghi un progetto in on-demand o flat-rate pricing, ridurre il numero di byte processati dalle query porta benefici sia sui costi sia sulle performance. Per i progetti in on-demand riduce direttamente i costi di analisi. Il flat-rate è invece fisso in base agli slot acquistati, ma ridurre i byte processati aiuta indirettamente ad abbattere i costi perché diminuisce l'utilizzo medio di slot. Questo, a sua volta, riduce il numero di slot che dovrà acquistare (i dettagli più avanti).
Un buon punto di partenza è proprio il clustering e/o il partizionamento delle tabelle.
Clustering delle tabelle (e come massimizzarne i benefici)
Il clustering migliora le performance delle query organizzando la tabella in blocchi di dati in base alla colonna (o alle colonne) di clustering scelte. In questo modo BigQuery può scansionare solo i blocchi rilevanti, a patto di strutturare le query nel modo corretto.
Il vantaggio che otterrà dal clustering, però, dipende da quali colonne sceglie, in quale ordine le imposta e da come strutturate le query sulle tabelle clusterizzate.
Conviene clusterizzare le tabelle in base alle colonne interrogate più di frequente, soprattutto quando contengono molti valori distinti. In questo scenario, BigQuery interroga le tabelle in modo più efficiente sfruttando l'ordine delle colonne definito dalla strategia di clustering.
Come si vede nel diagramma qui sotto, è altrettanto importante strutturare le query rispettando l'ordine dei campi di clustering scelti (cioè filtrare i campi nello stesso ordine del clustering). Solo così potrà sfruttare al massimo, nei suoi job BigQuery, la strategia di clustering impostata sulle tabelle.
BigQuery Lens individua le tabelle da clusterizzare e indica quali colonne usare e in quale ordine. Le basta cliccare sul nome della tabella nella finestra delle raccomandazioni per aprirla nella Google Cloud Console e procedere al clustering della tabella.
Vale anche la pena confrontare le query precedenti sulla tabella in questione con i job che esegue dopo il clustering. Con ogni probabilità noterà miglioramenti sia sui costi sia sui tempi di esecuzione dei job su quella tabella.
Partizionamento delle tabelle (e perché conviene)
Il partizionamento delle tabelle aiuta a tenere sotto controllo i costi suddividendo una grande tabella in porzioni più piccole. In particolare, sfruttando il partition pruning — filtrando partizioni specifiche nelle query così da non scansionare l'intera tabella — il partizionamento è davvero efficace.
Inoltre, consente di gestire i dati a un livello più granulare. Si possono impostare scadenze su singole partizioni o gestire in modo più efficiente l'ingresso di nuovi dati grazie alle partizioni delle tabelle BigQuery.
Come per le tabelle clusterizzate, per beneficiare del partizionamento la query deve usare un filtro qualificante sul valore della colonna di partizionamento.
Nota: BigQuery Lens individua anche le query su tabelle partizionate che potrebbero usare un filtro qualificante ma non lo fanno (vedi "Far rispettare i campi di partizionamento nelle query" più avanti).
Come per la raccomandazione sul clustering, BigQuery Lens segnala anche quali tabelle partizionare e su quale campo. È utile in generale, ma se ha dashboard BI alimentate da BigQuery, introdurre il partizionamento può rendere le dashboard più veloci e le query meno costose.
Quando clusterizzare E partizionare una tabella
In alcune circostanze può essere utile adottare una strategia che combini sia partizionamento sia clustering sulle tabelle BigQuery.
Questa strategia è particolarmente indicata quando si vuole un ordinamento molto fine all'interno delle tabelle (vedi diagramma qui sotto), avendo al tempo stesso più visibilità sui costi probabili delle query prima dell'esecuzione, grazie alle capacità di partition pruning di BigQuery.
Va però considerato che combinare le due strategie significa mantenere più metadati per le tabelle, e i benefici del clustering rischiano di non concretizzarsi se le tabelle non vengono interrogate spesso sui campi comuni. In quel caso, i vantaggi di questa specifica strategia di strutturazione delle tabelle BigQuery verrebbero meno.
Passare al flat-rate pricing
Man mano che l'uso di BigQuery e i volumi di dati crescono, può arrivare il momento in cui conviene passare dal modello on-demand al flat-rate.
Quando BigQuery Lens rileva che così facendo si possono ridurre i costi, mostra una raccomandazione di slot commitment. Nell'esempio qui sotto, BigQuery Lens indica che il nostro utilizzo medio massimo giornaliero è di 169 slot e quindi consiglia di prenotarne 200, dato che gli acquisti vanno fatti a incrementi di 100 slot. Notiamo anche un picco di utilizzo molto più alto, pari a 2.238 slot.
Nota: le BigQuery reservations e il modello on-demand non si escludono a vicenda. È possibile passare dall'uno all'altro tramite BigQuery Reservations e includere anche i Flex Slot.
Poiché gli slot prevedono un commitment minimo di un mese, in caso di incertezza sull'attività futura delle query, su picchi estremi o sulla stagionalità nell'uso di BigQuery, conviene fare molta attenzione all'acquisto. È qui che entrano in gioco i Flex Slot: permettono di acquistare slot per periodi brevi, anche di soli 60 secondi.
Ad esempio, se esegue tutti i job di load/report alle 3 del mattino, può scalare facilmente verso l'alto e verso il basso pianificando il provisioning e deprovisioning dei Flex Slot con Cloud Composer. Per evitare situazioni in cui la domanda superi gli slot disponibili, un nostro cliente usa addirittura Cloud Functions per controllare ogni cinque minuti se l'utilizzo degli slot supera il 90% del proprio commitment, eseguendo in automatico il provisioning di Flex Slot per evitarlo.
Ridurre la frequenza dei job pianificati e di altri job ricorrenti
Potrebbe avere job pianificati che non hanno bisogno di girare con la frequenza attuale, o che addirittura non andrebbero più eseguiti. BigQuery Lens evidenzia i job eseguiti con frequenza elevata e mostra il risparmio potenziale che otterrebbe riducendone la frequenza di esecuzione del 10-50%.
Questa raccomandazione facilita un dialogo più consapevole sul cost management tra lei e il suo team e garantisce che i job particolarmente costosi vengano eseguiti solo quando serve davvero.
Ad esempio, un cliente ha individuato diversi job che non avevano bisogno di essere eseguiti così di frequente. Ha sollevato il tema con il team allargato per ridurre la frequenza, calcolando di poter risparmiare il 10-15% sui costi delle query con una lieve riduzione del numero di esecuzioni.
Un altro cliente ha individuato query pianificate ormai obsolete. Prima di adottare BigQuery Lens, non aveva visibilità su questo aspetto. Il mese successivo all'eliminazione delle query pianificate non necessarie, la spesa per BigQuery - Analysis è scesa di oltre il 50%.
Infine, se queste query ricorrenti sono generate da una dashboard BI (per esempio Looker), può ridurre i costi facendole passare attraverso BI Engine. BI Engine è perfetto per le query delle dashboard perché mantiene in memoria i dati BigQuery in modo intelligente, rendendo le query più rapide. Poiché BI Engine memorizza i dati in-memory, lo stage di query che legge i dati delle tabelle è gratuito: si paga soltanto la capacità di memoria riservata. Tuttavia, se il progetto usa il flat-rate pricing, gli stage successivi attingono agli slot della BigQuery reservation.
Risparmiare sui costi di storage facendo backup e rimuovendo le tabelle inutilizzate
Le query non sono l'unica voce su cui può risparmiare: in BigQuery si paga anche lo storage! Le tabelle inutilizzate rappresentano, secondo la nostra esperienza, un'opportunità sottovalutata per ridurre la spesa BigQuery.
BigQuery Lens evidenzia le tabelle (e le partizioni, dove esistono) rimaste inutilizzate negli ultimi 30 giorni. Può ridurre i costi di storage facendo il backup di queste tabelle su Cloud Storage e poi rimuovendole da BigQuery (oppure modificando le impostazioni di scadenza delle tabelle).
Di recente un cliente ha usato questa raccomandazione per portare alla luce diverse tabelle con dati di oltre 3 anni che non venivano più interrogate. Dopo averle salvate in backup e rimosse, i costi BigQuery sono scesi di circa il 30%.
Far rispettare i campi di partizionamento nelle query
Partizionare le tabelle è solo metà del lavoro. Dopo il partizionamento, occorre assicurarsi che le tabelle vengano interrogate in modo efficace, utilizzando il campo su cui sono partizionate. Questo dà più controllo sui costi, perché si scansionano solo porzioni della tabella anziché l'intera tabella.
Quando però si gestisce un team di data analyst, è difficile sapere se tutti includano davvero il campo di partizionamento nelle proprie query. BigQuery Lens individua i job che interrogano tabelle partizionate senza sfruttarne il campo di partizionamento.
Ridurre i costi del flat-rate ridistribuendo i job ricorrenti
Pensi all'ottimizzazione dei costi flat-rate come a una partita a Tetris. L'obiettivo è stabilizzare l'utilizzo e avere "blocchi" piatti di consumo orario di slot.
Tipicamente, però, l'utilizzo medio orario degli slot presenta picchi e cali (vedi grafico qui sotto). E il rischio è di basare le decisioni di acquisto degli slot su questo utilizzo discontinuo, spendendo più del necessario.
Per ridurre i costi flat-rate, individui i job ricorrenti che cadono nelle ore di picco e li sposti, se possibile, nelle ore in cui l'utilizzo medio è basso, oppure preveda dei Flex Slot per gestire il carico in eccesso.
Così facendo si appiattiscono i picchi, ottenendo un consumo di slot più basso e costante. Di conseguenza, dovrà acquistare meno slot e ridurre nel lungo periodo i costi flat-rate.
BigQuery Lens mostra le query eseguite più di 30 volte al mese sui progetti in flat-rate pricing, indicando l'ora di esecuzione e il numero di slot consumati.
Può poi cercare le query eseguite nelle ore di picco e capire se è possibile spostarle nelle fasce di minore utilizzo. Prendendo a esempio il grafico qui sopra, dovrebbe cercare le query eseguite alle 4 del mattino o alle 16 e spostarle, se possibile, alle 7 o alle 20.
Come ottenere BigQuery Lens
Come per qualsiasi servizio in public cloud, se non si presta attenzione all'uso di BigQuery i costi possono crescere in fretta. E poiché BigQuery è il cuore della strategia dati di molte aziende, non ci stupisce che sia costantemente uno degli argomenti più ricorrenti nei ticket dei nostri clienti.
Per questo è fondamentale ottimizzare costantemente costi e performance. Ed è altrettanto cruciale capire come BigQuery viene utilizzato dal team, perché non si può ottimizzare ciò che non si conosce. BigQuery Lens la aiuta proprio in questo.
Se non è ancora cliente DoiT e desidera accedere a BigQuery Lens e ai nostri esperti BigQuery, ci contatti.
Se è già cliente DoiT, le consigliamo di attivare BigQuery Lens, se non l'ha già fatto.