Modifica

Condividi tramite

Business intelligence aziendale

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Archiviazione BLOB di Azure

Questo scenario di esempio illustra in che modo i dati possono essere inseriti in un ambiente cloud da un data warehouse locale, quindi gestiti usando un modello di Business Intelligence (BI). Questo approccio può essere un obiettivo finale o un primo passo verso la modernizzazione completa con componenti basati sul cloud.

I passaggi seguenti si basano sullo scenario end-to-end di Azure Synapse Analytics. Usa Azure Pipelines per inserire dati da un database SQL in pool SQL di Azure Synapse e quindi trasforma i dati per l'analisi.

Architettura

Diagramma dell'architettura bi aziendale con Azure Synapse.

Scaricare un file di Visio di questa architettura.

Workflow

Origine dati

  • I dati di origine si trovano in un database di SQL Server in Azure. Per simulare l'ambiente locale, gli script di distribuzione per questo scenario effettuano il provisioning di un database SQL di Azure. Il database di esempio AdventureWorks viene usato come schema dei dati di origine e dati di esempio. Per informazioni su come copiare dati da un database locale, consultare la sezione Copiare e trasformare i dati da e verso SQL Server.

Inserimento e archiviazione dei dati

  1. Azure Data Lake Gen2 viene usato come area di staging temporanea durante l'inserimento dati. È quindi possibile usare PolyBase per copiare i dati in un pool SQL dedicato di Azure Synapse.

  2. Azure Synapse Analytics è un sistema distribuito progettato per eseguire analisi su dati di grandi dimensioni. Supporta l'elaborazione parallela su larga scala (MPP), che può essere usata per l'esecuzione di analisi ad alte prestazioni. Il pool SQL dedicato di Azure Synapse è una destinazione per l'inserimento continuo da locale. Può essere usato per un'ulteriore elaborazione e per gestire i dati per Power BI tramite DirectQuery.

  3. Pipeline di Azure viene usato per orchestrare l'inserimento e la trasformazione dei dati all'interno dell'area di lavoro di Azure Synapse.

Analisi e creazione di report

Componenti

Questo scenario usa i componenti seguenti:

Architettura semplificata

Diagramma dell'architettura semplificata di Business Intelligence aziendale.

Dettagli dello scenario

un'organizzazione ha un ampio data warehouse locale archiviato in un database SQL. L'organizzazione vuole usare Azure Synapse per eseguire l'analisi e quindi usare queste informazioni dettagliate con Power BI.

Autenticazione

Microsoft Entra autentica gli utenti che si connettono a dashboard e app di Power BI. L'accesso Single Sign-On viene usato per connettersi all'origine dati nel pool di cui è stato effettuato il provisioning in Azure Synapse. L'autorizzazione viene eseguita nell'origine.

Caricamento incrementale

Quando si esegue un processo ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform) automatizzato, risulta più efficace caricare solo i dati modificati dopo l'esecuzione precedente. Questo viene definito caricamento incrementale, a differenza di un caricamento completo che carica tutti i dati. Per eseguire un caricamento incrementale, è necessario potere identificare i dati modificati. L'approccio più comune consiste nell'usare un valore di tipo limite massimo, ovvero nel tenere traccia del valore più recente di una colonna nella tabella di origine, ad esempio una colonna di tipo data/ora o una colonna con numero intero univoco.

A partire da SQL Server 2016, è possibile usare tabelle temporali, ovvero tabelle con controllo delle versioni di sistema che mantengono una cronologia completa delle modifiche ai dati. Il motore di database registra automaticamente la cronologia di ogni modifica in una tabella di cronologia separata. È possibile eseguire query sui dati cronologici aggiungendo una clausola FOR SYSTEM_TIME a una query. Il motore di database esegue internamente query sulla tabella di cronologia, ma questo processo è trasparente per l'applicazione.

Nota

