Da tempo esistono due dataset pubblici poco discussi: i campioni di query reali rilasciati da Snowflake e da Redshift. Fivetran li ha incrociati e ne ha ricavato un ritratto del workload tipico di un data warehouse cloud. Il risultato è meno glamour di quanto racconti il marketing di categoria.
Primo dato: secondo l’analisi, il cliente Snowflake medio spende circa 300.000 dollari all’anno sulla piattaforma, e il 90% di quella spesa è generato da query. Che query sono? Non quelle dell’analista che interroga l’intero patrimonio dati aziendale, a giudicare dai numeri. La realtà misurata è diversa: la stragrande maggioranza del lavoro ricade in ingestion e transformation. Read — dashboard di business intelligence e data science — ed export sono quote minoritarie; il resto è manutenzione di sistema. Detta senza giri di parole, il warehouse è usato soprattutto come ETL tool.
La taglia reale delle query
Secondo dato, più scomodo per chi vende scalabilità. Considerando le query che leggono almeno 1 MB, la mediana ne scansiona circa 100 MB e il 99,9° percentile si ferma intorno ai 300 GB. Vale a dire che il 99,9% del traffico reale girerebbe su un singolo nodo di dimensioni generose. I benchmark da 100 TB pubblicati dai vendor descrivono un caso d’uso che quasi nessuno esercita davvero. A supporto, l’analisi è stata fatta con DuckDB: gli 11 GB del campione Snowflake si scansionano in pochi secondi su un desktop.
Il massively parallel processing resta elegante quando il problema è esprimibile in SQL. Smette di esserlo appena serve qualcosa che SQL non copre, per esempio addestrare un modello con scikit-learn: a quel punto i dati vanno esportati fuori dal warehouse verso un nodo singolo, con costi e complessità aggiuntivi.
Cosa cambia con il data lake
Da qui la tesi dell’articolo: separare lo storage in un formato aperto su object storage, con un catalog che gestisce transazioni e permessi, permette di far convivere engine specializzati sugli stessi dati invece di piegare ogni workload ai vincoli dell’MPP. Come esempi già operativi la fonte cita il data lake writer di Fivetran e il motore BI di Power BI; l’ingest sarebbe talmente efficiente da essere incluso senza costo aggiuntivo per i clienti data lake, dichiarazione di parte da leggere come tale.
Per chi lavora sullo stack l’implicazione operativa è banale ma spesso ignorata: prima di dimensionare cluster e scegliere il tier di compute conviene misurare la distribuzione reale dei byte scansionati. Se il grosso della spesa sta in pipeline di ingestion e modelli di transformation ricorrenti, l’ottimizzazione va cercata lì (schedulazione, incrementalità, strategie di merge) e non nella capacità di reggere query da centinaia di terabyte. Sul compute locale la fonte indica una soglia esplicita: sotto i 100 MB scansionati, scaricare i dati ed eseguire la query in locale ha probabilmente più senso.
In sintesi
- Sui campioni pubblici di Snowflake e Redshift, ingestion e transformation dominano il workload: il warehouse funziona di fatto come ETL tool.
- Query mediana intorno ai 100 MB scansionati, 99,9° percentile intorno ai 300 GB: quasi tutto il traffico reale starebbe su un nodo singolo.
- La direzione proposta è il data lake con catalog condiviso ed engine specializzati; l’argomento tecnico regge, ma arriva da un vendor che vende ingestion.
Hai qualcosa da aggiungere? Unisciti alla discussione.