Partizioni nei modelli tabulari

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Le partizioni dividono parti di dati che devono essere elaborati (aggiornati) di frequente dai dati che possono invece essere elaborati meno frequentemente. Ad esempio, una tabella dei fatti può includere determinati set di righe che contengono dati che raramente cambiano, ma altri set di righe hanno dati che cambiano spesso. Non è necessario elaborare tutti i dati quando è necessario elaborare solo una parte di esso.

Le partizioni funzionano dividendo una tabella in oggetti di partizione logica. Le singole partizioni, ognuna contenente un segmento univoco di dati, possono quindi essere elaborate in modo incrementale in ordine sequenziale o in parallelo indipendentemente da altre partizioni, oppure escluse completamente dalle operazioni di elaborazione.

Granularità

Per impostazione predefinita, ogni tabella in un modello ha una singola partizione. In molti casi, ad esempio con tabelle dei fatti, la divisione della singola partizione di una tabella in più partizioni può usare meglio le risorse disponibili per l'elaborazione.

Una strategia efficace per la progettazione e l'elaborazione dei modelli usa le partizioni per eliminare il carico del processore e il consumo di memoria non necessari, rendendo allo stesso tempo certi che i dati vengano aggiornati abbastanza spesso per riflettere i dati più recenti dalle origini dati. Ad esempio, un modello tabulare può avere una tabella Sales che include i dati sulle vendite per l'anno fiscale corrente e ognuno degli anni fiscali precedenti. La tabella Sales del modello include le partizioni seguenti:

Partition	Periodo dei dati
Sales2020	Anno fiscale corrente
Sales2019-2010	Anni fiscali 2010, 2011, 2012, 2013, 2014, 2015. 2016, 2017, 2018, 2019
SalesOld	Tutti gli anni fiscali precedenti agli ultimi dieci anni.

Man mano che vengono aggiunti nuovi dati di vendita per l'anno fiscale corrente 2020, i dati devono essere elaborati quotidianamente per essere riflessi in modo accurato nell'analisi dei dati delle vendite dell'anno fiscale corrente, pertanto la partizione Sales2020 viene elaborata ogni notte.

Non è necessario elaborare i dati nella partizione Sales2019-2010 in modo notturno. Tuttavia, poiché i dati sulle vendite per i dieci anni fiscali precedenti possono comunque cambiare a causa di restituzioni del prodotto e altre modifiche, è comunque necessario elaborare regolarmente i dati nella partizione Sales2019-2010. I dati nella partizione SalesOld cambiano raramente, pertanto vengono elaborati solo ogni anno.

Quando si immette l'anno fiscale 2021, viene aggiunta una nuova partizione Sales2021 alla tabella Sales del modello. La partizione Sales2020 può quindi essere unita alla partizione Sales2019-2010 e rinominata Sales2020-2011. I dati dell'anno fiscale 2010 vengono eliminati dalla partizione Sales2020-2011 e spostati nella partizione SalesOld. Tutte le partizioni vengono quindi elaborate per riflettere le modifiche. Questo è comunemente noto come modello di finestra in sequenza : i dati in ogni partizione si trovano all'interno di un intervallo di date predefinito e incrementato in base alle esigenze, mantenendo la memoria e l'uso delle risorse di elaborazione all'interno di un intervallo prevedibile nel tempo.

La granularità è influenzata da vari fattori, tra cui la quantità di dati necessaria per l'elaborazione incrementale entro un periodo di tempo accettabile. Ad esempio, se solo l'ultimo giorno deve essere elaborato ogni giorno, può essere utile usare la granularità giornaliera. La granularità mista può essere configurata per scenari come l'aggiornamento quasi in tempo reale a bassa granularità associato a partizioni storiche e statiche con granularità superiore. Ciò comporta un minor numero di partizioni, ma aumenta anche il sovraccarico di gestione per garantire che gli intervalli di partizioni siano definiti correttamente.

Il partizionamento è efficace anche per le tabelle contenenti dati da più di un'origine dati. Origini dati diverse possono aggiornare i dati in momenti diversi, che possono determinare requisiti di granularità e elaborazione diversi per i dati della tabella del modello. Ad esempio, una tabella Orders in un modello contiene transazioni di ordine da due diverse tabelle dei fatti, factInternetOrders e factRetailOrders. Nell'origine dati, factInternetOrders viene aggiornato ogni ora. factRetailOrders invece viene aggiornato solo una volta al giorno dopo la chiusura di tutti i negozi al dettaglio. Creando partizioni separate in granularità diverse nella tabella Ordini modello per i dati importati da factInternetOrders e factRetailOrders, le operazioni di elaborazione nella tabella Orders possono essere separate ed eseguite più inline con i dati dell'ordine nelle origini dati.