Per le versioni precedenti di SQL Server è possibile usare Change Data Capture (CDC). Questo approccio risulta meno efficiente rispetto alle tabelle temporali, perché è necessario eseguire query su una tabella di modifiche separata e le modifiche vengono registrate tramite un numero di sequenza di log, invece che un timestamp.

Le tabelle temporali sono utili per i dati relativi alle dimensioni, che possono cambiare nel tempo. Le tabelle dei fatti rappresentano una transazione non modificabile, ad esempio una vendita, e in questo caso la conservazione della cronologia delle versioni di sistema risulta superflua. Le transazioni includono invece in genere una colonna che rappresenta la data della transazione, che può essere usata come valore limite. Ad esempio, nel data warehouse AdventureWorks le tabelle SalesLT.* hanno un campo LastModified.

Di seguito il flusso generale per la pipeline ELT:

  1. Per ogni tabella del database di origine, tenere traccia del valore temporale limite relativo all'esecuzione dell'ultimo processo ELT. Archiviare tali informazioni nel data warehouse. Durante l'installazione iniziale tutti i valori temporali vengono impostati su 1-1-1900.

  2. Durante il passaggio di esportazione dei dati, il valore temporale limite viene passato come parametro a un set di stored procedure nel database di origine. Queste stored procedure eseguono query relative a eventuali record modificati o creati dopo il valore temporale limite. Per tutte le tabelle dell'esempio, è possibile utilizzare la colonna ModifiedDate.

  3. Al termine della migrazione dei dati, aggiornare la tabella in cui sono archiviati i valori temporali limite.

Pipeline di dati

Questo scenario usa il database di esempio AdventureWorks come origine dati. Il modello di caricamento incrementale dei dati viene implementato per assicurarsi di caricare solo i dati modificati o aggiunti dopo l'esecuzione della pipeline più recente.

Strumento di copia dei dati guidata da metadati

Lo strumento di copia basata su metadati predefinito in Pipeline di Azure carica in modo incrementale tutte le tabelle contenute nel database relazionale. Passando all'esperienza basata su procedura guidata, è possibile connettere lo strumento Copia dati al database di origine e configurare il caricamento incrementale o completo per ogni tabella. Lo strumento Copia dati crea quindi sia le pipeline che gli script SQL per generare la tabella di controllo necessaria per archiviare i dati per il processo di caricamento incrementale, ad esempio il valore limite/colonna massimo per ogni tabella. Dopo l'esecuzione di questi script, la pipeline è pronta per caricare tutte le tabelle nel data warehouse di origine nel pool dedicato di Synapse.

Screenshot dello strumento di copia basata sui metadati in Azure Synapse Analytics.

Lo strumento crea tre pipeline per scorrere tutte le tabelle del database, prima di caricare i dati.

Le pipeline generate da questo strumento:

  • Contare il numero di oggetti, ad esempio tabelle, da copiare nell'esecuzione della pipeline.
  • Scorrere ogni oggetto da caricare/copiare e quindi:
    • Controllare se è necessario un carico differenziale; in caso contrario, completare un normale caricamento completo.
    • Recuperare il valore limite massimo dalla tabella dei controlli.
    • Copiare dati dalle tabelle di origine nell'account di staging in Data Lake Storage Gen2.
    • Caricare i dati nel pool SQL dedicato tramite il metodo di copia selezionato, ad esempio PolyBase, Comando Copia.
    • Aggiornare il valore limite massimo nella tabella dei controlli.

Caricare dati in un pool SQL di Azure Synapse

L'attività di copia consente di copiare i dati dal database SQL nel pool SQL di Azure Synapse. In questo esempio, poiché il database SQL si trova in Azure, viene usato il runtime di integrazione di Azure per leggere i dati dal database SQL e scrivere i dati nell'ambiente di gestione temporanea specificato.

L'istruzione copy viene quindi usata per caricare i dati dall'ambiente di gestione temporanea nel pool dedicato di Synapse.

Usare Azure Pipelines

