Suggerimenti per una corretta implementazione di LuckyTemplates

Continueremo la nostra serie sulla pianificazione e l'implementazione dei progetti di LuckyTemplates. Questa volta parleremo di progettazione , profilazione e modalità del set di dati . Dai un'occhiata alla prima parte della nostra serie sulla pianificazione del progetto che si occupa delle modalità di distribuzione e alla seconda parte che parla di rilevamento e ingestione .

Sommario

• Progettazione di set di dati per l'implementazione del progetto LuckyTemplates
  • 4 passaggi per la progettazione di set di dati
  • Seleziona il processo aziendale.
    • L'anti-pattern da evitare nell'implementazione di LuckyTemplates
  • Dichiara il grano.
  • Identifica le dimensioni.
  • Definisci i fatti.
• Matrice del bus dati per l'implementazione del progetto LuckyTemplates
• Profiling dei dati per l'implementazione di LuckyTemplates
  • Servizi di integrazione di SQL Server
  • DAX Studio
  • Desktop di PowerBI
• Pianificazione del set di dati per l'implementazione di LuckyTemplates
  • Scelta di una modalità set di dati
  • Alcune domande da porsi quando si scelgono le modalità del set di dati
• Conclusione

Progettazione di set di dati per l'implementazione del progetto LuckyTemplates

Parliamo del processo di progettazione del set di dati e discutiamo della matrice del bus del data warehouse , che è uno strumento che esiste da un po' di tempo.

La progettazione di set di dati di LuckyTemplates è simile alla progettazione di data warehouse. Quindi sia i set di dati che i data warehouse hanno concetti simili come tabelle dei fatti e delle dimensioni, schemi a stella, dimensioni che cambiano lentamente, granularità delle tabelle dei fatti e chiavi informate locali per costruire relazioni tra le tabelle.

4 passaggi per la progettazione di set di dati

Il processo di progettazione del set di dati prevede quattro passaggi: selezionare il processo aziendale , dichiarare la grana delle tabelle dei fatti, identificare le dimensioni e quindi definire i fatti .

Seleziona il processo aziendale.

Per la prima fase, ogni processo aziendale è rappresentato da una tabella dei fatti con uno schema a stella di relazione molti a uno con le dimensioni.

Durante un processo di rilevamento o di raccolta dei requisiti, è difficile concentrarsi su un singolo processo aziendale isolato, poiché gli utenti analizzano regolarmente più processi aziendali contemporaneamente.

L'anti-pattern da evitare nell'implementazione di LuckyTemplates

L' anti-pattern comune (che è una risposta a un problema ricorrente generalmente inefficace e potenzialmente controproducente) che si desidera evitare nei progetti LuckyTemplates è lo sviluppo di set di dati per progetti o team specifici piuttosto che per i processi aziendali .

Ad esempio, sviluppando un set di dati esclusivamente per il team di marketing e un altro set di dati per l'organizzazione di vendita. Questo approccio porta naturalmente allo spreco di risorse perché gli stessi dati di vendita vengono interrogati e aggiornati due volte in entrambi i set di dati. Questi consumeranno anche risorse di archiviazione nel servizio LuckyTemplates.

questi sono alcuni dei motivi per cui vuoi seguire un buon processo per la progettazione del set di dati. Un approccio isolato porta a problemi di gestione e controllo della versione perché i set di dati possono contenere variazioni e trasformazioni.

Sebbene le esigenze analitiche degli utenti o dei team siano la priorità dei progetti LuckyTemplates, è anche importante pianificare soluzioni sostenibili che possano essere condivise tra i team.

Dichiara il grano.

La grana delle tabelle dei fatti copre in definitiva il livello di dettaglio disponibile per le query analitiche, nonché la quantità di dati a cui è possibile accedere.

Quindi una grana più alta significa più dettagli mentre una grana più bassa significa meno dettagli. Un esempio di questo è quando si desidera ottenere il livello della riga dell'ordine cliente o se si desidera che il progetto contenga solo il livello di riepilogo di ogni ordine cliente e non arrivi ai prodotti specifici che sono stati ordinati come parte di quella vendita.

A volte, questo grano può variare a seconda del periodo di tempo. Mi sono imbattuto in un certo numero di clienti che desiderano tabelle dei fatti molto dettagliate per il trimestre in corso, ma per i trimestri precedenti avevano solo bisogno di sapere qual era il totale delle vendite per il trimestre.

Durante questa fase, si desidera determinare cosa rappresenta ciascuna riga dei diversi processi aziendali . Ad esempio, ogni riga della tabella dei fatti di vendita del nostro data warehouse rappresenta la riga di un ordine di vendita di un cliente.

Al contrario, le righe di un piano di vendita e margine verranno aggregate in un mese di calendario, una sottocategoria di prodotto e una regione del territorio di vendita. quindi in questo caso hai due diverse tabelle dei fatti e due grani diversi. se vuoi confrontare i due, ci sarà del lavoro di modellazione dei dati coinvolto.

