Condividi tramite

Impostazioni di SQL Warehouse per carichi di lavoro BI

I carichi di lavoro di Business Intelligence hanno caratteristiche distinte che richiedono considerazioni specifiche sulla configurazione di SQL Warehouse. Questa pagina fornisce indicazioni sull'analisi dei requisiti del carico di lavoro BI e sulla configurazione dei warehouse SQL per offrire prestazioni ottimali, efficienza dei costi e affidabilità.

Requisiti per l'analisi del carico di lavoro e il contratto di servizio

Ognuno il carico di lavoro BI è univoco e richiede un'attenta analisi prima di essere configurata. Quando si valutano i requisiti, tenere presenti le domande seguenti:

  • Migrazione o nuova implementazione: Questo carico di lavoro viene migrato da una piattaforma diversa o è una nuova implementazione? I carichi di lavoro migrati potrebbero avere stabilito contratti di servizio e linee di base delle prestazioni.
  • Contratti di servizio:Service Level Agreement (SLA): Quali sono i requisiti di latenza, velocità effettiva e disponibilità? Documentare SLA tecnici e aziendali.
  • Modelli di accesso: Come interagiscono gli utenti con i dati? La comprensione dei modelli di query tipici consente di ridimensionare correttamente la configurazione del warehouse e ottimizzare il livello dati per il carico di lavoro specifico.

Modelli tipici di accesso BI

I carichi di lavoro BI in genere rientrano in due categorie di criteri di accesso distinti, ognuna che richiede configurazioni di SQL Warehouse diverse.

Modello DirectQuery/LiveQuery

I modelli DirectQuery eseguono query sui dati in tempo reale e richiedono risposte a bassa latenza per l'analisi interattiva:

Caratteristiche:

  • Numero elevato di query
  • Le query restituiscono in genere set di risultati di piccole dimensioni (minori di 1.000 record)
  • In genere eseguito durante l'orario di ufficio
  • Requisiti rigorosi del contratto di servizio con aspettative di bassa latenza
  • Modelli di query imprevedibili (dashboard, report)
  • I dati a cui si accede per query sono in genere inferiori a 5 GB
  • Richiede una capacità di calcolo altamente scalabile per supportare andamenti irregolari

Aspettative sulle prestazioni:

  • Tempo di risposta delle query: secondi (in genere meno di 5 secondi per i dashboard interattivi)
  • Aggiornamento dei dati: aggiornato, che riflette i dati più recenti

Profilo del carico di lavoro:

  • Picchi frequenti durante l'orario lavorativo
  • Variazioni di carico imprevedibili (guidate dall'utente)
  • Può estendersi a 24x7 per le organizzazioni globali

Modello di importazione/estrazione

I modelli di importazione estraggono i dati per i sistemi downstream, assegnando priorità alla velocità effettiva rispetto alla latenza:

Caratteristiche:

  • Basso numero di query (aggiornamenti pianificati)
  • Set di risultati di dimensioni considerevoli (più di 1.000.000 record)
  • In genere pianificato durante le ore di minore attività
  • Modelli di query prevedibili (spesso basati sul drill-down)
  • Dati a cui si accede per query: fino a decine di GB

Aspettative sulle prestazioni:

  • Tempo di risposta alle query: da minuti a ore (orientato al batch)
  • Aggiornamento dei dati: snapshot del giorno o giorno precedente

Profilo del carico di lavoro:

  • Finestre di esecuzione pianificate e prevedibili
  • Caratteristiche del carico di lavoro note e requisiti delle risorse
  • Elaborazione orientata a batch

Combinazione di query nei carichi di lavoro DirectQuery

Quando si usano modelli DirectQuery con un modello di dati dello schema star, si prevede la distribuzione di query seguente:

  • Query su dimensioni: Molte piccole query che analizzano le tabelle di dimensioni (cliente, prodotto, tempo)
  • Query sulle tabelle dei fatti: Molte query di grandi dimensioni che analizzano le tabelle dei fatti con join e aggregazioni
  • Estrarre query: Alcune query semplici ma con esecuzione prolungata per l'estrazione di dati di grandi dimensioni

Questa combinazione di query varia richiede warehouse SQL in grado di gestire in modo efficiente sia query di piccole dimensioni che query analitiche di grandi dimensioni contemporaneamente.

Strategia multi-warehouse per l'isolamento del carico di lavoro

Databricks consiglia di effettuare il provisioning di più magazzini SQL per raggiungere:

Dimensionamento corretto e costi ottimali

  • Ridimensionare ogni magazzino in modo appropriato per il modello di carico di lavoro specifico
  • Evitare il over-provisioning separando i carichi di lavoro con requisiti di risorse diversi
  • Usare magazzini più piccoli per lo sviluppo e il test, più grandi per la produzione
  • Usare la scalabilità del magazzino per trovare l'equilibrio ideale tra prestazioni e costi

Prestazioni complessive migliori

  • Impedire conflitti di risorse tra DirectQuery e Modelli di importazione/estrazione
  • Isolare i dashboard interattivi dalle operazioni di aggiornamento batch
  • Abilitare la scalabilità indipendente in base alle esigenze del carico di lavoro

Addebito incrociato e allocazione dei costi

  • Tenere traccia dell'utilizzo e dei costi per business unit, progetto o team
  • Abilitare modelli di chargeback accurati
  • Migliorare la visibilità e la responsabilità dei costi

Amministrazione e gestione più efficienti

  • Assegnare responsabilità di proprietà e gestione in base al team o al progetto
  • Applicare criteri di arresto automatico diversi in base ai modelli di utilizzo
  • Configurare controlli di accesso e monitoraggio separati

Per carichi di lavoro DirectQuery/LiveQuery

  • Usare archivi SQL serverless per una gestione automatizzata delle risorse
  • Configurare l'arresto automatico aggressivo (15-30 minuti) per l'ottimizzazione dei costi
  • Impostare le dimensioni del cluster in base alla complessità delle query e al volume di dati (iniziare con Media, aumentare le prestazioni se necessario)
  • Impostare il numero minimo e massimo di cluster in base al carico di lavoro previsto
  • Monitorare la metrica Peak Queued Queries e regolare di conseguenza il numero massimo di cluster

Per i carichi di lavoro di importazione/estrazione

  • Usare i warehouse SQL pro o classici per processi pianificati e prevedibili
  • Configurare tempi di arresto automatico più lunghi (1-2 ore) se più processi vengono eseguiti in sequenza
  • Usare dimensioni del cluster maggiori (Large, X-Large) per aggregazioni complesse
  • Prendere in considerazione la pianificazione fissa per allinearsi alle finestre batch
  • Monitorare la durata delle query e regolare il dimensionamento in base ai requisiti del contratto di servizio

Per altre informazioni sul comportamento di ridimensionamento e ridimensionamento di SQL Warehouse, vedere Comportamento di ridimensionamento, ridimensionamento e accodamento di SQL Warehouse.

Per un rapido riferimento sulle best practice di servizio BI, vedere lo schema riassuntivo per il servizio BI.

  • Last updated on