Le pipeline in Azure Synapse vengono usate per definire il set ordinato di attività per completare il modello di carico incrementale. I trigger vengono usati per avviare la pipeline, che può essere attivata manualmente o alla volta specificata.

Trasformazione dei dati

Poiché il database di esempio nell'architettura di riferimento non è di grandi dimensioni, sono state create tabelle replicate senza partizioni. Per i carichi di lavoro di produzione, è probabile che l'uso di tabelle distribuite migliori le prestazioni delle query. Per maggiori informazioni, consultare le Linee guida per la progettazione di tabelle distribuite in Azure Synapse. Gli script di esempio eseguono le query usando un valore classe di risorse statico.

In un ambiente di produzione è consigliabile creare tabelle di staging con distribuzione round robin. Quindi trasformare e spostare i dati nelle tabelle di produzione con indici columnstore cluster, che offrono le migliori prestazioni complessive delle query. Gli indici columnstore sono ottimizzati per query di analisi di record numerosi. Gli indici columnstore non sono ottimali per le ricerche singleton, ovvero per ricerche di una singola riga. Se è necessario eseguire ricerche singleton frequenti, è possibile aggiungere un indice non cluster a una tabella. Le ricerche singleton possono essere eseguite molto più velocemente usando un indice non cluster. Tuttavia, le ricerche singleton sono in genere meno comuni negli scenari di data warehouse rispetto ai carichi di lavoro OLTP. Per maggiori informazioni, consultare la sezione Indicizzazione di tabelle in Azure Synapse.

Nota

Le tabelle columnstore cluster non supportano tipi di dati varchar(max), nvarchar(max), o varbinary(max). In tal caso, prendere in considerazione un indice cluster o heap. È possibile inserire tali colonne in una tabella distinta.

Usare Power BI Premium per accedere, modellare e visualizzare i dati

Power BI Premium supporta diverse opzioni per la connessione alle origini dati in Azure, in particolare il pool di cui è stato effettuato il provisioning in Azure Synapse:

  • Importazione: i dati vengono importati nel modello Power BI.
  • DirectQuery: i dati vengono estratti direttamente dall'archiviazione relazionale.
  • Modello composito: combinare l'importazione per alcune tabelle e DirectQuery per altre.

Questo scenario viene fornito con il dashboard DirectQuery perché la quantità di dati usati e la complessità del modello non sono elevate, quindi è possibile offrire un'esperienza utente ottimale. DirectQuery delega la query al potente motore di calcolo sottostante e usa funzionalità di sicurezza estese nell'origine. DirectQuery assicura anche che i risultati siano sempre coerenti con gli ultimi dati di origine.

La modalità di importazione offre il tempo di risposta alle query più veloce e deve essere considerata quando il modello rientra interamente nella memoria di Power BI, la latenza dei dati tra gli aggiornamenti può essere tollerata e potrebbero esserci alcune trasformazioni complesse tra il sistema di origine e il modello finale. In questo caso, gli utenti finali vogliono accedere completamente ai dati più recenti senza ritardi nell'aggiornamento di Power BI e a tutti i dati cronologici, maggiori di quelli che un set di dati di Power BI può gestire, tra 25 e 400 GB, a seconda delle dimensioni della capacità. Poiché il modello di dati nel pool SQL dedicato è già in uno schema star e non richiede alcuna trasformazione, DirectQuery è una scelta appropriata.

Screenshot della dashboard in Power BI.

Power BI Premium Gen2 consente di gestire modelli di grandi dimensioni, report impaginati, pipeline di distribuzione ed endpoint di Analysis Services predefiniti. È anche possibile avere capacità dedicata con proposta di valore univoco.

Quando il modello di business intelligence aumenta o aumenta la complessità della dashboard, è possibile passare a modelli compositi e iniziare a importare parti di tabelle di ricerca, tramite tabelle ibride e alcuni dati preaggregati. L'abilitazione del caching delle query all'interno di Power BI per i set di dati importati è un'opzione, nonché l'uso di doppie tabelle per la proprietà della modalità di archiviazione.

