Come usare ClickHouse per ridurre i costi di BigQuery e Looker - Parte 1

Questa è una serie di articoli divisa in più parti, ciascuna dedicata a una fase logica della configurazione del processo. Trattandosi di un argomento ricco di condizioni "if-then-else" dovute alla complessità dell'ecosistema e della tecnologia, ho preferito suddividere l'articolo in sezioni separate per non appesantire la lettura. La prima parte è dedicata principalmente alla teoria, mentre la seconda si concentrerà su un'implementazione di base.

Tanto per cominciare, per chi non lo conoscesse, ClickHouse è un data warehouse concorrente di BigQuery. Il suo punto di forza è essere un datastore ad altissime prestazioni, capace di eseguire operazioni molto più rapidamente rispetto agli altri data warehouse sul mercato. Questo lo rende ideale per archiviare e servire dati a workloads che lo interrogano in modo costante, come gli strumenti di BI tipo Looker.

L'articolo è stato scritto con l'assistenza tecnica del nostro partner Aiven, fornitore leader di soluzioni DBaaS che propone con orgoglio un servizio ClickHouse gestito. Per completezza, includo anche dettagli su ClickHouse, che a sua volta offre un proprio servizio gestito.

BigQuery è una piattaforma eccellente per analisi su larga scala o per workloads di ML ed è spesso collegata a strumenti di BI come Looker per attività di visualizzazione e reportistica. Purtroppo, le query di questo tipo possono incontrare problemi di performance dovuti a vincoli di risorse, talvolta imposti da ragioni di costo. E poi c'è il grande (e a volte irascibile) elefante nella stanza: il costo per query addebitato da BigQuery.

A questo si aggiungono i recenti aumenti del prezzo per query, che hanno reso BigQuery ancora più oneroso, soprattutto se collegato a uno strumento che esegue interrogazioni continue sui dati. Per questo molti clienti stanno cercando il modo di ridurre i costi dei propri workloads, scoprendo qualcosa che i Customer Reliability Engineers di DoiT International ripetono da anni: gli strumenti di BI sono uno dei principali — se non il principale — voce di costo di BigQuery, e rappresentano uno degli ambiti più importanti su cui intervenire per l'ottimizzazione della spesa.

A Google Next 2023, nella mia presentazione (la registrazione purtroppo è stata rimossa, ma le slide sono ancora disponibili), ho proposto un tema di ottimizzazione dei costi che molti nostri clienti hanno applicato con grande successo: spostare alcuni workloads costosi fuori da BigQuery, in particolare quelli ad alta intensità di calcolo, verso strumenti più economici e più adatti allo scopo.

In linea con quell'idea, in questo articolo propongo un metodo alternativo di presentazione dei dati, utilizzando il data warehouse ClickHouse come livello di "caching e serving" tra BigQuery e gli strumenti di BI come Looker. In questo modo i workloads di reportistica e visualizzazione possono essere spostati da BigQuery a una piattaforma più economica e più performante.

Nota importante: qui utilizzo ClickHouse, ma lo stesso risultato si potrebbe ottenere con altri strumenti e database. Uso ClickHouse perché funziona straordinariamente bene nel servire dati in modo molto rapido agli strumenti di visualizzazione, e perché lo incontro abbastanza spesso da giustificare un articolo dedicato.

Ultimamente, su LinkedIn o su altri siti, potrebbe aver visto parecchie inserzioni che sostengono che ClickHouse è più economico o più veloce di BigQuery. Le menti brillanti dietro quella campagna pubblicitaria stanno facendo leva sui principi cardine del concetto che propongo in questo articolo. I nostri data architect di DoiT International hanno osservato su larga scala come le variazioni di prezzo stiano impattando una vasta fetta di clienti GCP, individuando al contempo modi creativi per aiutarli a risparmiare.