Identifica le dimensioni.

Le dimensioni sono solo il sottoprodotto naturale della grana scelta nella precedente fase di progettazione.

Quindi una singola riga campione della tabella dei fatti dovrebbe indicare chiaramente le dimensioni dell'entità aziendale associate a un dato processo, come il cliente che ha acquistato un singolo progetto, il prodotto in una certa data e in un certo momento. Le tabelle dei fatti che rappresentano grani inferiori hanno meno dimensioni.

Ad esempio, una tabella dei fatti che rappresenta il livello di intestazione di un ordine di acquisto può identificare il fornitore, ma non il singolo prodotto acquistato dal fornitore. pertanto, in tal caso, non è necessario includere una categoria di prodotto o una dimensione di sottocategoria di prodotto.

Definisci i fatti.

I fatti rappresentano le colonne numeriche incluse nelle tabelle dei fatti. Pertanto, mentre le colonne delle dimensioni del passaggio 3 vengono utilizzate per le relazioni, le colonne dei fatti vengono utilizzate nelle misure contenenti la logica di aggregazione, ad esempio la somma di una colonna di quantità o la media di una colonna di prezzo.

Matrice del bus dati per l'implementazione del progetto LuckyTemplates

La matrice di bus del data warehouse è un punto fermo dell'architettura del data warehouse di Ralph Kimball, che fornisce un approccio incrementale e integrato alla progettazione del data warehouse.

L'architettura che vedi qui è tratta da The Data Warehouse Toolkit , 3a edizione di Ralph Kimball. Consente modelli di dati scalabili che spesso richiedono più team o funzioni aziendali per accedere agli stessi processi e dimensioni aziendali.

È utile mantenere una matrice di bus del data warehouse in giro. quando lo compili, saprai se ci sono altri set di dati che contengono tabelle dei fatti Internet e tabelle delle dimensioni simili. questo promuove la riusabilità del progetto e migliora la comunicazione del progetto.

Quindi ogni riga riflette un processo aziendale importante e ricorrente come la chiusura mensile della contabilità generale. ogni colonna rappresenta un'entità aziendale, che può essere correlata a uno o più processi aziendali, mentre le righe ombreggiate rappresentano il processo aziendale che viene incluso nel progetto.

Profiling dei dati per l'implementazione di LuckyTemplates

una volta che hai identificato la grana e il processo di progettazione del set di dati in quattro passaggi è stato completato, dovrebbe essere immediatamente seguito da un'analisi tecnica dei dati di origine delle tabelle dei fatti e delle dimensioni .

I metadati tecnici, compresi i diagrammi del database e i risultati della profilazione dei dati, sono essenziali per la fase di pianificazione del progetto.

Queste informazioni vengono utilizzate per garantire che il set di dati di LuckyTemplates rifletta le definizioni aziendali previste e sia basato su una fonte solida e attendibile.

Quindi tre sono tre modi diversi di raccogliere quelle informazioni di profilazione, che dovrebbero essere il primo passo che le persone faranno una volta usciti dal processo di progettazione.

Servizi di integrazione di SQL Server

Ci sono un paio di modi per farlo. Un metodo consiste nell'usare un'attività di profilatura dei dati all'interno di un pacchetto di SQL Server Integration Services (SSIS).

L'attività di profilatura dei dati richiede una connessione ADO.NET e può scrivere l'output in un file XML o in una variabile SSIS.

In questo esempio, i dati di origine ADO.NET sono un data warehouse, un database e un server SQL AdventureWorks e la destinazione è un file XML.

Pertanto, una volta eseguita l'attività, il file XML può essere letto tramite un visualizzatore di profili dati del server SQL. È possibile visualizzare i risultati in termini di conteggio nullo e percentuali di conteggio nullo.

DAX Studio

Un altro modo di profilazione dei dati è tramite DAX Studio. devi effettivamente importare i dati in un set di dati di LuckyTemplates accedendo a DAX Studio, vai alla scheda Avanzate ed esegui VertiPaq Analyzer .

Ti mostrerà lo stesso tipo di informazioni attorno alla cardinalità delle tue colonne in modo da sapere quali occupano più spazio nel tuo modello di dati. include tutte le varie statistiche intorno ai dati.

Desktop di PowerBI

la profilazione dei dati è disponibile anche in Power query all'interno di LuckyTemplates desktop. se vai alla scheda Visualizza , puoi attivare cose come la qualità della colonna, la distribuzione della colonna e il profilo della colonna. Per almeno le prime mille righe circa, puoi visualizzare informazioni come errori, valori nulli, medie e deviazioni standard.

Pianificazione del set di dati per l'implementazione di LuckyTemplates

