Le Multi-Dataset Relationships di Amazon QuickSight spostano l’approccio dell’analisi da “appiattisci tutto prima” a “modella una volta, combina al momento della query”. Invece di preparare un unico dataset denormalizzato, si mantiene ogni tabella come dataset separato, si dichiarano le relazioni in un Topic e QuickSight assembla gli inner join on demand tra visual, calcoli, filtri e Chat. Per chi costruisce dashboard su volumi di dati che cambiano a velocità diverse, questo riduce il lavoro di ETL a monte e apre la strada a modelli riutilizzabili.
La seconda parte della serie AWS passa dai concetti ai pattern concreti, documentando sette scenari nativi con struttura delle tabelle, casi d’uso, passi di implementazione e query SQL di esempio.
I sette pattern supportati
Si parte dallo star schema, il pattern consigliato, con una fact table centrale collegata a più dimension table tramite join single-hop. Segue lo snowflake schema, che normalizza le dimensioni in catene multi-livello: AWS suggerisce di pre-unire le catene in un’unica dimensione flat, a meno che la tabella non superi il milione di righe. Il galaxy schema condivide dimensioni conformi tra più fact table, ad esempio per confrontare vendite e resi. Ci sono poi le role-playing dimensions (una stessa tabella DATE_DIM usata come data ordine, spedizione e consegna) e il caso multi-fact a grana diversa, in cui i runtime join aggregano automaticamente la fact più fine fino alla grana più grossa.
Gli ultimi due scenari riguardano le capacità operative: gli schedule di refresh indipendenti per ogni dataset di un Topic e la row-level security applicata a runtime. Un dettaglio rilevante: la RLS viene applicata prima del join, quindi gli utenti vedono l’intersezione delle righe consentite in ciascun dataset, un modello più restrittivo del filtro post-join.
Workaround e limiti
Alcuni pattern non sono nativi ma si risolvono nel livello di preparazione dei dati: i join circolari vanno spezzati con la denormalizzazione, le gerarchie ricorsive vanno appiattite in una view con colonne di livello esplicite, le gerarchie ragged si gestiscono ripetendo il valore del genitore. Restano invece alcuni vincoli dell’attuale release da tenere presenti in fase di progettazione.
- Sono supportati solo gli inner join: le righe senza chiave corrispondente vengono escluse e non sono ammessi outer join né self-relationship.
- Il grafo delle relazioni deve essere aciclico e un Topic non può superare i 12 dataset.
- Tutti i dataset di un Topic devono usare la stessa modalità (SPICE o Direct Query); il Direct Query supporta solo Amazon Redshift, Athena, S3 Tables, Snowflake e Databricks.
Fonte: Data modeling patterns for Amazon QuickSight multi-dataset relationships — https://aws.amazon.com/blogs/machine-learning/data-modeling-patterns-for-amazon-quick-sight-multi-dataset-relationships/
Hai qualcosa da aggiungere? Unisciti alla discussione.