Modellazione Semantica Avanzata
L'architettura del modello dati è il fondamento su cui poggia l'intera efficienza del motore VertiPaq. In questa sezione analizziamo come la scelta tra Star, Snowflake e Galaxy influenzi direttamente la compressione colonnare e la propagazione dei filtri.
Benchmark: Latenza Query vs Schema
Valori indicativi basati su dataset enterprise >100M righe.
Star Schema (Ottimale)
Massima compressione VertiPaq e join minimi. La propagazione del filtro è lineare.
Snowflake Schema
Aumenta la normalizzazione ma introduce latenza per join sequenziali complessi.
Galaxy Schema
Gestione di processi multipli con dimensioni conformate. Complessità DAX elevata.
Seleziona uno schema per i dettagli
Analizza l'impatto tecnico delle diverse scelte architetturali sul motore in-memory.
Meccanismi Computazionali DAX
Il cuore della logica analitica risiede nella comprensione della Transizione di Contesto. Questa sezione esplora come le espressioni vengono valutate tra contesti di riga e filtri, e come ottimizzare le metriche semi-additive.
Logica di Transizione di Contesto
Processo: Row Context → CALCULATE → Filter Context
Riga Corrente (Valori v1, v2...)
→
Intersezione Filtri (Ci = vi)
La transizione di contesto converte un contesto di riga in un filtro equivalente. È fondamentale ricordare che questo processo avviene su tutta la tabella espansa.
Metriche Semi-Additive (Last Date with Data)
Balance_LastDateWithData :=
VAR MaxBalanceDate =
CALCULATE (
MAX ( Balances[Date] ),
ALLEXCEPT ( Balances, 'Date' )
)
RETURN
CALCULATE (
SUM ( Balances[Balance] ),
'Date'[Date] = MaxBalanceDate
)
Ottimizzazione: Identifica l'ultimo stato noto del sistema evitando valori vuoti alla fine del periodo.
⚠️ Warning: Sideways Recursion
Nei Gruppi di Calcolo, evitare riferimenti ricorsivi tra elementi dello stesso gruppo. Questo può causare loop infiniti nel Formula Engine.
Pro-Tip: Storage Engine
Preferisci COUNTROWS a COUNT. Opera sui metadati della tabella senza scansionare i singoli valori, riducendo l'uso del Formula Engine (FE).
Diagnostica & Performance Tuning
Monitorare i tempi di rendering non è sufficiente. Bisogna scomporre la latenza tra DAX Query, Visual Display e tempi tecnici per isolare i colli di bottiglia nel modello semantico.
Landing Page
< 2s
Target Benchmark
Detail Page
< 5s
Target Benchmark
Visual Rendering
< 8s
Maximum Threshold
Max Visuals
8-10
Per Page (Consigliati)
Analisi Scomposizione Query (Performance Analyzer)
Ottimizzazione Query Folding
1
Filtri & Trasformazioni SQL (Folding OK)
2
Logica M Complessa (Folding Interrotto)
3
Elaborazione locale Mashup Engine
Utilizzo di Table.Buffer
La bufferizzazione forza la materializzazione in RAM. Utile per:
- Preservare l'ordinamento prima di
Table.Distinct
- Ridurre chiamate ripetute a piccole tabelle di lookup
- Isolamento controllato dal query folding
⚠️ Evitare su tabelle con milioni di righe: rischio saturazione memoria.
Enterprise Governance & Microsoft Fabric
In un ecosistema moderno, la governance si sposta verso il Direct Lake di Microsoft Fabric e l'automazione CI/CD tramite deployment pipelines.
Workflow Deployment Pipelines
L'Autobinding mappa automaticamente il report al modello semantico della fase corrispondente, garantendo l'integrità dei dati tra ambienti.
Architettura Direct Lake
Vantaggio: VertiPaq legge direttamente file Delta Parquet da OneLake (Framing).
V-Order
Ottimizzazione fisica Spark per lettura intensiva Power BI.
No Import
Elimina i refresh pesanti del dataset.
Analisi del Fallback (DirectQuery)
Il fallback a DirectQuery distrugge le performance in-memory. Identifica le cause critiche:
-
01
Uso di Viste SQL
Direct Lake richiede solo tabelle fisiche Delta Parquet.
-
02
RLS a livello SQL
La sicurezza deve essere gestita nel modello semantico, non nell'endpoint SQL.
-
03
Limiti SKU Superati
Superamento delle soglie di memoria o dimensioni file nella capacità Fabric.
Strumento Diagnostico
Utilizza SQL Server Profiler per intercettare gli eventi DirectQuery Begin e confermare il fallback.