ClickHouse è un data warehouse "simile" a BigQuery, ma con alcune differenze architetturali sostanziali. È costruito su un'architettura più monolitica, incentrata su "moduli" definiti dall'utente che vengono utilizzati al suo interno per aumentarne enormemente le prestazioni. Grazie a questa infrastruttura modulare, può risultare significativamente più performante di BigQuery o di altre soluzioni di data warehousing per molte tipologie di task.

Questa citazione di PostHog riassume bene il concetto:

"La differenza di performance tra BigQuery e ClickHouse può essere enorme. BigQuery può impiegare decine di secondi per eseguire una query. ClickHouse, se ottimizzato correttamente, può eseguire la stessa query su terabyte di dati con prestazioni inferiori al secondo."

"Elementare, mio caro Watson: si tratta di risparmio sui costi" — Sherlock Holmes (con un tocco moderno in chiave cloud)

La risposta è il risparmio sui costi! O, per essere più realistici: il potenziale risparmio sui costi.

Questo accade perché si interroga un data warehouse che non addebita l'utilizzo per query ma applica una tariffa fissa: si possono quindi eseguire tutte le query che le risorse consentono, senza essere fatturati a consumo.

In questo articolo utilizzerò l'offerta di servizio ClickHouse gestito di Aiven come riferimento per i prezzi. È il servizio con cui ho testato i contenuti dell'articolo, e Aiven ha reso molto semplice collegare ClickHouse, e gli altri suoi servizi, all'ambiente GCP.

I piani business di Aiven partono da circa 500 $/mese per il livello startup e da circa 2.000 $/mese per il livello business: sono i punti di prezzo che useremo come riferimento per valutare se questa soluzione è sostenibile per il suo ambiente.

Esistono alcuni punti di pareggio oltre i quali questa soluzione diventa conveniente dal punto di vista dei costi.

Tenga presente che, se spende meno di 500 $/mese per BigQuery o per il suo strumento di visualizzazione, è probabile che questa soluzione non le porti riduzioni di costo; di contro, è molto probabile che le offra notevoli miglioramenti di performance.

Considerando i punti di prezzo di 500 e 2.000 $ di Aiven, parliamo rispettivamente di 1 TiB e 321 TiB (320 TiB + 1 TiB di tier gratuito) di dati elaborati al mese con il modello di prezzo on-demand di BigQuery. Può anche eseguire questa query [1] sul progetto che gestisce i job del suo strumento di BI.

Per un confronto, ClickHouse offre piani con componente di autoscaling e istanze leggermente più grandi a prezzi del tutto comparabili. A seconda del dimensionamento e delle esigenze di sviluppo/produzione, potrebbero rappresentare un'alternativa più economica.

Per BigQuery Editions non esiste un valore univoco che indichi il punto di pareggio, perché Editions usa un autoscaler che funziona di fatto come una scala di prezzo dinamica. Il metodo più semplice è eseguire la query indicata sopra [1] nel progetto interrogato da Looker, così da calcolare i costi approssimativi di Looker.

Una nota su questa query:

Potrebbe dover modificare la regex o sostituirla completamente con il nome del suo service account di Looker per ottenere costi accurati, soprattutto se utilizza un service account Looker non standard o più service account.

Una volta calcolato quel valore, potrà determinare se il prezzo è sopra o sotto le soglie di 500 e 2.000 $ menzionate sopra. Inoltre, se le performance sono un fattore critico, il costo aggiuntivo potrebbe valere la pena pur di non dover aspettare 20 secondi affinché un dashboard di Looker mostri dati in tempo reale.

L'idea è "replicare" i dati tra BigQuery e ClickHouse e collegare poi a ClickHouse tutti gli strumenti di BI ad alto carico di query, o qualsiasi altro strumento che esegua interrogazioni intensive. In teoria, questo elimina i costi per query associati a BigQuery e riduce sensibilmente la spesa, dato che si passa a un asset a prezzo fisso per le proprie query.

Questa soluzione può essere utile anche se servono capacità di interrogazione in tempo reale o molto più rapide, perché ClickHouse, se ottimizzato correttamente, può essere un motore di query MOLTO più performante.