All'interno del modello composito, i set di dati fungono da livello pass-through virtuale. Quando l'utente interagisce con le visualizzazioni, Power BI genera query SQL nei pool Synapse SQL con doppio spazio di archiviazione: in memoria o query diretta, a seconda di quale sia più efficiente. Il motore decide quando passare dalla memoria alla query diretta ed esegue il push della logica nel pool Synapse SQL. A seconda del contesto delle tabelle di query, possono fungere da modelli compositi memorizzati nella cache (importati) o non memorizzati nella cache. Selezionare e scegliere quale tabella memorizzare nella cache in memoria, combinare i dati da una o più origini DirectQuery e/o combinare dati da una combinazione di origini DirectQuery e dati importati.

Raccomandazioni: quando si usa DirectQuery sul pool di provisioning di Azure Synapse Analytics:

  • Usare il caching dei set di risultati di Azure Synapse per eseguire il caching dei risultati delle query nel database utente per uso ripetitivo, migliorare le prestazioni delle query fino a millisecondi e ridurre l'utilizzo delle risorse di calcolo. Le query che usano set di risultati memorizzati nella cache non usano slot di concorrenza in Azure Synapse Analytics e, pertanto, non vengono prese in considerazione per i limiti di concorrenza esistenti.
  • Usa le viste materializzate di Azure Synapse per pre-calcolare, archiviare e gestire i dati proprio come una tabella. Le query che usano tutti o un sottoinsieme dei dati nelle viste materializzate possono ottenere prestazioni più veloci e non devono fare un riferimento diretto alla vista materializzata definita per usarla.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

I titoli frequenti su violazioni dei dati, infezioni malware e injection di codice dannoso sono solo alcune tra le numerose preoccupazioni relative alla sicurezza per le aziende che desiderano eseguire la migrazione al cloud per la modernizzazione. I clienti aziendali hanno bisogno di una soluzione di servizi o un provider di servizi cloud che possa risolvere le sue preoccupazioni in quanto non può permettersi di sbagliare.

Questo scenario risolve i problemi di sicurezza più impegnativi usando una combinazione di controlli di sicurezza a più livelli: rete, identità, privacy e autorizzazione. La maggior parte dei dati viene archiviata nel pool di provisioning di Azure Synapse, con Power BI tramite DirectQuery tramite Single Sign-On. È possibile usare Microsoft Entra ID per l'autenticazione. Sono inoltre disponibili controlli di sicurezza estesi per l'autorizzazione dei dati dei pool di cui è stato effettuato il provisioning.

Alcune domande comuni sulla sicurezza includono:

  • Come è possibile controllare chi può visualizzare quali dati?
    • Le organizzazioni devono proteggere i dati per rispettare le linee guida federali, locali e aziendali per attenuare i rischi di violazione dei dati. Azure Synapse offre più funzionalità di protezione dei dati per ottenere la conformità.
  • Quali sono le opzioni per verificare l'identità di un utente?
  • Quale tecnologia di sicurezza di rete è possibile usare per proteggere l'integrità, la riservatezza e l'accesso alle reti e ai dati?
    • Per proteggere Azure Synapse, è disponibile una serie di opzioni di sicurezza di rete da considerare.
  • Quali sono gli strumenti che rilevano e notificano le minacce?
    • Azure Synapse offre molte funzionalità di rilevamento delle minacce, ad esempio il controllo SQL, il rilevamento delle minacce SQL e la valutazione delle vulnerabilità per controllare, proteggere e monitorare i database.
  • Cosa è possibile fare per proteggere i dati nell'account di archiviazione?
    • Gli account di archiviazione di Azure sono ideali per carichi di lavoro che richiedono tempi di risposta rapidi e coerenti o che hanno un numero elevato di operazioni di input/output (IOP) al secondo. Gli account di archiviazione contengono tutti gli oggetti dati Archiviazione di Azure e hanno molte opzioni per la sicurezza degli account di archiviazione.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