Dopo che i dati di origine sono stati profilati e valutati rispetto ai requisiti identificati nel processo di progettazione del set di dati in quattro fasi, il team BI può analizzare ulteriormente le opzioni di implementazione per il set di dati.

In quasi tutti i progetti di LuckyTemplates, anche quelli con investimenti significativi in ​​dati aziendali, magazzino, architettura e strumenti e processi ETL, è necessario un certo livello di logica aggiuntiva, integrazione o trasformazione per migliorare la qualità e il valore dei dati di origine.

La fase di pianificazione del set di dati determina il modo in cui vengono affrontati i problemi di trasformazione dei dati identificati per supportare il set di dati. Inoltre, il team di progetto deve determinare se sviluppare un set di dati in modalità di importazione , un set di dati di query diretta o un set di dati composito .

Per chiarire il processo di pianificazione del set di dati, questo diagramma identifica i diversi livelli del data warehouse e del set di dati di LuckyTemplates in cui è possibile implementare la trasformazione e la logica aziendale.

in alcuni progetti è necessaria una trasformazione minima e può essere facilmente inclusa nel set di dati di LuckyTemplates. Ad esempio, se sono necessarie solo poche colonne aggiuntive per una tabella delle dimensioni e sono disponibili indicazioni chiare su come queste colonne verranno calcolate, l'organizzazione IT può scegliere di implementare queste trasformazioni all'interno di M power query piuttosto che rivedere il data warehouse.

Se si lascia che il divario sostanziale tra le esigenze di BI e il data warehouse aziendale persista, i set di dati di LuckyTemplates diventano più complessi da creare e mantenere.

I progettisti di set di dati dovrebbero analizzare e comunicare regolarmente le implicazioni dei set di dati in caso di livelli di complessità maggiori.

Tuttavia, se la logica di trasformazione richiesta è complessa o estesa con più operazioni congiunte, filtri di riga e modifiche al tipo di dati, l'organizzazione IT può scegliere di implementare modifiche essenziali nel data warehouse per supportare il nuovo set di dati e i futuri progetti di BI.

Ad esempio, potrebbe essere necessaria una tabella di staging e una procedura di archiviazione SQL per supportare, rivedere e aggiornare il processo oppure potrebbe essere necessaria la creazione di un indice per migliorare le prestazioni delle query per i set di dati DirectQuery.

Scelta di una modalità set di dati

Un passaggio successivo ma strettamente correlato alla pianificazione del set di dati consiste nella scelta tra la modalità di importazione predefinita, la modalità DirectQuery/live o la modalità composita.

In alcuni progetti, questa è una decisione semplice in cui solo un'opzione è fattibile o realistica dati i requisiti noti, mentre altri progetti comporteranno un'analisi significativa dei pro e dei contro di ciascun progetto.

Pertanto, se un'origine dati è considerata lenta o inadeguata per gestire un volume elevato di query analitiche, è molto probabile che un set di dati in modalità di importazione sia l'opzione preferita.

Allo stesso modo, se la visibilità quasi in tempo reale di un'origine dati è essenziale, DirectQuery o la modalità live sono l'unica opzione per ottenerla. le modalità DirectQuery e live sono molto simili tra loro. Entrambi i metodi non archiviano i dati all'interno del set di dati stesso ed entrambi interrogano direttamente i sistemi di origine per recuperare i dati in base all'azione dell'utente. Ora abbiamo DirectQuery per i set di dati di LuckyTemplates e DirectQuery per Analysis Services.

Alcune domande da porsi quando si scelgono le modalità del set di dati

Di seguito sono riportate alcune domande da porsi quando si decide quale modalità utilizzare. esiste un'unica fonte per il nostro set di dati? Se non è presente un'unica origine, in passato non era possibile utilizzare l'origine DirectQuery/Live.

Anche se ora disponiamo di set di dati in modalità composita, è comunque una buona domanda da porre all'inizio perché se non esiste un'unica fonte, sarà importata o composita.

Se l'origine DirectQuery/Live è un'opzione, l'origine è in grado di supportare query analitiche? Se stai lavorando con miliardi o trilioni di righe, forse un set di dati in modalità di importazione non è fattibile e dovrai passare a DirectQuery o alla modalità composita per assicurarti che il set di dati sia utilizzabile.

Se l'origine DirectQuery/Live è in grado di supportare il carico di lavoro, la connessione DirectQuery/Live è più preziosa delle prestazioni e della flessibilità fornite da un modello di importazione?

Conclusione

Questo post conclude questa serie sulla pianificazione dei progetti LuckyTemplates. questi, penso, siano i passaggi essenziali per ogni progetto di LuckyTemplates su cui lavori. Questi passaggi sono importanti quando si esegue la due diligence, soprattutto in un contesto di business intelligence aziendale.

Ti auguro il meglio,

Greg Decker