Perché mi serve Analysis Services?

Detto che, forse, un titolo ancora più chiaro poteva essere "perchè mi serve un motore analitico per i miei dati?", la risposta più immediata alla domanda potrebbe essere simile a: per avere la possibilità di creare analisi, report e dashboard con dati aggregati e/o calcolati e ottenere risposte, anche (e soprattutto) su volumi molto grandi, in tempi rapidi.

Se dovessi rispondere con quattro punti, senza un ordine specifico, direi che mi serve per avere:

• Velocità di risposta
• Calcoli, misure, gerarchie dei dati
• Sicurezza / permessi / coni di visibilità
• Analisi analitiche (analisi ad-hoc, time intelligence, drill-through, ...)

Entrando più nel merito della domanda, dalla documentazione ufficiale:

Analysis Services is an analytical data engine (Vertipaq) used in decision support and business analytics. It provides enterprise-grade semantic data models for business reports and client applications such as Power BI, Excel, Reporting Services reports, and other data visualization tools.

In altre parole Analysis Services, che sia nella versione:

• SQL Server Analysis Services (on-premise),
• Azure Analysis Services (cloud),
• Power BI o Power Pivot for Excel (che utilizzano, anch’essi, lo stesso identico motore dei prodotti citati poco sopra)

è una tecnologia pensata per poter costruire modelli dati tabulari utili per progettualità di supporto decisionale, business intelligence / business analytics, in sostanza delle soluzioni di tipo Online Analytical Processing (OLAP).

Permette di avere a disposizione una struttura dati creata per:

1. superare i limiti dei database relazionali (che hanno altri scopi e sono pensati per supportare un lavoro transazionale, ad esempio: creo una nuova anagrafica di un cliente, aggiorno i dati di un listino, inserisco una vendita di un prodotto, mantengo lo storico del venduto, gestisco cancellazioni logiche e non fisiche dei dati per poter “tornare indietro”, …)
2. fornire una rapida analisi dei dati
3. essere facilmente espandibile / arricchibile con l'aggiunta di altre tabelle

Proviamo a fare un esempio.

Ho bisogno di avere un report che mi rappresenti il totale delle vendite del mio negozio raggruppato per categoria del prodotto. Poi decido di vedere il solito totale raggruppato per colore del prodotto, oppure per taglia, oppure per fascia di età della clientela, oppure per fascia oraria della vendita, …

In un mondo puramente relazionale, fatto di tabelle, di righe e di colonne (un mondo fatto di due dimensioni), sarebbe certamente possibile rispondere a queste richieste ma, altrettanto certamente, non sarebbe possibile cambiare dimensioni di analisi d’interesse con un click.

Con un database analitico questo è possibile per come è costruito / ingegnerizzato e perché permette di avere, al suo interno, tutte quelle che sono:

• le regole di business necessarie a definire le relazioni tra le entità in gioco. Ad esempio, con quali attributi e con quali relazioni devo legare tra loro le vendite, i prodotti, i clienti, il calendario, …. Tipicamente (ed è la best practice suggerita) viene creato uno schema a stella (star schema) con una tabella dei fatti in relazione con diverse tabelle di dimensione di analisi.
• le colonne calcolate (sostanzialmente colonne il cui valore si basa su qualcosa già presente nel modello). Potrei avere, ad esempio, la necessità di avere nel mio modello dati una nuova colonna del mio calendario con un valore che sia rappresentato come “01- Monday”, “02-Tuesday”, “03-…”, … In questo caso la colonna calcolata potrebbe essere definita con una formula simile a:

=RIGHT(" " & FORMAT([DayNumberOfWeek],"#0"), 2) & " - " & [EnglishDayNameOfWeek]

• le misure calcolate (sostanzialmente un calcolo creato utilizzando il linguaggio che il Tabular fornisce: il DAX) necessarie per supportare al meglio i processi decisionali e di analisi del dato. Potrei aver bisogno di funzionalità di time intelligence (Year-to-date total, Quarter-to-date total, Month-to-date total, Year over year change, …), oppure di running total (simili ai calcoli di YTD ma applicati a qualsiasi attributo, non solo a date). Potrei aver bisogno di calcolare il numero di giorni trascorsi dall’inizio del trimestre a una precisa data che sto analizzando, allora il mio calcolo sarebbe qualcosa come:

=COUNTROWS( DATESBETWEEN( 'Date'[Date], STARTOFQUARTER( LASTDATE('Date'[Date])), ENDOFQUARTER('Date'[Date])))

• le gerarchie (gruppi di colonne ordinati secondo dei livelli) utili per poter effettuare analisi a differenti piani di interesse. Un classico esempio è quello di una tipica gerarchia geografica basata su Nazione – Regione – Provincia – Comune.
• le regole di sicurezza dinamica, per avere una sicurezza a livello di riga (cono di visibilità) in base al nome utente o all'ID di accesso dell'utente attualmente connesso.

Uno dei vantaggi di Analysis Services, al di là di poter sfruttare una tecnologia totalmente in-memory (tutti i dati risiedono in memoria evitando così l’accesso al disco che, in scenari database, può rivelarsi un collo di bottiglia in termini di performance), è il poter avere a disposizione i dati già pre-calcolati risparmiando, in questo modo, i tempi di attesa necessari a un’eventuale computazione.

Questo significa, ad esempio, che se sto analizzando il totale delle vendite, organizzato per categorie merceologiche, fatte all’interno della regione Lazio, non dovrò aspettare un ricalcolo del valore totale del venduto nel momento in cui dovessi scegliere una differente regione, o un differente periodo temporale, o qualsiasi altra dimensione di analisi: il dato è già pronto, sto semplicemente spostando il mio "angolo d'inquadratura", la mia analisi.

In ultima istanza: potrei fare a meno di Analysis Services, in una delle sue forme? Dipende.

Se la mia reportistica è solo di tipo “istituzionale”, qualcosa come schede clienti o di prodotti, tabelle di consumi o di vendite, elenchi, … si potrebbe anche non prendere in considerazione e sfruttare solo un motore dati relazionale. Alla fine, se non è necessario fare analisi analitiche / business intelligence / supporto alle decisioni ci si può ragionare.

Aggiungo due bit della nostra storia, forse utili anche per conoscere la strada fatta da Microsoft per arrivare fino a dove siamo oggi:

• 1996: MS crea un team per costruire un database OLAP (codename Plato) acquisendo la divisione di sviluppo della società isrealiana Panorama Software
• 1998: OLAP Services in SQL Server 7 (codename Sphinx; supporto per OLAP, MOLAP, HOLAP)
• 2000: Analysis Services "dentro" SQL Server 2000 (codename Shiloh per la versione a 32 bit, codename Liberty per la versione a 64 bit)
• 2005: SQL Server 2005 (SQL Server ha codename Yukon ma Analysis Services ha codename Picasso; Unified Dimensional Model, AMO)
• 2008: SQL Server 2008 (codename Katmai; attribute relationships & aggregations)
• 2010: Power Pivot 1.0 (codename Crescent)
• 2012: SQL Server 2012 (codename Denali; Tabular & DAX)
• 2013: Power BI for Office 365 (Power Query, Power Pivot, Power View)
• 2014: SQL Server 2014 (codename Hekaton)
• 2015: Power BI
• 2016: SQL Server 2016
• 2017: SQL Server 2017 (codename Helsinki)
• 2019: SQL Server 2019 (codename Seattle)

Dopo aver ragionato sul non poter fare a meno di Analysis Services, rimane ancora una parte interessante, ovverosia ragionare sulla possibilità offerta oggi dalla versione on-premise di poter scegliere tra due distinti approcci per la modellazione dati: tabulare e multidimensionale (la versione cloud, così come anche Power BI e Power Pivot, lavorano esclusivamente con la versione tabular).

In generale, le differenze tra modelli tabulari e multidimensionali possono essere riassunte come:

• multidimensionale: usa costrutti di modellazione OLAP (cubi e dimensioni) e l'archiviazione MOLAP, ROLAP o HOLAP che usa il disco come archivio per i dati preaggregati
• tabulare: utilizza costrutti di modellazione relazionali (tabelle e relazioni) e il motore di analisi in memoria archivia e calcola i dati (questi modelli sono, per essere in RAM, più veloci rispetto alla controparte multidimensionale)

Approfondirò questi aspetti con un altro post ma, nel frattempo, vi lascio una call-to-action se siete nell'idea (o nella condizione) di voler migrare i vostri modelli multidimensionali da on-premise al cloud: qui. 

I commenti, come sempre, sono aperti.