In questa sezione vengono fornite informazioni sui prezzi per i diversi servizi coinvolti in questa soluzione e vengono menzionate le decisioni prese per questo scenario con un set di dati di esempio.

Azure Synapse

L'architettura serverless di Azure Synapse Analytics consente di dimensionare i livelli di calcolo e archiviazione in modo indipendente. Le risorse di calcolo vengono addebitate in base all'utilizzo ed è possibile dimensionare o sospendere queste risorse su richiesta. Le risorse di archiviazione vengono addebitate per terabyte, pertanto i costi aumenteranno man mano che si inseriscono altri dati.

Azure Pipelines

I dettagli sui prezzi per le pipeline in Azure Synapse sono disponibili nella scheda Integrazione dei dati della pagina Prezzi di Azure Synapse. Esistono tre componenti principali che influenzano il prezzo di una pipeline:

  1. Attività delle pipeline di dati e ore del runtime di integrazione
  2. Dimensioni ed esecuzione dei cluster dei flussi di dati
  3. Addebiti per le operazioni

Il prezzo varia a seconda dei componenti o delle attività, della frequenza e del numero di unità di runtime di integrazione.

Per il set di dati di esempio, il runtime di integrazione ospitato in Azure standard, l'attività di copia dei dati per il nucleo della pipeline, viene attivata in base a una pianificazione giornaliera per tutte le entità (tabelle) nel database di origine. Lo scenario non contiene flussi di dati. Non sono previsti costi operativi perché sono presenti meno di 1 milione di operazioni con pipeline al mese.

Pool e archiviazione dedicati di Azure Synapse

I dettagli sui prezzi per il pool dedicato di Azure Synapse sono disponibili nella scheda Archiviazione dati della pagina Prezzi di Azure Synapse. Nel modello a consumo dedicato, i clienti vengono fatturati per unità data warehouse (DWU) di cui è stato effettuato il provisioning, per ora di tempo di attività. Un altro fattore che contribuisce è costituito dai costi di archiviazione dei dati: dimensioni dei dati inattivi + snapshot e ridondanza geografica, se presenti.

Per il set di dati di esempio, è possibile effettuare il provisioning di 500DWU, che garantisce un'esperienza ottimale per il carico analitico. È possibile mantenere il calcolo operativo durante l'orario lavorativo di creazione di report. Se impiegato in produzione, la capacità riservata del data warehouse è un'opzione interessante per la gestione dei costi. È consigliabile usare tecniche diverse per ottimizzare le metriche relative ai costi/prestazioni, descritte nelle sezioni precedenti.

Archiviazione BLOB

Valutare l'uso della funzionalità di capacità riservata Archiviazione di Azure per ridurre i costi di archiviazione. Con questo modello si ottiene uno sconto se si riserva la capacità di archiviazione fissa per uno o tre anni. Per maggiori informazioni, consultare la sezione Ottimizzazione dei costi per l'archiviazione BLOB con capacità riservata.

In questo scenario non è disponibile alcuna risorsa di archiviazione permanente.

Power BI Premium

I dettagli sui prezzi di Power BI Premium sono disponibili nella pagina Prezzi di Power BI.