Ogni scenario è univoco. Assicurarsi di definire una granularità per il modello di dati che divide in modo più efficace i dati in partizioni che devono essere elaborati spesso rispetto a quelli che non lo fanno.

Limiti della partizione

Indipendentemente dalla piattaforma, non esiste alcun limite rigido per il numero di oggetti di partizione in un modello. Tuttavia, ogni partizione ha almeno un segmento di dati con un footprint di memoria. Troppe partizioni di piccole dimensioni possono causare troppi segmenti di piccole dimensioni. Le prestazioni delle query possono essere influenzate negativamente quando il motore di archiviazione deve analizzare un numero eccessivo di segmenti. Anche la velocità delle operazioni sui metadati su troppe partizioni può influire negativamente sulle risorse di elaborazione.

Creare il numero minimo di partizioni pur soddisfando in modo efficace gli obiettivi di partizionamento. È più importante concentrarsi su una strategia di partizionamento efficace in base alla granularità e l'elaborazione solo di queste partizioni con i dati di modifica più rilevanti all'interno delle risorse di elaborazione e memoria disponibili in momenti in cui le query utente sono basse.

Non esiste anche alcun limite alla quantità di dati in una partizione. Sebbene improbabile, un modello potrebbe avere una singola tabella con una singola partizione predefinita e tale tabella potrebbe contenere tutti i dati nel modello. La quantità di dati nella partizione sarebbe limitata solo dalle risorse di memoria disponibili per il piano di servizio o l'hardware.

Creazione e gestione di partizioni

Quando si creano modelli con progettazione modelli tabulari in Visual Studio, è possibile creare nuove partizioni, modificare, unire o eliminare partizioni nel database dell'area di lavoro modello usando Partition Manager. A seconda del livello di compatibilità del modello creato, Partition Manager offre due modalità per la selezione dei dati da includere in una partizione: per i modelli tabulari 1400 e versioni successive con origini dati strutturate, le partizioni vengono definite usando un'espressione M Power Query. Ad esempio, la query seguente definisce una partizione per l'anno di calendario 2019:

let
    Source = #"SQL/sqlserver database windows net;Contoso",
    dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
    #"Filtered Rows"

Per le origini dati del provider, le partizioni vengono definite usando una query SQL. Ad esempio,

SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))

Si noti l'argomento Righe filtrate nell'espressione M Power Query e la clausola WHERE nell'istruzione SQL definiscono esattamente un anno di calendario usando operatori maggiori di (), minori di (><) e uguali (=). Quando si definiscono partizioni, è importante che ogni query di ogni partizione definisca un intervallo univoco di dati che non può causare la duplicazione dei dati con altre partizioni.

SQL Server Management Studio (SSMS)

Dopo aver distribuito il modello, le partizioni vengono visualizzate come oggetti in SQL Server Management Studio (SSMS). Creare, modificare, unire ed eliminare partizioni per un modello distribuito usando la finestra di dialogo Partizioni in SSMS, eseguendo uno script TMSL (Tabular Model Scripting Language) o a livello di codice usando il modello a oggetti tabulari (TOM).

Tabular Model Scripting Language (TMSL)

Le partizioni per un modello sono definite nell'oggetto Partitions. Nell'esempio seguente la partizione Sales2019 è definita come:

"partition": {
      "name": "Sales2019",
      "mode": "import",
      "source": {
        "type": "m",
        "expression": [
          "let",
          "    Source = #\"SQL/sqlserver database windows net;Contoso\",",
          "    dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
          "in",
          "    #\"Filtered Rows\""
        ]
      },

Le azioni sull'oggetto Partitions possono essere specificate nei comandi TMSL seguenti:

• Creare
• CreateOrReplace
• Modificare
• Elimina
• MergePartitions
• Aggiorna

Gli script TMSL possono essere eseguiti in SQL Server Management Studio, con PowerShell eseguendo il comando Invoke-ASCmd o tramite un'attività script SSIS (SQLServer Integration Services).

Per i modelli a 1100 e 1103 livelli di compatibilità, analysis Services Scripting Language (ASSL) viene usato invece se TMSL.

Modello a oggetti tabulare

Nel modello a oggetti tabulari le partizioni sono definite da una classe Partition nello spazio dei nomi Microsoft.AnalysisServices.Tabulare. Per altre informazioni sulle soluzioni a livello di codice che usano TOM come API, vedere Creare tabelle, partizioni e colonne (TOM) estrategie di partizionamento avanzate più avanti in questo articolo.

Per i modelli a 1100 e 1103 livelli di compatibilità, usare Gli oggetti di gestione analisi (AMO).

Elaborazione di partizioni

Quando i dati della tabella vengono partizionati, tali partizioni possono quindi essere elaborate alla volta e la cadenza appropriate per la soluzione. Quando viene eseguita un'operazione di elaborazione (aggiornamento), viene eseguita una connessione all'origine dati usando la connessione all'origine dati. Analysis Services usa le query specificate per ogni partizione per eseguire query sull'origine dati. I dati nuovi e aggiornati vengono caricati nelle tabelle del modello, le relazioni e le gerarchie vengono ricompilati e le colonne calcolate vengono calcolate nuovamente.

Quando si creano modelli in Visual Studio, è possibile eseguire manualmente operazioni di processo nelle partizioni del database dell'area di lavoro dal menu o dalla barra degli strumenti. Per i modelli distribuiti, le operazioni di elaborazione vengono richiamate manualmente usando la finestra di dialogo Tabelle di elaborazione in SSMS, eseguendo uno script che include il comando Aggiorna (TMSL) o a livello di codice usando il modello a oggetti tabulare (TOM).

Elaborazione parallela

Analysis Services usa l'elaborazione parallela per due o più partizioni, aumentando le prestazioni di elaborazione. Per l'elaborazione parallela non sono previste impostazioni di configurazione. L'elaborazione parallela si verifica per impostazione predefinita quando si elabora tabella o si selezionano più partizioni per la stessa tabella e processo. Esistono tuttavia impostazioni che limitano le operazioni di elaborazione parallele.

MaxConnections

Per impostazione predefinita, ogni operazione di elaborazione si connetterà a e eseguirà una query su un'origine dati per ogni partizione. Il numero massimo predefinito di connessioni, specificato come proprietà MaxConnections in un'unica origine dati è 10. Analysis Services determina il numero di operazioni di elaborazione simultanee da eseguire in base al numero di core e thread disponibili. Questi thread vengono condivisi nell'istanza del server. Un singolo comando come il processo potrebbe non ricevere tutti i thread disponibili. I thread che avviano per l'elaborazione, uno per ogni operazione di elaborazione parallela, possono essere ritardati per rimanere entro il limite MaxConnections.

MaxParallelism

Per impostazione predefinita, le operazioni di elaborazione vengono eseguite in parallelo il più possibile. È tuttavia possibile scegliere di elaborare le partizioni in sequenza o in parallelo specificando l'opzione della proprietà maxParallism con il comando Sequence (TMSL). L'impostazione del valore su 1 significa non parallela: viene usato un thread per l'elaborazione. Se si imposta il valore su 2 o più, è possibile usare un numero fisso di thread per le operazioni di elaborazione parallele.

Monitoraggio

Per determinare l'uso efficace dei thread disponibili durante le operazioni di processo, per Azure Analysis Services, usare Esplora metriche di Azure per monitorare CommandPoolIdleThreads e CommandPoolBusyThreads. Per altre informazioni, vedere Monitorare le metriche dei server. Per SQL Server Analysis Services, usare Monitor prestazioni per monitorare i thread non I/O del pool di elaborazione non inattivo e i thread non I/O occupati nel pool di elaborazione. Per altre informazioni, vedere Contatori delle prestazioni (SSAS).

Nota

Se viene rilevata nuovamente la codifica, l'elaborazione parallela può causare un aumento dell'uso delle risorse. Ciò avviee perché è necessario interrompere e riavviare più operazioni di partizione con la nuova codifica in parallelo.

Strategie avanzate di partizionamento

L'articolo Gestione partizione automatizzata per i modelli tabulari di Analysis Services .pdf, insieme all'esempio di codice AsPartitionProcessing in GitHub fornisce informazioni approfondite e un esempio di soluzione per la società fittizia, Advenure Works, usando il modello a oggetti tabulari (TOM) per creare e gestire partizioni. Concetti descritti in questo articolo e progetto si applicano a tutte le piattaforme di Analysis Services.

Vedi anche

Creare e gestire partizioni di modelli tabulari
Oggetto Partitions (TMSL)
Creare tabelle, partizioni e colonne con il modello a oggetti tabulare (TOM)
Creare partizioni (lezione esercitazione)