Quando ci si appresta a fare qualcosa che potrebbe far risparmiare molto denaro ci sono sempre dei primi passi da compiere, e questo processo non fa eccezione.

La prima cosa da determinare è quanti dati e quali tabelle vengono utilizzate dal suo strumento di BI su BigQuery. È un'affermazione molto generica e non è un problema banale da risolvere in BigQuery, ma come ho già fatto in passato le metto a disposizione una query d'aiuto[2]. Nota: questa query potrebbe risultare piuttosto costosa, quindi verifichi sempre la stima nella UI di BQ prima di eseguirla.

Il secondo punto della lista è il più articolato dei due e consiste nel fare una discovery sul proprio processo di ingestion. Dovrà capire "come funziona davvero" e analizzare il modo in cui i dati vengono attualmente ingeriti in BigQuery. Il motivo è che andremo a modificare quel processo per "sdoppiare" i dati tra BigQuery e la nuova istanza ClickHouse, in modo che vengano propagati a entrambi.

Per concludere questa prima parte, vorrei dare qualche indicazione sul dimensionamento e sulla creazione dell'istanza ClickHouse che useremo nel resto della serie.

Avendo gestito diverse migrazioni BigQuery -> * (qualche altro sistema di database), mi viene chiesto spesso come scegliere il dimensionamento corretto del database di destinazione. La risposta, purtroppo, è che non esiste davvero un metodo infallibile.

Ho fatto vari tentativi analizzando i dati estratti da BigQuery nelle query, il volume di cache hit e l'uso degli slot, ma la verità è che BigQuery è un sistema così diverso dalla maggior parte degli altri database che non si riesce davvero a costruire un confronto diretto. Da queste prove ho scoperto che si potrebbe fare, ma BigQuery non espone alcune metriche necessarie, come i dati unici interrogati o l'uso di CPU/memoria da parte degli slot.

Detto ciò, questi tentativi mi hanno insegnato una cosa: parta sempre da almeno 8 GB di RAM per un database su cui esegue query di base con regolarità; se invece sta allestendo un vero database di visualizzazione di produzione con più di 10 utenti che eseguono query computazionalmente pesanti durante la giornata, allora 16 GB sono il minimo. Man mano che la complessità delle query aumenta, conviene aggiungere CPU, ma una macchina dual CPU è un buon punto di partenza qualunque sia il workload, dato che la memoria è molto più importante della CPU per la maggior parte delle attività di interrogazione.

Seguendo questa indicazione, partirei con un proof-of-concept su un'istanza molto piccola, come il tier hobbyist di Aiven o l'istanza di sviluppo di ClickHouse, per mettere tutto in piedi e poi crescere da lì, facendo right-sizing in base alle esigenze.

Anziché proporre qui una guida completa che diventerà inevitabilmente obsoleta al cambiare della UI, rimando direttamente alla documentazione di Aiven.

Il primo passo è creare un account Aiven, come descritto qui.

Il secondo passo è creare una VPC Aiven, come descritto qui, e poi configurare il peering con la sua VPC GCP, come descritto qui.

Il passo successivo è creare il servizio ClickHouse, come descritto qui. Potrebbe richiedere qualche minuto, quindi nel frattempo si conceda un caffè o un tè.

Verifichi che funzioni utilizzando il container Docker o lo strumento CLI all'interno della VPC in peering: a quel punto sarà pronto a iniziare a usarlo.

Come sopra, mi limiterò a rimandare alla documentazione del fornitore, perché qualsiasi cosa scriva qui diventerà inevitabilmente obsoleta in futuro.

Ecco la guida quickstart del fornitore su come creare un'istanza.

Consiglio di configurare GCP Private Service Connect verso la sua istanza ClickHouse seguendo questa guida: garantisce il massimo livello di sicurezza e richiede la minima configurazione per utilizzare l'istanza.

Questa parte è stata solo un'introduzione di base a ciò che faremo con questo piano; nella prossima sezione vedremo come portare i dati in ClickHouse e impostare la replica tra ClickHouse e BigQuery.