Questo scenario usa le aree di lavoro di Power BI Premium con una serie di miglioramenti delle prestazioni integrati per soddisfare esigenze analitiche impegnative.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Raccomandazioni di DevOps

  • Creare gruppi di risorse separati per gli ambienti di produzione, sviluppo e test. L'uso di gruppi di risorse separati semplifica la gestione delle distribuzioni, l'eliminazione delle distribuzioni di test e l'assegnazione dei diritti di accesso.

  • Inserire ogni carico di lavoro in un modello di distribuzione separato e archiviare le risorse nei sistemi di controllo del codice sorgente. È possibile distribuire i modelli insieme o separatamente come parte di un processo di integrazione e consegna continuo CI/CD, rendendo il processo di automazione più semplice. In questa architettura sono disponibili quattro carichi di lavoro principali:

    • Il server del data warehouse e le risorse correlate
    • Pipeline di Azure Synapse
    • Asset di Power BI: dashboard, app, set di dati
    • Scenario simulato da locale a cloud

    Mirare a avere un modello di distribuzione separato per ognuno dei carichi di lavoro.

  • Prendi in considerazione la possibilità di staging dei carichi di lavoro laddove possibile. Eseguire la distribuzione in varie fasi ed eseguire controlli di convalida in ogni fase prima di passare alla fase successiva. In questo modo, è possibile eseguire il push degli aggiornamenti negli ambienti di produzione in modo controllato e ridurre al minimo i problemi di distribuzione imprevisti. Usare le strategie di distribuzione blu-verde e canary per aggiornare gli ambienti di produzione live.

  • Avere una buona strategia di rollback per la gestione delle distribuzioni non riuscite. Ad esempio, è possibile ridistribuire automaticamente una distribuzione precedente con esito positivo dalla cronologia della distribuzione. Vedere il flag --rollback-on-error in CLI di Azure.

  • Monitoraggio di Azure è l'opzione consigliata per analizzare le prestazioni del data warehouse e l'intera piattaforma di analisi di Azure per un'esperienza di monitoraggio integrata. Azure Synapse Analytics offre una ricca esperienza di monitoraggio nel portale di Azure per scoprire informazioni dettagliate sul carico di lavoro del data warehouse. Il portale di Azure è lo strumento consigliato per il monitoraggio del data warehouse, in quanto fornisce periodi di conservazione, avvisi, raccomandazioni, grafici personalizzabili, nonché dashboard di metriche e log configurabili.

Avvio rapido

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

Questa sezione fornisce informazioni dettagliate sulle decisioni di dimensionamento per supportare questo set di dati.

Pool di cui è stato effettuato il provisioning in Azure Synapse

È disponibile una serie di configurazioni del data warehouse tra cui scegliere.

Unità di data warehouse N. di nodi di calcolo N. di distribuzioni per nodo
DW100c 1 60
-- TO --
DW30000c 60 1

Per ottenere vantaggi della scalabilità orizzontale in termini di prestazioni, in particolare per le unità di warehouse dati di dimensioni maggiori, usare un set di dati di almeno 1 TB. Per trovare la quantità di unità di data warehouse più adatta per il pool SQL dedicato in uso, provare ad aumentarne e a ridurne il numero. Dopo il caricamento dei dati, eseguire alcune query con numeri di unità di data warehouse diversi. Poiché il ridimensionamento è rapido, è possibile provare diversi livelli di prestazioni in un'ora o meno.

Trovare il numero migliore di unità data warehouse

Per un pool SQL dedicato in fase di sviluppo, iniziare selezionando un numero minore di unità di data warehouse. Un buon punto di partenza è DW400c o DW200c. Monitorare le prestazioni dell'applicazione, osservando il numero di unità di data warehouse selezionato rispetto alle prestazioni ottenute. Presupporre una scalabilità lineare e determinare quanto è necessario aumentare o ridurre le unità di data warehouse. Continuare ad apportare modifiche finché non si raggiunge un livello di prestazioni ottimale per i propri requisiti aziendali.

Ridimensionamento del pool SYNapse SQL

Azure Pipelines

Per le funzionalità di scalabilità e ottimizzazione delle prestazioni delle pipeline in Azure Synapse e l'attività di copia usata, consultare la Guida alle prestazioni e alla scalabilità dell'attività Copy.

Power BI Premium

Questo articolo usa Power BI Premium Gen 2 per illustrare le funzionalità di BI. Gli SKU di capacità per Power BI Premium sono attualmente compresi tra P1 (otto v-core) e P5 (128 v-core). Il modo migliore per selezionare la capacità necessaria consiste nell'eseguire la valutazione del caricamento della capacità, installare l'app metriche di seconda generazione per il monitoraggio continuo e valutare l'uso della scalabilità automatica con Power BI Premium.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi